Como você inicia o desenvolvimento de um jogo? [fechadas]

Quando você inicia um novo projeto de jogo, o que você faz primeiro? Como você começa? O que lhe dá a melhor vantagem para concluir o projeto em vez de se esgotar antes que ele chegue a algum lugar?

_{Mods por favor me ajude com as tags ... Eu não tenho idéia de como categorizar isso ... :)}

Protótipo. Tente implementar seu conceito de jogo usando algum tipo de ferramenta de iteração rápida. Experimente o python ou apenas uma API de código aberto fácil de trabalhar para executar sua "ideia de jogo". Tente simplificar o máximo possível, use bolas em vez de personagens, abaixe a visão sobre algum tipo de representação visual. Dessa forma, você sempre pode olhar, discutir, debater e dar feedback. Coloque um cronograma definido para cada protótipo (talvez 2 dias - talvez uma semana no máximo). Dessa forma, você só pode fazer o que quiser no protótipo.

Às vezes, você pode plotar sua idéia em um pequeno pedaço de papel, se for simples o suficiente. Depois de definir sua idéia, comece a planejar para ver que tipo de sistemas e mecânicos você precisa. Tente estruturar os prazos para as coisas e veja se é possível se comprometer com elas. Se você é um grupo de pessoas que querem fazer um jogo juntos, é preciso fazer isso juntos. Faça isso com uma cerveja, pessoalmente ou usando um programa de bate-papo por voz. Depois que você souber o que fazer - todos poderão começar com o que estão fazendo. Verifique se você tem comunicação. Tente ter uma reunião de equipe com um intervalo frequente, dependendo de quanto tempo vocês querem dedicar.

Se você está criando seu próprio jogo, lembre-se de que o tempo é limitado e você não pode fazer tudo bonito. Talvez esferas e cubos sejam suficientes para fazer com que seus gráficos funcionem se você for um programador. Perceba suas limitações e trabalhe com elas, e não contra elas.

Espero que essas dicas ajudem :)

Como professor, vejo muitos projetos de hobby dos alunos que fracassam. Invariavelmente, a única razão mais alta para o fracasso é o escopo: o projeto começa com essa grande visão de uma coisa enorme que é grande demais para ser concluída, mais e mais pessoas são atraídas até que caem sob o peso de seu próprio design e todos deixa-se frustrado e desmoralizado.

O melhor remédio para isso é restringir seu escopo sem piedade. Em vez de dizer "como mantenho minha energia suficiente para terminar um projeto longo?" você deveria estar dizendo "como faço para projetar um projeto que seja curto o suficiente para que eu possa concluí-lo antes de ficar entediado?"

Os eventos de "congestionamento de jogo" (tipos de coisas que fazem um jogo no fim de semana) são uma ótima maneira de começar, e são ótimos para criar bons hábitos ao criar protótipos rápidos. Na PIOR, você passa um fim de semana fazendo um jogo ruim ... provavelmente aprendeu algo no processo ... E economizou meses trabalhando em uma idéia que acabou não sendo tão legal quanto você pensava originalmente. Na melhor das hipóteses, você descobre que tem algo realmente especial e pode começar a adicionar pequenos recursos, um de cada vez, até ter um projeto completo.

Em meus pequenos projetos de hobby, a outra coisa que achei que ajuda é começar com uma lista completa de todas as tarefas de desenvolvimento conhecidas que precisam ser executadas, ordenadas e reduzidas para que cada tarefa individual seja factível e testável, talvez 30 a 60 minutos, no máximo. É muito estimulante fazer uma pequena tarefa, vê-la funcionando no jogo e riscá-la da lista ... o que torna muito mais provável que eu faça a próxima coisa na lista desde a última tão fácil, e depois o próximo ... mais ou menos como comer batatas fritas.

Outra dica: sempre que você implementar com êxito um novo recurso, faça um backup (ou use o controle do código-fonte, que é basicamente a mesma coisa, mas nem todo mundo usa o controle da fonte se forem apenas eles trabalhando em seu próprio projeto pessoal). Dessa forma, se você estragar totalmente o código às 2 da manhã e não conseguir descobrir como recuperá-lo em um estado de funcionamento, o projeto não está morto e não precisa ser reiniciado do zero; em vez disso, basta reverter para o último marco concluído e funcionando e tentar novamente.

Eu diria que o mais importante é sempre mostrar algo.

Quero dizer, você pode gastar idades e idades em um sistema de entidade orientado a dados, com renderização diferida e FPS realmente alto, e tudo isso. Mas é provável que você se canse de não ter nada para mostrar e desista. Considerando que, se você tentar obter alguns modelos na tela, movê-los e sair daí, terá uma chance muito maior.

Eu acho que o primeiro é o desenvolvimento de baixo para cima; trabalhando de uma estrutura até o conteúdo real, e a segunda é de cima para baixo; trabalhando para obter algum conteúdo e construir a partir daí.

Um pequeno argumento, mas algo que realmente ajuda.

Como desenvolvedor solitário, acho que ajuda a implementar o som desde o início. Acho que isso me motiva a trabalhar mais com os outros recursos, porque mesmo nas primeiras semanas (com gráficos limitados a polígonos de cores vivas, detecção de colisão escamosa, falta de controles etc.), o som ainda dá a sensação de estar "quase lá" . "

Certa vez, trabalhei em um projeto que parecia fazer tudo certo. Eles criaram um site / quadro de avisos para todos os que trabalham no projeto colaborarem. Eles apresentaram a todos prazos e objetivos específicos e o jogo em si era um bom conceito. Apesar disso, ainda demorou apenas dois meses para as pessoas começarem a deixar o mapa. Após 3 meses, o desenvolvimento foi concluído e o jogo nunca foi concluído.

Então, se você está trabalhando em equipe, acho que precisa de incentivo. Você precisa de alguém em contato contínuo com todos, certificando-se de que estão fazendo o trabalho e lembrando-os por que querem continuar fazendo.

Se você está trabalhando sozinho; Eu não tenho tanta certeza. Sou péssimo com obras de arte, etc., então me concentro principalmente no lado do motor. Isso sempre é suficiente para me manter interessado :)

Os desenvolvedores sempre dizem para você não mudar para novas áreas até que você termine a área em que está trabalhando agora. Se você está tentando construir um jogo sozinho, não acho muito hediondo se você decidir quebrar essa regra. Trabalhar em algo novo é uma boa maneira de manter seus níveis de emoção altos!

Existem muitas respostas boas, mas vou adicionar as minhas também:

• Sempre tenha um projeto em execução que possa ser visto. Não entre no modo tanque, onde você codifica por 2 semanas sem algo para mostrar.
• Mantenha o ciclo de feedback curto (isso está se expandindo ainda mais no ponto anterior): codifique um novo recurso, mostre-o, obtenha feedback.
• Não sempre implementar algo que você não precisa agora, que é o corolário: não construir uma primeira coisa framework em um projeto.

Eu gostaria de expandir um pouco o último ponto, pois já vi isso acontecer várias vezes: nunca construa um framework primeiro. Existem muitas razões, mas, basicamente, você não terá a visão necessária para fazer as coisas direito, perderá muito tempo pensando no que fazer e perderá a moral quando, após X dias / semanas de trabalho, haverá nada para mostrar.

O problema é que a estrutura é frequentemente necessária para o produto final; então, o que um codificador deve fazer? Comece a construir especificamente, com valores codificados. Quando você precisar alterar um valor, modifique-o nas opções. Quando você precisar fazer duas coisas semelhantes, abstraia as peças semelhantes, mas mantenha o restante específico. Se você continuar fazendo isso, na verdade, você terminará com uma estrutura que surge devido à necessidade, em vez de perder tempo com o que aconteceria a princípio.

Depois de criar o seu décimo jogo, considere começar com o framework, pois você terá experiência suficiente para executá-lo.

Eu tinha dois ou três cadernos de ideias antes de começar a desenvolver meu primeiro jogo. Passei vários meses jogando jogos semelhantes para fins de pesquisa - determinando quais recursos eu gostei ou não. Geralmente, tento me concentrar na mecânica primeiro e lidar com a aparência depois (mas tomando cuidado para não ignorar a usabilidade). Eu recomendaria ter um design áspero mas completo antes de mergulhar no desenvolvimento. Não tente definir todos os detalhes cedo demais, pois seu design evoluirá necessariamente para acomodar problemas de jogabilidade, limitações de tecnologia etc.

Certifique-se de que sua ideia esteja completa, discutindo-a e anotando alguns dos principais objetivos do projeto. Eu passo por um processo que chamo de encontrar o jogo 'alma'. Ou seja, qual é a principal razão pela qual estou fazendo este jogo. A partir daqui, desenvolvo mais alguns conceitos e idéias que apoiarão esse objetivo principal. Todo esse processo pode levar horas, dias, semanas ou mais, dependendo de como a idéia chega até você.

A partir daqui, obtenha algo visível e cinético. Acho que ser capaz de jogar com o jogo e obter feedback é vital para manter a motivação. Costumo implementar efeitos visuais e sonoros, além de manipulação e processamento simples de entradas, para que algo esteja 'acontecendo' e pareça mais uma realidade do que um sonho.

Não importa como é a sua estratégia de desenvolvimento, não posso enfatizar o suficiente para que você não se comprometa a tentar criar e codificar um "mecanismo" de jogo. Todo recurso que não tenha efeito visível ou tátil no jogo oferecerá muito pouca recompensa. Para ajudar a compensar isso com os principais sistemas essenciais, coloque as informações de desenvolvimento na tela. IE FPS, variáveis ​​de IA e qualquer outro texto que ajude a expor que algo está lá antes. Não há nada mais desgastante do que passar 10 horas codificando um sistema, compilando e tendo exatamente a mesma experiência de antes.

Eu escrevi um artigo há vários anos sobre como encontrar sua alma nos jogos que você pode achar interessante aqui: http://deleter.phatcode.net/index.php?page=articles&a=8

edit: E mais uma coisa que vejo mencionada em outro post que quero elaborar. Jogue não apenas enquanto cria seu jogo, mas sempre que você não estiver muito motivado para trabalhar no seu próprio jogo. Acho que jogar jogos semelhantes me ajuda a lembrar por que quero fazer o meu jogo e me dá o impulso extra que preciso para continuar.

Além disso, você pode criar um "banco de inspiração" de fotos, vídeos, músicas e clipes de som que contêm elementos do que você deseja colocar no jogo. Sempre que precisar de orientação, volte a essas fontes para ajudar a orientar suas decisões. Isso ajudará a mantê-lo motivado e no caminho certo.

Normalmente, concentro-me primeiro na interface do usuário. Isso me ajuda a imaginar como o jogo será jogado. Também costumo trabalhar com pensamentos fáceis primeiro, para não ficar atolado em algo.

Comece com um conceito de jogo, defina o motivo do jogo, a jogabilidade, a aparência do jogo que você deseja criar.

A partir daí, você pode começar a criar uma lista de recursos e recursos para que o programador e o artista possam pelo menos começar a trabalhar em alguma coisa, enquanto o designer pensa ou aprimora a mecânica do jogo.

Dessa forma, você terá pelo menos algum código e ativos dentro de alguns dias ou semanas para aumentar o moral e iniciar o projeto.

Para mim, ajuda a 'mapear' mentalmente a ideia do jogo antes de iniciá-la. Vou tentar descobrir a mecânica principal, uma estrutura básica do jogo interno, talvez alguns pequenos detalhes sobre como eu quero que funcione. Então aplico borracha na estrada e começo a trabalhar, dobrando ou quebrando partes do meu mapa mental, onde o código precisa de uma configuração diferente. Posso escrever algumas coisas (uma história de fundo, talvez os principais recursos), mas nesse ponto o design geralmente está mudando demais para que um documento seja útil.

Caso contrário, eu meio que acabo sendo um projeto faled desde o início: /