DEBATE SOBRE CONHECIMENTO E TÉCNICA.

GE é a sigla de Game Engine (Motor de Jogo), um software que agrega bibliotecas de física, gráfica, mecânica, personagem e mundo 2D/3D que pode ter um editor visual ou não, e pode ter suporte para linguagens de programação, apenas ou não. podemos compreender como um programa que cria jogos ou experiências interativas. E será que o GD (Game Design) precisa ter conhecimento de GE? Vamos lá.

Precisa, mas não no aprofundamento que se trata software, requisitos, área de codificação e linguagens. Essa é a parte que você precisa compreender, GD não lida com programação. Ele é a parte que concebe o projeto do game e precisa pensar em muitos detalhes do que unir outra área que é tão complexa, porém muito diferente. Uma lida com o processo criativo e projetista e a outra com a implementação e campo técnicos de informática. São duas profissões distintas para completar a explicação. E vimos isso bastante no artigo 1 dessa série.

Mas o GE é o framework que dará suporte para a criação do GAME, e o Game Design vai precisar de ter conhecimento das que existem e ver o que pode lhe oferecer. Por exemplo que é importante fazer leitura sobre quais existem e o que é necessário para fazer algo com elas. Será que é possível mexer com elas e ter o resultado que deseja sem precisar de uma mão de obra especializada? Ou é preciso? Do que se precisa para definir quais os pontos temos que levar em consideração.

GD é um especialista em projetos. E com o foco em games ou experiências interativas. Ou seja podemos conceber que ele é um Especialista em projetos de games e experiências interativas. Levantar recursos materiais que farão parte do projeto é uma etapa importante. Então é preciso ter conhecimento sobre o que a ferramenta permite, mas não de forma técnica. Precisamos separar isso aqui. E vamos ver do que se trata ter conhecimento, mas não técnico.

CONHECIMENTO.

• Entender a funcionalidade (e não como funciona ou aplica) como um recurso que permita realizar o que foi desenhado. Um GE que seja capaz de simular a física realista de trincar vidro. Uma leitura superficial permite compreender se há ou não.

TÉCNICO.

• A funcionalidade da física de trincar vidro como funciona? Aspecto de cálculos? Qual seria a linguagem mais apropriada para lidar com motor de física desse tipo? Gerar testes e experimentações visuais para cada situação. E criar algoritmos específicos para a solução do projeto em si.

O GAME DESIGN vai se preocupar com o CONHECIMENTO. Essa ferramenta tem isso. Ok. Não tem, vamos continuar a procurar. Se acharmos, quem vai entender como o processo funciona e quais as opções que podemos ter a mais? O programador.

Vamos compreender o lado do programador aqui, pois no nosso artigo 1 definimos muito bem essas duas áreas que são muito confundidas e sobretudo confusas também. Pois o GD lida com a concepção do Level Design como as mecânicas vão funcionar na fase e o programador meio que vai por esta linha, e esses dois se encontram. Mas uma coisa é você “desenhar” e “arquitetar” como a mecânica vai funcionar, outra é você implementar a mecânica.

São fases de planejamento e execução. O programador ele não é uma parte criativa, não digo que seja não imaginativo. Mas dentro do escopo do projeto, ele é o executor do plano. É como se olhássemos para um mapa e fossemos até o ponto com o X marcado nele. Vamos ver os papéis desempenhados aqui. Quem desenhou o mapa? E nós, somos quem nesta história? Se optamos por ler o mapa e ir até o X teremos que aprender técnicas e exploração, sobrevivência e leitura geográficas.

O segundo tipo, que seríamos nós neste caso, executaríamos o plano tendo conhecimento técnico para tal. Quem construiu o mapa tinha outro tipo de conhecimento técnico, provavelmente de interpretação histórica ou desvendar de pistas, porque ele de fato tirou esse mapa de algum lugar. Mas o sobrevivencialista que vai procurar o X no mapa terá outras habilidades que quem desenhou o mapa, que pode ser um historiador, filósofo se diferenciam por meio de pilares de conhecimento. Compreenderam?

O programador não é ausente da criatividade, mas normalmente ele executa o que já foi desenhado. E se sair daquilo pode ser que tenhamos um pé no lugar errado, uma mão de zebra no lugar de um braço de pessoa. E há outros pontos a ser considerado quando pensamos em implementar e projetar. Duas áreas diferentes demais. E há uma máxima, até muita antiga, você não executa ao mesmo tempo que você planeja.

COMO O GD PRECISA ENCARAR O GE?

Diferente do programador, ele e não vai atrás de GE que são unicamente codificadas. Como por exemplo o PYGAME, PANDAS3D, Ogre3d, Unity. Ele vai atrás das que dispensa as linhas de código, que possui parte funcional e quase pronta, senão pronta das aplicações. Como Unreal, Godot, Rpg Maker. Sabendo disso, o primeiro ponto é aprender a mexer com o Software, ou seja, ler o manual. Depois é compreender os recursos, mesmo que tenha que ler alguma tecnicidade, é provável que isso será importante.

Por exemplo, GODOT tem o lado funcional, não precisa programar. Basta mexer como se fosse um Photoshop. Mas há mutas ferramentas que são convencionadas da programação. Como nós, Classes, Objetos. Então muitas vezes o manual faz analogias as classes da programação para o uso do conceito que o jogo cria. Todos os jogos são criados com o paradigma de POO (Programação Orientada a Objetos), a lógica é que tudo que tem no jogo é um OBJETO.

Faz sentido. Então essa ideia precisa ser absorvida. Mas não é preciso ou tão intencional, buscar conhecimentos avançados em POO para tal entendimento. Essa compreensão é como uma linguagem do GE. E não é tão complicada de entender com o material fornecido. O foco do GD não é como a GE processa, mas se processa o que ele tem em mente. GODOT consegue criar jogos do tipo plataforma, puzzle, primeira pessoa, nave, jogo medieval, cyberpunk? Consegue importar modelos 3D de suíte terceira? Essa física de trincar vidro tem? Como isso funciona, a mecânica, a engenharia por trás, isso é a parte do programador.

Mesmo aqueles que se aventuram a aprender sobre conceitos mais profundos, sugiro evitarem se perder. A linha de conhecimento técnico de projetista e programador é bem fina. É fácil você começa com Level Design e terminar o dia programando em Java. Porque eles são muito próximos. Mas onde um termina o outro começa. Então ao olhar GE, olhem os recursos em sua documentação. Se começar a ficar muito programacional, e tiver menos formas de compreender os recursos, sugiro mudar de GE.

COMO FUNCIONA O MERCADO GD PARA GE?

Você imagina. Pensa se a GE existe para o que você imagina para depois. O mercado de GD com GE é simples. Normalmente você tem uma equipe de desenvolvimento que vai procurar formas de criar soluções para o projeto elaborado. Se não houver solução pronta, vai ser criado. Muitos GE foram criados a partir de necessidades de projetos. Por exemplo, a maioria das pessoas gosta de fazer jogos de construção de base, defesa de torre, RPG de slash\loot, gosta de jogo de carro. Então não é muito complicado que as GE do mercado ofereçam tais respostas.

Mas se quiser elaborar mais do que isso, pode ser que criar uma GE própria seja necessário. Foi assim com Kojima Productions ao desenvolver o Decima. Ou Frostbite. Mesmo os GE conhecidos como CryEngine, Havok, tiveram seus dias iniciados por uma necessidade de projeto. Mas não é o GD que inicia essa solução, ele precisa de um programador para fazer isso. Não queira perder seu tempo em estudar programação para criar GE, é bem mais complexo do que você imagina.