Wasteland Frontier
Servidor · C# e TypeScript
Projeto em fase de fundação, com decisões estruturais definidas antes do gameplay.
- Documentos de arquitetura
- 15 numerados
- Experimentos técnicos planejados
- 4
- Verificações automáticas de qualidade
- 6
- Código de gameplay
- nenhum
decisão explícita, não atraso
Fonte verificada no repositório interno em 08/09/2026
O que faz
Em uso
A premissa é incomum para o meio: construir uma plataforma de jogo própria sobre o runtime do RedM, com domínio separado da infraestrutura. A divisão de linguagem é a decisão que carrega o resto — C# é o jogo, TypeScript é a experiência, Lua é exceção com justificativa técnica registrada.
A fase de decisões estruturais foi fechada antes de qualquer mecânica existir: registros de decisão, esqueleto do monorepo, verificações automáticas de qualidade e o plano dos experimentos que ainda precisam provar as premissas.
O mundo do jogo tem uma regra de desenho que também é uma restrição de engenharia: tudo é físico. Não existe banco mágico nem saldo abstrato — riqueza pode ser roubada, perdida na morte ou esquecida num baú.
Evidência
Como o sistema aparece
Capturas da interface real, renderizada com payload de demonstração derivado dos contratos do resource — organizações, cargos, pessoas e identificadores são sintéticos. Onde não existe interface, entra visualização técnica, rotulada como tal.
Visualização técnica As cinco camadas, e a fronteira que permite testar regra de jogo sem abrir o jogo.
Arquitetura
Arquitetura e responsabilidades
Camada por camada, com o motivo de cada escolha ao lado dela.
Casca
Resources em C#
Conhece o runtime, não decide nada.
Domínio
C# puro, sem dependência da plataforma
Roda no executor de testes do .NET.
Plataforma
Dados, eventos, natives e runtime
A única camada que fala com o jogo.
Interface
TypeScript
Interface em jogo, painel administrativo, site público e ferramentas de balanceamento.
Plano de controle
Serviço .NET separado
Observa. Nunca é gargalo.
Por dentro da engenharia
Decisões de implementação
Um bloco por decisão de implementação. Abra o que interessa.
Domínio que roda sem o jogo
Problema
Regra de jogo escrita dentro do resource só pode ser testada subindo o servidor e entrando nele. Isso encarece justamente o que mais precisa de verificação: economia, progressão e balanceamento.
Solução
Três camadas com fronteira dura. A casca é fina, conhece o runtime e não decide nada. O domínio é puro, não importa nada da plataforma e roda no executor de testes do .NET. A camada de plataforma reúne dados, eventos, natives e runtime.
Por que foi feito assim
Uma regra de balanceamento vira teste de unidade em vez de sessão em jogo. O ciclo de verificação cai de minutos para segundos, e a regra passa a ser verificável por outra pessoa.
O plano de controle observa e nunca é gargalo
Problema
Painel administrativo, telemetria e site público costumam compartilhar o caminho do jogo. Quando um relatório pesado roda, quem paga a conta é o jogador.
Solução
O banco do jogo é acessado direto, sem intermediário, e o plano de controle é um serviço separado que observa. A regra está escrita na arquitetura: ele nunca entra no caminho crítico.
Por que foi feito assim
Separar leitura administrativa do caminho de jogo é a diferença entre um relatório lento e um servidor travado.
Provar o runtime antes de construir em cima dele
Problema
A premissa mais arriscada do projeto é também a mais fácil de adiar: C# de fato roda bem no runtime do RedM? Descobrir que não, com gameplay pronto em cima, custa o projeto inteiro.
Solução
A premissa virou o primeiro experimento planejado da fase seguinte, junto com o gerador de bindings das natives. Gameplay não começa antes disso.
Por que foi feito assim
Os experimentos de maior risco foram priorizados antes do gameplay.
Decisões
Decisões e trade-offs
Cada decisão registra a justificativa e o trade-off aceito.
C# como linguagem do jogo, com Lua tratado como exceção justificada.
Domínio testável fora do jogo, tipos verificados na compilação e uma única linguagem do resource ao serviço de apoio.
Custo aceito · Sai do caminho mais trilhado da comunidade: menos exemplo pronto, e a viabilidade precisa ser provada por experimento antes de virar fundação.
Riqueza sempre física, sem saldo abstrato.
Economia de servidor de survival costuma colapsar pelo mesmo motivo: valor que não pode ser perdido acumula até não significar nada.
Custo aceito · Cada item precisa existir em algum lugar do mundo, o que encarece armazenamento, transporte e sincronização.
Escopo
Implementado e pendente
Estado atual do projeto.
Concluído
- Repositório, documentação numerada e registros de decisão
- Arquitetura C#-first aceita e registrada
- Esqueleto do monorepo
- Integração contínua e verificações de qualidade, que passam a valer sozinhas conforme o código chega
Pendente
- Decisão de banco de dados — proposta, fecha com benchmark
- Primeiro resource C# rodando no RedM, o experimento mais crítico
- Gerador de bindings das natives
- Qualquer mecânica de jogo
A fundação da plataforma ainda não começou. O que existe hoje é decisão estrutural registrada e o andaime que a sustenta — e o repositório diz isso antes de dizer qualquer outra coisa.
Stack
O que foi usado
Jogo
- C#
- .NET
- RedM
Interface
- TypeScript
- Contratos tipados compartilhados
Serviços
- Plano de controle em .NET
- Painel administrativo
- Site público
Processo
- Monorepo pnpm com solução .NET
- Registros de decisão
- Verificações automáticas de estrutura, segredos e documentação