Floreio, minha gramática de geração procedural de texto

Gostaria de falar um pouco da ferramenta de geração procedural de texto por gramática de substituição que eu venho desenvolvendo na Unity para usar nos meus projetos atuais de narrativa procedural. Eu gostaria de eventualmente tornar ela disponível para os outros e queria falar um poucos da funcionalidade caso alguém se interesse por testar ela antes deu estar segura para liberar ela para geral.

Caso alguém não saiba, falando em termos gerais, uma gramática formal de substituição permite que você gere texto proceduralmente ao substituir coisas por outras coisas, normalmente partindo de categorias mais amplas para coisas mais específicas, como substituir "animal" por "cavalo", "cachorro", "jacaré", etc. Essas opções em si podem ter termos que devem ser substituídos por outros até que você eventualmente fez todas as substituições possíveis e chegou ao resultou final do texto expandido.

Digamos que você começa com o termo [início] e esse termo pode ser substituído pelas opções "eu não gosto de [animal]" ou "eu adoro esse [animal]". O sistema escolhe a segunda opção por exemplo e substitui o termo "início" por ela. Agora você tem a frase "eu adoro esse [animal]" em que o termo [animal] pode ser substituído por "gato", "cachorro", "passarinho" e por aí vai. Se a primeira opção tivesse sido escolhida, as opções fornecidas para o termo [animal] seriam as mesmas, já que é a mesma categoria.

Um exemplo abaixo utilizando a ferramenta na Unity:

a frase que inicia a geração com um único termo substituível, [animal]

um resultado possível da geração

as opções de substituição para o termo "animal"

 

Outros resultados utilizando outras frases iniciais com a mesma categoria [animal].

outras opções de frase inicial

Eu não tenho muita prática explicando esse processo de forma teórica, então quem quiser saber mais sobre o funcionamento de uma gramática em termos gerais pode assistir essa talk da GDC pela Kate Compton em que ela fala de múltiplos métodos de procgen, incluindo gramáticas, e esse vídeo do Coding Train em que ele explica mais do algoritmo em si de gramáticas de geração de texto. Ambos os vídeos infelizmente estão em inglês.

A função de uma gramática é permitir a geração de texto declarando categorias que podem ser substituídas por outras e possivelmente reutilizadas ou recontextualizadas múltiplas vezes, como o caso da categoria [animal]. Você declara possibilidades e possivelmente tags ou condições para essas possibilidades serem escolhidas e o texto se adapta ou se varia na hora que ele é gerado.

Gramáticas podem ser usadas para se variar o texto sendo apresentado ao jogador a fim de evitar repetição, para se lembrar de certas coisas que o jogador fez, desde o nome que ele escolheu até ações que ele tomou, alterar o tom e a atmosfera do texto, ou o tempo verbal e a época em que se passa e por aí vai.

Você pode ter múltiplas opções inteiras de frase, parágrafo ou até um texto completo e escolher entre uma e outra se quiser mudar algum desses parâmetros, mas ao quebrar esse texto em partes menores, cada uma com suas próprias possibilidades de expansão, cada parte do texto pode expressar algo diferente que você precisa sem que um texto inteiro tenha que ser feito para cada combinação de demandas.

Se você precisa passar um texto para o passado, ao mesmo tempo mudar o tom das descrições e definir a personalidade de cada personagem, os verbos podem escolher opções diferentes com tempos verbais diferentes, enquanto os adjetivos escolhem opções que definem a atmosfera das coisas e os diálogos dos personagens escolhem opções apropriadas para a personalidade de cada um.

Tem duas coisas que gosto na técnica da gramática de substituição e que tornam ela minha técnica favorita de geração procedural. Para começar você tem um controle muito forte da estrutura geral. Você começa do topo e vai decidindo níveis cada vez menores conforme você expande as categorias até chegar a possivelmente pequenos detalhes. A todo momento é possível ter um bom controle da estrutura geral de cada um desses níveis de detalhe.

Além disso, gramáticas te permitem uma gradação completa entre coisas muito controladas e autorais e coisas completamente procedurais e possivelmente surpreendentes e descontroladas. Você pode fazer uma gramática que substitui poucas coisas em frases quase estáticas, ou escolhe entre grandes porções de texto, até gramáticas em que cada palavra foi uma escolha entre muitas. Ter essa possibilidade no mesmo algoritmo e poder empregar qualquer um dos extremos num mesmo texto te dá muita liberdade e não te prende a um nível só de proceduralidade por conta da sua escolha de técnica ou ferramenta.

Essa gramática eu venho desenvolvendo com o objetivo de permitir uma recontextualização muito robusta de cenas genéricas em jogos de narrativa procedural em que não se sabe ao certo que personagens estarão ocupando que papel na cena na hora de escrever ela, ou até os próprios personagens são procedurais também. Dessa forma uma cena pode ser pensada para tomar múltiplas direções de estrutura, atmosfera, tom, escolha de palavras ou descrições de locais e pessoas dependendo de quem está tomando parte nela ou onde ela está ocorrendo.

Com isso quero dizer que meu objetivo com essa ferramenta é menos criar variação por si só e mais poder fazer a cena refletir aspectos diferentes do mundo quando ela ocorre que não podiam ser previstos quando ela foi escrita, permitindo que o texto reflita as ações do jogador ou de IAs e dê mais agência para ambos.

Alguns exemplos de geração de outro exemplo básico um pouco mais variado que o anterior:

 

Não que a gramática não possa ser usada para algo mais simples. Eu já usei ela num teste de joguinho de combate em que a descrição das habilidades eram geradas na hora com os dados da skill naquele momento. Dessa forma eu podia mudar os atributos de uma habilidade e a descrição dela era atualizada automaticamente substituindo os números de dano ou cooldown por exemplo.

Esse é um uso mais funcional e determinista, em que o algoritmo não toma direções criativas ou variadas. Porém, se esse for ser a única demanda de um projeto, existem ferramentas disponíveis de gramática de substituição mais simples que a minha que fazem isso sem precisar lidar com todo o engodo extra necessário para coisas mais complexas.

Para permitir essa recontextualização, a ferramenta oferece a possibilidade de se passar muitos dados para o algoritmo de gramática, essencialmente variáveis, que podem oferecer informação sobre os personagens, cenas ou locais narrados a fim de tornar o texto bem específico para cada contexto diferente.

Também é possível receber informações de volta sobre o texto que foi gerado, para que isso possa ser guardado ou refletido em outras áreas do jogo. Se o texto gerou um lugar novo por exemplo, ou o nome de um personagem, isso pode ser registrado para que o resto do jogo possa fazer menção à essas coisas. Logo o objetivo é poder continuamente passar e receber informação do texto gerado para que ele possa refletir o que ocorre no jogo e para que o jogo depois possa reconhecer o que foi narrado.

Além disso a ferramenta também conta com uma funcionalidade de tags que permite que o conteúdo seja comentado e que o algoritmo use isso para pesar as opções de substituição de forma diferente. Na hora de fazer a geração de texto você pode passar uma lista de tags que serão usadas como prioridade na escolha de conteúdo, ou passar tags que não podem ser selecionadas, além da possibilidade de customizar com precisão a chance de escolha de cada conteúdo com o uso de curvas.

Se alguém estiver interessado em testar a ferramenta, que eventualmente vai ser um plugin para Unity, pode entrar em contato comigo. Gostaria bastante de poder testar ela botando em uso por outras pessoas antes de lançar de forma mais ampla.

Quem quiser ler ou assistir mais material sobre gramáticas de substituição, eu sugiro essa apresentação da Emily Short sobre um dos projetos mais interessantes que eu já vi usando esse ferramenta e esse artigo do desenvolvedor do jogo Voyageur.

projeto arlequim pt.3: o fluxo de uma cena

Uma cena no jogo não tem a intenção de simular uma cena narrativa normal, não mais do que combate em video games costumam se assemelhar a cenas de combate em outras mídias. O foco é mais no game design e no fluxo da cena em direção à certos momentos significativos de mudança no estado do mundo, como dois personagens mudando a relação entre um e outro, ou um personagem ganhando uma característica nova de personalidade.

Para simplificar um problema comum de narrativas procedurais, a sequência de causalidade entre uma série de eventos, a ideia é que um evento não proceda outro de forma direita, quero dizer, com uma relação direta de causalidade. A relação entre dois eventos ocorrendo é mais lateral. Quando um evento ocorre ele altera o estado do mundo daquela cena, o próximo evento a ocorrer é influenciado por esse estado do mundo e influencia ele em retorno.

Os eventos que ocorrem em uma cena influenciam sim um ao outro, não são 100% aleatórios e desconexos, mas essa influência ocorre de forma lateral através do estado do mundo que ambos compartilham, sem que um evento leve à outro de forma direta. Esse é um tipo de causalidade mais difícil de autorar em um sistema procedural, seja por que exige um sistema com uma capacidade mais complexa de identificar padrões em uma simulação ou por que exige mais conteúdo gerado por parte do desenvolvedor.

Quando eu falo do estado do mundo me refiro a duas coisas, os personagens que fazem parte desse mundo e as características que compõe cada um, e o contexto atual da cena, os aspectos que ela acumulou até o momento.

Um ato numa cena, que não é nada mais complexo que uma ação atômica, como um personagem discutindo com outro durante uma briga, ou contado uma piada para os amigos, ou acertando um soco em um oponente, só pode ser "gatilhado" em uma cena se cumprir certos pré requisitos. Um personagem acertar outro com um soco por exemplo, pode exigir que esse personagem seja agressivo, tenha uma opinião muito negativa do seu alvo ou esteja com o humor muito bravo.

Esse evento portanto faz referência ao estado do mundo, o humor, a personalidade ou as relações de um personagem, para saber se pode ocorrer ou não, e sendo influenciado pelo estado do mundo ele também é influenciado por eventos que afetaram esse estado do mundo. Digamos que um evento passado em que um personagem A provoca um personagem B levou o personagem B a ficar exaltado e isso cumpriu os pré requisitos para que o evento do soco pudesse ocorrer. O sistema não racionaliza que a provocação levou o personagem provocado a bater no outro, o que é mais rígido e complexo de autorar, o primeiro evento simplesmente atualizou o estado do mundo permitindo que o segundo evento cumprisse seus pré requisitos.

Isso segue o princípio de Quality Based Narrative e permite que unidades narrativas sejam autoradas de forma quase auto contida sem que o desenvolvedor ou o sistema tenham que lidar com uma sequência de causalidade mega complexa. Uma unidade narrativa só especifica os pré requisitos para acontecer de forma lógica e coesa e múltiplos outros acontecimentos que levem o estado do mundo a cumprir esses requisitos podem se tornar a possível causa dessa unidade narrativa poder ocorrer.

Além de ter pré requisitos, todo ato (um evento) em uma cena também é sensibilizado para certos aspectos. Esses aspectos, cujo conjunto total eu ainda estou no processo de iterar, fazem referência ao tipo de evento ocorrendo, como conflito, amizade, interferência, introspecção, e por aí vai. Um ato tem mais chance de ocorrer se os aspectos a que ele está sensibilizado são mais prevalentes na cena. A ideia é ter um modo flexível e genérico de fazer com que eventos semelhantes influenciem a frequência um do outro por compartilharem aspectos.

Apesar dos atos não levarem uns aos outros de forma linear, eu no momento estou planejando as cenas meio que de forma a criar certas sequências, para que uma cena tenha caminhos possíveis e contrastantes que ela pode tomar dependendo do RNG e dos personagens que o jogador botar dentro dela.

Isso pode envolver coisas como certos atos exigindo que um personagem esteja com o humor em um certo estado e um ato "preparatório" que dirige o humor do personagem para aquele ponto. Dessa forma o jogador pode ver um evento alterando o humor do personagem acontecer algumas vezes e depois eventos novos que ocorrem em decorrência dessa mudança, passando a ideia de um arco narrativo?? talvez??

fluxo de atos expressivos na cena teste de discussão verbal

 

Na hora de planejar o conjuntos de atos narrativos que podem ocorrer, eu tenho organizado eles em volta de aspectos chave que simbolizam bem os múltiplos caminhos que uma cena pode seguir. Na cena de discussão por exemplo, um caminho de conflito leva os personagens discutindo a ficarem cada vez mais agressivos uns com os outros e potencialmente piorarem ainda mais sua relação, enquanto um caminho de harmonia pode levá-los a superar a inimizade ou pelo menos não piorar as coisas.

A ideia é que o jogador assista os pequenos atos acumulando esses aspectos em direções diferentes, levando a cena a se concluir em uma situação de conflito ou de harmonia por exemplo, o que foi de certa forma um pouco influenciado por esse texto sobre estados narrativos, da Emily Short. A diferença é que no momento, a conclusão da cena não acontece de forma determinista e ainda usa aleatoriedade ponderada.

Uma cena com uma grande quantidade de "conflito" não vai necessariamente se concluir com um ato de conflito, apenas possui mais chance disso. Eu venho refletindo sobre a possibilidade de experimentar com esse determinismo apenas no ato conclusivo, que é um momento importante para marcar a identidade da cena e sumarizar o que ocorreu.

Também venho refletindo sobre o algoritmo que calcula a influência dos atributos na chance de um ato ocorrer. No momento atribuir um aspecto minoritário a um ato imediatamente mina a chance dele de ocorrer, visto que esse aspecto sempre vai ser um porcentagem minúscula do contexto da cena. Estou pensando na possibilidade de testar adicionar um peso adicional aos aspectos dependendo da proporção total deles no deck de atos da cena.

Quer dizer, se o aspecto harmonia aparece apenas três vezes entre os atos de uma cena, ele terá um peso três vezes maior quando compor o contexto da cena que um aspecto que aparecer nove vezes no deck total. Isso significa que quando um dos poucos atos de harmonia acontecer, isso aumentará significativamente a chance de outros atos de harmonia.

Isso tem o risco de causar o problema oposto, dificultando a presença dos aspectos mais básicos e fundamentais da cena, que passariam a ter uma influência bem mais reduzida. Acho que isso seria mitigado pelo fato dos atos serem tratados como cartas em um baralho sendo sorteadas uma depois da outra. O jogo sorteia um ato da lista e depois roda um algoritmo de rejeição para ver se aceita que aquele ato seja executado, que é onde entra a influência dos aspectos da cena. Se a maioria dos atos no baralho são de conflito, eles ainda tem mais chance de serem sorteados mesmo que o peso do algoritmo beneficie os aspectos mais raros.

arlequim project pt.2: resuming the project

I'm posting again on the blog to give a brief update about a project I finally resumed after about a year. I restarted the procedural interactive fiction project, that for now I'm still calling Arlequim (Harlequin in portuguese), since it's still a prototype.

I decided to start the code from scratch, since I improved a lot as a C# coder in the mean time and also took some better decisions regarding pipeline and planning. Instead of immediatly starting the visual interface, even with temporary graphics, I'm still designing the scenes independently of each other in an editor window that allows me to simulate the whole scene. One of the great advantages of the game structure being segmented in generic scenes with flexible roles is that it becomes easy to test the arc and the internal dynamics of a scene in a self contained manner, without having to play or simulate big portions of the game.

My objective for the rest of the month is either developing the visual interface for testing the interaction with the scene, dragging the characters inside and out of it, or investing more time on designing scene models, developing a bit of a bigger set and making their designs more interesting before making a playable visual prototype of the system. As I mentioned before, it's possible to test if the internal dynamic of a scene is working just by the simulation on the editor window.

At the moment I'm iterating on the design of a verbal argument scene between two parties of characters, with one possible neutral side trying to mediate the situation, attempting to get the weights and the algorithm for act selection right, to achieve an interesting arc.

The scene simulation window with argument scene and the current act that is happening, there's already a sliver of functional text generation to express the events.

 

As I mentioned in the previous post, months ago (I think I did), the chance of an act being drawn and expressed depends on the aspects that make up the current scene's context, an act of conflict has a better chance of happening if the scene has a big degree of conflict, this act then increases the degree of conflict in the scene leading to this feedback loop. I'm now trying to find the weights and functions that will create an explicit arc, like a scene becoming increasingly more conflictual, while not preventing many different acts from occuring.

The ideal is to balance the identity and legibility of a scene with a reasonable swat of possibilities. What I mean by that is, during a scene I want the player to be able to see that it is threading certain specific paths, like conflict or introspection, for it to be easy to make a reading of the situation and for the scene to gain a specific identity among its other possibilities (with different characters, for instance), but I also don't want for a single path to dominate the whole scene.

If all the acts are conflict, it's obvious where the scene is going and there is no tension, being too boring for the scene to happen in such a predictable way. The ideal would be to have two or three possible threads, so the player can have  expectation of how the scene ends. 

To test this I started to work on an automatic testing process that runs the whole scene at once and emmits me a report of what role was assigned to which character, what was the sequence of acts, with what aspects the scene ended with, how many acts it took to finish, what was the ending and what changes on the world state happened throughout.

My goal here while testing the scenes is for them to consistently end with a few dominant aspects, giving identity to each scene instance, with a series of acts that correspond to this aspects, especially the one that ends the scene, the most salient one. It doesn't matter if the aspects grow in an interesting way if it's not possible to notice this having na impact on the sequence of acts.

This is all too abstract yet, I'm gonna write another post through this month detailing how I develop the model of a scene, how the game instances it and how I'm planning to design each one, to try and give a good little dynamic to each of them. I wish I had written more, but I'm really tired at the moment.

For now I just wanted to tell that I resumed the project and what part of it I'm developing right now.

projeto arlequim pt.2: retomando o projeto

Estou postando novamente no blog para dar um breve update de um projeto que eu finalmente retomei depois de quase um ano. Eu reiniciei o projeto de ficção interativa procedural, que por enquanto ainda estou chamando de arlequim visto que ainda está em fase de protótipo.

Decidi recomeçar o código do zero, visto que melhorei muito enquanto programadora de C# nesse meio tempo e também tomei umas decisões melhores de pipeline e planejamento. Ao invés de já recomeçar a interface visual, mesmo com gráficos temporários, por enquanto estou trabalhando as cenas de forma independente e auto contida em uma janela de editor que me permite simular a cena toda. Uma das grandes vantagens da estrutura do jogo ser segmentada em cenas genéricas com papéis flexíveis é que fica fácil de testar o arco e a dinâmica de uma cena de forma auto contida, sem precisar jogar ou simular grandes porções do jogo.

Meu objetivo para o resto do mês é ou desenvolver a interface visual para testar a interação com a cena, arrastando personagens para dentro ou fora dela, ou investir mais nos modelos de cena, desenvolvendo um conjunto maiorzinho e já deixando o design delas mais interessante antes de fazer um protótipo jogável do sistema. Como eu falei antes, é possível testar se a dinâmica interna de uma cena está dando certo só pela simulação na janela de editor.

No momento estou iterando o design de uma cena de discussão verbal entre dois conjuntos de personagens, com um possível lado neutro tentando mediar a situação entre os os dois, buscando acertar os pesos e os algoritmos de seleção dos atos para ter um arco interessante acontecendo.

A janela de simulação da cena de discussão com os dados gerais da cena e do ato ocorrendo no momento, já tem um princípio de geração de texto funcional para expressar os eventos.

 

Como falei na postagem anterior, meses atrás, a chance de um ato ser sorteado e expressado depende dos aspectos que formam o contexto atual da cena, um ato de conflito tem mais chance de acontecer se a cena tem um grau muito grande de conflito, esse ato então aumenta o grau de conflito da cena levando a esse loop de retroalimentação. Eu estou tentando agora achar os pesos e algoritmos que vão criar um arco bem explícito, como um cena ficando cada vez mais conflituosa, mas que ao mesmo tempo não impeça atos diferentes de acontecerem.

O ideal é balancear a identidade e legibilidade da cena com uma gama razoável de possibilidades. O que quero dizer por isso, no decorrer de uma cena, quero que o jogador consiga ver que ela está seguindo um caminho específico, como conflito ou introspecção, para que seja fácil de criar uma leitura da situação e a cena ganhe uma identidade específica dentre as suas outras possibilidades (com personagens diferentes, por exemplo), mas também não quero que um único caminho domine a cena toda.

Se todos os atos forem de conflito, fica óbvio para onde aquilo está indo e não tem tensão nenhuma, sendo muito sem graça assistir a cena acontecendo de forma previsível. O ideal seria ter dois ou três caminhos possíveis, para que o jogador fique na expectativa de saber como a cena acaba.

Para testar isso comecei a programar um processo de testagem automática que roda a cena toda de uma vez e me emite um relatório mostrando que papéis foram dados para que personagem, qual foi a sequência de atos, com quais aspectos terminou o contexto da cena, quantos atos ela durou, qual foi seu ato final e que mudanças no estado do mundo ocorreram no decorrer dela. Uma vantagem grande do jogo conseguir jogar a si mesmo.

Meu objetivo testando as cenas dessa forma é conseguir de forma consistente que a cena termine com alguns aspectos claramente dominantes, dando identidade pra aquela instância, com atos que expressam corretamente esses aspectos, especialmente o ato que encerra a cena, o mais marcante. Não adianta os aspectos acumularem de um jeito interessante se não é possível notar isso tendo um impacto legível no decorrer dos atos.

Tudo isso é muito abstrato ainda, ao longo do mês vou escrever uma nova postagem detalhando melhor como eu monto o modelo de uma cena, como o jogo cria uma instância dela e como estou planejando o design de cada uma, para tentar dar uma dinâmica interna legal para cada modelo. Queria ter escrito mais agora, só que estou muito cansada no momento.

Por enquanto, só queria anunciar que retomei o projeto e que parte dele estou trabalhando agora. Até depois.

bate-bate pt.14: botando lutadores em campo

comecei agora uma mudança muito importante no projeto, um reestruturação da batalha que vai iniciar o desenvolvimento da parte meta de progressão do jogo. o pivô disso tudo é a nova possibilidade de você colocar novos lutadores em campo e de novos inimigos surgirem no meio da partida.

os cenários de batalha anteriores foram desenvolvidos para testar a relação das diferentes mecânicas e personagens, mas sempre foram apenas um teste. tendo personagens e inimigos fixos em posições especificas tornava eles quase um puzzle. no novo modelo, que permanecerá assim até o fim do desenvolvimento, a batalha inicia com alguns poucos inimigos e sem lutadores seus. o jogador possui dez lutadores no geral, mas apenas quatro estão disponíveis por vez para serem escolhidos e depositados em campo, como se fossem uma mão de cartas.

escolher depositar um lutador consta como uma ação e incorre em uma reação do lado oponente. agora, além da possibilidade de inimigos se moverem ou usarem itens, esse reação pode ser um inimigo completamente novo surgindo em campo. a possibilidade de inimigos novos aparecerem cria uma tensão bem maior a cada ação que você realiza.

em contraposição a natureza de puzzle do modelo anterior dos cenários de batalha, o modelo atual não só é mais flexível, como exige mais flexibilidade, já que te apresenta com uma seleção de quatro lutadores entre dez, te levando a tentar improvisar uma estratégia ou gastar uma ação sorteando uma mão nova. quero ver se isso traz usos novos e interessantes para personagens que antes eram um pouco inúteis quando se podia ter uma configuração ideal, ou se eu só vou eliminar esses lutadores.

as configurações novas de lutadores aliados e inimigos em cada cenário foram derivadas dos cenários anteriores. fui vendo quais cenários eram mais divertidos e funcionais e observando a proporção de um inimigo em relação a outro para determinar a chance de cada inimigo aparecer no modelo atual.

o jogador posiciona um lutador no campo e em resposta, um inimigo novo surge

15 soldados pt.1: meu primeiro protótipo de jogo analógico

esse é meu primeiro design analógico que acaba sendo funcional. não consegui fazer muito play-test, nem com muitas pessoas, mas como isso não vai ser viável com a quarentena, já vou botar esse jogo para jogo mesmo nesse estado pouco testado.

sumário das regras

um jogo de carta para dois jogadores, bem curtinho, com 20 cartas para cada jogador.

os jogadores duelam pelo controle de cinco campos de batalha, cada um valendo uma quantia crescente de pontos. no final do jogo, ganha quem tiver a maior quantidade de pontos dentre os campos de batalha em que venceu.

um jogador ganha em um campo de batalha se, no final do jogo, totalizar a maior quantidade de pontos com os soldados que tiver designado nesse campo de batalha. todo soldado tem um valor numérico de 1 a 15 e um poder especial que pode ser acionado quando o jogador joga ele em um campo de batalha.

no deck de ambos os jogadores há cartas de tempo junto às cartas de soldado. quando um jogador compra uma carta de tempo do seu deck, ele revela ela ao invés de botá-la na sua mão. quando ambos os jogadores, juntos, tiverem comprado 7 cartas de tempo, o jogo acaba na hora.

entretanto, a qualquer momento um jogador pode escolher desistir de um campo de batalha. ele dá a vitória desse campo pro oponente, mas pode recolher todos os soldados que tiver jogado nele. os soldados do oponente ficam trancados no campo de batalha cedido e não podem ser movidos ou recuperados por qualquer motivo.

meus objetivos com o jogo

queria fazer um jogo leve e rápido que permitisse que os jogadores fizessem jogadas surpreendentes e dramáticas, podendo virar o jogo várias vezes. dessa forma, botei os jogadores para competir em cinco campos ao mesmo tempo, dessa forma os jogadores podem virar o jogo em um campo de batalha de forma dramática sem a partida no geral ser tão instável, já que é um campo apenas.

entretanto, essa virada de jogo pode vir através do poder das cartas, quase todos envolvendo você mover soldados para outros campos de batalha, então os campos ainda estão conectados.

quero que a possibilidade de ceder um campo ao oponente tenha dois efeitos. o primeiro é permitir a um jogador reaver várias cartas de uma vez, mudando subitamente os soldados que ele pode designar a outros campos de batalha e os revezes que isso pode causar.

a segunda é criar uma momento de tensão toda vez que um jogador toma a frente em um campo de batalha. se você toma uma vantagem pequena é bem mais fácil ao oponente roubar a vantagem de você, possivelmente no finalzinho do jogo, sem te dar a oportunidade de pegá-la de volta, em compensação, se você envia bem mais soldados que o necessário, o oponente pode ceder aquele campo travando todas essas cartas.

no geral quero que esse seja um jogo de blefe e push your luck, onde os jogadores tentam prever onde o oponente está mais comprometido e quanto, para tentar ganhar com a menor vantagem possível, sem desperdiçar seus soldados. com a possibilidade dos jogadores fingirem se comprometer com um campo de batalha para então desistir dele, travando várias cartas do oponente, ou movendo subitamente seus soldados para outro campo, virando o jogo lá.

opiniões e comentários

fiquei surpresa com a quantidade de partidas que eu gostei e os momentos de tensão e estratégia que rolaram no geral. gostei bastante também do quão curtinhas eram as partidas.

ainda me incomoda um pouco a falta de consistência, várias partidas eram muito qualquer coisa, mas eu adoro magic e tenho partidas medíocres com frequência. o tempo curto ajuda bastante nesse sentido também, uma partida ruinzinha não dura muito.

algo que me incomoda entretanto é que o final do jogo as vezes é pouco dramático. queria que acontecesse subitamente para manter uma tensão constante conforme as cartas de tempo fossem acumulando e ninguém soubesse quando seria a última, mas vezes quando isso rola o jogo meio que só acaba do nada e é isso? nada de muito interessante aconteceu?

essas cartas de tempo são algo que me fazem pensar um pouco. eu gosto da mecânica, que o jogo progride constantemente até o final e portanto não pode se arrastar, mas que o final dele ainda chega de forma surpreendente, mas lidar com as cartas é mais chatinho do que eu queria para um jogo leve e rápido. o que rola no momento é que você embaralha seu deck só com os soldados, compra sua mão, depois embaralha as cartas de tempo e começa o jogo. parece um procedimento muito complexo e demorado para o jogo que se sucede. fora que para garantir que as cartas de tempo fiquem bem distribuídas no deck e não venham várias de uma vez, o procedimento pode acabar sendo ainda mais demoradinho.

apesar dessas considerações, eu gostei do jogo e quero continuar a trabalhar nele.

versões jogáveis

eu botei tantos as regras detalhadas quanto os componentes para impressão no drive. quero fazer um mod no tabletop simulator no futuro, mas preferi me familiarizar com o programa antes disso.

como eu não consegui fazer um playtest apropriado, em função da quarentena, eu não tenho certeza se as regras e os esquemas visuais conseguem explicar o jogo plenamente, então agradeço não só possíveis playtesters, mas também qualquer pessoa que se disponibilize a ler as regras só pra me informar se daria para começar uma partida com isso.

link pro drive: https://drive.google.com/drive/folders/1uIRsczWmkRsmn8DDjsgU_a7Zs8JDZSPu?usp=sharing 

bate-bate eng.3: new game mechanic! countdown objects

I implemented a new mechanic into the game, field objects that also have effects on the fighters, but only when their countdown reaches zero. some examples of this are bombs that explode, broken mechanisms that have to be fixed before they're usable and monster eggs that hatch new enemies.

the idea with the counters is strengthening a bit the arc of a battle. besides watching the hp of the fighters go down (for good and evil), the amount of buffs increase until a strike, the countdown of the counters adds another anticipation arc to the battle. I hope this can ensure an interesting mini climax inside a battle where a counter is present, so it isn't just a repetitive back and forth.

well that's it :) this is the last game mechanic to add, next I will work on advancing the game's structure and meta layer, so things will change considerably moving foward.

 

the moment an egg hatches and spawns a new enemy