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

19

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!

angryCodeMonkey
fonte
1
Esta é uma leitura algo relacionado e interessante que eu encontrei útil: makegames.tumblr.com/post/1136623767/finishing-a-game
zfedoran

Respostas:

22

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.

Assustadores
fonte
4
Isso quase matou um dos meus jogos FB. É repleto de recursos, mas a coisa toda parece meio idiota.
Tesserex 01/10/10
Se bem me lembro, esse fenômeno é chamado de "fluência de recursos". Uma armadilha perigosa, de fato.
S. Tarık Çetin 21/03/19
14

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

David Young
fonte
Isso é ótimo ... vou ter que dar uma olhada nesse artigo. Apenas no trecho que você postou, parece que eu estou olhando a prototipagem incorretamente, mas também parece que pode ser um erro comum.
AngryCodeMonkey
o erro que você citou está me incomodando há um bom tempo.
Jokoon 01/10/10
4

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.

jpaver
fonte
Os conselhos que recebo aqui são ótimos e posso ver que estou adotando a abordagem errada em relação a isso. A razão, no entanto, de ter reescrito o mecanismo é que acho que o estou tornando muito complicado. Minha versão mais recente do mecanismo de batalha é uma classe com (no momento) uma única função pública e vários suportes. A principal função 'luta' não é apenas calcular o ataque básico contra a defesa, mas também determinar o primeiro ataque, verificar as jogadas para determinar se sua habilidade tática lhe dá um segundo ataque, etc., etc., etc. Acho que acabei de fazer isso difícil!
AngryCodeMonkey 02/10
Não separando sua lógica dos seus dados. Esse é um ótimo ponto, que quase sempre causa problemas no caminho ou durante a atualização!
Assustadores
2

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.

Ian Schreiber
fonte
1

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.

user744
fonte
O problema que estou tendo agora é me sentir bem com o código que estou escrevendo. Você quer um back-end contábil para o seu negócio, não há problema ... 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?
AngryCodeMonkey 01/10/10
por que reescrever o mecanismo? você pode implementar código específico do jogo em uma linguagem de script como lua. Altere variáveis ​​ou como a matemática é calculada e nunca precisará recompilar apenas para verificar as coisas. gamedev.net/reference/articles/article1932.asp
David Young
1

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.

canto superior direito
fonte