Novo Rio – RPG de Simulação de Agrofloresta

Novo Rio é um RPG de simulação de agrofloresta baseado em navegador desenvolvido como parte da EKO – Residência Artística, uma residência cultural financiada pelo FAC – Fundo de Apoio à Cultura do Distrito Federal, Secretaria de Cultura e Economia Criativa / GDF. O jogo é construído em torno dos princípios da agricultura sintrópica — a filosofia de agricultura regenerativa brasileira associada a Ernst Götsch. Jogadores gerenciam terrenos degradados em um cenário do Rio de Janeiro, restaurando-os plantando espécies brasileiras reais (Feijão Guandu, Banana, Cajuzinho, Ipê-roxo, Milho, Abacaxi), gerenciando parâmetros de saúde do solo e adaptando-se a um sistema climático realista com seca, chuva forte, ondas de calor e multiplicadores sazonais. O backend executa um motor de ticks em tempo real (APScheduler, ciclo de 6 horas) que impulsiona o crescimento das plantas, aplica eventos climáticos e avalia a saúde do solo. EKO, alimentado por um LLM Ollama local com histórico de conversa no Redis, atua como conselheiro agrícola IA do jogador.

A agrofloresta sintrópica é uma técnica comprovada de restauração de terras com consciência pública limitada e nenhum ponto de entrada gamificado. A maioria dos jogos ambientais abstrai a complexidade técnica da agricultura real ou foca em mecânicas de punição. O Novo Rio visa ensinar lógica de plantio real — tolerâncias reais de espécies, interdependências de parâmetros do solo, multiplicadores sazonais de crescimento — através da gameplay, tornando a curva de aprendizado invisível.

Construir um jogo de simulação que: (1) modele espécies reais de agrofloresta brasileira e dinâmicas do solo com precisão; (2) execute um motor de ticks em tempo real com compressão de tempo configurável para testes; (3) integre um LLM local como guia no jogo com consciência do estado do jogo; (4) suporte WhatsApp como canal de entrada de primeira classe para que jogadores possam interagir sem abrir um navegador.

• ◈Desenvolvedor solo — design do jogo, backend, frontend, modelagem de dados, integração IA

1. 01Motor de ticks APScheduler com TIME_SCALE_FACTOR — um scheduler de 6 horas em tempo real impulsiona todas as mudanças de estado do jogo. A variável de ambiente TIME_SCALE_FACTOR comprime o tempo do jogo (ex: TIME_SCALE_FACTOR=24 faz 1 hora real = 1 dia do jogo), tornando o ciclo completo de vida das plantas testável em horas em vez de meses.
2. 02Configuração de espécies via YAML com hot-reload — o species.yml define todos os parâmetros das plantas (dias de germinação, dias de maturidade, tolerância à seca, rendimento de colheita). A função tick_day() relê o YAML a cada ciclo para que designers de jogo possam ajustar o balanceamento sem reiniciar o servidor.
3. 03Índice de saúde do solo com pesos — um algoritmo de pontuação customizado calcula uma pontuação de saúde do solo de 0 a 100 em 6 parâmetros com faixas ideais e limiares de severidade por parâmetro. Isso produz categorias de qualidade significativas (Excelente / Muito Bom / Regular / Crítico) que dão ao jogador feedback acionável em vez de números brutos.
4. 04Propagação de 15% para quadrantes vizinhos — aplicar água, fertilizante ou composto em um quadrante propaga 15% do efeito para os 4 quadrantes adjacentes (N/S/L/O), modelando a difusão real de umidade do solo e tornando as decisões espaciais de plantio consequentes.
5. 05Máquina de estados do ciclo de vida das plantas — 5 estados (SEMENTE / MUDINHA / MADURA / COLHIVEL / COLHIDA / MORTA) com transições controladas por tempo pelos parâmetros da espécie. A tolerância à seca determina quantos ciclos de tick uma planta sobrevive sem água antes de morrer.
6. 06WhatsApp como canal de entrada principal — um endpoint /whatsapp/message analisa comandos de texto em linguagem natural ('plantar 3 regador') e os mapeia para ações do jogo, limitados pela mesma taxa de ações por ciclo de 6 horas que a UI web. O jogo foi projetado para que um jogador possa gerenciar sua fazenda completamente pelo WhatsApp.
7. 07Arquitetura dual sync/async — src/api/ (sync com run_in_threadpool) e src/api_async/ (async nativo) coexistem, refletindo uma migração em andamento para FastAPI totalmente async. A coexistência permitiu migração incremental sem quebrar endpoints existentes.
8. 08EKO/Ollama com contexto de conversa no Redis — o endpoint /eko encaminha mensagens para uma instância Ollama local com histórico de conversa por sessão armazenado no Redis, permitindo que EKO dê conselhos contextuais de plantio referenciando trocas anteriores.
9. 09Habilidades secretas de ferramentas scaffolded em tools.yml — cada ferramenta tem um campo secret_special_ability definindo uma mecânica de descoberta ('se usado para AÇÃO em CLIMA com ESPÉCIE → desbloquear bônus'). Ainda não implementado no motor do jogo, mas totalmente especificado na camada de dados, projetado para adicionar uma camada de descoberta oculta para jogadores experientes.

• →APScheduler combinado com TIME_SCALE_FACTOR é um padrão de teste poderoso para jogos baseados em tempo — poder executar um ciclo completo de cultivo em minutos em vez de meses torna o balanceamento do jogo tratável sem exigir um harness de teste separado.
• →YAML para configuração de dados do jogo (espécies, ferramentas, insumos) separa a autoria de conteúdo das mudanças de código de forma significativa — um designer de jogo não programador pode ajustar o balanceamento de espécies sem tocar em arquivos Python.
• →Modelar sistemas ecológicos reais (pH do solo, interdependências de matéria orgânica, tolerância à seca) produz mecânicas de simulação mais envolventes do que parâmetros inventados, porque as relações reais já são interessantes e não óbvias para a maioria dos jogadores.
• →WhatsApp como canal de entrada do jogo é arquiteturalmente direto (endpoint de webhook + parsing de comandos NLP), mas produz uma experiência de jogo fundamentalmente diferente — interações assíncronas e de baixo atrito que se encaixam naturalmente nas rotinas diárias em vez de exigir sessões de jogo dedicadas.
• →Coexistência de API dual sync/async no FastAPI é gerenciável, mas cria overhead de manutenção — ter duas implementações paralelas dos mesmos endpoints significa que qualquer correção de bug deve ser aplicada duas vezes. Um caminho de migração mais limpo seria adicionar uma camada de wrapper async em vez de manter duas árvores de código.

Protótipo funcional — desenvolvimento ativo pausado, retomada planejada