Quão detalhados e / ou completos são / são os seus documentos de design do jogo antes de iniciar um projeto?

O que eu quero saber é como os documentos de design são completos antes de iniciar a implementação de um projeto? Estou falando de projetos médios a muito pequenos, com uma equipe muito pequena aqui, onde até o documento completo pode ser de apenas algumas dezenas de páginas.

Você começa com uma estrutura grosseira e começa a detalhar os detalhes ao mesmo tempo em que a implementação está sendo iniciada?

Você detalha todas as seções completamente antes mesmo de iniciar qualquer implementação? Em caso afirmativo, que alteração percentual você viu após o início da implementação?

Se você tiver experiência com um dos dois cenários que descrevi, adoraria ouvir sua opinião sobre quais problemas seguiram essa rota específica e quais obstáculos você acha que ajudaram a evitar.

Se a ideia do jogo é fortemente baseada em algum conceito incomum de jogabilidade , eu protótipo isso imediatamente , usando um projeto anterior como modelo. 95% do tempo leva a perceber que não é tão divertido quanto eu imaginava, e para torná-lo divertido seria necessário mais recursos do que vale a pena.

Entretanto, se estiver trabalhando em outro projeto, dedique um tempo, faça um doodle para ter uma idéia de como deve ser o protótipo (tente não se distrair com o sketch art). Depois, compartilho com os amigos, em parte para ver se eles têm alguma opinião, mas principalmente para me fazer pensar em coisas que não são óbvias imediatamente (sempre existem toneladas de coisas, mesmo para as pessoas mais inteligentes que pensam nas idéias mais simples). Depois de algumas horas assim, vou anotar alguns conceitos-chave que precisam estar na arquitetura, literalmente ~ 20 palavras. Então eu posso construir um protótipo quando tiver tempo.

Atualmente, meus designs de jogo foram detalhados adequadamente antes de começar.

Vou detalhar a maioria das classes importantes, desenhar algumas maquetes (os desenhos geralmente são horríveis), fazer uma descrição do jogo.

Embora isso se deva principalmente a um longo trajeto para o trabalho e mais nada a fazer. Prefiro gastar menos tempo fazendo isso e mais tempo programando, pois desenvolver classes que provavelmente vão mudar parece um exagero.

Trabalhando em equipes pequenas em jogos pequenos (equipes de um homem em jogos casuais pequenos), mudei de "design pesado" para "design rápido". Acho que o desenvolvimento iterativo (duas semanas focadas em um único objetivo, por exemplo, jogabilidade básica) ajuda a aprimorar o design e oferece algo para você jogar, o que significa que você não mudará de idéia e invalidará 90% do que projetou. parecia bom "no papel", mas não no jogo.

Dito isto, passo a maior parte do meu tempo de design na mecânica e jogabilidade principais (como o jogo principal funcionará), e isso raramente muda muito - ele muda e às vezes eu pego novas idéias ou largo idéias antigas; mas nada acontece sem um protótipo funcional.

No lado técnico, qualquer coisa deve refletir pelo menos alguns minutos antes de tornar o código real. Mas você sempre pode refatorar mais tarde.

A documentação do projeto tem um custo de manutenção; À medida que as coisas mudam, você deve voltar e reler e atualizar os documentos existentes. Como tal, deve ser um objetivo de produção minimizar a quantidade de documentação que pode ser mantida, pois isso maximizará o tempo gasto na construção do jogo.

A partir daí, segue-se que você não deseja projetar tudo com os mínimos detalhes de antecedência, porque sabe muito bem que metade disso mudará e estará lidando com muito tempo perdido. Faça o design mínimo necessário para começar a criar o jogo principal. Quando terminar, itere conforme necessário e repita o processo para cada novo recurso.