Meu problema é que, sempre que começo a programar um clone de um jogo (para prática), meu próprio jogo ou algum outro problema, paro em algum lugar no meio do desenvolvimento, porque perdi o interesse nele.
Como você mantém o interesse em desenvolver um jogo ou em geral?
Respostas:
Como designer, costumo pensar nas pessoas como coleções de estatísticas e variáveis. Quando você faz sua pergunta, posso facilmente visualizar [Pong_Dev_Interest] diminuindo e [Spa_Inv_Dev_Interest] aumentando. Quando a diferença entre os dois é maior que [Dev_Project_Inertia] (um pouco relacionada a [Dev_Completion_Desire]), a atividade em [Pong_Dev] é interrompida e [Spa_Inv_Dev] é iniciada.
Em inglês: você falha ao concluir o projeto porque seu desejo bruto de ver um produto acabado é substituído por sua falta de interesse no projeto atual. Se você realmente deseja terminar um, a única solução é escolher um (eu iria com o seu clone de pong) e finalizá-lo . Diga a si mesmo: "Eu sei que talvez eu pudesse refinar esse clone um pouco mais, mas caramba, é bom chutar um projeto pela porta". Então continue trabalhando.
Quando estiver entediado, continue trabalhando. Quando estiver indo muito bem, continue trabalhando. Quando estiver caindo porcaria, continue trabalhando! Perseverar! Seja o pequeno desenvolvedor que poderia! Eu acredito em você!
Ahem. Ficou um pouco exagerado lá. Mas você entende.
Estou seguindo meu próprio conselho diariamente. Consegui meu ambiente e atores trabalhando, construí minhas condições de ganhos e perdas e criei os objetos que o Jogador usará. Basicamente, estou pronto para começar a fazer algum design de nível e meu interesse foi prejudicado. Mas eu faço alguns todos os dias. Todo dia Um dia eu vou terminar.
E vai parecer tão bom.
fonte
Eu sempre me faço a mesma pergunta e há algumas coisas que você pode fazer para se motivar (muitas delas já postadas aqui). O que funciona bem para mim é algo que ouvi em um dos Indie Talks na GDC deste ano, acho que foi o cara que fez o jogo em Mônaco :-)
Primeiro, encontre um projeto que esteja bem em sua linha de experiência. Ou seja, não comece a criar um FPS se você nem conhece o básico do OpenGL / DirectX. (a menos que você esteja usando um mecanismo de jogo, mas esse não é o ponto aqui ;-))
Em seguida, faça uma lista de coisas a serem feitas e marcos que você deseja alcançar, para sempre saber para onde ir. Os TODOs são a parte importante. Defina suas tarefas para que cada tarefa possa ser realizada facilmente em um dia ou em algumas horas . Então, quando você começa a codificar, projetar, modelar etc., você já vê a luz no fim do túnel. Nada é mais deprimente do que projetar e codificar seu grande Game Engine por um mês sem se aproximar da linha de chegada. Divida tarefas grandes em tarefas menores. Terminar uma tarefa rapidamente é realmente gratificante e mantém você em atividade. Por exemplo, esta foi a minha lista de tarefas para um pequeno jogo de tiro espacial ao mesmo tempo:
Todas essas tarefas foram fáceis de executar e, uma vez que funcionem no jogo, você pode iterar nessas áreas e aperfeiçoá-las.
E ei, eu terminei um pequeno jogo. Não é bonito, mas é basicamente feito, o que foi realmente gratificante no final :-)
fonte
Você precisa identificar o problema antes de poder resolvê-lo. Por que você perde o interesse?
Para mim, isso geralmente acontece porque estou gastando muito tempo na estrutura e, depois de semanas, eu não conseguia nem criar um único elemento de jogo.
Uma maneira que encontro para melhorar minha motivação é fazer prototipagem iterativa ou alguma forma de desenvolvimento orientado a testes. Geralmente, isso envolve a automação de casos de teste, mas como os jogos exigem muitos gráficos, você não pode automatizar telas e animações como testes, mas a lógica do jogo pode ser automatizada.
Para as partes que não podem ser automatizadas, basicamente planejarei alguns marcos para o jogo. O marco 1 provavelmente seria renderizar um sprite na tela e fazer o WASD funcionar, por exemplo. Gradualmente, adicionarei mais recursos e refatorarei.
É uma forma de dividir e conquistar. Divida em pequenos pedaços, trabalhe no que você se sentir confortável e depois integre. Enxague e repita. Eventualmente, você poderá ver uma maneira melhor de reorganizar as coisas e refatorar seu código. É uma bagunça não ter uma arquitetura adiantada, mas geralmente quando se inicia a programação, é difícil visualizar a arquitetura até que você tenha alguns anos de experiência.
fonte
Eu tento encontrar uma parte mais fácil de fazer. Como se eu não conseguisse descobrir como fazer algo ou não quisesse, mudo de marcha e modelo ou escrevo um shader etc.
Veja este e este outro post.
fonte
Se você não sabe como estruturar um jogo corretamente, comece a aprender a abstrair seus elementos em blocos independentes de jogo. Isso pode ajudá-lo de várias maneiras (além de interessante), como: experiência em dividir abstrações de implementações, uma melhor exploração da herança e design de interface ou apenas como colocar o jogo em vários arquivos para parecer profissional (ou fornecer uma flexibilidade de implementações pelo uso de bibliotecas de vínculo dinâmico ou outros usos de interface). Mais cedo ou mais tarde, você perceberá que tudo pode ser feito e, então, ficará sem esse problema de motivação (basta fazê-lo).
Eu tive o mesmo problema quando fiquei preso no início, mas a melhor solução é continuar em movimento, ou você pode parar para sempre até que algo o redefina de alguma forma (e isso pode levar muito tempo). Não importa se você codifica apenas 2 linhas em alguns dias, mas todos os dias você precisa pelo menos abrir o projeto e tentar melhorar alguma coisa (é uma tarefa sem fim, mas esse não é o problema).
Se em algum momento o programa não funcionar, você deve desfazer o que fez por último (mantenha um backup, use um svn ou pelo menos um .rar com o nome da data) para um ponto em que funcionou e tente fazê-lo novamente ou trabalhe em outras alterações que você precisa fazer até que você tente novamente.
No começo, você deve tentar corrigir o erro com a ajuda do depurador, mas não sei se o seu idioma suporta um depurador ... mas se você por acaso usar C ++ ou algo parecido (o que eu recomendaria se você deseja fazer jogos), você deve fazer melhor uso do seu depurador, pois ele ajudará muito a encontrar o erro rapidamente em uma única execução.
Ler sobre programação de jogos também é uma boa coisa para se manter no tópico, se você não quiser trabalhar em nada em particular. Existem alguns bons livros e artigos sobre mecanismos de jogos e design que você pode encontrar online.
Você não poderá fazer nada se não praticar. Tentar encontrar um bug pode ser muito frustrante no começo, mas você aprende que é realmente fácil se você sabe como fazê-lo. Isso é algo que você aprende a evitar com o tempo, codificando de maneira que suas alterações não tenham impacto em todo o programa, diminuindo a quantidade de lugares em que procurar o erro. Se toda vez que fica difícil você desistir, toda vez que você pensar em fazer um jogo, desistirá antes de começar. Apenas aprenda a superar o momento ruim superando-o: P Se você não passar pelo momento em que perde a motivação, sua preguiça vencerá e você perderá, é assim que funciona, até que você aprenda a recuperar a motivação. sem muito esforço.
PS: Eu estava pensando ... o que você está usando para fazer o jogo?
fonte
[deveria ser deixado como um comentário na resposta de anon, que foi excluída quando eu a publiquei. Ele mencionou que tinha toda essa funcionalidade funcionando e depois dividiu o código de arquivo único em vários arquivos, apenas para que tudo desmoronasse]
Re: refatoração, coisas podem acontecer, mesmo para profissionais. Às vezes, mesmo com boas ferramentas como o Git, uma mesclagem pode falhar, portanto, ao invés do recurso A e do recurso B, ambos funcionam, nem funcionam! A única opção é voltar para A e tentar novamente. Felizmente, o controle de versão salvará esse código para você; se você não usar o controle de versão real, faça-o manualmente manualmente, fechando a pasta dev regularmente - o espaço em HD é barato! Em conclusão, volte ao que funciona e refatorar em etapas menores, garantindo que o jogo ainda funcione a cada etapa. É realmente deprimente limpar o código apenas para ver tudo desmoronar. Basta reverter para o código antigo.
fonte
Para se manter motivado, continue dizendo a si mesmo que você está criando um jogo, não um mecanismo de jogo - bem, a menos que seja isso que você gosta. E isso é legal, os mecanismos de jogos são ótimos, mas muitas vezes atrapalham a criação de jogos.
Para ilustrar meu argumento, posso dizer com que frequência as coisas acontecem: a princípio, você cria alguns sprites, move-os na tela com seu proto-framework e fica emocionado! Você pode ver seu progresso e está indo bem; você pode mostrar aos seus amigos.
Então, depois de brincar um pouco com o seu conceito, você percebe que precisa tornar sua estrutura (ou mecanismo de jogo) mais flexível. Ou que você deve fatorar novamente alguma classe que não está seguindo os padrões mais recentes. E a partir daí, você embarca em uma espiral da morte: para de trabalhar em um jogo e começa a trabalhar em um mecanismo de jogo. E os mecanismos de jogo não são tão divertidos de fazer. Você pode passar horas refatorando e não tem nada para mostrar - no jogo. E então, você perde o interesse.
Então, lembre-se: crie jogos, não mecanismos de jogos. Refatorar somente quando necessário. Não seja muito flexível - apenas o mínimo necessário. *
*: é claro que refatoração e flexibilidade são importantes. Mas não é tão importante quanto realmente ter um jogo terminado.
fonte
Tente criar uma versão jogável em um dia, não importa quão simples. Em seguida, itere.
fonte
Não tente tornar seu jogo muito complicado!
Divida sua tarefa em subtarefas pequenas, específicas e mensuráveis. Se alguma subtarefa parecer muito grande, subdivide-a ainda mais.
Certifique-se de escrever "CONCLUÍDO" em letras grandes na sua lista de tarefas (eu uso um arquivo .txt) quando sua tarefa estiver concluída. Não remova a tarefa, porque não parecerá que você está fazendo progresso.
Isto é o que eu faço. Funcionou no passado.
fonte