Criar jogo de mundo aberto no gemini: o limite da ia em 1 hora (estilo gta)
Criar um jogo do zero costumava exigir meses de programação, planejamento de física e design de assets. hoje, a barreira não é mais o código, mas a capacidade de pedir exatamente o que deseja para a ferramenta certa.
O custo de um prompt genérico na criação de código é a frustração de receber um jogo quebrado, com física travada, telas de erro e dependências que não funcionam. mas o que acontece quando tentamos empurrar a inteligência artificial ao seu limite absoluto?
Para provar a capacidade (e descobrir as fraquezas) do modelo pro, desenhamos um desafio extremo: criar um jogo de ação urbana em mundo aberto, visto de cima (ao estilo dos primeiros gta), num único arquivo html, com limite de 1 hora. copie os prompts exatos que usamos e veja onde a ia brilhou, onde quebrou, e como a salvamos no final.
Gemini pro é o llm avançado do google, projetado para raciocínio complexo, lógica e programação de alto nível. diferencia-se pela capacidade de processar janelas de contexto gigantescas, permitindo a ingestão de regras de desenvolvimento inteiras de uma só vez.
Neste desafio, usamos a sua capacidade para gerar html5, css3 e javascript (canvas api) integrados, testando o limite de sobreposição de sistemas (trânsito, dia/noite, física, missões) sem recorrer a motores de jogo externos.
Neste guia: entenda o método de iteração, copie os 3 mega prompts usados no desafio, veja os prints reais do processo e baixe o código final (city zero) para explorar.
Resposta curta:
É possível criar a fundação de um jogo de mundo aberto (carros, ciclo dia/noite e cidade) em 1 hora usando o gemini pro. no entanto, o segredo revelado neste teste é que existe um limite de complexidade. empilhar sistemas demais num único arquivo html acaba por “confundir” a ia. a solução é desenvolver de forma modular e priorizar a jogabilidade antes dos detalhes.
Como este guia foi montado: Submetemos o gemini pro a um teste real com limite de tempo. todo o código gerado foi testado em navegador. as imagens e os prompts documentados aqui são as versões exatas e sem cortes geradas durante a nossa experiência, incluindo os erros e o processo de recuperação.
⚡ Tl;dr
- Tempo: 8 min (ou salte para os prompts)
- Nível: Avançado
- O que vai copiar: 4 mega prompts de engenharia de software complexa
- Lição principal: Como debugar e reconhecer o limite de contexto da ia
Índice
- As regras do desafio de 1 hora
- Anatomia do mega prompt urbano
- Os 4 prompts mestres e os prints da evolução
- O resultado: baixe o city zero
- Amanda aconselha: lidando com o colapso da ia
- Sos: a tela ficou preta!
- Faq
As regras do desafio de 1 hora
Regra 1: arquivo único (zero dependências)
O maior erro ao pedir código à ia é deixá-la separar o projeto em vários arquivos ou usar imagens externas. para este teste, a regra de ouro manteve-se: o jogo inteiro (cidade, trânsito, pedestres, física) deve rodar num único arquivo .html usando apenas a canvas api nativa.
Regra 2: originalidade forçada
Pedir para “copiar o grand theft auto” faria a ia tentar puxar assets protegidos e quebrar a renderização. o prompt forçou a criação de um universo próprio, chamado “city zero: urban chaos”, desenhado proceduralmente via código.
Regra 3: limite de iteração e sobrevivência
Diferente de um jogo de plataformas simples, um mundo aberto tem dezenas de sistemas a colidir. o desafio estipulou 1 mega prompt inicial de fundação, seguido de prompts de correção precisos sempre que a ia demonstrasse esquecimento ou colapso estrutural.
Anatomia do mega prompt de desenvolvimento urbano
| Elemento do prompt | O que faz | O que acontece por dentro | Impacto real | Erro se ignorado |
|---|---|---|---|---|
| Sistemas independentes | Pede gestão de npcs, trânsito e player separadamente. | A ia estrutura o código em classes lógicas diferentes. | Impede que um carro apague a física do jogador. | Código espaguete onde tudo colide com tudo de forma caótica. |
| Culling e renderização | Exige que apenas o que está na tela seja desenhado. | Otimiza o loop do canvas (requestanimationframe). | O navegador não bloqueia ao tentar desenhar uma cidade enorme. | O jogo roda a 2 fps e bloqueia totalmente o browser. |
| Arquitetura mobile-first | Exige suporte a multitouch e joystick virtual. | Força a ia a usar pointer events em vez de apenas cliques de mouse. | Permite andar e realizar ações ao mesmo tempo no celular. | O jogador toca na tela e o boneco fica preso num loop eterno. |
💡 O segredo dos especialistas: Em jogos complexos, a prioridade é a fundação mecânica. não peça para a ia criar o “nível de procurado da polícia” se o personagem principal ainda nem sequer consegue andar em linha reta.
Os 4 prompts para construção e o limite da ia (com prints) 📌
Abaixo estão os prompts exatos usados para desafiar o gemini, e os resultados visuais reais que obtivemos a cada iteração. diferente de jogos de plataforma simples, aqui a ambição era gigante. veja como a ia lidou com a complexidade — e o momento exato em que a tivemos de “salvar”.
👾 Série dev — o desafio city zero
📸 Prompt 01 — a fundação (o mega prompt de mundo aberto)
Este prompt é massivo e tenta injetar todo o conceito de um “sandbox urbano” de uma só vez na cabeça da ia.
Crie um jogo completo de mundo aberto 2d com visão de cima, inspirado no conceito dos primeiros jogos de ação urbana top-down, mas com universo, mapa, personagens, veículos, missões e identidade 100% originais. O jogo não deve copiar gta, grand theft auto, rockstar games, liberty city, vice city, san andreas ou qualquer mapa, personagem, missão, diálogo, veículo, arte ou asset existente. O nome do jogo será: city zero Subtítulo: urban chaos Objetivo: Criar um jogo realmente jogável de ação e exploração em uma cidade aberta. O jogador controla um personagem que pode: andar pela cidade; explorar livremente; entrar em veículos; dirigir; sair dos veículos; cumprir missões; ganhar dinheiro; enfrentar criminosos; escapar da polícia; encontrar veículos diferentes; explorar diferentes regiões da cidade. Regra principal de entrega: Todo o jogo deve estar em um único arquivo html. Utilizar apenas html5, css3 e javascript puro (canvas api). sem imagens, sprites ou bibliotecas externas. Estilo visual: Pixel art top-down. cidade detalhada, cores fortes, veículos identificáveis e ciclo dia e noite funcional (começa de dia e escurece com o tempo, acendendo faróis e postes). Controles: Teclado (wasd para mover, e para entrar em veículos) e touch (joystick virtual esquerdo, botões de ação na direita com suporte a multitouch). Veículos e mundo: Criar trânsito funcional com carros controlados por ia circulando pelas ruas. permitir que o jogador roube/entre nos carros. o mapa deve ter regiões distintas (centro, industrial, vila portuária, subúrbio). Criar sistema de hud, missões básicas e minimapa. implementar culling inteligente para não desenhar o mapa todo de uma vez e travar o navegador. Entregue apenas o código html final completo e funcional.
O que aconteceu no teste 1: Surpreendente! o ciclo de dia e noite foi perfeitamente programado. os carros gerados por ia circulavam livremente pela cidade de forma autônoma com faróis à noite. mas o problema fatal: o nosso personagem estava congelado. não andava para lado nenhum, o que impedia testar o resto do jogo. além disso, as texturas do chão eram confusas; não dava para perceber o que era grama, asfalto ou calçada.


👉 Deslize para ver os carros e o ciclo noturno do 1º teste. clique na imagem para ampliar com qualidade.
📸 Prompt 02 — a correção prioritária (mobile-first)
Quando o núcleo do jogo quebra, tem de parar de pedir funcionalidades novas e focar-se em isolar o problema.
Correção prioritária - city zero Movimentação mobile-first e acessibilidade Você está trabalhando no código existente do jogo city zero. Regra mais importante: não refaça o jogo do zero. A dinâmica atual de mapa, texturas, cidade, carros, trânsito, câmera e sistema de dia/noite melhorou bastante e deve ser preservada. neste momento, não quero novas mecânicas. concentre praticamente todo o trabalho em uma única coisa: movimentação do personagem. 1. prioridade absoluta: touch O controle touchscreen deve ser considerado o principal método. implemente um joystick virtual simples, responsivo e analógico. o jogo deve detectar automaticamente a entrada disponível sem menus de seleção. 2. multitouch fluido Prepare o sistema para touchscreen real (pointerdown, pointermove, pointerup). o dedo que iniciou o joystick deve continuar controlando mesmo que ele se mova pela tela, e a tela não pode travar se o jogador usar o outro dedo para botões de ação. 3. não quebre o mapa e revise as colisões Preserve o trânsito e o visual atual. a ordem de prioridade de colisão deve ser: o personagem se movimenta -> em 8 direções -> touch funciona -> ele para ao soltar -> ele não atravessa prédios -> ele caminha nas ruas e calçadas. Entregue o arquivo html completo, mantendo a sensação de que o personagem está realmente sob controle do jogador.
O que aconteceu no teste 2 (sucesso técnico): O jogo reviveu! a movimentação ficou super responsiva e a condução (dirigibilidade) dos veículos ficou absolutamente fantástica, melhor do que muitos jogos indie. o joystick touch apareceu perfeitamente e funcionou sem falhas. mas… apesar de muito fluido, visualmente as texturas ainda estavam rudimentares (difícil distinguir a calçada da estrada), o minimapa sumiu, e a cidade parecia fantasma sem pedestres.



👉 Deslize para ver o joystick touch e a condução corrigida. clique para ampliar.
📸 O colapso e a tensão: o limite da janela de contexto
Após o sucesso da condução, cometemos o erro capital do desenvolvimento com ia: a ganância. Enviamos um novo prompt pedindo simultaneamente para criar npcs (pedestres), recuperar o minimapa, polir as texturas das estradas e adicionar um sistema de missões dinâmicas. este foi o prompt exato que causou o colapso:
# City zero — segunda grande correção ## Mapa + minimapa + objetivo + pedestres Você está trabalhando no código atual e funcional do city zero. ## ⚠️ Regra absoluta Não refaça o jogo do zero. O projeto finalmente chegou a um ponto em que: * o personagem está andando normalmente; * a movimentação está funcionando; * o controle touchscreen está funcionando; * a dirigibilidade dos carros está boa; * os carros estão funcionando; * o sistema de dia/noite está funcionando; * o mapa e as texturas evoluíram bastante. ### Não quebre nada disso. Não reescreva o sistema de movimentação. Não reescreva a física dos carros. Não substitua o mapa atual. Não troque as texturas atuais por um mapa novo. A partir de agora, queremos evoluir o jogo, não voltar para a fase de protótipo. --- # 🎯 Nova prioridade O jogo está tecnicamente mais jogável, mas agora falta: 1. clareza visual entre rua e calçada; 2. minimapa; 3. objetivos/missões; 4. pedestres; 5. uma sensação maior de que existe uma cidade viva para explorar. Faça essas melhorias sem destruir as funcionalidades existentes. --- # 1. 🛣️ Diferenciar claramente rua e calçada Esse é um dos problemas mais importantes atualmente. O jogador precisa olhar para a tela e entender imediatamente: "isso é rua" e "isso é calçada". Não quero depender apenas de pequenas diferenças de textura. Crie uma hierarquia visual muito clara. ### Rua A rua deve possuir características visuais próprias: * superfície claramente diferente da calçada; * largura suficiente para circulação dos carros; * faixas de trânsito quando fizer sentido; * linhas de pista; * cruzamentos; * faixas de pedestres; * meio-fio separando da calçada; * aparência consistente em todo o mapa. ### Calçada A calçada deve ser claramente reconhecível: * textura/padrão próprio; * cor/tonalidade visual diferente da rua; * meio-fio; * largura suficiente para o personagem; * continuidade ao redor dos prédios. ### Importante Não transforme a cidade em um desenho excessivamente simples. Mantenha as texturas e o estilo visual atual. A solução deve ser uma melhoria da leitura visual, não uma simplificação do mapa. --- # 2. 🚧 Elementos de leitura urbana Adicione pequenos elementos que ajudem o jogador a interpretar a cidade: * meio-fios; * faixas de pedestres; * marcações de estacionamento; * linhas de pista; * postes; * placas; * árvores; * entradas de prédios; * pontos de ônibus; * estacionamentos. Esses elementos devem ajudar a comunicar: Rua → calçada → prédio sem sobrecarregar o mapa. --- # 3. 🗺️ Recuperar o minimapa O minimapa desapareceu na versão atual. Recupere o minimapa. Não crie um minimapa completamente diferente se o código anterior já possuía um sistema funcional. Procure no código atual ou no histórico da implementação por: * minimap; * radar; * mapa; * canvas do mapa; * player marker. Se houver código antigo funcional, restaure-o e adapte ao mapa atual. --- ## O minimapa deve mostrar * posição do jogador; * ruas principais; * regiões importantes; * prédios/blocos urbanos de maneira simplificada; * carros próximos, se o desempenho permitir; * objetivo atual; * posição de locais importantes. O minimapa deve permanecer fixo na interface enquanto o mundo se movimenta. --- # 4. 📱 Minimapa no celular Como o city zero possui foco mobile-first, o minimapa precisa funcionar bem no celular. Não pode: * ocupar uma parte enorme da tela; * esconder o joystick; * bloquear botões; * ficar minúsculo demais; * desaparecer em telas menores. Adapte automaticamente o tamanho. No celular: minimapa compacto, mas legível. No desktop: minimapa um pouco maior. --- # 5. 🎯 O jogo precisa ter um objetivo Atualmente o jogador pode andar e dirigir, mas falta uma razão para fazer isso. Precisamos criar o primeiro objetivo jogável do city zero. Não transforme isso ainda em uma campanha gigantesca. Crie uma primeira missão simples que ensine o jogador a explorar a cidade. ### Primeira missão Exemplo: Missão 01 — primeiro trabalho Objetivo: > Vá até o ponto marcado no mapa. Ao chegar: > Entre no veículo. Depois: > Dirija até o destino. Ao chegar ao destino: > Entregue a encomenda. Recompensa: +$100 Depois mostrar: Missão concluída --- # 6. 🎯 Marcador de objetivo O objetivo precisa aparecer: ### No mundo Um marcador visual deve indicar o destino. Pode ser: * ícone; * círculo; * marcador vertical; * seta; * ponto luminoso discreto. ### No minimapa O destino também deve aparecer no minimapa. ### Na interface Mostrar algo como: Objetivo Vá até o ponto marcado. Quando o jogador estiver próximo: Você chegou ao destino. --- # 7. 🧭 Indicação de distância Adicione uma informação simples: Destino: 247 m Ela deve atualizar conforme o jogador se aproxima. Isso ajuda muito no celular, porque o jogador pode não saber imediatamente para onde ir. --- # 8. 👥 Pedestres Agora precisamos adicionar um elemento clássico dos jogos de mundo aberto: # Pedestres A cidade não pode parecer vazia. Crie npcs civis andando pelas calçadas. Importante: Eles não precisam ser extremamente complexos. Queremos primeiro uma simulação convincente e leve. --- # 9. Comportamento dos pedestres Os pedestres devem: * aparecer nas calçadas; * caminhar; * escolher direções; * evitar ficar parados no meio da rua; * mudar de direção em alguns pontos; * atravessar ruas quando apropriado; * desaparecer/reaparecer fora da área de interesse para economizar processamento. Crie diferentes tipos visuais simples. Por exemplo: * homem; * mulher; * pessoa com roupa clara; * pessoa com roupa escura; * pessoa com mochila; * trabalhador; * pedestre casual. Não é necessário criar personagens extremamente detalhados. --- # 10. Pedestres + carros Os carros já possuem uma dirigibilidade boa. Preserve isso. Agora faça os pedestres coexistirem com o trânsito. Não precisa implementar física extremamente complexa. Mas evite situações absurdas como: * dezenas de pedestres andando no meio da pista; * pedestres surgindo dentro dos carros; * todos andando exatamente na mesma direção; * todos usando a mesma posição; * pedestres ocupando a rua inteira. A cidade deve parecer minimamente viva. --- # 11. Densidade inteligente Não coloque centenas de npcs. Priorize desempenho. Uma quantidade moderada de pedestres próximos ao jogador é suficiente. Use um sistema de ativação por distância: perto do jogador → npc ativo longe do jogador → npc reduzido/desativado Isso é especialmente importante para celulares mais simples. --- # 12. Pedestres no mobile Lembre: O city zero será testado em celulares. Portanto: desempenho é prioridade. Não use ia complexa para cada npc. Um sistema simples de estados é suficiente: Walking Waiting Crossing Avoiding Não precisamos de inteligência artificial pesada. --- # 13. Primeira missão deve ser o tutorial natural A primeira missão deve ensinar sem colocar uma tela enorme de tutorial. O jogador aprende naturalmente: 1. movimentar o personagem; 2. andar pela calçada; 3. localizar o destino; 4. entrar no carro; 5. dirigir; 6. seguir o minimapa; 7. chegar ao destino; 8. receber recompensa. Isso transforma o protótipo em um jogo. --- # 14. Interface Mantenha a interface limpa. Na tela: Missão atual Vá até o ponto marcado. Dinheiro $0 Minimapa posição + objetivo. No celular, não deixe essas informações cobrirem o joystick ou o mundo. --- # 15. Não implementar ainda Ainda não precisamos de: * armas; * polícia; * sistema de procurado; * dezenas de missões; * lojas; * inventário; * multiplayer; * interiores complexos; * centenas de npcs; * sistema econômico complexo. Primeiro queremos: Cidade → pedestres → objetivo → carro → destino → recompensa funcionando perfeitamente. --- # 16. Prioridade de implementação Trabalhe exatamente nesta ordem: ### Prioridade 1 Corrigir a leitura visual: Rua ≠ calçada ### Prioridade 2 Recuperar o: Minimapa ### Prioridade 3 Criar: Objetivo/missão ### Prioridade 4 Adicionar: Pedestres ### Prioridade 5 Integrar tudo: Player + carro + pedestres + mapa + minimapa + missão --- # 17. Teste final Antes de entregar, imagine um usuário abrindo o jogo no celular. Ele deve conseguir: 1. tocar na tela; 2. movimentar o personagem; 3. entender imediatamente onde é rua e onde é calçada; 4. enxergar o minimapa; 5. ver o objetivo; 6. caminhar até o objetivo; 7. encontrar pedestres; 8. entrar no carro; 9. dirigir; 10. seguir o minimapa; 11. chegar ao destino; 12. concluir a missão; 13. receber dinheiro. Se isso funcionar, teremos uma base real de jogo, não apenas uma demonstração visual. --- # ⚠️ Regra final — preservação Antes de alterar qualquer sistema, identifique o que já está funcionando. ### Preservar obrigatoriamente: ✅ movimentação do personagem ✅ controle touchscreen ✅ joystick ✅ dirigibilidade dos carros ✅ carros/trânsito ✅ câmera ✅ sistema dia/noite ✅ mapa atual ✅ texturas atuais ✅ estrutura da cidade ### Melhorar: 🔧 leitura rua/calçada 🔧 minimapa 🔧 objetivos 🔧 missão 🔧 pedestres 🔧 integração da cidade --- # Entrega Entregue novamente o arquivo html completo. Nome: city-zero.html Tudo deve continuar em um único arquivo: Html + css + javascript. Sem bibliotecas externas. Sem arquivos externos. Sem placeholders. Sem: ... Sem dizer "o restante do código permanece igual". Quero o código completo e funcional. O objetivo desta atualização é fazer o city zero deixar de parecer apenas um mapa jogável e começar a parecer uma cidade onde existe algo para fazer.
O que aconteceu depois deste prompt: O colapso total. a ia atingiu o limite de processamento de contexto num único arquivo. ao tentar injetar a matemática das rotas dos pedestres, do minimapa e das novas texturas ao mesmo tempo, ela esqueceu-se de fechar loops do canvas. o jogo tornou-se injogável, resultando numa tela preta e desfigurada (imagem abaixo). a lição: pedir tudo de uma vez é o caminho mais rápido para quebrar o projeto.

👉 A imagem do colapso técnico. o limite de um único arquivo html foi ultrapassado.
📸 Prompt 04 — o resgate final
Para salvar o projeto, tivemos de recuar. a regra foi: preservar o que funciona e adicionar o mínimo absoluto para que fosse considerado um jogo.
Última alteração city zero: preservar o que funciona + primeira missão simples Você está trabalhando no código atual do city zero. Esta é uma alteração de preservação e estabilização. o projeto estava funcionando bem, mas a última alteração tornou o jogo injogável. ! não refaça o jogo Não reconstrua o projeto, não tente implementar várias funcionalidades simultaneamente. o objetivo agora é: salvar o estado jogável do city zero e adicionar apenas um sistema de missão muito simples. 1. preserve o que já funcionava Devem ser preservados obrigatoriamente: movimentação em 8 direções, joystick virtual, dirigibilidade dos carros, carros e trânsito gerados por ia, câmera, colisões e sistema de dia/noite. 2. primeira missão do city zero Crie apenas uma missão. nome: missão 01 - primeiro trabalho. objetivo deve ser extremamente simples: ir até o ponto marcado. crie um marcador simples no destino e, ao chegar perto, exiba "missão concluída! +$100". 3. regra final - preservação Não tente salvar o jogo adicionando mais coisas. salve o jogo justamente fazendo menos. não adicione diálogos, novos npcs, novas texturas ou menus complexos. entregue o arquivo html completo, limpo e jogável.
📊 O resultado final (a base sólida): Funcionou! temos um gta funcional. aceitamos que faltariam pedestres e um sistema complexo de polícia para respeitar o limite arquitetônico do modelo, mas a ia impressionou demais. toda a movimentação, a condução do carro, as colisões e a atmosfera básica estão prontas e criam uma excelente fundação “open source” para desenvolvedores reais explorarem.



👉 Deslize para ver a base final que o gemini construiu. clique para ver em tela inteira.
O resultado: baixe o city zero (e continue o desenvolvimento) 🕹️
Ao contrário do nosso sucesso imediato com jogos 2d simples, este teste serviu para desenhar uma linha nítida na areia: a ia generativa atual é fenomenal, mas criar um gta inteiro num simples arquivo html exige arquitetura de software contínua, não apenas “prompts milagrosos”.
Deixamos aqui o arquivo html exato gerado na nossa última iteração. é uma base com física de condução surpreendentemente boa. baixe-o, analise como o gemini estruturou as classes javascript e, se for capaz, tente adicionar os pedestres por conta própria!
City zero: o desafio open-source
Quer analisar como a ia tentou construir o motor físico do jogo ou tentar expandir o código? baixe o html original e abra-o no seu editor (vs code, notepad++).
👉 Amanda aconselha: lidando com a complexidade da ia
- Se quer criar um rpg ou mundo aberto: Não force a ia a gerar tudo num arquivo html colossal de 5.000 linhas. use motores de jogo reais (como phaser, godot ou unity) e peça à ia para gerar módulos pequenos (“crie apenas o script de patrulha do npc”).
- Guarde sempre uma cópia da versão anterior: Este artigo é a prova viva! se não tivéssemos o backup da iteração 2 (onde a condução funcionava perfeitamente), o colapso da iteração seguinte teria destruído o projeto inteiro. versionamento de arquivos salva vidas.
- Se o código parar no meio (corte de janela): Em prompts massivos, a ia simplesmente “desiste” de escrever por atingir o limite de tokens (memória). o erro de renderização do teste 3 quebrado aconteceu provavelmente porque a ia não terminou de fechar as tags e funções cruciais.
🚨 Sos: a tela do meu jogo ficou completamente preta
- Causa: Amnésia de contexto. ao focar-se em desenhar elementos complexos novos, a ia esqueceu-se de fechar parênteses ou apagou a variável que limpava o canvas a cada frame (`ctx.clearRect`). o erro de sintaxe quebra a janela gráfica.
- Correção prática: Não tente dizer à ia “conserta tudo o que acabaste de fazer”. pegue no código da versão antiga, abra um chat novo e diga: “quero desenhar [elemento x] sem quebrar o loop principal. dá-me apenas a função isolada.”
- Resultado: Você mesmo faz o “copy-paste” da função isolada de forma segura para dentro do seu html que estava a funcionar.
Faq: dúvidas reais a serem respondidas 🔍
O gemini pro é mau a programar jogos complexos?
De todo! ele programou rotinas de trânsito em 2 minutos. o problema não é a inteligência, é o limite de memória (janela de saída) de tentar descarregar um ecossistema inteiro de uma só vez num arquivo estático.
O que fazer quando a ia quebra o código todo?
Use sempre controle de versões (ou guarde arquivos como v1, v2). se a iteração 3 quebrar a renderização, reverta para a v2, isole o problema num prompt mais curto, e cole a solução manualmente.
É possível criar um gta viável só com html?
Tecnicamente sim, mas seria um pesadelo de performance. para mundos abertos densos, é crucial usar webgl (three.js/phaser) em vez do canvas 2d nativo, e separar a lógica em múltiplos arquivos js.
O código fornecido roda bem no celular?
Sim, porque exigimos no mega prompt a criação de um joystick virtual na tela e suporte a toques múltiplos (“multitouch”) usando a pointer api do javascript nativo.
Conclusão: respeitar os limites também é dominar a ia 🙌
O desafio de tentar construir o “city zero” no gemini pro ensinou-nos uma lição inestimável. a inteligência artificial não é uma varinha mágica que concebe videojogos colossais num estalar de dedos. ela é, sim, um programador incansável e rápido, mas que precisa de um “diretor técnico” humano a organizar as gavetas.
Economizamos dezenas de horas na matemática da física de condução e na lógica de pathfinding dos carros de ia, mas quase perdemos o projeto quando fomos gananciosos e pedimos o mundo inteiro num único prompt final.
Se quer conceber sistemas massivos com a ajuda da ia, o segredo é o desenvolvimento modular: peça um componente de cada vez, teste, valide, e só depois encaixe no projeto principal.
Ei, antes de ir: se este conteúdo ajudou, não pode perder o que separamos nestas outras categorias. é conhecimento de nível pago, entregue de graça aqui:
Se baixar o nosso código, colocar a mão na massa e conseguir adicionar o sistema de pedestres ou polícia, publique nos stories e marque o nosso instagram @mktamanda. vamos adorar divulgar o seu trabalho! :))
ps: obgda por chegar até aqui, é importante para mim.