Ao prototipar, como posso explorar mais facilmente o comportamento do jogo?

Eu mesmo construo jogos independentes, mas geralmente fico sem energia depois que levo um jogo recém-desenvolvido a um nível em que é possível jogar com comportamento, por isso me refiro ao refinamento em vez de à exploração. Com resultados terríveis.

^{(foto do blog da Intercom )}

Por exemplo, acho que os ciclos de iteração para ajustar o comportamento (por exemplo, vincular e reiniciar um aplicativo C ++) são tão longos que acabam com toda a criatividade. Estou construindo uma ferramenta para lidar com isso.

Que outras maneiras existem para explorar rapidamente o comportamento do jogo? Estou interessado nas metodologias usadas por desenvolvedores independentes, bem como por empresas maiores.

Como você observou, quando você está trabalhando em mecânica de jogos, a velocidade da iteração é crítica. Quanto maior o tempo entre pensar em uma modificação e poder testá-la, menos produtivo você será e mais distraído ficará. Como resultado, você definitivamente deseja gerenciar o tempo de iteração.

Para mim, acho que minha produtividade realmente começa a diminuir quando o tempo para testar uma simples alteração excede cerca de cinco segundos. Então, quando você está tentando aperfeiçoar a aparência do jogo, um dos seus objetivos deve ser descobrir "como posso fazer uma alteração e depois jogar usando essa alteração em menos de cinco segundos". Realmente não importa como você faz isso, desde que você possa manter esse tempo de iteração até esse nível.

Muitos mecanismos modernos grandes (Unity, Unreal, etc) tendem a fazer isso colocando seu editor dentro do mecanismo do jogo, para que você possa fazer a maioria das modificações ao vivo, sem nunca reiniciar o jogo. Motores / jogos menores geralmente focam o trabalho na outra direção; faça o jogo compilar e iniciar tão rapidamente que não importa se você precisa reiniciar o jogo para cada alteração; você ainda estará testando antes desse período de cinco segundos.

No meu projeto atual, são necessários cerca de dez segundos para que eu faça uma pequena recompilação, vincule, inicie o jogo e alcance a jogabilidade (a maior parte disso está gerando geometria do mundo renderizável ao carregar um jogo salvo). E isso é muito longo. Então, eu criei modos de jogo "testando" separados, que me permitem testar diferentes partes do jogo sem carregar todos os recursos reais do jogo, para que eu possa entrar e sair muito, muito mais rápido; normalmente em cerca de dois a três segundos. Se eu quiser testar alguma interface do usuário, posso fazer isso sem carregar no jogo real. Se eu quiser testar a renderização, tenho outro modo em que posso testá-la, novamente sem carregar o sistema de jogo inteiro.

Eu já vi outras pessoas que abordaram o problema colocando a lógica do jogo em uma DLL e permitindo que o executável do jogo na memória recarregue a DLL enquanto o jogo estiver em execução, para que você possa reconstruir a DLL e apenas recarregá-la dentro de um diretório. executável já carregado, para que você não precise recarregar / reconstruir os recursos artísticos do seu jogo. Isso parece loucura para mim, mas eu já vi isso.

Muito mais simples do que isso seria especificar comportamentos e / ou configurações de jogos em scripts ou arquivos de dados e fornecer uma maneira de fazer com que o sistema recarregue esses arquivos, sob demanda, ou apenas observando-os quanto a modificações, sem precisar fechar jogo inativo, reconecte-o e inicie-o novamente.

Existem muitas abordagens. Escolha o que funciona melhor para você. Mas uma das chaves para o refinamento bem-sucedido da mecânica do jogo é a iteração extremamente rápida. Se você não tem isso, quase não importa o que mais você faz.

Para prototipar bem, reduza o custo de testar idéias.

Meu fluxo de trabalho está ajustado para jogos pequenos, mas achei estas coisas úteis:

• Tecnologia amiga do protótipo  Eu achei útil usar uma linguagem e estrutura de programação dinâmica, como Lua ( LÖVE é bom para 2D), JavaScript ou Lisp / Scheme, onde fazer com que o programa faça alguma coisa exige pressionamentos de tecla mínimos, mesmo com o custo de tudo o resto. Depois de saber o que deseja e aperfeiçoá-lo, otimize ou mova para outro mecanismo.
• Controle de versão  Mantenha os protótipos em um repositório controlado por revisão . Ramifique cedo, ramifique frequentemente. Isso mantém você confortável tentando as coisas sem se preocupar com a perda ou esquecimento de algo. (O Git tem o modelo de ramificação mais barato.)
• Automação de compilação  Certifique-se de fazer o mínimo possível para realmente executar o processo. Na minha opinião, mesmo ter que pressionar um botão é demais: eu normalmente tenho um Makefilecom um make watchalvo que roda inotifywaitem loop, reagindo às alterações de arquivos compilando / executando automaticamente o jogo. Em uma linguagem interpretada ou compilada por JIT , isso é instantâneo.

Como desenvolvedor focado principalmente em prototipagem, aqui estão alguns conselhos da minha experiência.

1. Use um mecanismo que permita fazer alterações RÁPIDAS. Isso inclui coisas como "Não aguardando compilação", mas também "alterando as coisas em tempo de execução", "facilidade de depuração", "disponibilidade de ativos de teste" etc. Eu pessoalmente amo o Unity3D, mas não é a melhor ferramenta disponível. A melhor ferramenta depende do jogo: por exemplo, o Unreal Engine compila o código muito mais lentamente que o Unity3D, mas pode iniciar rapidamente vários clientes conectados. Para um jogo em rede, isso geralmente compensa os custos de compilação. Considere também familiaridade. Se você é um gênio em C ++, mesmo o melhor mecanismo Javascript não fará muito bem e vice-versa. Não gaste tempo lutando com tecnologia desconhecida (quero dizer, aprenda outras linguagens / estruturas, mas não ao mesmo tempo em que cria protótipos importantes).
2. Aprenda a descartar recursos existentes sem piedade. Apegar-se às coisas que você já implementou é um anátema para a criação de protótipos bem-sucedidas, mas deixar o trabalho de lado é difícil.
3. Se você não trabalha com um designer de jogos, coloque uma linha clara entre "usar chapéu de programador" e "usar chapéu de designer". Adicionar um novo recurso de jogabilidade legal parece muito tentador, mas não faça isso quando estiver na posição de designer. Em vez disso, tente criar uma jogabilidade divertida (de preferência várias variantes) com o que você tem; faça uma lista de recursos que ajudariam e depois os implementasse (alguns).
4. A prototipagem rápida envolve o equilíbrio entre dois opostos. Você quer fazer as coisas o mais rápido possível, para escrever um código incorreto. Mas você quer mudar as coisas o máximo possível, por isso precisa escrever um bom código! Aprenda a equilibrar esses dois. Desculpe, não consigo pensar em nenhum conselho concreto sobre como realmente fazer isso, mas pelo menos esteja consciente desse problema (-8

Veja quanto tempo sua prototipagem requer. Na minha experiência, você deseja ter uma versão reproduzível de qualquer coisa no máximo em dois dias - começando do zero; e você deseja testar um ou dois novos recursos todos os dias. Se você não estiver atingindo essas metas, procure maneiras de ser mais rápido.

Pode-se dividir o desenvolvimento do jogo entre estas quatro fases:

• prototipagem
• refinamento de jogabilidade
• desenvolvimento
• refinamento de desempenho

Acredito que a exploração da jogabilidade acontece principalmente na fase de prototipagem e esses são alguns conselhos que tento seguir:

• Comece a projetar com um protótipo de papel. Depois de ter uma idéia clara do que poderia ser o jogo, comece a codificá-lo para que você possa realmente sentir as interações. Talvez isso seja inútil para jogos 3D, mas, pessoalmente, me ajudou muito no passado.

• Código sabendo que você jogará fora seu código depois que terminar. Isso permitirá que você seja liberal quando se trata de qual mecanismo de jogo escolher.

• Ciclos de iteração rápidos são importantes (como outros já apontaram anteriormente). Escolha um mecanismo de jogo com base em sua capacidade de mostrar rapidamente o que você codificou. Você também não precisa se preocupar com desempenho ou fidelidade gráfica nesta fase.

• Limite seu escopo. Se a jogabilidade real é 2D (jogo de estratégia usual, JRPG), protótipo em 2D. Nesta fase, você se preocupa apenas com o feedback da jogabilidade .

• Não perca tempo polindo ou procurando por ativos. Rabisque algo em um papel, tire uma foto, corte no Photoshop, talvez pinte e use-o como um sprite. Ligue o microfone e diga "banco de banco". Coloque dois cubos e uma esfera juntos e você terá um robô. Tenha sempre em mente que explorar as possibilidades de jogo é sua primeira e única prioridade.

Depois de decidir sobre um protótipo divertido, comece a refiná-lo. Eu não acho que haja uma razão para mudar de tecnologia ainda, exceto se houver um elemento de jogabilidade que precise.

Mais tarde, na fase de desenvolvimento, você manterá o protótipo refinado em mãos enquanto desenvolve um novo jogo, muito mais bonito, com muito melhor som e muito melhor. Aqui você tem que escolher o mecanismo de jogo real para usar.

No final, pegue o que você tem e ajuste-o para usar menos recursos.

A maior parte do que eu descrevi acima é de conhecimento comum, mas colocá-lo em uma lista, compartimentando todo o processo de desenvolvimento, me ajuda a colocar cada passo em perspectiva. Espero que ajude você também.

Concordo com a resposta de Trevor Powell de que a velocidade da iteração é fundamental para você permanecer no clima criativo, em vez de apenas polir. Uma grande fonte de inspiração para mim é a palestra de Bret Victor, "Inventando o Princípio" . Infelizmente, é difícil encontrar ferramentas reais nesse nível. Tentei criar um para o desenvolvimento do Python que me permite executar meu código Python enquanto o digito. Chama-se Live Coding in Python .

Criei uma ferramenta de prototipagem chamada Trabant que:

• é 3D e mecânica de jogo SOMENTE (sem UI, nenhum texto, nada);
• requer muito pouco código e nenhum recurso para construir um protótipo;
• Modelos 3D são criados em código usando arte ASCII ;
• permite iterações de sub-segundo;
• possui suporte para simulação de corpo rígido;
• funciona em Windows, Mac, Linux e iOS;
• usa uma conhecida linguagem de uso geral, Python;
• possui um IDE para Windows e iOS.

Eu construí 30 protótipos de teste nele para verificar o acima.

Como Trevor Powell enfatizou, as iterações precisam ser menores que 5 segundos, e eu acho as iterações quase cinco vezes melhores.:)

Anko mencionou que usar uma linguagem dinâmica é uma boa ideia, eu escolhi o Python, pois é um dos mais usados . Com relação à automação de compilação, o teste no Trabant é tão rápido quanto pressionar F5 no IDE (ou F6 para testá-lo no seu iPad) e, como não há etapa de compilação envolvida, não é mais instantâneo do que isso.

Throwaway código foi um dos de de Nevermind delivery . Eu concordo totalmente, e Trabant a aplica.

Além da velocidade de iteração de Trevor Powell, que é realmente importante, aqui estão algumas outras considerações úteis:

É como um bom código ...

Muitos FIs lá.

Quanto mais sólido o conceito, menos você precisa brincar. Se você sabe o que sua carne está tentando fazer, a prototipagem se torna - o que colocar e como organizar as coisas em relação ao pilar central (sua principal coisa).

Se você está começando como muitos outros - sem ter certeza do que deseja fazer, segue uma direção e explora muito o caminho da imagem exibida.

De qualquer maneira, o comprometimento com uma tecnologia é irrelevante se o que você procura pode ser simulado sem muita profundidade - faça o protótipo no que você quiser / puder.

Não perca um único segundo extra em recursos. Baixe tudo da Internet. Proprietário ou não. Você quer ter uma idéia do seu conceito no trabalho - a menos que os gráficos sejam sua principal característica, ninguém vai processá-lo por experimentar sons, texturas e tudo o mais de outras pessoas, você ainda não o está colocando na prateleira da loja. A menos que você já seja financiado - convencer as pessoas de que o conceito vale a pena é o que vai lhe dar dinheiro para obter os recursos que deseja. Vi pessoas do estúdio de jogos apresentarem conceitos de jogos com versões modificadas de jogos proprietários às quais eles não têm direito.

É como se você estivesse construindo um modelo em escala. Embora seja incrível ter uma réplica em vida miniaturizada do que você deseja. Às vezes, basta cortar as revistas, fazer artesanato e colar as peças. Todo mundo com uma mancha de imaginação não vai assumir que você construirá o arranha-céu com o mesmo papelão com o qual você mostrou a maquete. E nas indústrias criativas - é mais preferível trabalhar com pessoas com alguma imaginação. Se eles não conseguem olhar além de alguns problemas preliminares para ver o potencial por trás de um conceito inteiro, raramente apreciarão um produto. Nenhuma apreciação significa que eles estão menos dispostos a se comprometer e isso é uma espiral descendente. É a diferença entre definir a atitude de seu filho para conquistar o mundo e dizer "Você não pode nem amarrar seus sapatos direito, seu idiota,

O que quer que você esteja fazendo, lembre-se apenas da atitude, por si só, é mais do que suficiente para arruinar tudo absolutamente, independentemente de seu potencial tecnológico ou econômico.

Certa vez, criei um protótipo de um jogo usando imagens exclusivamente gif e dando a elas algo a ver com javascript. Não é deslumbrante, mas serviu ao propósito de mostrar o que eu queria mostrar. Não importa se você o desenvolverá posteriormente para o Xbox exclusivamente.

Se a sua ideia for mais complexa do que um simples protótipo, você precisará fazer pesquisas sobre a tecnologia que usará - já que o protótipo será o andaime para a coisa final (simplesmente porque muito é investido em e não pode ser jogado fora levemente) - se você o aprovar obviamente.