Criar jogos sempre foi uma fascinação, desde o primeiro contato com eles. Aquele negócio de criar um mundo/universo imaginário onde é possível fazer coisas que na realidade não é, fascina e leva muitos a se interessarem por TI.
Contudo, a maioria de nós, não tem a menor ideia de como realmente se faz um jogo. Queremos fazer um, mas não sabemos como fazê-lo. Minha ideia nesse post é elucidar um pouco de como é implementar um jogo, sob a ótica de quem trabalha na área de TI a algum tempo. Interessado? Então vamos nessa!
Etapa #1 – IdeiA
Todo software começa com uma ideia e jogos não são diferentes. Entretanto, assim como todo software, existe uma diferença bem estrita entre ideia implementável em nossa mente e ideia implementável em um computador.
Por ideia implementável em computador entenda ideia que pode ser codificada em algoritmo (ou conjunto de algoritmos) processável por nossa tecnologia de computação atual. Isso implica incluir além da possibilidade de processamento em tempo razoavelmente rápido, a possibilidade de uso dos métodos de input atuais (de nada adianta pensar num jogo que faz uso de interface neural quando não se tem esse tipo de tecnologia a disposição).
Além da limitação tecnológica, tem ainda a limitação de interesse. Esse jogo seria jogado por alguém mais além de você ou é um um jogo que provavelmente só você irá entender e gostar? Ou seja, haverá público para o seu jogo?
O último ponto a analisar na ideia é o ‘como eu pretendo jogar’? Será utilizando teclado e mouse? Terá níveis? Vai ter personagem? Vai ter luta?
Mas pera, isso não é a primeira coisa em que pensamos quando queremos um jogo?
Coloquei essa questão por último não foi atoa. Na etapa da concepção tendemos a pensar primeiro em como jogar, em imaginar as telas do jogo, em ver-nos ou ver outros jogando. Contudo, se fizer essa análise antes de considerar a limitação tecnológica e de público, a chance do seu jogo não dar certo cresce exponencialmente. Porque?
1 – Você pode pensar em utilizar uma tecnologia que ainda não existe ou não está disponível comercialmente ou não é comum e acessível para a maioria do seu público planejado.
2 – Você pode não ter público algum no final das contas. Embora não há problema em fazer um jogo para você mesmo, você pode!, se está querendo que outros joguem o seu jogo, precisará considerar a opinião alheia. Afinal, se depois de todo o trabalho para construir o jogo (o que mostremos a seguir) ninguém gostar dele, isso poderá ter um impacto muito negativo na sua estima ao ponto de lhe desestimular de tentar desenvolver outros jogos.
3 – Descobrir se a tecnologia suporta o que você quer pro seu jogo e se há pessoas interessadas, irá influenciar positivamente o planejamento do jogo e até te ajudar a pensar melhor em ‘como eu jogarei isto’.
Agora que já criticamos o bastante a ideia, é hora de passa pra próxima etapa.
Etapa #2 – Definição de Escopo
Quem nunca leu aquela frase “quem se define, se limita”? Pois bem, independente dela ser verdade ou não para uma pessoa, ela é bem verdadeira para softwares.
E a etapa de definição de escopo é exatamente isso: limitar o que terá e o que não terá no jogo.
Como é de se esperar, pra definir um escopo é necessário considerar a etapa anterior. Se a ideia é jogar num console, então a primeira limitação é a plataforma. Se a ideia é um jogo para o público infantil, então outra limitação é a complexidade do gameplay (não que crianças não possam jogar um frenético FPS, elas podem. Só não é comum para a maioria do público). Se a ideia é permitir lutas tridimensionais então um pré-requisito é uma engine que suporte objetos 3D e execute animações sobre esses objetos a um nível decente. E assim por diante.
Aqui vou eleger alguns dos elementos de escopo necessários a um jogo e que já usamos em projetos do tipo da Nibblelab:
1 – Ambiente
O local ou locais onde o jogo irá executar influencia e muito. Não só na disponibilidade de métodos de input e tamanhos de tela, como também no tamanho do público potencial, assim como na disponibilidade de software de suporte ao desenvolvimento como SDK’s decentes e engines. Definir o ambiente é de suma importância!
2 – Softwares de suporte
Em decorrência direta da escolha do ambiente vem os softwares de suporte ao desenvolvimento, afinal, a menos que você queira escreve tudo que irá precisar do zero, da engine aos drivers, irá precisar utilizar bibliotecas, SDK’s e outros softwares de terceiros. Alguns irão resolver seu problema. Outros não. Alguns serão acessíveis, outros não (sim, acessíveis. Tem software que é bom mas custa sozinho todo o budget do projeto. Aí não dá né!).
Em algumas situações, um software de suporte, tipo uma engine, pode até influenciar na escolha do ambiente. Eu já vi projetos que deixaram de suportar determinadas plataformas porque nelas não tinha suporte da engine utilizada no projeto. Não que isso seja um problema. Ao contrário, é uma escolha. Entretanto cabe ao você ou seu responsável técnico definir quando um software de suporte vale tanto ao ponto de influenciar outros pontos do seu jogo.
Outro ponto a analisar é continuidade do software. Isso é expresso pelo tamanho da comunidade em torno do software e a frequencia em que ele recebe atualizações. Uma vez eu trabalhei num projeto de jogos em que utilizamos uma engine que tinha tudo o que precisávamos, mas era mal documentada e a comunidade em torno dela era muito pequena. Resultado? Tivemos que trocar por outra inferior, porém mais bem documentada e com comunidade maior (de certa forma, isso vale para softwares comerciais também).
No geral a regra é muito simples: escolha os softwares que atendem ao jogo. Ou seja, os que cabem no orçamento, os que oferecem as funcionalidades que precisam (lembra o que falei de animações? Não adianta querer um jogo com animações e não usar uma engine que suporte esse tipo de coisa), os que tem bom suporte dos desenvolvedores ou da comunidade.
3 – Gameplay e Level Design
Isso aqui é traduzir o ‘como eu jogo isso?’ da etapa anterior em definições claras de projeto.
Ex: no meu jogo o jogador poderá criar personagens com características A, B e C. Então eu defino onde e como isso será feito e quais são características. O que elas representarão e como irão interagir com o resto do jogo.
Outro exemplo: no meu jogo o player precisa pilotar a nave escapando de uma série de obstáculos para passar de nível. Então eu defino como e quantos serão esses obstáculos, como eles serão exibidos e com qual frequencia e qual a relação deles com a nave. Também defino por quanto tempo o player precisa pilotar ou de quantos obstáculos ele precisa passar para terminar o level e após isso, o que será feito logo em seguida. Se irá abrir outro level ou se terá algum troféu.
4 – Serviços anexos
Pode não parecer mas há muito em jogo além do que o jogo propriamente dito. Você pode precisar de um site para fazer a divulgação. Pode precisar de uma API para registrar online os jogadores e seus scores. Pode precisar de outros serviços como processar pagamentos de micro-transações. Tudo isso precisa ser definido adequadamente antes de começar a desenvolver o jogo. Porque? Pra não ter surpresas depois com funcionalidades necessárias que simplesmente ‘surgiram do nada’ sqn, assim como para planejar melhor o uso do orçamento.
Etapa #3 – Produção/Definição do conteúdo áudio-visual
Agora que já tem ideia e escopo definidos, é hora de pensar numa das partes fundamentais de todo jogo: o áudio-visual.
“Ah mas tem jogo aí que usa gráficos pixelizados e fazem sucesso”. Você pode questionar isso (como já me questionaram uma vez). Contudo, pode não parecer mas aqueles gráficos pixelizados com aquela música ‘zuada’ foram definidos como parte do escopo daquele projeto e cuidadosamente implementados.
Uma coisa importante para lembramos sobre jogos é que eles são arte e arte nem sempre nos agrada. Porém, se agrada a outros, é arte (ignore a discussão filosófica do termo, please!).
E por ser arte, você precisa se dedicar nessa parte. Mesmo que você já seja um excelente designer ou compositor, ou mesmo não saiba nada de música ou arte gráfica, não poderá deixar o conteúdo áudio visual sem a devida atenção.
Além deles comporem o seu jogo e serem por eles que o player verá e experimentará o jogo, eles estão diretamente ligados ao gameplay e level design. Lembra daqueles sons de suspense em jogos de survival horror ao abrir uma porta por exemplo? Então, eles estão lá para te induzir a um comportamento que compõe a imersibilidade do jogador no ambiente do jogo.
A imersibilidade é algo tão importante que você se lembra dos jogos por conta dela. E mais importante, jogos com boa imersibilidade mas pontos fracos em outros aspectos (como história) já conseguiram ficar entre os mais jogados por quase meia década (já sabe de quem estou falando né?). Então, cuide bem dessa parte.
Agora, como fazer isso depende dos recursos a sua disposição. Se você domina a arte gráfica ou música, faça você mesmo. Ou se tiver alguém em sua equipe com boas skills nessas áreas, a sua equipe pode fazer. Agora se esse não é o seu caso, há sempre repositórios de gráficos e sons disponíveis na internet, assim com bons profissionais a disposição para fazê-los.
De um jeito ou de outro, é possível conseguir gráficos e sons decentes para atender o seu jogo.
Quanto ao onde aplicar esses recursos, isso dependerá completamente do seu tipo de jogo e do que definiu no gameplay. Lembra do exemplo que citei do som de suspense em jogos de survival horror? Bom, esse é um bom exemplo de onde aplicar adequadamente recursos audio-visuais.
Etapa #4 – Ahhhh finalmente a programação
Com ideia, escopo e recursos audio-visuais definidos, a próxima etapa é aquela que engenheiros de software e geeks em geral se deleitam: a programação.
Da configuração (ou implementação) da engine até escrever os levels, tudo é muita festa e claro, muito trabalho. E embora eu não vou me alongar muito aqui (afinal, o post já está muito grande), farei apenas algumas observações às quais você precisa se atentar quando chegar nessa etapa
1 – Jogos são programas rápidos: do jogo mais simples de dress-up até os poderosos jogos que simulam ambientes 3D inteiros, a velocidade de execução é uma constante. Usuários em geral odeiam lags e em jogos, isso pode significar a morte de um
2 – Testes: a maioria dos softwares tem bugs embutidos. Mesmo aqueles construídos com base em heurísticas podem ter erros, afinal, são criaturas imperfeitas que constroem os softwares. Contudo, lançar um jogo (ou qualquer outros software) bugado por demais prejudicará a experiência do jogador e poderá fazer com que ele abandone o jogo permanentemente. Por isso considere o período de testes alpha e beta, open e closed antes de lançar.
3 – Entregue o que prometeu: todo mundo gosta de surpresas e presentes (os bons presentes, claro), porém antes de encher seu jogo de conteúdo adicional, de easter eggs, certifique-se que ele faz exatamente aquilo que se propõe a fazer, ou seja, se é um jogo para teste matemático, então ele deve permitir no gameplay a realização de testes matemáticos e isso deve funcionar muito bem, afinal, a maioria das pessoas compram jogos por causa do que eles propõe, não por conta de algum bônus.
Etapa #5 – Hora da jogatina!!!
Uma vez que tenha uma versão testável do jogo, é altamente recomendável realizar os testes alpha e beta.
Esse conceito vem da disciplina de engenharia de software, estudada nos cursos de ciências da computação entre outros nos universidades e se refere basicamente a testes realizados em estágios diferentes do desenvolvimento.
De maneira resumida, os testes alpha são realizados pela equipe de desenvolvimento em ambiente controlado, ou seja, no próprio equipamento de desenvolvimento disponível à equipe. Esses testes servem para corrigir bugs e melhorar funcionalidades de um software e geralmente vem após os testes automáticos realizados pela própria máquina (unit test, por exemplo).
Seguindo os testes alpha, vem os testes beta que podem ser fechados a um grupo específicos de testers (closed beta) ou abertos a qualquer um que desejar participar (open beta). Você já deve ter visto por exemplo jogos em estágio de early access no steam que você pode comprar para ajudar a equipe de desenvolvimento testanto o jogo pra eles. Esse é um tipo de teste beta.
Uma vez finalizados os testes, vem a parte final.
Etapa #6 – Publicação
Depois de tempo produzindo, definindo, programando, finalmente vem a parte da publicação, a parte em que lança o seu jogo para outras pessoas jogarem e se divertirem junto com você no seu jogo.
Embora essa etapa pareça simples, há também alguns pontos a considerar. Se está por exemplo lançando um jogo para plataformas mobile, como android e iOS, precisará enviar o jogo para a loja avaliar e às vezes, precisará alterar alguma coisa por conta de alguma política de uso que possa ter ignorado em alguma etapa anterior (isso já aconteceu em uma app que lançamos na Nibblelab).
Além disso, se fará alguma divulgação do jogo, todo o material publicitário deve estar pronto no momento do lançamento e se possível, já ter sido veiculado alguma parte dele, igual as grandes desenvolvedoras fazem na E3.
Outra coisa que precisará ficar atento é com os serviços anexos. Se seu jogo precisará de um servidor público online para funcionar, ele precisará estar pronto e funcionando até aqui.
Por último, lançar o jogo não é tudo. Precisará monitorar a vendas, se for um jogo pago, e recomendavelmente, monitorar o retorno da comunidade. Os comentários dos jogadores no blog do jogo, ou nas lojas de aplicativos ou no steam. Precisará ficar atento pois sempre há algo no qual os jogadores poderão acrescentar ao jogo ou a sua experiência nessa área.
Fazendo um jogo
Como escrevi no início do post, desenvolver jogos é uma arte que chama a atenção de muita gente. Se você não conhecia o processo de desenvolvimento, espero tê-lo ajudado a entender um pouco melhor como se cria um jogo e quem sabe, te estimular a desenvolver um.
Em meu tempo de graduação, participei de um projeto de desenvolvimento de jogos, com o qual aprendi muita coisa. Depois da graduação, trabalhei em alguns projetos de jogos para alguns clientes e hoje temos na Nibblelab um projeto de desenvolvimento de jogos, o projeto R (aguardem mais notícias hehehehe).
Nesse projeto um dos nossos desenvolvedores, que também é um fã de jogos mas nunca tinha trabalhado com isso antes, fez um comentário que me motivou a criar esse post e nomeá-lo: “cara, jogar um jogo é muito mais fácil que criar um jogo”.
E o que ele falou é verdade. Usar é mais fácil do que desenvolver. Porém isso não significa que você não pode ter seu jogo só porque não tem habilidades de desenvolvimento de software ou design. Você pode contar conosco pra isso, então, se está procurando equipe para desenvolver seu jogo, fale conosco que vemos uma maneira de nos ajudarmos 😀
E esse post foi longo pessoal. Agora acabou.