Ao desenvolver meu playground para o Scholarship, eu aprendi…

Essa é tensa! Uma das reflexões mais difíceis para mim. Porém, uma das mais valiosas.

Começarei a história pelo meu ingresso na Pós-Graduação de Jogos. Acredito que seja relevante pois usarei alguns trabalhos que fiz para exemplificar o que concluirei mais pra frente.

Basicamente, fui muito feliz na escolha. E não falo isso só pelo fato de que o coordenador do curso provavelmente lerá esse artigo e sim pela grande liberdade que o curso fornece.

Logo a partir do primeiro trabalho entregue pude notar que os professores não tomavam somente o resultado gráfico como parâmetro da nota mas também a forma como foi desenvolvido. Essa foi uma surpresa muito gratificante para mim, pois munido desse feedback me senti mais a vontade para explorar o que realmente me interessava que é o desenvolvimento, arquitetura, modularização e estruturação do código.

Exemplificando:

BattleCityWannaBe (Battle City)

Clone do jogo Battle City. Executado em terminal (console do Windows)

Fiquei bem receoso de defender a entrega desse jogo após ver alguns de meus colegas apresentarem jogos bem personalizados, com identidade visual e estilo único e vários outros termos que não tenho a menor afinidade. No entanto, para a minha alegria, o professor gostou e inclusive elogiou o fato de ter usado um pouco de IA e a implementação do algoritmo de A*.

Beat’Em All

Na verdade o nome deveria ser Shoot’Em All, mas só aprendi isso depois

Para esse jogo houve um leque muito maior de possibilidades para desenvolvimento (não estavámos mais com o desafio de desenvolver um jogo para console). Poderíamos usar várias bibliotecas gráficas diferentes (excluindo engines) e por essa razão, muitos resultados diferentes foram apresentados. Havia jogos de partidas, story-telling, tabuleiro, plataforma e etc. Jogos com fases, objetivos, colecionáveis, inimigos.

O meu?
Não tinha fases!
Não tinha objetivo!
Não tinha inimigos!
Não tinha colecionáveis!
Até o estilo do jogo que deu nome ao jogo está errado.

Pensando bem, talvez seja melhor dizer o que o jogo possui:

1. Leitura de um arquivo .tmx gerado pelo projeto open-source Tiled.
2. Utilização da biblioteca de física Box2D. Nunca havia mexido com uma biblioteca de física antes e a experiência de integrá-la com SFML foi bem interessante.
3. Alguns Steering Behaviours
4. Possibilidade de alterar as propriedades dos objetos por arquivos de configuração.

Arquivo para configuração do Player

Essa foi uma tentativa de orientar o jogo a dados, de forma que um Game Designer, por exemplo, pudesse editar a maior parte das características do jogo sem a necessidade de uma recompilação.

E novamente, apesar do resultado gráfico dizer completamente o contrário, não foi um completo desastre. Dá pra acreditar? O pessoal gostou muito da integração com Box2D, uso de consts em tudo (cortesia de um amigo cearense) e configuração livre dos elementos de física por meio de arquivos externos ao código. Apesar de eu passar vergonha mostrando esse jogo para qualquer pessoa, os professores me forneciam feedbacks onde eu mais me interessava, no código.

E pra não dizer que não falei das flores, apresento um último exemplo. Esse foi feito para a matéria de iOS (Swift).

Jogo de matemática — Swift

Desafio do Scholarship

Bom, acredito que tenha ficado claro a minha tendência de não priorizar ̶i̶g̶n̶o̶r̶a̶r̶ ̶c̶o̶m̶p̶l̶e̶t̶a̶m̶e̶n̶t̶e̶ o resultado visual do jogo. E é exatamente esse o ponto onde mais tive dificuldade na submissão para o Scholarship.
Acredito que minha maneira de realizar trabalhos não seja a melhor, principalmente para apresentações, que é exatamente o objetivo da experiência visual e interativa exigida pelo programa. Em alguns momentos, me senti mais perdido que o pessoal de Design, que além de estar com a corda no pescoço como todo mundo ainda teve de aprender programação em semanas.

Para concluir faço uma analogia com uma vertente do design chamada de ‘Conditional Design’ a qual fui apresentado no BEPiD. Esse tipo de pensamento preza pelo processo muito mais do que pelo resultado. Tirando do manifesto:

The process is the product.

Exemplo do que pode ser formado após estabelecido um conjunto de regras (não tão bem definidas, concordo contigo Charles Ferreira)

Ou seja, nessa linha de pensamento valoriza-se muito mais as regras de formação da arte, seus pontos de liberdade e os pontos de restrição do que o próprio resultado da iteração dessas regras.

Esse é exatamente o mesmo sentimento que eu tenho quando tento pensar na melhor forma de definir os componentes de um jogo, como os objetos serão carregados, que Design Patterns utilizar, que abstrações fariam sentido, gerenciamento de estados, dos elementos do jogo, do cenário e etc.

O ponto que eu quero chegar é: se houver uma categoria análoga a essa para desenvolvimento de jogos com certeza vestirei a camisa!

Aquele abraço,
Luís Copetti