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

49

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.

Refinamento vs. exploração
(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.

Jonas Byström
fonte
11
Essa é uma imagem muito bonita. De onde é?
Superbest
Eu acho que o que você está fazendo é formalmente chamado de "teste de unidade", especialmente se você deseja ajustar uma pequena parte do jogo de cada vez. Infelizmente, os jogos são difíceis de realizar, na verdade, testes de unidade, porque é difícil isolar componentes e automatizar o teste em si (para que ele possa decidir sobre aprovação / reprovação). Porém, ler sobre estratégias de teste de unidade pode fornecer idéias úteis.
Superbest
5
@Superbest: Conheço o teste de unidade de dentro para fora, e você não pode comparar a exploração do comportamento ao teste de unidade. Ao explorar o comportamento, você precisa carregar a maior parte do seu mecanismo de jogo, juntamente com os ativos relevantes. O teste de unidade é somente quando você sabe para onde está indo; neste caso, ninguém sabe. É por isso que é "exploração", não "refinamento". Foto do blog Intercom .
Jonas Byström
Quando você está testando no modo Debug, pode alterar seu código quando o pausa (pelo menos no visual studio). enquanto você não mudar a muito (cabeçalhos de função, etc), você pode carregá-lo em seu jogo pausado com apenas um curto período de tempo de compilação
Tobias B
@ TobiasB: na prática, infelizmente, achei isso inútil. Especialmente porque você normalmente tem sua mecânica de jogo espalhada em scripts, já instanciando objetos de jogo, ativos e assim por diante. Eu nem tenho certeza de que o Visual Express gratuito suporta isso, não o uso há 14 anos! :)
Jonas Byström

Respostas:

30

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.

Trevor Powell
fonte
3
Você poderia elaborar seus modos de jogo "testando"? Você cria uma fatia do jogo aqui e ali para cada parte sempre que quiser iterar? Quanto tempo você precisa para configurar sua "fatia"? O que é deixado de fora e como? Você tem um tipo de funcionalidade "salvar jogo" e "carregar jogo" para esse tipo de coisa ou é menos genérico?
Jonas Byström
2
@ JonasByström Eu não o conheço, mas quando tenho um bom controle sobre meus estados de jogo, muitas vezes posso ter versões alternativas "Debug" (geralmente IF DEBUGdiretivas de compilador literais ) que vão direto para o meu estado "testing" (pulando o menu do jogo etc.), que é apenas uma área de jogo com todos os recursos que estou testando no momento. Então, eu basicamente compilo um executável alternativo que carrega automaticamente um nível muito reduzido (menos recursos para carregar + sem mexer no menu do jogo toda vez).
Superbest
@ JonasByström Divido meus jogos em "modos". É basicamente apenas uma grande máquina de estado. Então, normalmente terei o modo "Tela de título", modo "No jogo", modo "Rolagem de créditos", etc. Eles são como jogos incorporados dentro do executável. Meus modos de "teste" são coisas como "UITest", que simplesmente carregam e desenham uma parte da interface do usuário, sem carregar nenhum outro conteúdo do jogo. Ou "RenderTest", que carrega e desenha algum objeto específico, sem carregar mais nada.
Trevor Powell
@ JonasByström Quando preciso criar um novo modo de teste, normalmente leva alguns minutos para escrever o código que configura a coisa específica que quero testar e quaisquer dependências que possa ter. Ou, alternativamente, geralmente posso adaptar um modo de teste existente em alguns segundos (por exemplo. Geralmente modifico meu modo UITest existente para carregar uma parte diferente da interface do usuário, em vez de criar uma nova). Não importa muito quanto tempo leva para configurar; o ponto é que, uma vez configurado, posso iterar em velocidades absurdamente rápidas, o que me mantém produtivo durante esse tempo de iteração.
Trevor Powell
11
@ JonasByström Também vale a pena notar que "comprar um computador mais rápido" também é uma solução completamente legal para a pergunta "como diminuo meus tempos de iteração". E, muitas vezes, pode ser a solução mais barata, quando comparada ao investimento de tempo na implementação de equipamentos de teste especiais. Reduzir o tempo de iteração é um investimento que você dedica muito tempo / dinheiro / esforço antecipadamente, mas que paga muitos dividendos no caminho.
Trevor Powell
20

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.
Anko
fonte
11
Lua parece não suportar código de hotswapping. Isso significa que você precisa reiniciar seu jogo / protótipo para testar suas alterações?
Jonas Byström
6
Definitivamente o código Lua quente é possível.
Josh
11
@ JonasByström É possível, mas apenas no ambiente certo. Se você não encontrar um, escreva um, o código-fonte de Lua é escrito em C, portanto é portátil para qualquer coisa que aceite chamadas de função no estilo C. Misture-o com o OpenGL, SDL 2 ou alguma outra biblioteca de empacotamento de gráficos / harware e construa para você um IDE de grande impacto.
Pharap
2
@ JonasByström Veja como fazê-lo com suporte e sem IDE .
Anko
2
@ JonasByström: ... exceto voltando à lua, aparentemente. :(
Mason Wheeler
11

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.

deixa pra lá
fonte
Estou pensando que os recursos são diferentes da exploração do comportamento. Eu quero explorar "a sensação". Os recursos são mais parecidos com a renderização bonita: não essencial e não relacionada à forma como o jogo será divertido. Minecraft, Candy Crush, Tetris e jogos similares provam isso IMHO.
Jonas Byström
@ Jonas Byström Para esclarecer: aqui por "recursos" quero dizer mudanças essenciais na jogabilidade. Ou seja, NÃO é uma renderização bonita, mas algo como "adicione uma maneira de criar blocos" ou "adicione mobs que atacam e matam jogadores" ao criar um protótipo de Minecraft.
Nevermind
11
A importância do seu segundo ponto, "deixar os recursos irem", não pode ser exagerada. Muitas fases exploratórias falham por não dizer "não" a esse recurso que levou duas semanas para ser implementado.
Kostas
Uma observação no ponto 4. Acho que a chave para isso é entender o que você precisará alterar rapidamente no código. Certifique-se de expor os valores que você sabe que deseja ajustar. Deixe outras seções do código enterradas se você souber que elas não afetam tanto a jogabilidade e as exponha mais tarde, quando necessário. Você precisa resolver isso rapidamente, mas se puder tentar projetar sua arquitetura desde o início, para que o material de 'game design' fique voltado para a frente e limpo sempre que possível, o resto pode ser ruim.
Sydän
11
@ sydan a infeliz verdade é que sua idéia de qual código é "voltado para a frente" está errada. Quero dizer, SEMPRE acontece que algo que você nunca deveria mudar é realmente uma coisa muito dinâmica. Ao prototipar, é melhor você estar preparado para alterar literalmente todos os aspectos e fazê-lo rapidamente.
o Nevermind
5

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.

Kostas
fonte
11
Foto de papel e "banco de banco" são excelentes conselhos; e sim - as listas também me ajudam. "Identifique suas três principais prioridades. Jogue fora os números dois e três." :)
Jonas Byström
4

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 .

Don Kirkby
fonte
11
Eu já vi o vídeo antes, mas esqueci. Hum. A interação imediata é realmente algo a ser buscado; Vou tentar seguir o seu conselho. Bom trabalho no interessante plugin Live Coding btw!
Jonas Byström
2

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.

Jonas Byström
fonte
1

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.

helena4
fonte
A prototipagem só é necessária se você estiver construindo algo novo, isso é certo. A falta de ferramentas é como a falta de caneta e papel irl - e com certeza você pode desenhar na areia, mas é ineficiente. Eu construí o Trabant para evitar ter que usar GIF + JS ou Scratch .
Jonas Byström