Quais são as maiores armadilhas a considerar ao desenvolver um novo jogo?

Na verdade, eu apenas comecei a rastrear (obrigado David Young pela correção da nomenclatura) alguns novos jogos baseados na Web para o Facebook há algumas semanas atrás e acabei de ser inundado com bloqueios mentais e o tempo é ruim com a recodificação. Estou trabalhando em algo semelhante ao RPG baseado em turnos (Vampire Wars). Eu tenho as habilidades necessárias para codificar um jogo, mas estou tentando conseguir os padrões de design corretos e fazer o produto corresponder ao que vejo nos meus olhos.

Normalmente, ao criar um site, gosto de 'pensar em código' e acho mais rápido alterar o código / HTML para ajustá-lo. Isso provavelmente ocorre porque me sinto MUITO confortável no que faço e sei o que esperar como eu fiz várias vezes. Neste ponto, com o desenvolvimento de jogos, eu me pego começando no papel novamente (como costumava fazer nos sites) e me pergunto se isso é apenas minha falta de foco e intuição com a lógica dos jogos ou se é uma maneira apropriada de mostrar meus pensamentos. avanço da codificação.

Eu gostaria de receber alguns conselhos sobre como atacar corretamente esse problema e me manter na tarefa. Estou aprendendo rapidamente o quão diferente é um mecanismo de jogo em um site comercial padrão! Toda vez que eu coloco algo no lugar, ele se sente meio nebuloso e incompleto e está se tornando frustrante.

Estendido

Como exemplo, o mecanismo de batalha que me causou tantos problemas recentemente usa uma habilidade de ataque simples e depois faz um teste aleatório entre -50% e + 50% e multiplica a habilidade de ataque original contra esse percentual. A mesma coisa é feita com a defesa e, então, eu as uno para determinar se algum dano é causado à saúde do inimigo. Acho que eu deveria perceber que estou louca quando comecei a me perguntar se essa é a maneira certa de fazê-lo, ou se existe uma maneira "certa". Uma falha grave que encontrei com isso é que dois personagens do mesmo nível podem ter várias jogadas em que o ataque é de -50% e a defesa é de + 50%, então acabo com algumas sequências de batalha EXTREMAMENTE longas em que ninguém faz nada. FALHOU

Talvez meu post devesse estar pedindo links sugeridos descrevendo a lógica simples do jogo.

Extensão final

Obrigado a todos antecipadamente!

adicionando muitos recursos. Concentre-se no núcleo do jogo, construa-o e, se tudo funcionar bem, adicione recursos. As pessoas ficam muito focadas em adicionar coisas legais e nunca fazer nada.

Este é um ótimo artigo sobre como criar um protótipo de um jogo. Da sua pergunta, parece que você está perdendo a ideia do que um protótipo deveria ser.

Prototipagem: você (provavelmente) está fazendo errado

Destaque:

Erro # 4: Construindo um sistema, não um jogo
Quando você cria um protótipo, se você se encontra trabalhando em algo que não está avançando diretamente, pare aí. Como programadores, temos a tendência de tentar generalizar nosso código, torná-lo elegante e poder lidar com todas as situações. Achamos que uma coceira terrivelmente difícil não arranha, mas precisamos aprender como. Levei muitos anos para perceber que não é sobre o código, é sobre o jogo que você lança no final.

Não escreva um sistema elegante de componente de jogo, pule completamente o editor e conecte o estado no código, evite a loucura XML, baseada em dados e de análise automática, e apenas codifique a maldita coisa.

Editar:

Estou adicionando isso apenas para esclarecer a diferença entre o Prototype e o Tracer Code.

Lembre-se sempre: um protótipo foi projetado para ser jogado fora! O código do rastreador não é.

A armadilha do protótipo

... A abordagem do código rastreador soluciona um problema diferente. Você precisa saber como o aplicativo como um todo se une. Você deseja mostrar a seus usuários como as interações funcionarão na prática e deseja dar a seus desenvolvedores um esqueleto arquitetônico no qual travar o código. Nesse caso, você pode construir um rastreador que consiste em uma implementação trivial do algoritmo de empacotamento de contêiner (talvez algo como primeiro a chegar, primeiro a ser servido) e uma interface de usuário simples, mas funcional. Depois de ter todos os componentes do aplicativo juntos, você tem uma estrutura para mostrar aos usuários e desenvolvedores. Com o tempo, você adiciona a essa estrutura com novas funcionalidades, concluindo rotinas stubbed. Mas a estrutura permanece intacta e você sabe que o sistema continuará a se comportar da maneira como se comportou quando seu primeiro código rastreador foi concluído.

A distinção é importante o suficiente para garantir a repetição. A criação de protótipos gera código descartável. O código rastreador é simples, mas completo, e faz parte do esqueleto do sistema final. Pense na prototipagem como o reconhecimento e a coleta de informações que ocorrem antes do disparo de uma única bala rastreadora.

Mais informações sobre o design do código Tracer, do The Pragmatic Programmer

Marcadores e protótipos do rastreador

Armadilhas: Não separa sua lógica dos seus dados. Não testando se seus dados produzem os resultados desejados.

Do seu comentário no post de Joe:

Você quer que eu codifique um mecanismo de batalha para encontros com monstros, BOOM! Reescrevi meu mecanismo pelo menos três vezes nesta semana e nunca me sinto bem com isso. Quero dizer, a matemática funciona, mas quando eu experimento isso parece instável. Isso faz sentido?

Parece que você está combinando o mecanismo com os dados aqui. Seu mecanismo de encontro de monstros deve ser orientado por dados. Se os dados que afetam seu equilíbrio / diversão do jogo estiverem incorretos, não será necessário reescrever completamente seu mecanismo - basta ajustar suas variáveis ​​de equilíbrio até que pareça correto.

No entanto, como as variáveis ​​de equilíbrio às vezes são interdependentes, alterar uma variável para melhor um cenário pode ter um efeito vasto (negativo) em outros cenários.

Para testar se seus dados recentemente aprimorados não afetam muitos outros casos, é útil manter alguns casos de teste por perto e garantir que eles não sejam quebrados após os ajustes. Aqui está um exemplo inventado de como você testaria isso.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

Por exemplo. Se você chamar isso com PlayerStats.Level == 5 e MonsterStats.Level == 3, você esperaria que o jogador sempre derrotasse esse monstro eventualmente.

A armadilha aqui, até onde posso ver, é que você está tratando a programação e o design de jogos como a mesma tarefa, quando na verdade são tarefas separadas. Como você sugere, este não é um problema de programação ou algoritmo (você pode codificar o sistema de batalha da maneira que quiser), é sobre o que é divertido e interessante para o jogador.

A resposta é: procure recursos em design e equilíbrio de jogos. Na verdade, existem universidades que dedicam todo um programa de estudos de quatro anos aos tópicos que você está levantando, portanto, é impossível fornecer uma resposta rápida e suja (da mesma maneira que você provavelmente ficaria surpreso se alguém dissesse " Sim, eu tenho essa idéia para um jogo, mas não sei como programá-lo, o que devo prestar atenção? "). Existem livros, cursos e textos on-line sobre design de jogos; procurá-los.

A maior armadilha ao escrever jogos é se preocupar se você está ou não usando os padrões de design certos, em vez de apenas escrever o código com o qual se sente bem.

Eu recomendaria os artigos de Steve Pavlina sobre gerenciamento de tempo e auto-motivação: http://stevepavlina.narod.ru/

Ele também é programador. Suas experiências de estilo de vida geraram algum interesse da mídia convencional.