Problemas resolvidos. Decisões explicadas.

Contexto

O OpenTibiaBR Canary é um grande runtime de servidor online em C++/Lua cuja inicialização percorre scripts, dados do mapa, caches de tiles, configuração de spawns e registros de runtime.

Problema

A inicialização tinha caminhos críticos caros que atrasavam a iteração e a subida operacional do servidor.

Solução

Otimizei o carregamento Lua, o parsing do mapa, a construção do cache de tiles, a indexação de zonas e a inicialização de spawns sem alterar o comportamento esperado do runtime.

Impacto

O carregamento de scripts e módulos caiu de cerca de 54 segundos para aproximadamente 1,5–3,0 segundos nas medições públicas do PR.

TecnologiasC++ · Lua · análise de desempenho · runtime de servidor

Contexto

Um runtime de servidor C++ de longa duração precisa manter entradas e movimentos visíveis ao jogador responsivos enquanto processa pathfinding, seleção de alvos, preparação de combate, manutenção e trabalhos assíncronos caros em segundo plano.

Problema

Filas amplas do dispatcher permitiam que grandes cargas em segundo plano competissem com tarefas sensíveis a latência. Tarefas assíncronas repetidas, decisões obsoletas, custo de ownership e fanout ilimitado também reduziam a justiça e o uso de múltiplos núcleos.

Solução

Introduzi agendamento consciente de filas, orçamentos adaptativos de runtime, computação multinúcleo limitada, snapshots imutáveis de navegação, promoção baseada em visibilidade, coalescência, telemetria de filas e validação rigorosa de conclusões obsoletas.

Impacto

Melhorei o comportamento do runtime e a responsividade percebida pelos jogadores sob cargas intensas de monstros. A arquitetura passou por 264 testes unitários e de regressão e foi validada em campo em vários servidores OT, enquanto o retorno operacional mais amplo continua sendo coletado.

TecnologiasC++ · concorrência · round robin ponderado por déficit · filas limitadas · snapshots imutáveis · telemetria de runtime

Contexto

Um runtime cliente/servidor C++ precisava atender às famílias de clientes modernos 15.x, protocolo antigo 11.00 e compatíveis 8.60 sem binários ou portas separados nem verificações frágeis de versão espalhadas pela pilha de protocolo.

Problema

As famílias de clientes diferem no enquadramento TCP, checksums, layout de criptografia, compactação, handshake, payloads de login, assinaturas de assets, mapeamento de itens e campos de mensagens específicos por versão.

Solução

Implementei codecs de transporte, comportamento da conexão inicial, perfis de protocolo em runtime, indicações de sessão, contratos de payload condicionados por versão, testes de compatibilidade, perfis de exportação de assets legados e empacotamento coordenado de releases do cliente.

Impacto

Três famílias de clientes compartilham agora um runtime C++ e um modelo de implantação validados em campo, sem exigir portas ou builds de servidor separados por versão.

TecnologiasC++ · enquadramento TCP · XTEA · checksums · compactação · perfis de protocolo · feature flags · testes unitários

Contexto

Alguns fluxos C++ com gerenciadores de pacotes e builds cruzados usam um protoc do host, enquanto os pacotes de destino precisam apenas de protobuf::libprotobuf-lite.

Problema

O pacote do Protobuf para o destino ainda podia pagar o custo de build e instalação do runtime completo e de artefatos do compilador que o grafo de dependências do destino não utilizava.

Solução

Implementei no upstream do Protobuf o suporte CMake a um build limitado do runtime lite e contribuí com a alteração do port vcpkg que torna libprotoc opcional em builds para destinos não nativos.

Impacto

A alteração no Protobuf foi integrada via Copybara no commit público 7c090172. A PoC local mediu a queda da etapa de build de 508,063s para 55,648s e do espaço instalado de 113.754 KB para 21.579 KB.

TecnologiasCMake · vcpkg · Protocol Buffers · gerenciamento de pacotes · builds cruzados

Contexto

Fluxos de market, inbox e salvamento offline precisam de invariantes fortes para itens e persistência. Pequenos erros podem duplicar ou perder itens e sobrescrever progresso válido do jogador.

Problema

Inboxes cheios, divisão de stacks, inserções parciais, clonagem do market e salvamentos parciais de jogadores offline tinham casos extremos nos quais a ordem das mutações podia corromper o estado.

Solução

Fortaleci os caminhos de inserção do inbox e do market com verificações de capacidade, clonagem e inserção mais seguras, helpers de inserção em lote e proteções no salvamento offline.

Impacto

Reduzi o risco de itens duplicados ou fantasmas, perda de itens e regressões de progresso nos fluxos de economia e persistência.

TecnologiasC++ · persistência SQL · contêineres de inventário · segurança de dados · testes

Contexto

Um grande runtime C++/Lua carrega perfis de conteúdo mutuamente exclusivos com scripts Lua, registros XML, definições de itens em Protobuf, storages, actions, movements, weapons, spells, monstros e NPCs.

Problema

Definições entre perfis podiam satisfazer umas às outras incorretamente, expressões Lua dinâmicas podiam ser confundidas com referências autoritativas, intervalos XML inválidos podiam ser ignorados silenciosamente pelo runtime e varreduras ingênuas do repositório inteiro produziam resultados ruidosos ou inseguros.

Solução

Construí um auditor determinístico e consciente de perfis que produz registros tipados de símbolos, relatórios de referências, cobertura de itens não resolvidos, fingerprints estáveis, anotações de CI e artefatos JSON/Markdown validados por schemas incluídos.

Impacto

Analisei 39.311 fatos em dois perfis de runtime, corrigi oito erros bloqueantes de conteúdo, reduzi os achados de storage de 1.225 para 405 ao remover falsos positivos e concluí 72 testes sem erros restantes na varredura.

TecnologiasPython · análise Lua · XML · Protocol Buffers · JSON Schema · análise estática · GitHub Actions

Contexto

A entrega do cliente precisava atender a conjuntos de assets modernos e legados, módulos por servidor, downloads públicos do launcher, visibilidade de catálogo, monitoramento operacional e metadados versionados de atualização sem expor detalhes privados de implementação.

Problema

A distribuição para parceiros não era um problema de download único. Diferentes servidores e versões de cliente exigiam árvores de assets, conjuntos de módulos, objetivos de inicialização, cadência de atualização, seleção de arquivos, integridade de catálogo, notícias, monitoramento e regras de entrega isolados por um ponto público controlado.

Solução

Integrei automação de assets no cliente, fluxos de entrega por launcher/API, arquivos associados à versão, validação de catálogo, carregamento de assets e módulos por servidor, regras de parceiros, monitoramento administrativo, APIs de notícias, metadados assinados e suporte a releases.

Impacto

Oferece a jogadores e operadores um caminho controlado de download e atualização, evitando pacotes de versão incorreta, corrigindo 11 colisões de spritesheets e preservando a separação entre pacotes por servidor e operações confidenciais de parceiros.

TecnologiasC++ · Lua · Go · entrega de assets · integridade de catálogo · launcher/API · operação de releases · monitoramento

Contexto

O Remere's Map Editor é uma ferramenta desktop C++ de longa duração usada para inspecionar, editar, carregar, salvar, renderizar e exportar grandes conjuntos de dados de mapas e assets do cliente.

Problema

Fluxos com mapas grandes tinham custos excessivos de alocação, travessia, E/S binária, salvamento, invalidação de repintura e exportação de assets gerados.

Solução

Adicionei alocação em pool, cache de buscas de floors e tiles, melhorias em E/S binária, travessia otimizada no salvamento, redução de repinturas desnecessárias e suporte à exportação de assets de mapas grandes.

Impacto

As métricas públicas dos PRs registram a queda das recargas de slabs de 17.830 para 2.230, da parcela de CPU de alocação de 20,01% para 14,62% e da CPU amostrada em uma viewport estática de 139.767 para 126.

TecnologiasC++ · trabalho no alocador · E/S binária · renderização · Protocol Buffers