Estou falando sobre o livro Game Mechanics – Advanced Game Design; aqui está a parte 1.

 

Comentei sobre os capítulos iniciais e agora a parte mais importante, o diferencial que torna este livro único:

 

* Machinations Framework *

 

O que é isso?

 

É um sistema criado por um dos autores do livro, uma espécie de fluxograma animado, para ajudar o designer a criar, ajustar, balancear, economias internas de jogos.

Comentei sobre estas economias na parte 1 deste artigo, mas lembrando: pode ser desde um simples sistema de pontos de vida, XP, até uma economia que lembra mais a vida real, muito usado em jogos como SinCity, Civilization… Card games como Magic são outro tipo de jogo que tratam muito sobre balancear os custos e vantagens de cada criatura, ou seja, uma economia interna complexa.

 

Imagine que você está fazendo um jogo como Banco Imobiliário, onde o objetivo é ser o mais rico possível, comprando propriedades, recebendo aluguel sobre elas, e por ai vai. Você poderia simular esta economia no machinations, criando valores iniciais de renda e tendo uma noção do quanto ganharia em determinado tempo (o sistema pode criar gráficos para demonstrar isso). Então pense que quer colocar mais desafio no jogo, adicionando um feedback loop negativo (comentei sobre estes elementos na parte 1 do artigo também), algo como imposto de renda. Quanto mais imóveis eu tiver, mais irei pagar de imposto, ou seja, isso irá diminuir meus ganhos, estimulando criar uma estratégia para escolher com cuidado onde investir o dinheiro; além de impedir que meu lucro escale muito rapidamente sem dar chance a outros jogadores.

Para testar isso precisaria implementar esta regra num protótipo e jogar algumas vezes, mas usando o machinations é só adicionar esta regra e observar o gráfico, acelerando muito o processo de ajustar a economia, mesmo antes de existir o jogo.

 

Como funciona?

O sistema foi feito em flash e pode ser acessado aqui => http://www.jorisdormans.nl/machinations/

Basta clicar nos botões na lateral para ir adicionando elementos e montando o que quiser, depois executar para ver em ação todo o sistema.

Esta é a interface, com alguns elementos adicionados para demonstração.exemplo

 

Os elementos principais são:

  • Reservatório [pool] – (círculo) onde armazena recursos.
  • Portão [gate] – (losango) distribui o fluxo de recursos baseado no seu tipo.
  • Fonte – (triângulo com ponta para cima) cria recursos. A notação * indica que é um recurso que começa a ser criado automaticamente, é uma das opções de ativação de um elemento.
  • Dreno [drain] – (triângulo com ponta para baixo) drena recursos, elimina eles.
  • Conversor [converter] – (triângulo com ponta para direita com uma linha vertical sobre) converte um recurso em outro.
  • Trocador [trader] – (dois triângulos apontando para esquerda e direita, um sobre o outro, com uma linha vertical sobre) troca um recurso por outro. A diferença entre o conversor é que o conversor destrói o recurso antigo e cria um novo em um ritmo ilimitado, e o trocador pode ter uma quantidade determinada de recursos disponíveis, então quando acaba o jogador não pode mais trocar até que o recursos voltem a ser disponíveis.
  • Conexão de recursos [resource connection] – (seta sólida) indica a direção que os recursos fluem.
  • Conexão de estado [state connection] – (seta pontilhada) influencia o fluxo de recursos baseado no estado de um elemento, seja direto ou pela influência de outra conexão de recurso.
  • Jogador de inteligência artificial [AI player] – (quadrado com “AP”, dentro do diagrama em qualquer lugar) permite o designer codificar um jogador artificial para “jogar” o sistema.

 

Depois de montado o diagrama, basta executar para vê-lo em ação. Recursos que são criados por fontes são representados como pequenas bolinhas que seguem pelas setas para o reservatório ou outro elemento que está ligado a ela. E assim você pode ir acompanhando o fluxo de dados. Como opção alguns elementos podem ser acionados manualmente, por exemplo, você pode simular que apareceu um boss ou aumentou a dificuldade do jogo, clicando em um elemento que irá criar um recurso novo e alterar o resultado. Poderia haver uma fonte que gera uma unidade no reservatório “dificuldade”, e a quantidade armazenada neste reservatório será usada em outros cálculos no diagrama. E por ai vai.

 

Dá para adicionar gráficos para ver como algum dado específico vai crescendo ou diminuindo com o tempo. Também pode rodar a simulação de forma instantânea, chegando no resultado final (que o designer define) sem precisar ficar esperando.

E também é possível adicionar o jogador com inteligência artificial, programando regras simples para ele realizar.

 

Por exemplo: imagine em um RTS, onde minhas unidades cortam madeira e armazenam em um galpão. A quantidade de madeira estocada permite que eu construa casas. Eu poderia simular isso criando:

  • uma fonte (representa a floresta de onde a madeira é extraída), que começa a gerar unidades de forma automática;
  • um reservatório (representa o galpão);
  • então ligar eles com um conector de recursos para indicar o fluxo de dados (da fonte para o reservatório).

rts-ex1

Quando executo este diagrama, assisto o fluxo de dados, as bolinhas são criadas na fonte e andam pela seta até o reservatório. Lá vão sendo empilhadas, depois de uma certa quantidade as pilhas de bolinhas param de ser desenhadas e só aparece o número total de recursos acumulados (só por questão estética).

rts-ex2

 

Adicionando mais alguns elementos:

  • um conversor que irá converter a madeira em casas;
  • um novo reservatório que irá contar a quantidade de casas que possuo;
  • então ligar o reservatório de madeira com o conversor e depois o conversor com o reservatório de casas. Na primeira ligação informo que preciso de 5 unidades de madeira para gerar uma casa, por exemplo. Para isso no atributo “label” do conector de recursos coloco 5. Desta forma quando passar 5 unidades por ele, irá sair 1 do outro lado, ou seja, 5 madeiras = 1 casa.

Por fim, posso colocar um gráfico – chart – e ligá-lo com o reservatório de casas, assim vendo o quanto este valor aumenta com o tempo.

rts-ex3

 

E se quiser pode fazer conectores que modificam outros parâmetros, como a cada casa construída, a quantidade de madeira para a próxima sabe 10%, etc.

 

Este atributo label de vários elementos serve para não só escrever algo descrevendo o que significa este elemento, como também colocar condições e algumas palavras especiais, como “D” que significa dice – dado (neste caso criando um fluxo aleatório de dados). Ou seja, o sistema todo parece ser simples, mas esconde uma complexidade e profundidade considerável.

 

No site da editora tem um material bônus que explica passo a passo como funciona o machinations, recomendo dar uma olhada para quem ficou interessado e quer mais detalhes. Pra faciliar a sua vida eu já baixei e deixei disponível aqui.

 

 

E ai, útil ou inútil?

Bem, a base do sistema é fácil entender, porém quando pensamos em modelar a economia de um jogo de verdade com isto, pode ficar bem complicado. A quantidade de elementos que precisa interligar e configurar corretamente, deixa tudo visualmente confuso. Conforme o livro vai detalhando mais exemplos complexos, o meu interesse pelo sistema diminuía. É bem difícil entender diagramas maiores, ainda mais no papel.

Na minha opinião é um sistema interessante que vale dar uma conferida, mas a não ser que você esteja trabalhando em algum jogo com economia interna profunda e importante, me parece que não vale a pena investir muito no uso do machinations. Afinal o designer precisa dominar tanto a ferramenta a ponto da modelagem do gameplay nela casar exatamente com o jogo real. Qualquer erro pode gerar conclusões erradas.

 

Tenho a impressão que este sistema ainda não “pegou”, é pouco conhecido e não é usado por designers na prática. Nunca li nada sobre alguém utilizando isso além dos próprios autores. No máximo recomendações que vale a pena conhecer.

Será que compensa o esforço necessário para montar um diagrama complexo buscando chegar em boas conclusões para aplicar no jogo? Talvez em uma fase inicial do projeto, mas logo depois quando os protótipos estiverem sendo feitos, acho que vale mais investir neles pois são o jogo de verdade, eliminando o risco da sua modelagem da economia não estar totalmente correta dentro do machinations.

 

De qualquer maneira conhecer este sistema me estimulou a pensar se não é possível criar outras ferramentas parecidas para outros elementos de design do jogo, além de economias. Algum tipo de editor visual interativo que poderia auxiliar na criação da ideia, escopo, emergência do gameplay… seria possível? Arrastar e interligar conceitos, mecânicas, temáticas, referências de outras obras… e ter uma saída útil para o desenvolvimento… hmm… é uma semente para a mente. Se alguém tiver uma sugestão…

 

Outros exemplos de diagramas que encontei, pra ter uma ideia da complexidade:

 

Pac-Man:

pacman

 

Futebol: (veja as conexões aleatórias que podem levar a bola para o meio de campo, ataque, gol ou defesa…)

futebol

 

Diablo: (já tá complicando… e é só a superfície do jogo, claro)

diablo

 

Outros capítulos do livro: (capítulo 5 foi o Machinations)

 

Capítulo 6 – Mecanismos comuns

Detalha alguns sistemas comuns em jogos e como eles podem ser modelados no machination. Por exemplo, você pode querer fazer uma skill tree, aquelas árvores de habilidades/tecnologias que podem ser escolhidas na hora de um upgrade, como isto poderia ser feito no machinations. Vários exemplos deste tipo, ou seja, usos mais complexos, com vários elementos interligados.

 

Capítulo 7 – Padrões de design

Alguns padrões de design que são comumente usados em jogos, e como são representados no machinations. É a tentativa de criar um vocabulário de design, termos que representam sistemas que muitos jogos usam para auxiliar na criação. Como se fossem alguns pedaços de quebra-cabeças que você pode usar para montar o gameplay do seu jogo. Não quer dizer que todos serão úteis, mas as peças estão ali prontas para o uso se necessário.

São elementos mais complexos, e tem um material bônus no site da editora que é um resumo destes padrões. É um apêndice do livro, também já baixei e deixo disponível aqui.

São abstrações de mecânicas comuns, alguns simples como “Mecanismo de parada”, um padrão que reduz a eficiência de um mecanismo toda vez que é ativado. Pode ser usado quando quer que o jogador não abuse de uma ação, evitar estratégias dominantes, etc.

E tem muitos outros mais complexos. Veja no apêndice.

Eu acho um trabalho acadêmico interessante abstrair essas mecânicas, mas na vida real o designer irá consultar isso na hora de criar o jogo para ver qual padrão poderia usar para melhorar o gameplay? Acho pouco provável, mas tá ai, vale dar uma olhada.

 

Capítulo 8 – Simulando e balanceando jogos (usando o machinatons, claro…)

Fala sobre coletar dados de várias passadas da simulação, criando estratégias para jogadores artificiais (IA), etc.

Só útil se você estiver de cabeça no machinations, são usos mais complexos dele.

 

Capítulo 9 – Construindo economias

Fala de forma mais geral sobre jogos que usam economia complexa como Civilization, com exemplos no machination.

 

Capítulo 10 – Integrando level design e mecânicas

Algumas formas de estruturar o jogo, com desafios, contando a história ao mesmo tempo, misturando as mecânicas com level design. Sempre com exemplos do machination. Algumas coisas mais abstratas, mas a teoria não tem muita novidade.

 

Capítulo 11 – Mecanismos de progressão

Como estruturar a progressão do jogo, de linear até exigir itens para abrir parte do cenário e seguir em frente, etc. Mais alguns exemplos complexos no machinations. Algumas partes da teoria são interessantes mas nada incrível.

 

Capítulo 12 – Mecânicas com significado

Aqui comenta sobre a importância das mecânicas carregarem algum significado maior, falando dos serious games, gamification, teoria da comunicação. Um pouco sobre semiótica… pra quem curte esse tipo de coisa. Esta parte do livro parece deslocada do resto, onde tenta falar de jogos que podem impactar positivamente na vida das pessoas com alguns exemplos já bem conhecidos sobre este assunto. Não achei que este livro mais técnico abordaria esta temática.

 

Concluindo:

A partir da introdução do machinations, o livro fica orbitando ao redor dele, com cada vez mais exemplos de uso, incluindo as padrões de design. A teoria que fica no meio não é tão interessante quanto a parte inicial do livro, apesar que sempre vale a leitura. Se você considerar o machination pouco útil ou não interessante para seus objetivos, vai ser difícil passar por estes capítulos recheados de diagramas e gráficos. Então o meu proveito do livro foi conhecer o machinations (que só tinha ouvido falar) e a teoria de emergência dos primeiros capítulos que é um conceito interessante, mesmo já sendo retratado em outras obras. De qualquer maneira eu recomendo o livro, o machinations é uma ferramenta que tem sua utilidade prática questionável, mas é uma boa ideia e mais uma possibilidade de auxílio ao trabalho do game designer, só que requer em certo esforço para dominá-la.

 

Extra: artigo no gamasutra sobre machination (dos próprios autores):

http://www.gamasutra.com/view/feature/176033/the_designers_notebook_.php

Anúncios