Vale a pena planejar antes de pular no código?

Eu sempre pensei que o planejamento é importante para um jogo. Mas eu não sei em que ponto. Alguns estão me dizendo para codificar em vez de planejar, mas eu sinto que ainda é importante porque, quando você estiver no código, saberá o que fazer a seguir mais facilmente. Atualmente, estou trabalhando em um jogo que terá muito conteúdo, então decidi iniciar um documento de design que introduza esse conteúdo e, em um nível lateral, estou fazendo provas de conceito para verificar se isso pode ser feito. Partes de cada prova de conceito poderiam ser usadas posteriormente no jogo real.

Edição: Eu estou trabalhando sozinho neste projeto.

Então, minha pergunta é: vale a pena planejar antes de pular o código? Ainda estou interessado em saber o que os outros têm a dizer sobre isso. Porque eu ainda entendo algumas pessoas dizendo que eu deveria codificar em vez de pensar .. então qual a sua opinião sobre isso?

Você disse duas coisas inteligentes em sua pergunta:

1. "código em vez de pensar" - há toda uma filosofia descrevendo isso: http://gettingreal.37signals.com/toc.php
2. "provas de conceito para verificar se isso pode ser feito" - vi e tive muitas idéias que se tornaram impossíveis ou extremamente difíceis de serem feitas quando estavam quase terminadas. Às vezes você simplesmente não pode prever, porque o seu ambiente de programação (linguagem, bibliotecas, desempenho de hardware) o limita.

Por isso digo:

• design, mas não crie um documento de design enorme se não estiver procurando colaboradores ou investidores, a menos que seja divertido para você e você faça isso como uma pausa na programação;
• sempre tenha em mente o que você deseja alcançar; todo módulo deve ter uma entrada e saída projetadas; Dessa forma, você pode testar facilmente o módulo e não sentir que está vagando no nevoeiro;
• lembre-se de que você projeta a maior parte do tempo de qualquer maneira, pois a digitação do código leva apenas cerca de 5% do seu tempo (pelo menos digitando o código final);
• a programação não é uma ciência teórica; em vez de verificar se algo funcionará em um pedaço de papel, você pode simplesmente codificá-lo e tentar; o produto final é principalmente para tornar a entrada do usuário infalível, a GUI com boa aparência e lidar com casos especiais - um teste sujo de uma ideia pode ser feito imediatamente;
• crie uma lista de tarefas se tiver medo de esquecer suas idéias
• converse com seus amigos sobre suas idéias, pois elas serão menos entusiasmadas e poderão ter mais experiência em um campo; uma vez eu tive uma idéia de manter os parâmetros da unidade (em um jogo estratégico) em segredo, mas meu amigo me disse que é uma má idéia, pois ele jogou um jogo como esse e foi uma experiência terrível para o usuário.

Sim, mas só um pouco .

Para a programação de jogos, especialmente a programação de jogos, é essencial ter um bom caso de uso antes de escrever qualquer código. Por exemplo, o que o jogador deve fazer, para onde ele deve ir e como, como ele interage com o mundo etc. Isso pode ser um storyboard esboçado no papel ou sair de uma discussão com um colega ... Isso faz parte do design do jogo , e será uma tolice começar a codificar sem sequer uma idéia aproximada de como o jogo deve ser jogado.

Mas os jogos precisam ser criados iterativamente . Você não pode criar uma grande especificação para o seu jogo e espero que seja divertido de jogar. Você precisa de testes de reprodução regulares para descobrir o que funciona e o que não funciona e manter a iteração. Quanto mais rápido o executável é executado, mais rápido o design do jogo pode ser testado, melhor o jogo fica no final. Portanto, é sempre melhor começar a codificar o mais rápido possível, a partir de um design de jogo não formal, ver o que sai e continuar.

Uma coisa é certa: como você está codificando sozinho, não precisa de nenhum documento ou metodologia sofisticado de design de software, o código-fonte é o design.

Alguns dizem que você deve codificar em vez de pensar? Bem, para codificar, você precisa saber o que deseja criar, para saber o que deseja criar, primeiro precisa pensar no que deseja ter, logo, precisará pensar antes de codificar;).

E sério, você provavelmente não precisa de um plano detalhado logo no início, mas ter um esboço e / ou marcos é sempre benéfico - também para sua atitude, quando você cruza as coisas como feitas, você será mais incentivado a fazer mais trabalhos.

Tanto a codificação quanto o planejamento são necessários. Primeiro planeje, depois codifique, mas não planeje tudo de uma vez. Planeje um núcleo, codifique-o, atualize seu plano conforme necessário e, em seguida, planeje recursos que aumentam a jogabilidade, gráficos, sons, sprites etc. etc, isso fará com que o jogo que você está criando pareça melhor e, em geral, melhor. Você pode executar esse ciclo mais de uma vez, obviamente, e eu aconselho você a tomar decisões que darão suporte ao aumento de escala, se necessário.

Você precisa saber para onde está indo antes de escrever código e escrever / desenhar pode ser uma boa maneira de materializar o que você deseja alcançar. Digo desenho porque desenhar diagramas, esboços etc. também pode ajudá-lo bastante. Você não precisa criar um documento maravilhoso feito com o Word ou algo assim, basta pegar um lápis e um pedaço de papel (muitos pedaços de papel?) E desenhar, escrever tudo o que possa pensar.

Para mim, é uma boa prática usar lápis e papéis, ajuda a materializar suas idéias e também define onde você deseja ir para evitar ir a qualquer lugar, fixar seu objetivo. Funciona para tudo o que precisa de reflexão. E é óbvio em muitos domínios escrever as coisas antes de fazer o trabalho real.

Faça o que funciona para você. Pessoalmente, planejo as coisas em pequena medida, mas não tenho documentos de design, são planos extremamente detalhados antes de começar a codificar qualquer coisa. Faça o que for mais produtivo para você, especialmente porque você está trabalhando sozinho.

(Presumo que a pergunta seja feita do ponto de vista do design de código / arquitetura, não do design de jogos, embora a resposta, pelo menos até certo ponto, se aplique a ambos.)

Como já foi dito, você precisa de ambos e precisa equilibrá-lo. A superexposição e a subexposição do fluxo / estrutura do código podem causar problemas. É difícil dizer qual é o equilíbrio certo, mas geralmente acho que preciso ter pelo menos uma vaga idéia de como o restante do código se juntará ao que estou programando no momento e pensar em possíveis problemas, caso contrário, eu tendem a "me codificar para um beco sem saída" - entrar em uma situação em que percebo "ok", agora, graças à forma como resolvi esse problema, criei um novo problema que processou toda a minha solução anterior (ou até mais, nos piores casos) ) Fútil".

Geralmente, na minha opinião, você pode julgar grosseiramente se tem o equilíbrio certo pensando nos cenários "e se" como em "e se eu depois" (quando tudo estiver totalmente implementado no paradigma semelhante ao que estou usando agora) essa parte A precisa funcionar de maneira um pouco diferente, o que significa que eu tenho que refazer completamente a parte B que se conecta a ela para acomodar as alterações? ". Se as alterações arquiteturais em uma parte não exigirem que você altere mais de uma ou duas outras partes, e as alterações não ocorrerão em cascata (o que significa que, por sua vez, você deverá alterar também as próximas partes que se conectam à parte B e, em seguida, as partes que se conectam a etc.), o código é compartimentado de maneira relativamente boa.

Mas, na verdade, é algo que você sentirá depois de ganhar alguma experiência. Isso é parcialmente porque todos dão conselhos aos iniciantes para codificar primeiro algo conhecido e fácil (Breakout / Tetris / Snake) e fazê-lo completamente, com todos os menus, sons, efeitos, tudo para torná-lo um jogo completo - é melhor estragar um projeto menor, e fazê-lo (seja de uma maneira boa ou ruim) ajudará exatamente você a ter uma idéia de quão longe os efeitos de várias decisões arquiteturais se estendem.