Com pouco tempo disponível para concluir os jogos que criamos, como você pode encontrar um bom equilíbrio entre uma arquitetura sólida de software e fazer um bom progresso para fazer tudo isso?
Meu desafio pessoal: que tal ser eficaz hoje e pensar a longo prazo ao mesmo tempo? Além disso, enquanto você está fazendo isso, pode querer aprender coisas novas a caminho, em vez de recorrer aos mesmos padrões repetitivos que você usa nesses últimos cinco anos?
Respostas:
Quanto menos experiência você tiver, mais tempo perderá com o design inicial. Fazer bons projetos é algo que você aprenderá fazendo e depois vendo / avaliando como ficará. Algumas decisões têm implicações de longo alcance, mas obscuras. Após alguns jogos, você provavelmente conseguirá tornar o design inicial bastante sólido e valerá a pena investir mais tempo nesse estágio.
Meu lema: faça as coisas em primeiro lugar, mas use seu bom senso para detectar quais componentes são mais críticos que outros e os projeta muito bem, dentro do seu limite de tempo. Por exemplo, se a IA for essencial para o seu jogo, certifique-se de que você pode estender / alterar facilmente mais tarde. Ou, se você estiver escrevendo um componente que usará em todos os jogos, projete-o para reutilização. Acompanhe o seu tempo e não se preocupe em projetar. Defina um prazo de design e depois disso, comece a invadir tudo para obter seu prazo de liberação. Mas lembre-se de observar quais pontos precisam ser refatorados / reprojetados posteriormente e calcule em algum tempo antes de iniciar o próximo jogo para melhorar essas coisas, para que eles não o mordam de volta!
Um bom conselho: se você tiver que escolher entre duas opções, não demore muito nos detalhes. Na maioria das vezes, não há "bom" ou "ruim". Em algumas situações, A será melhor, em algumas, B será e, em geral, a diferença entre os dois nem sempre vale o tempo.
Há muita experiência a ganhar na criação de software ou jogos; portanto, dedique um pouco do seu tempo à pesquisa (por exemplo, lendo um livro sobre design, lendo sobre a experiência de outras pessoas, conversando com outros programadores sobre seus designs, etc.) )
As pessoas são terríveis em prever o futuro. Isto é especialmente verdade para jogos, onde os requisitos podem mudar diariamente.
Há um princípio chamado YAGNI , também conhecido como "Você não vai precisar", que basicamente diz que você não deve implementar algo até saber que vai precisar.
Eu já vi tantos sistemas atolados com a rigidez arquitetônica que na verdade não usava nada, já que os recursos que as pessoas pensavam que precisariam nunca chegaram a ser usados.
Minha filosofia pessoal é fazer a coisa mais simples possível . Dito isto, há uma diferença entre Getting It Done e Hacking Shit Together. Escrever código com um propósito não deve implicar em coisas que geram "cheiro de código", como tornar tudo público, ter classes de blob que fazem tudo, ou qualquer uma dessas dezenas de outras coisas que significam código "ruim".
Isso avalia como verdadeiro em minha mentalidade hoje:
Sou amigo da prototipagem rápida de software. Especialmente durante o desenvolvimento do jogo. É bom para aprendizado rápido, teste e uso de coisas. Para programação próxima a hardware ou algoritmos complicados, é o melhor método para mim.
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();Minha versão do Rapid Prototype deve ter uma crosta de protótipo adequada:
Vantagens:
Se você fizer isso bem, poderá ter uma versão de depuração / aprendizado real do seu produto no final.
Estamos usando no nosso projeto e estamos felizes com isso.
Veja o desenvolvimento ágil de software . Embora não seja uma bala de prata, o objetivo é fazer as duas coisas (fazê-lo e ter um design de software sólido).