Um guia informal e agressivo para desenvolvimento de jogos
Published: 2020-01-26 22:58:27

Ao longo do tempo em que desenvolvi projetos, me deparei com alguns momentos onde precisei desses conselhos. E bem, vocês os terão aqui, grátis :3 
Se você em algum momento questionou o porque de um projeto não ter dado certo, continue lendo.


![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/24fuxg06qc12gfqsf2t9.jpg)


##10.Sonha, pero no mucho 

Não importa se você tem 1 dia pra fazer um jogo, 6 meses ou 2 anos. Se atenha ao tempo que você tem. Não dá pra fazer um jogo AAA em 1 dia, e fazer um jogo de 1 telinha em 2 anos, é decepcionante. 

Você já começa um projeto sabendo seu prazo,salvo os casos em que o projeto é pessoal, nesse caso.. ignore essa dica. 

O fato é.. foque em fazer coisas legais compatíveis com o tempo que você tem. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/7dt57bf7louvsdlqmm4u.jpg)


##9.Evite decorações

Menu, telas de crédito, pause, etc.. não fazem parte do gameplay.OKay, tem sua importância como interface, mas o mais importante em um jogo acima de tudo é o gameplay, as mecânicas, a interação com o cenário. 

Um menu bonitinho ou uma tela de crédito não vão salvar um jogo ruim. O foco da produção tem que sempre ser o conteúdo jogável e interativo. 

Melhor ter pelo menos o jogo para entregar do que um monte de telas "só pra dizer que fez".

Antes de desenvolver algo, se pergunte "é possível ter um jogo sem isso?".

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/8uzgovrz4efz3fiucjdt.jpg)


##8.Diversão 

Se for pra fazer um jogo lindo, com uma narrativa maravilhosa, com todos os paradigmas de desenvolvimento, e não for divertido.. nem começa.Foque em planejar as mecânicas, e o principal: 

Como o seu jogo será jogado? 

Sério. Faça essa pergunta a si mesmo. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/hjd9n2z5feg6vfuiax2h.jpg)


##7.Planeje antes de desenvolver  parte I

Antes de programar, procure por alguma ferramenta\asset que atenda o que você necessita, programar é trabalhoso e gasta tempo. E né.. tempo não volta mais. Acredito que o mesmo vale pra arte. 

Não perca tempo desenhando arvorezinhas e props pro cenário.. personagens principais, inimigos e cenários autênticos são mais importantes. 

Ainda, considere a possibilidade de reaproveitar assets de projetos anteriores. 


![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/istop0jwwd8fndaihk7x.gif)


##6.Planeje antes de desenvolver parte II

Atenha-se ao conceito do jogo. Quando tiver uma ideia, e optar por desenvolve-la, não pode, depois de ter gastado muito tempo programando, desenhando, mudar de ideia do nada. 

NÃO JOGUE TRABALHO FORA, PLANEJE. 

Uma dica pra isso é prototipar no papel.Terá menos prejuízo se mudar de ideia nessa etapa. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/8cbud9sh0h4r8umjpx14.jpg)
 
##5.Look and feel 

Quando planejar um jogo, aqui algumas perguntas a se fazer durante o brainstorming: 

- Qual o sentimento que quero que jogador tenha jogando? 
- A diversão, o foco do jogo será mais em narrativa,mecânicas ou gameplay?
- Quais desenhos, filmes, jogos temos observado ultimamente e podemos utilizar de referência? 

O que importa nessa etapa é focar o design do jogo sempre na experiência do jogador.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/otbsndmogopvciscilk7.jpg)


##4.Documente essa @##$%!! 

O palavrão foi censurado, mas a verdade dessa dica não. Sem uma documentação do que foi decidido no brainstorm: 

- O\a programador(a) não irá entender "o que deve programar" 
- O\a artista pode esquecer de algum asset 
- Em pleno desenvolvimento, ninguém irá saber o que está sendo desenvolvido

E nem precisa ser um GDD completo, uma planilha bem feita ou um rascunho no papel já atendem a necessidade, basta descrever o que será feito. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/0s7d1g0yk4do4pfddwnh.png)

##3.Action! 

Não adianta planejar demais, e não colocar a mão no código ou não prototipar. É necessário um equilíbrio. O que deve ficar claro é.. desenvolva e não tenha medo de errar, porque ao final, tentativa e erro podem fazer um produto se tornar realidade, mas só planejar..acho que não. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/jpug8e1ldwjy2kt33i34.jpg)

##2.Testar 

Testa,mas assim..testa mesmo. Sem vergonha nenhuma.Testa. Se tem algo que você não vai querer que aconteça, é descobrir, perto da data da entrega, que algo não funciona e não irá dar tempo de arrumar.

Teste: 

-Regressivo, ou seja, a fim de descobrir se algo novo que foi colocado no jogo estragou alguma outra coisa 
-Unitário, para saber se o que está fazendo no momento está funcionando 
-Integrado, teste se cada uma das partes que foram desenvolvidas, de forma separada por cada membro da equipe, funcionam juntas.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/afjw4vfywzzrlh3fxp9d.jpg)

##1.Faça backup e controle de versão

Não preciso nem dizer a probabilidade de dar errado sem essa dica. 

Mantenha cópias online (google drive, git) de tudo o que foi feito por cada um.E também seria interessante ter uma cópia local, como em um HD externo por exemplo (caso tenha problemas com a internet, you know). 


![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/5iotre0bhzpyug6pinyj.jpg)

##Conclusão

Concluímos então que:
- O tempo é seu recurso mais valioso e deverás protege-lo com a sua vida! 
- Mais vale ter um produto entregavel do que apenas uma ideia interessante 
- Backup e testes nunca saem de moda 

Espero que esse artigo mais ajude em algum aspecto. 
Muito obrigada por ler até aqui,e espero que leia o próximo artigo, pois será sobre MVP :3