Fazer um jogo sozinho: o que deixar para a IA e o que decidir você mesmo
Depois de algumas semanas escrevendo código com IA, tudo parece rodar. Aí você tenta mudar uma lógica central e descobre que a arquitetura inteira está enroscada: mexe em um ponto, quebra meio projeto. Um desenvolvedor acabou apagando todo o código gerado por IA e recomeçou do zero. Do outro lado, alguém usou IA para passar por 8 protótipos de minigames em uma única tarde; antes, esse volume levaria pelo menos uma semana. As duas experiências são reais, mas apontam para conclusões bem diferentes.
Dados da GDC 2026 mostram que 52% dos desenvolvedores acreditam que a IA tem impacto negativo na indústria de jogos, quase três vezes mais do que dois anos antes. A oposição é maior em arte, com 64%, enquanto a taxa de uso entre gestores chega a 47% e, entre quem executa na linha de frente, fica em apenas 29%. A diferença é clara. Em desenvolvimento de jogos, IA não é cura milagrosa nem desastre inevitável. O problema está nos limites. Para desenvolvimento independente, esse senso de limite importa ainda mais: uma equipe de uma pessoa não tem mão de obra sobrando para amortecer erros. Usar IA no lugar errado custa caro; usar no lugar certo multiplica a eficiência.
Este artigo não é sobre o que a IA consegue fazer. Já existem textos demais assim. O ponto aqui é o que a IA não consegue fazer e, mais importante, quando você precisa decidir por conta própria.
A pergunta central é simples: diante de uma tarefa concreta, ela deve ir para a IA ou você deve fazer manualmente? A resposta não está em “dá para fazer?”, mas em “vale delegar?”.
O que a IA consegue fazer — entregue o trabalho repetitivo à IA
Primeiro, uma coisa precisa ficar clara: há áreas do desenvolvimento de jogos em que a IA é realmente útil. Não é “talvez funcione”; na prática, economiza tempo mesmo.
Usei por mais de um ano, caí em armadilhas e também aproveitei bons ganhos. O resumo é: tarefas que podem ir para a IA costumam ter o mesmo perfil: têm resposta padronizada, são repetitivas e carregam pouco valor criativo.
Geração e autocompletar de código
Na validação de protótipos, a eficiência da IA é visível de cara.
Um artigo aprofundado da NetEase cita um caso: durante uma sessão de brainstorming, o designer destrincha requisitos e escreve o primeiro rascunho; o bot acompanha a conversa e, depois da reunião, entrega código de protótipo executável. Antes, esse tipo de protótipo levava uma semana. Agora sai em uma tarde.
No Zhihu, há relatos parecidos. Um desenvolvedor comentou que problemas matemáticos e conhecimento de APIs de engines são respondidos pela IA em poucos segundos. “Por exemplo, como usar o Unity Animator ou configurar URP RenderFeature: procurar isso na documentação leva um tempão; a IA explica em uma frase.”
Minha experiência é parecida. Para escrever a lógica básica de movimentação de um RPG em visão superior, o esqueleto de código gerado pela IA já era utilizável. Depois, ajustei a sensação de controle e adicionei colisões por conta própria, mas a estrutura inicial veio da IA.
O Sohu publicou um dado de teste: em 40 minutos, foi possível concluir cerca de 70% das funcionalidades de uma demo de RPG em visão superior. Eu acredito nesse número, porque meu ritmo foi bem próximo.
Mas atenção: aqui estamos falando de “esqueleto” e “validação de protótipo”. Antes do lançamento, o código gerado pela IA precisa passar pela sua revisão: otimizar o que precisa ser otimizado, refatorar o que precisa ser refatorado. Não espere que a IA entregue código em nível de produção.
Geração de texto em lote
Aqui a IA é forte. Diálogos de NPCs, descrições de missões, descrições de itens, nomes de conquistas: tudo isso é texto de preenchimento, com baixo peso criativo e alto volume.
Um roteirista de jogos da NetEase compartilhou uma prática simples: jogar para a IA os textos de preenchimento que são “trabalho pesado” e resolver em poucos minutos. Depois ele revisa, ajusta a linguagem e calibra a própria produção comparando com a saída da IA.
“Nós tratamos a IA como grupo de controle para ver se o que escrevemos está muito abaixo.” Essa ideia é bem prática: a IA não substitui você; ela ajuda a calibrar o resultado.
O guia do Sohu também menciona que a IA pode gerar 10 missões para a fase inicial, com condições de acionamento e mecanismos de recompensa. Esse tipo de conteúdo estruturado é algo que a IA processa muito bem.
Já usei IA para escrever um conjunto de descrições de itens, cerca de 50 entradas. Tempo gasto: 15 minutos. Se eu escrevesse sozinho, seriam pelo menos duas horas. Diferença de qualidade: mínima. Porque descrições de itens não exigem tanta criação; precisam ser corretas, concisas e coerentes com o mundo do jogo.
Geração de protótipos visuais
Arte é o ponto mais polêmico, mas na fase de demo ela pode ser útil.
Um desenvolvedor no Zhihu contou que, na fase de demo, usa IA para gerar recursos visuais temporários, e o resultado “também não fica ruim de ver”. O importante é não esperar que isso vá direto para o lançamento: erros de anatomia, estilos diferentes e detalhes mal resolvidos ainda exigem retoque profissional.
Fiz uma demo em que a IA gerou blocos de cor para personagens e fundos de cenário. Mostrei para amigos e eles disseram: “até que vai”. Mas eu sabia que era uma solução temporária. Para publicar de verdade, ainda seria necessário contratar alguém para desenhar.
Do ponto de vista de um desenvolvedor independente, usar arte gerada por IA na fase de demo é uma escolha pragmática: você não tem orçamento para contratar arte, mas precisa de algo visual para validar a jogabilidade.
O ponto central é: como temporário, funciona; para lançamento oficial, não.
Expansão criativa e validação de protótipos
Aqui o papel da IA é mais parecido com o de uma “assistente de referência”.
O guia do Sohu cita o Ludo.ai, que analisa dados de Steam e TapTap para gerar conceitos de jogos. Esse tipo de saída, mais próximo de pesquisa de mercado, a IA faz mais rápido que humanos: há muitos dados, muitas dimensões e a análise manual é lenta demais.
Um artigo da ACM também aponta que a IA pode apoiar o fluxo criativo, mas não deve substituir a decisão criativa. Resumindo: a IA entrega um monte de opções, mas quem escolhe é você.
Já testei IA para gerar um esqueleto de GDD. Dei uma descrição da mecânica central e a IA retornou 5 possíveis direções de expansão. Escolhi 2 para pensar com mais profundidade. O trabalho da IA era “abrir caminhos”, não “tomar a decisão”.
O que a IA não consegue fazer — isso precisa ser decidido por você
Já falamos do que pode ir para a IA. Agora vem o que não pode.
Esta parte é mais importante. Porque usar IA no lugar errado costuma custar mais caro do que não usar IA nenhuma.
Decisão criativa e game feel
Jogabilidade central, visão de mundo, experiência emocional: a IA realmente não resolve isso.
Um artigo da ACM traz uma observação muito precisa: “a IA não entende jogos”. Ela sabe escrever código, mas não sabe o que torna algo “divertido”.
Um texto no Medium diz de forma ainda mais direta: a magia do jogo não está no código, mas no “feel”. Sensação de controle, ritmo, fluxo emocional: tudo isso precisa ser experimentado e ajustado pelo desenvolvedor.
Eric Barone, criador de Stardew Valley, representa bem o grupo mais contrário à IA na indústria. Ele diz que a “criatividade humana deve vir antes de máquinas sem alma”. A frase soa um pouco intensa, mas, do ponto de vista de quem cria, faz sentido. O ritmo de um jogo de fazenda, a sensação acolhedora de interagir com os moradores, a satisfação na hora da colheita: isso não é algo que o código expresse sozinho. É uma experiência lapidada repetidas vezes por quem desenha o jogo.
Eu mesmo fiz um jogo de pinball em que os parâmetros físicos gerados pela IA rodavam desde o começo. Mas o “toque” estava errado: a bola quicava duro demais, o ritmo era rápido demais e o jogador não sentia controle. Passei três dias ajustando inúmeros parâmetros até encontrar aquela sensação de “prazeroso, mas sem perder o controle”.
A IA entrega código. Ela não entrega game feel.
Controle de estilo artístico
Arte é o campo mais controverso e também aquele em que a IA erra com mais facilidade.
Relatos no Zhihu mencionam que a IA gera erros de estrutura corporal e exige retoque de artistas profissionais. Número errado de dedos, perspectiva confusa, luz e sombra inconsistentes: são problemas comuns de IA, e o jogador percebe de cara.
No Reddit, alguém reclamou que arte de IA “não consegue seguir uma direção artística definida”. Você quer pixel art, a IA entrega cartoon; quer uma paleta fria, ela insiste em tons quentes. Consistência de estilo é o núcleo da arte de um jogo, e a IA ainda é quase um desastre nisso.
Depois de usar IA, artistas na linha de frente descobriram que o resultado não é confiável: retocar dá mais trabalho do que desenhar.
Fiz uma demo em que a IA gerou retratos de personagens. O resultado: 5 personagens em estilos completamente diferentes. Um cartoon, um realista, um pixel art, um anime e um que nem dava para nomear. No fim, apaguei tudo e procurei um artista para redesenhar.
Consistência de estilo é um ponto fraco da IA. Até agora, não há uma solução real para isso.
Arquitetura e compreensão do problema
Este é o problema central do caso do Reddit em que o desenvolvedor “apagou todo o código e recomeçou”.
O código gerado pela IA roda, mas a arquitetura costuma ficar emaranhada. Funcionalidades ficam acopladas demais; alterar uma parte afeta várias outras. Esse tipo de código vira um “pesadelo arquitetural”.
O artigo da ACM descreve a IA como uma “Ill-Informed Co-Worker”: ela tem capacidade técnica, mas falta compreensão profunda. Ela sabe implementar uma funcionalidade, mas não sabe por que aquele desenho faz sentido nem o impacto que ele terá no futuro.
Um desenvolvedor no Zhihu resumiu bem: “em problemas de raciocínio e direção, a IA não ajuda”.
O que são problemas de direção? Por exemplo:
- Qual é a mecânica central do seu jogo?
- Como os sistemas interagem entre si?
- Qual é o caminho de expansão posterior?
- Onde estão os gargalos de desempenho?
Essas perguntas não têm resposta padronizada. Exigem reflexão do desenvolvedor. A IA pode ajudar, mas não pode decidir.
No post original do Reddit há uma frase importante: “usar IA limita seriamente a capacidade de voltar atrás e ajustar”. Como a arquitetura não está clara, você tenta mudar uma lógica e descobre que o impacto é grande demais. Não dá para mexer.
Segurança e controle de manutenção
A análise da SonarSource menciona que código gerado por IA pode esconder vulnerabilidades de segurança. Falta de validação de entrada, ausência de checagem de permissões, exposição de dados sensíveis: esses detalhes, que a IA ignora facilmente, podem ser fatais depois do lançamento.
A recomendação do Escritório Federal de Segurança da Informação da Alemanha é que assistentes de código com IA sejam supervisionados por desenvolvedores experientes. Não é “nunca usar”; é revisar manualmente depois de usar.
Do ponto de vista da manutenção de longo prazo, o problema do código de IA é mais discreto. Ele costuma vir sem comentários, sem documentação e sem explicação de design. Três meses depois, quando você quer mudar algo, percebe que nem entende mais como aquilo foi escrito.
Já caí nessa. Um módulo gerado por IA funcionava bem em produção. Seis meses depois, ao adicionar uma nova funcionalidade, abri o código e ele parecia completamente estranho: nomes de variáveis confusos, saltos lógicos esquisitos, zero comentário. No fim, gastei dois dias refatorando, mais lento do que se tivesse escrito eu mesmo desde o início.
A IA pode economizar tempo de desenvolvimento, mas não necessariamente economiza tempo de manutenção. Muita gente ignora esse ponto.
Framework de decisão — quando delegar e quando fazer você mesmo
As duas partes anteriores mostraram o que “dá para fazer” e o que “não deve ser delegado”. Mas, no desenvolvimento real, muitas tarefas ficam no meio do caminho.
É aí que você precisa de um framework de decisão.
Perguntas de conhecimento vs perguntas de direção
Um desenvolvedor no Zhihu resumiu um critério muito útil: “perguntas de conhecimento vão para a IA; perguntas de direção ficam com você”.
O que é uma pergunta de conhecimento? Algo com resposta absolutamente correta. Por exemplo:
- Como configurar uma máquina de estados no Unity Animator?
- Como implementar detecção de colisão no Cocos Creator?
- Como calcular esta fórmula matemática?
Nesses casos, a IA consegue responder bem, porque a resposta é única e verificável.
O que é uma pergunta de direção? Algo sem resposta absoluta, que exige estética e experiência. Por exemplo:
- A mecânica central é divertida?
- A visão de mundo é coerente?
- A sensação de controle é fluida?
Essas perguntas a IA não consegue responder, porque a resposta depende do seu gosto, do seu público-alvo e da sua filosofia de design.
Meu hábito é perguntar primeiro: “este problema tem uma resposta padronizada?”
Se tiver, pergunto à IA.
Se não tiver, penso por conta própria.
Por exemplo, para escrever uma lógica de pulo, a IA consegue entregar o esqueleto de código. Mas qual altura de pulo é adequada? Quanto tempo deve durar a suspensão no ar? Como deve ser o feedback ao tocar o chão? Isso precisa ser ajustado por você, porque “sensação de jogo” não tem resposta padrão.
Fase de protótipo vs fase final
O estágio do projeto também importa.
Na fase de protótipo, o objetivo é validar a viabilidade da ideia, não atingir qualidade de lançamento. Aqui você pode usar IA com ousadia: código que roda já basta, arte pode ser bloco de cor, texto pode ser provisório.
Na fase final, o jogo será visto por jogadores e precisa entregar uma experiência completa. Aqui o controle humano é obrigatório: código precisa ser refatorado, arte precisa ser refinada, texto precisa ser lapidado.
O teste do Sohu mostrou 70% de uma demo de RPG concluída em 40 minutos. Isso é na fase de protótipo. Para transformar essa demo em produto publicável, 40 minutos ficam longe de bastar: ainda há os 30% de funcionalidades centrais, refatoração de arquitetura, troca de arte e revisão de texto.
O caso da NetEase é parecido: designers usam IA para validar um protótipo em uma tarde, mas o desenvolvimento formal continua sob controle humano.
Fiz uma demo de pinball em que o código gerado por IA rodou em 20 minutos. Para virar uma versão publicável, levei mais duas semanas: ajuste de game feel, otimização de desempenho, design de fases e refinamento da UI.
Na fase de protótipo, IA acelera. Na fase final, IA exige cautela.
Tarefas repetitivas vs criação central
Este critério é ainda mais direto.
Tarefas repetitivas: baixo valor criativo, muito tempo gasto, alta repetição. Exemplos: gerar diálogos de NPCs em lote, preencher descrições de itens, criar nomes de conquistas.
Criação central: alto valor criativo, define a alma do jogo. Exemplos: design de ramificações narrativas, inovação da mecânica central, construção da personalidade dos personagens.
Tarefas repetitivas vão para a IA. Você economiza tempo sem prejudicar a qualidade.
Criação central fica com você. É isso que define a força competitiva do jogo.
A prática do roteirista da NetEase era: textos de preenchimento vão para a IA; narrativa central fica com ele. Assim, ele economiza tempo sem sacrificar criação.
Já escrevi cerca de 100 diálogos de NPCs. Conversas cotidianas, papo casual, comentários fora da trama principal: tudo isso foi gerado por IA em 15 minutos. Mas a trama principal, falas-chave do antagonista, diálogos que moldam a personalidade dos personagens e viradas emocionais: escrevi eu mesmo, e levei dois dias.
Trabalho repetitivo com IA, criação central com você. Essa divisão maximiza eficiência.
Você pode usar uma tabela simples de decisão:
| Tipo de tarefa | IA faz | Você faz | Motivo |
|---|---|---|---|
| Pergunta de conhecimento | ✅ | ❌ | Tem resposta padronizada |
| Pergunta de direção | ❌ | ✅ | Exige julgamento estético |
| Fase de protótipo | ✅ apoio | ✅ controle | Valida viabilidade |
| Fase final | ❌ | ✅ | Busca qualidade |
| Tarefa repetitiva | ✅ | ❌ | Baixo valor criativo |
| Criação central | ❌ | ✅ | Alto valor criativo |
Sempre que uma tarefa aparecer, faça três perguntas:
- Esta tarefa tem uma resposta absolutamente correta?
- Esta tarefa exige meu julgamento estético?
- Ela está na fase de protótipo ou na fase final?
Depois dessas três perguntas, a resposta costuma ficar clara.
Casos práticos — limites de uso da IA por função
Já temos o framework. Agora vale olhar como ele se aplica a funções diferentes.
Cada função tem uma natureza própria, então os limites de uso da IA também mudam.
Função de game design
O trabalho de game design é amplo, e os usos de IA também são variados.
No caso da NetEase, o designer destrincha requisitos e escreve um rascunho durante o brainstorming; o bot registra a conversa e, depois, gera código de protótipo executável. Esse é o uso mais típico da IA em game design: transformar uma ideia rapidamente em algo verificável.
Mas o núcleo do trabalho de game design é decisão criativa: visão de mundo, jogabilidade central, estrutura narrativa. Isso a IA não faz; precisa ficar com você.
Já vi um designer usar IA para gerar 10 propostas de mecânica e depois escolher 3 para aprofundar. A função da IA era “abrir o leque”, não “decidir”.
Limites de uso da IA em game design:
- IA faz: destrinchar requisitos, escrever rascunhos, registrar brainstorming, gerar código de protótipo
- Você faz: desenhar visão de mundo, definir mecânica central, tomar decisões criativas, estruturar narrativa
Função de roteiro e texto
Para roteiristas, a fronteira de uso da IA é relativamente clara.
O roteirista da NetEase compartilhou: textos de preenchimento vão para a IA; narrativa central fica com ele. Depois, ele compara a saída da IA para calibrar sua própria produção.
Na prática:
- IA faz: diálogos cotidianos de NPCs, descrições de itens, nomes de conquistas, descrições de missão
- Você faz: trama principal, falas de personagens-chave, textos de visão de mundo, viradas emocionais
Escrevi um sistema de diálogos de NPCs para um jogo. Conversas do dia a dia e falas sem ligação com a trama foram geradas por IA: coisas como “hoje o tempo está bom” ou “os negócios andam difíceis”. Mas a trama principal, as falas decisivas do vilão e os diálogos que constroem personalidade ficaram comigo, porque cada palavra precisava carregar emoção.
O texto de preenchimento gerado por IA economiza tempo, mas não carrega emoção. O valor central do roteiro está na emoção; essa parte precisa ser controlada por você.
Função de programação
Programadores são quem mais usa IA e também onde a disputa é mais forte.
Dados da GDC mostram que 36% usam IA, principalmente para código e fluxo de trabalho, não para geração de assets. Isso indica que programadores aceitam melhor a IA, mas também mantêm limites.
A recomendação do artigo da ACM é que desenvolvedores experientes supervisionem o código gerado por IA para evitar vulnerabilidades. Não é “não usar”; é revisar depois de usar.
Limites de uso da IA em programação:
- IA faz: autocompletar código, responder dúvidas de API, cálculos matemáticos, validação de protótipos
- Você faz: arquitetura, lógica complexa, otimização de desempenho, controle de segurança, manutenção de longo prazo
O caso do Reddit em que o desenvolvedor “apagou todo o código e recomeçou” é o exemplo negativo de dependência excessiva. O código da IA roda, mas a arquitetura fica enroscada e depois não dá para evoluir.
Meu hábito ao programar é: a IA dá o esqueleto; eu completo a lógica central e o desenho arquitetural. Funções simples, código repetitivo e consulta de documentação vão para a IA. Arquitetura do sistema, caminhos críticos de desempenho e código relacionado à segurança ficam comigo.
Função de arte
Arte é a função em que o uso de IA exige mais cautela.
Relatos no Reddit dizem que arte de IA “não consegue seguir uma direção artística definida”.
Relatos no Zhihu dizem que a IA gera erros de anatomia e exige retoque profissional.
Limites de uso da IA em arte:
- IA faz: arte temporária na fase de protótipo, materiais para demo, substitutos por blocos de cor
- Você faz: correção de anatomia, controle de consistência de estilo, qualidade visual, arte de lançamento
Fiz uma demo com retratos de personagens gerados por IA. O resultado ficou inconsistente e, no fim, apaguei tudo para redesenhar com um artista. Essa experiência deixou claro: arte de IA serve na fase de demo, mas não no lançamento.
O valor central da arte está na consistência de estilo. O que a IA entrega costuma ser estilisticamente confuso, e retocar pode dar mais trabalho do que desenhar. Até agora, esse problema não tem solução.
Uma tabela comparativa por função ajuda:
| Função | Uso de IA | IA faz | Você faz | Oposição/controvérsia |
|---|---|---|---|---|
| Game design | Médio a alto | Decomposição de requisitos, código de protótipo | Visão de mundo, mecânica central | Baixa |
| Roteiro/texto | Médio a alto | Texto de preenchimento, diálogos de NPCs | Trama principal, falas de personagens | Baixa |
| Programação | Maior | Autocompletar código, consulta de APIs | Arquitetura, controle de segurança | Média |
| Arte | Menor | Arte temporária para demo | Controle de estilo, retoque de anatomia | Maior |
A tabela mostra um padrão: quanto menor o peso criativo da tarefa, maior a aceitação da IA. Quanto maior o peso criativo, maior a cautela.
Na NetEase, a taxa de uso da IA pela gestão é 47%, enquanto na linha de frente é apenas 29%. Por trás dessa diferença há um fato simples: quem executa entende melhor os limites da IA. Essas pessoas usam todos os dias e sabem o que é confiável e o que não é.
Conclusão
Voltando à história do desenvolvedor do Reddit no começo: ele apagou todo o código gerado por IA e recomeçou. Isso não é uma negação da IA, mas a descoberta do limite certo.
O blog da Sealos tem uma boa ideia: IA é “ferramenta”, não “arquiteta”. A ferramenta reduz a barreira de entrada, mas quem decide a direção é a arquiteta. O desenvolvedor independente continua sendo o diretor criativo; a IA é só o acelerador.
Qual é o modelo mais bem-sucedido? Dados da GDC e casos da NetEase apontam para a mesma resposta: IA cuida de tarefas repetitivas, você controla a criação central.
Não é uma escolha binária entre “entregar tudo para a IA” e “não usar IA nunca”. É divisão de trabalho: entregue à IA o que deve ser entregue e proteja você mesmo o que não deve sair da sua mão.
Três hábitos de decisão:
-
Crie consciência de “conhecimento vs direção”. Ao encontrar um problema, pergunte primeiro: isto tem resposta padronizada? Se não tiver, pense por conta própria.
-
Separe “fase de protótipo vs fase final”. Use IA com ousadia no protótipo; controle com cuidado na fase final.
-
Toda vez que usar IA, pergunte: esta tarefa tem alto valor criativo? Exige meu julgamento estético? Afeta a manutenção de longo prazo?
Nenhuma IA consegue responder essas perguntas por você. Elas são a capacidade central de um desenvolvedor independente: julgamento.
Julgamento vem da experiência. Usar IA não acumula julgamento; pode acumular dependência. Julgamento só se acumula julgando.
IA é uma boa ferramenta, mas não deixe que ela julgue por você.
Quer entender como usar IA na prática? Veja o artigo 13 desta série, “Desenvolver minigames em Cocos com apoio de IA: meu fluxo completo e comparação de eficiência”, que detalha o método. Para aprender a escrever requisitos para IA, veja o artigo 14, “Como escrever requisitos de minigames para IA: cenas, nós, componentes e interações”. Este artigo oferece o framework de decisão; os próximos trazem a prática concreta.
FAQ
Código gerado por IA pode ir direto para produção?
A arte de um jogo pode ser gerada por IA?
Como um desenvolvedor independente decide se uma tarefa deve ir para a IA?
Quais funções aceitam mais e menos a IA?
A IA vai substituir desenvolvedores independentes de jogos?
Como evitar o pesadelo arquitetural causado por dependência excessiva da IA?
20 min de leitura · Publicado em: 23 mai 2026 · Atualizado em: 14 jul 2026
Desenvolvimento de mini games Cocos com IA
Se você chegou pela busca, o caminho mais rápido é ir para o post anterior ou próximo desta série.
Anterior
Como descrever requisitos de jogos para IA: cenas, nós, componentes e interação
Como escrever requisitos de desenvolvimento de jogos para IA? Veja o método dos quatro elementos de cena, JSON de árvore de nós, template de componentes e fórmula de interação.
Parte 17 de 21
Próximo
Depois do MVP de um minigame: como saber se vale continuar
Use 5 métricas de referência e uma matriz de decisão em três dimensões para avaliar se vale continuar desenvolvendo um MVP de minigame, com casos reais, diferenças entre WeChat e Douyin e um fluxo de decisão em 5 passos.
Parte 19 de 21
Comentários
Entre com GitHub para comentar