Escolha a decisão da colônia antes de descrever seu mundo
Um prompt de gestão de colônia precisa de uma decisão com consequências, não apenas uma lista de prédios e recursos. Comece com uma ação que compete com outra, declare quando seu custo e resultado são resolvidos e anote o que significa sobreviver e concluir. O primeiro protótipo pode responder a uma pergunta: o jogador consegue planejar de modo a manter os moradores abastecidos enquanto avança um objetivo separado?
Dayglass Outpost é uma colônia de superfície fictícia usada para ensinar essa estrutura de prompt. A cada amanhecer, o jogador direciona a bateria de duas unidades do posto para uma estufa hidropônica ou um mastro retransmissor. A estufa produz refeições; o retransmissor avança um sinal. O exemplo de três dias abaixo foi calculado à mão. Nenhum prompt foi executado e não foi fornecido protótipo gerado ou testado.
Mantenha a primeira decisão pequena o bastante para acompanhar de um estado ao seguinte. Se o jogador não consegue perceber a troca que fez, acrescentar moradores, árvores de pesquisa ou clima tornará o prompt mais difícil de conferir, não mais útil.
Escreva o contrato de estado antes de pedir sistemas extras
Um prompt fica mais fácil de implementar quando cada número tem uma fase e cada ação tem um limite. Em Dayglass, a bateria reinicia ao amanhecer e o jogador precisa gastar tudo em exatamente um módulo selecionado manualmente. A verificação de rações ocorre depois da resolução do módulo. Essa ordem determina se escolher o retransmissor é seguro em um dia de pouco estoque de refeições.
| Regra | Proposta de Dayglass | O que a primeira verificação deve mostrar |
|---|---|---|
| Estado inicial | Amanhecer do Dia 1: 3 moradores, 3 refeições, sinal 0/2. A bateria volta a 2 unidades a cada amanhecer. | O jogador pode ler o dia, refeições, sinal e bateria atual antes de escolher. |
| Limite de ações | Escolher exatamente uma ação de módulo por dia. Qualquer ação gasta as duas unidades da bateria; energia não usada não pode ser guardada. | Depois de uma escolha, ambos os módulos ficam indisponíveis até o próximo amanhecer. |
| Hidroponia | Ativação manual acrescenta 6 refeições. O sinal não muda. | O estoque de refeições aumenta em seis antes da verificação do anoitecer. |
| Retransmissor | Ativação manual acrescenta um estágio de sinal enquanto estiver abaixo de 2/2. Em 2/2, fica indisponível. | Somente escolher Retransmissor avança o sinal; nunca produz refeições. |
| Verificação de rações ao anoitecer | Depois que o módulo é resolvido, confira se há pelo menos 3 refeições. Se houver menos, falhe antes de subtrair qualquer coisa. Caso contrário, subtraia 3, uma por morador. | A ordem das fases fica visível, inclusive falha sem consumir estoque. |
| Fim e reinício | Depois da etapa de rações do Dia 3, vença com sinal 2/2 se nenhuma verificação de rações falhou. Caso contrário, perca. Reiniciar restaura o estado completo do Dia 1. | A vitória depende do objetivo e da verificação de sobrevivência, não de pontuação nem de evento oculto. |
Esta tabela fecha várias lacunas que um prompt curto de gênero deixaria em aberto. Ela diz quando a energia retorna, se o jogador pode dividir uma ação, se o retransmissor pode ser repetido após concluir e se a comida é verificada antes ou depois do consumo. Se quiser alterar uma dessas regras, mude primeiro o contrato e recalcule o exemplo.
Calcule manualmente três dias antes de acrescentar recursos
Antes de pedir a um gerador que construa uma colônia, acompanhe uma rota com as regras propostas. A aritmética pode revelar uma condição de vitória impossível ou um atalho indesejado antes que arte, moradores ou mais recursos dificultem o diagnóstico do protótipo.
| Dia | Ação | Refeições antes da verificação do anoitecer | Sinal após a ação | Anoitecer e estado final |
|---|---|---|---|---|
| 1 | Retransmissor | 3 | 1/2 | Subtrai 3 refeições. Termina com 0 refeições e sinal 1/2; a colônia sobrevive. |
| 2 | Hidroponia | 6 | 1/2 | Subtrai 3 refeições. Termina com 3 refeições e sinal 1/2; a colônia sobrevive. |
| 3 | Retransmissor | 3 | 2/2 | Subtrai 3 refeições. Termina com 0 refeições e sinal 2/2; a colônia vence após a verificação final de rações. |
O resultado depende da ordem escrita no contrato: a produção do módulo é resolvida antes do anoitecer. Se Hidroponia funcionasse depois da ração, o estado do Dia 2 seria diferente. Outra rota pode começar com Hidroponia e depois usar Retransmissor duas vezes; pelas mesmas regras, sobram refeições para as três verificações. Por outro lado, repetir Retransmissor no Dia 2 após a escolha da tabela no Dia 1 deixa zero refeições antes do anoitecer, e essa rota falha sem subtrair estoque.
Este é um exemplo didático calculado à mão, não um teste de balanceamento. Guarde-o como referência de estado esperado para um protótipo futuro, não como prova de que uma implementação seguiu as regras.
Use três prompts em vez de um pedido sobrecarregado
Separe o esclarecimento das regras da implementação e da correção. Isso facilita revisar cada solicitação e detectar contradições antes de expandir a cena. Estes prompts prontos para experimentar descrevem o design fictício; não foram executados.
Prompt 1: peça uma folha de regras
Transforme esta ideia de colônia em um contrato de regras compacto. Não acrescente sistemas. Estado inicial: amanhecer do Dia 1, 3 moradores, 3 refeições, sinal 0/2, bateria de 2 unidades. A cada amanhecer, redefina a bateria para 2. O jogador escolhe exatamente uma ação manual, gastando as duas unidades. Hidroponia acrescenta 6 refeições. Retransmissor acrescenta 1 estágio de sinal apenas se o sinal estiver abaixo de 2/2. Resolva a ação selecionada antes do anoitecer. Ao anoitecer, se houver menos de 3 refeições, falhe sem subtrair refeições; caso contrário, subtraia 3. Após a etapa de rações do Dia 3, vença somente se o sinal estiver em 2/2 e nenhuma verificação de rações tiver falhado. Reiniciar restaura todo o estado inicial. Retorne: (1) variáveis de estado, (2) ordem das fases, (3) ações permitidas e limites, (4) regras de vitória/derrota e reinício e (5) ambiguidades ou contradições. Resolva manualmente Retransmissor no Dia 1, Hidroponia no Dia 2 e Retransmissor no Dia 3. Não afirme que essas regras foram testadas nem invente eventos extras.
Compare o contrato retornado com as regras de origem antes de continuar. Se ele mover a verificação de rações, permitir guardar bateria não usada ou acrescentar um custo oculto de comida, corrija a folha de regras em vez de pedir uma construção maior.
Prompt 2: peça somente o protótipo mínimo
Construa um pequeno protótipo para um jogador de colônia de superfície chamado Dayglass Outpost com base no contrato de regras abaixo. Mostre um habitat compacto, uma estufa hidropônica, um mastro retransmissor, três moradores e um estoque de refeições. Use uma vista de gestão de cima ou isométrica clara, com caminhos legíveis entre módulos. Exiba o dia atual, refeições, progresso do sinal, bateria, ação selecionada e resultado resolvido. Dê ao jogador uma escolha manual de módulo por dia. Redefina a bateria para 2 ao amanhecer; qualquer módulo consome as 2 unidades. Hidroponia acrescenta 6 refeições. Retransmissor acrescenta 1 estágio de sinal enquanto estiver abaixo de 2/2. Resolva o módulo antes de verificar ao anoitecer se há pelo menos 3 refeições; em caso de falha, pare antes de subtrair. Caso contrário, subtraia 3 refeições. Depois da verificação do Dia 3, vença somente com sinal 2/2. Reiniciar restaura Dia 1, 3 moradores, 3 refeições, sinal 0/2 e bateria 2/2. Omita clima, atribuições de trabalhadores, automação, criaturas, recursos extras, árvores de pesquisa, combate, eventos aleatórios e multijogador. Mantenha o retorno ligado à ação escolhida. Trate isto como design proposto; não relate resultado de teste.
Isso pede uma decisão e estado visível suficientes para inspecioná-la. Não pede todos os recursos de uma colônia de uma só vez. Se a ferramenta retornar algo diferente, registre o resultado real antes de mudar o prompt; não presuma que o comportamento solicitado apareceu.
Confira as regras que podem mudar silenciosamente
Use verificações específicas em vez de uma pergunta ampla como “está funcionando?”. A lista abaixo é um plano para um protótipo real futuro. Contém resultados esperados, não testes aprovados.
| Tentativa | Estado esperado | Divergência a registrar |
|---|---|---|
| Começar uma partida nova. | Dia 1, 3 refeições, sinal 0/2, bateria 2. | Qualquer valor inicial ausente ou diferente. |
| Escolher Retransmissor e tentar selecionar Hidroponia de novo antes do amanhecer. | Retransmissor gasta as duas unidades, avança o sinal a 1/2 e a segunda ação fica indisponível. | Duas ações resolvidas no dia ou bateria transferida. |
| Resolver Retransmissor no Dia 1 e depois escolher Retransmissor novamente no Dia 2. | A segunda verificação ao anoitecer encontra 0 refeições e falha antes de subtrair estoque. | Comida fica negativa ou a partida continua apesar da verificação falha. |
| Usar Retransmissor → Hidroponia → Retransmissor em três dias. | Refeições ao fim do dia são 0, 3 e 0; sinal é 1/2, 1/2 e 2/2. A partida vence depois da etapa de rações do Dia 3. | Qualquer transição diverge do percurso calculado à mão. |
| Tentar Retransmissor quando o sinal já está em 2/2. | Retransmissor indisponível; sinal permanece no limite. | Sinal ultrapassa 2/2 ou surge outro estágio de conclusão. |
| Reiniciar depois de um resultado. | Voltar ao Dia 1 com 3 refeições, sinal 0/2, bateria 2 e 3 moradores. | Estoque, dia ou resultado anterior permanece. |
Em cada verificação, anote a ação exata e o que a interface mostrou. Se não houver protótipo para inspecionar, mantenha isto como lista planejada. Um resultado previsto pela tabela não é o mesmo que um resultado observado em jogo.
Peça uma revisão baseada em uma observação
Quando um protótipo real divergir do contrato de regras, dê à próxima solicitação uma tarefa delimitada. Diga o que fez, o que esperava e exatamente o que apareceu. Peça alteração somente da regra envolvida e preserve o restante. Depois repita a mesma sequência de ações. Assim, o reparo se vincula a evidências, em vez de acrescentar sistemas em resposta a uma impressão vaga.
Divergência observada no meu protótipo atual: Ação: [dia exato e módulo selecionado] Esperado: [estado da tabela de regras] Observado: [o que o protótipo mostrou] Altere somente a regra responsável por esta divergência. Mantenha iguais todos os outros recursos, tempo das ações, condições de vitória/derrota e elementos da interface. Diga qual regra mudou e liste a mesma verificação que devo repetir. Não afirme que a correção foi testada até que eu execute a verificação novamente.
Se você não executou um protótipo, não preencha a linha “Observado” usando o percurso calculado à mão. Deixe-a como modelo. O percurso oferece algo para comparar depois; ele não fornece uma observação real.
Escolha um cenário pequeno de colônia
A página atual do Free AI Game Maker da SEELE descreve como inserir uma ideia de jogo em linguagem simples, revisar um resultado jogável em 2D ou 3D, iterar no Workspace e conferir os custos de Koin e as opções da conta exibidos antes da geração. São detalhes gerais do fluxo de trabalho. A página não comprova compatibilidade com Dayglass Outpost, gestão de colônia ou essas regras exatas de recursos.
Leve o contrato de regras e a tabela de verificações como seu próprio briefing de design. Inspecione qualquer resultado disponível, compare seu estado visível com uma transição esperada e decida se deve revisar ou simplificar. A descrição de uma página não prova que este exemplo foi gerado nem que um resultado corresponderá a todas as regras solicitadas.
Perguntas frequentes
Quais mecânicas pertencem ao primeiro prompt de colônia?
Inclua recursos iniciais, uma ação do jogador, seu custo e resultado, quando a ação é resolvida e a condição verificada depois. Acrescente regras de vitória, falha e reinício para fechar o ciclo. Deixe funções de trabalhadores, clima, pesquisa e automação para depois, a menos que uma delas altere a decisão que você quer inspecionar.
Com quantos recursos um protótipo de colônia deve começar?
Use somente os recursos necessários para tornar a decisão central compreensível. Dayglass começa com refeições, bateria e sinal porque esses valores explicam a troca entre alimentar os moradores e concluir o retransmissor. Se um recurso não mudar a escolha de ação, a verificação de sobrevivência ou o objetivo, omita-o do primeiro pedido.
Como mostrar claramente produção e consumo?
Mostre o estado antes da escolha, resolva o módulo selecionado e depois mostre a verificação ao anoitecer e o estoque final. Separar essas fases facilita identificar se a produção chegou tarde ou se uma ração foi descontada duas vezes. O painel exato pode variar; o prompt precisa especificar quais valores o jogador deve conseguir inspecionar.
O que deve acontecer quando uma verificação de rações falha?
Escolha a regra de falha antes de escrever o prompt. Neste exemplo, um estoque abaixo de três refeições causa falha antes de qualquer refeição ser subtraída, então o estado exibido permanece consistente com a regra. Outra colônia pode permitir escassez ou rações parciais, mas o prompt deve dizer como essas opções alteram o estoque e se a partida continua.
Um prompt detalhado garante um jogo de gestão de colônia jogável?
Não. Um prompt detalhado facilita inspecionar as regras solicitadas, mas não prova que uma ferramenta específica as implementará corretamente. Revise o resultado real, confira as transições de estado importantes e mantenha qualquer divergência visível em suas notas. Trate os valores de Dayglass como exemplo didático fictício, não como resultado testado.
Construa um ciclo de colônia que possa ser conferido
Escreva a decisão, o tempo, as mudanças de recursos, a verificação de sobrevivência e a condição final antes de pedir uma colônia maior. Resolva manualmente uma rota, inspecione um resultado real por vez e use a primeira divergência para orientar uma revisão delimitada. Quando estiver pronto para experimentar seu próprio briefing, comece pelo Free AI game maker. Confira o custo atual exibido e verifique o que o protótipo resultante realmente faz. Crie jogos com IA grátis
