Como você se prepara para a fluência dos recursos?

Como posso me preparar para a fluência de recursos durante a pré-produção?

A fluência do recurso é quando você está na fase de produção e decide "Seria legal se isso fosse um recurso!" Isso adiciona n horas ao tempo de desenvolvimento que não foram contabilizadas e, a menos que você seja da Blizzard, não tem tempo para isso. Você não pode prever que seja um recurso interessante durante a pré-produção, porque o recurso é descoberto apenas durante a produção.

O que posso fazer durante a pré-produção para explicar, prevenir ou preparar a fluência de recursos?

Devo permitir que os recursos fluam e corte menos recursos desejados? Ou isso criará problemas, já que a arquitetura não foi projetada para os novos recursos? Devo dizer que não há recursos, a menos que eles se encaixem na arquitetura existente?

Sei que essa é uma pergunta ampla, mas espero que não seja fechada como tal. Esta é uma questão importante no desenvolvimento de jogos e deve ser considerada.

Embora, naturalmente, não haja regras rígidas no que se refere à pré-produção, há uma variedade de heurísticas para ajudar. Algumas características são naturais e necessárias - nenhum plano sobrevive ao primeiro contato com a realidade, e talvez você não saiba o que seria "legal" até vê-la.

Primeiro, prepare seu desenvolvimento. Desenhe seu esboço em um mapa de recursos e, em seguida, procure maneiras de agrupar seus recursos em iterações testáveis , cada uma com um prazo . Depois de iniciar uma iteração, resista a adicionar novos recursos a ela. Quaisquer necessidades técnicas imprevistas devem, obviamente, entrar na iteração atual, mas novas idéias de recursos devem entrar em uma lista para consideração futura. Você pode considerar se deve ou não adicioná-lo a uma iteração quando a atual estiver concluída.

Isso segue o método MoSCoW , no qual você categoriza os recursos da seguinte forma:

• Deve ter - recursos que são vitais para que a iteração atual seja estável , ou seja, testável . Se a iteração não funcionar sem ela, é essencial.
• Deveria ter - recursos que precisarão ser concluídos em algum momento, mas se a iteração passar ao longo do tempo, poderá ser empurrada para a próxima iteração . As coisas exigidas por um editor, por exemplo, podem ir aqui.
• Poderia ter - recursos que você acha que podem ser importantes para a iteração atual, mas que podem ser retirados do projeto. Esses são os recursos importantes de polimento .
• Não haverá - itens que potencialmente alimentam o backlog , recursos identificados nesta iteração a serem considerados para iterações posteriores.

Idealmente, você deseja que o desenvolvimento seja um refinamento progressivo, não tudo ou nada. Trabalhando dentro de um prazo final, os recursos menos importantes devem ser levados ao fim, para que tudo o que você não consiga seja algo que possa ser cortado. Certifique-se de estimar quanto tempo cada recurso levará para desenvolver e refinar essas estimativas à medida que avança. Nunca comprima a programação para liberar espaço para mais recursos. Resista a empurrar prazos (iteração ou final) para o futuro - mova ou corte recursos, se possível. Se você está chegando ao prazo e o jogo ainda é uma bagunça que não pode ser vendida, então você sabe que é hora de reavaliar seriamente suas decisões e considere canibalizar o projeto antes que ele se transforme em um poço de tempo / dinheiro.

• Planeje usar uma fração do tempo de pré-produção disponível para o conjunto de recursos base.
• O conjunto de recursos de base deve ser de baixo risco e alta recompensa, para que você não tenha medo deles
• O conjunto de recursos de base é mínimo e inegociável - eles devem estar presentes - caso contrário, não há uma base sólida para se trabalhar e você ficará cheio de dúvidas / / "devo substituir essa" síndrome?
• Certifique-se de que as iterações mais antigas do seu jogo sejam atraentes o suficiente para que você possa permitir a fluência dos recursos. Um jogo fundamentalmente inexpressivo não vai chegar tão longe, muito menos com fluência.
• Saiba de antemão qual a margem de fluência que você pode pagar, para poder usá-la com sabedoria.
• Use tecnologia pré-construída e altamente generalizada, como Unity, e use-a canonicamente para melhorar a flexibilidade, para que a fluência de recursos não tenha um impacto muito grande na arquitetura existente
• Não construa subsistemas complexos - uma abordagem de programação eXtreme é adequada aqui
• Peça a outras pessoas (designers e codificadores) cujos cérebros você possa tocar periodicamente para ajudá-lo a priorizar quais recursos você permitirá que ocorra, tenha alguém experiente na revisão do seu código como principal ponto de partida para essas perguntas.
• Você ainda terá que limitar a fluência dos recursos, então priorize constantemente e saiba onde traçar a linha

Por fim, não é algo que eu sugira para iniciantes, porque você precisa tomar a decisão certa em todas as etapas e isso não é fácil, mesmo para os mais experientes. Se você não tiver certeza sobre quais são as decisões corretas, tenha uma política estrita de "não rastejar além deste ponto".

Você também pode ver como o primeiro ponto e o de usar uma tecnologia que você conhece bem significa que você precisa de experiência substancial tanto em prototipagem rápida (congestionamentos de jogos) quanto no conjunto de ferramentas escolhido.