Godot para projetos de jogos

Para voltar aos estudos do mestrado, e recuperar parte do ritmo de leituras em inglês, que este ano me trará outra vez uma prova de proficiência (a última não foi tão boa quanto deveria ter sido), dedicar tempo a um treinamento de um outro programa que produzi jogos é constatar que esse tipo de livro tem uma forma bem especifica de ser escrito. Infelizmente constatar que a esmagadora maioria dos livros de treinamento, tanto da editora quanto da área, sigam uma be-a-bá pré definido específico que acaba por deixar os leitores em uma situação de conforto, depois de alguns livros, um tanto elevada. Querendo ou não, é preciso melhorar a narrativa desses projetos e não apenas escrever, dentro de um mesmo modelo, as informações que o autor quer. Uma pena isso ter se tornado padrão.

Ler o livro Godot Game Engine in 24 hours não foi um problema. Lê-lo me ajudou a saber o que tem de conteúdo importante ou extra nele e o que tem de relevante disponível no programa. Usar o conceito de nós para se organizado foi uma surpresa porque leva a organização dos projetos aos mesmos conceitos de trabalho que Natron e Blender usam como base.

Para quem não conhece o conceito ou nunca ouviu falar a ideia é simples. Define-se um ponto, neste caso nó, que será o ponto inicial de uma cadeia. Essa cadeia tem uma série de nós filhos mas apenas um nó pai. Cada nó pai será responsável pelo tipo de hierarquia que a cadeia inteira de nós terá. Podendo ser uma cadeia pequena com objetivo determinado ou um combinado de cadeias que são interligados se tornando um emaranhado de arquivos interdependentes que organizam e executam o projeto da forma como se deseja. Essa organização é fundamental para fazer o projeto se tornar viável e exequível ou apenas um conjunto de arquivos perdidos sem origem ou destino que só ocupam espaço.

Entre muitos nós de interação e complementação, na prática o livro tenta, e até consegue, demonstrar como podemos usar cada um dos nós que nos é apresentado (e isso é uma quantidade mínima do que existe) e se for ler pensando nos projetos que deveria ter, e seriam bem uteis no decorre do livro, é melhor esquecer a leitura pois ela não vale o esforço.

Mérito do livro é explicar como os arquivos precisam ser organizados e salvos em pastas determinadas. Não adianta nada querer executar os projetos quando eu tenho uma variedade de arquivos parecidos com pequenas variações dentro deles e na prática são só os personagens do projeto. Sem uma organização precisa dos cenários, dos personagens, dos códigos, da cenas e da interface, nada fará o projeto ser bom e nesse detalhe, o livro se esforçou bastante para deixar claro, seja coerente nas pastas e nomes dos arquivos.

 

O livro "Godot in 24 hours" foi lido com certa facilidade, tema dessa postagem, porém existem outros e um deles é o "Game Developement" que será o próxima a ser lido. Existem outros livros foram publicados porém não encontrei os respectivos PDFs. Vai ser preciso mais tempo de busca.

Na prática, é tipo uma mini bíblia do programa (para quem conhece os livros de nome "bíblia do programa tal..." é um grande manual impresso da documentação que existe online no site da fabricante). Por bem ou por mal, não é um total desserviço o trabalho do autor mas deixa a desejar devido a falta de exemplos mais práticos que poderiam levar a resultados melhores. É uma alternativa bem prática devido a ordem como são colocadas as coisas, no caso os nós usados nos exemplos, mas nada que um pouco de esforço e estudo na documentação oficial não vá fazer.

Outra curiosidade foi ao final de cada capítulo existirem algumas atividades, sugestões de retrabalho e uma forma diferente de se fazer os mesmo trabalhos apresentados nos capítulos que na pratica só levam a uma maior fixação do conteúdo que está mais solto do que preso a algo crucial.

Faltou sim uma espinha dorsal de aplicabilidade do conteúdo em projetos menores que levariam a resultados visuais reais do que está sendo feito. Fazer um Pong; um jogo de corrida para 2 jogadores; um plataforma mundo principal, 3 fases e um chefe; um jogo de corrida infinito e um de tiro ou mesmo mini RPG teriam gerado mais retorno ao leitor do que sair socando coisas como foram colocadas. Senti falta também, e isto é em praticamente todos os livros e vídeos de treinamento, exemplos práticos de como criar interfaces e sequenciadores de arquivos/fases para mostrar como devem ficar os projetos no decorrer do tempo.

A interface do programa com as suas respectivas áreas de trabalho. Neste caso está em exibição o modo 3D de projetos, a organização dos arquivos e o sistema de nós mostrando a hierarquia interna do arquivo em execução. A direita o inspetor destes arquivos. Para que conhece a Unity sabe da importância da tela Inspecto no programa. Na Godot essa importância também é grande.

A parte boa é a linguagem usada. Simples e acessível para a maioria dos adolescentes com algum interesse em conhecer programação ou projetos de jogos. Mais recomendado ainda para os iniciantes no inglês que vem de países onde a língua mãe é outra. Ao menos ajuda a estudar um pouco esta outra língua.

Se for ler pelo GDScript passe longe. Pouca coisa relevante é incluída. Tem os códigos de como usar e como fazer funcionar, sim mas não é o bastante sem a tal espinha dorsal de aplicabilidade. Um livro só de GDScript faz falta e com ênfase em logica de programação mais ainda.

Outros livros de Godot descobertos recentemente.

Resultado: a obra foca mais na apresentação dos nós do que nos projetos. Eles existem? Sim, tem 3 lá mas nada de muito importante. Podem funcionar bem mas para quem quiser trabalhar com a Godot focada em algo diferente como: Cenários 3D realistas, programação avançada, projetos escolares menores, ou até mesmo projetos grandes, não é o caso. Ele fica devendo mesmo.

Até o próximo livro.

Ass.: Thiago C. Sardenberg

22-02-2021