As game developers, we’re tempted (if not outright encouraged) to code first and think later. There’s lots of good reasons for this – games are big projects, and feeling out a game’s mechanics through play is much easier than imagining them. What can we gain from planning, modelling and thinking out systems ahead of time, though? Maybe there are different ways of thinking about games that have their own power and usefulness. This week on The Saturday Paper we look at a language for modelling systems in games, and think about why it might come in handy.
We’re reading Ceptre: A Language for Modeling Generative Interactive Systems by Chris Martens. Chris presented the work at AIIDE last year, where she also gave an excellent tutorial as part of the EXAG workshop explaining how Ceptre works. The paper describes the Ceptre language for modelling game systems, with lots of examples and motivation to help understand how it can be used. You can download Ceptre at Chris’ project repo site too, if you’re interested in trying it out.
Ceptre uses logic to specify facts about a system, and rules that govern how those facts can change. So we can say something like…
at character location : pred
Which tells Ceptre that at is a predicate (sort of like a logical fact about the world) that has two bits of information, which we’ve called character and location. This is like the template for a fact - then we can fill in the template with concrete versions of it that add real facts about our game world:
at romeo town, at juliet town,
(These screenshots are from Klik & Play, not Ceptre – but the paper reminded me of how great KnP was.)
So now we have two facts (that Juliet and Romeo are both in town) we can write a rule that uses these facts to change the game world.
meetup : at C L * at C' L -o at C L * at C' L * knows C C'
There’s three bits to this rule – the name of the rule (‘meetup’ in this case) helps us keep track of our rules. Then the second line is the setup for the rule, the conditions we need to be true before this rule can fire, separated by * which works a bit like a Boolean AND. In this case, this rule matches whenever two characters are in the same location. C, C’ and L start with capital letters, which means they’re variables – so Ceptre can match them against any fact that fits.
The third line, which starts with a funny symbol called lolli, describes the result of this rule taking place. What happens is that the facts in the second line get replaced by the facts in the third line. As you can see, both characters are still at the location they started at, but we have a new extra fact – that C and C’ now know each other. Ceptre notes down that this fact is now true. Ceptre has some nice syntax for describing these rules much more compactly, but for the purposes of this post I’ll be skipping a full syntax lesson. Check out the paper for more!
But why would we want to model our game? Well, one of the things that Ceptre can do is run through a system of facts and rules, and then show us the result, called a trace. It can make rather fetching graph diagrams that show how facts about the world change, what rules fire, and what the results are. As Chris notes in the paper, this can help us find out why a certain situation came about that we might not have expected. We can also see the general flow of rules – if we notice that the player has insulted someone five hundred times in a row it’s easy to notice this and think about what we’d need to change to stop it from happening (assuming we want to).
Another thing we can do in Ceptre is describe how we expect the player to behave, and then ask Ceptre to simulate what the result would be. The paper describes how to model player activity in its language, by describing action phases (where a player can choose one of many moves to make) and reaction phases (where the game fires off rules in response to what the player did). Once you’ve got your model ready, you can tell Ceptre to make sure the player always makes certain choices, which might help you check certain scenarios.
The example in the paper is quite a nice one – suppose we model our roguelike environment with combat and loot and dungeoneering. Then we tell Ceptre that our player will always fight unless the next blow would kill them, in which case they’ll always run away. We can run and run and run our model and see if our player ever dies. If we found a trace that did, we’d know something was wrong with our model – and we could go and look at where the problem might be. We can also encode player behaviour that might be problematic – like exploiting a system to get infinite gold – and then adjust our model and resimulate until the problem goes away. I think Ceptre’s use in modelling game balance could be huge, actually.
Ceptre is still in development so it doesn’t have every feature you might wish for just yet. For example, because it randomly chooses which rules to apply, it can’t completely prove something will or won’t happen in a given game. It can show you one possibility, but more complicated kinds of proof are still future work. Chris has very exciting plans for the system, however, including things like invariants – facts that should always hold about a system. This would let us specify things like “the player never has negative gold” and Ceptre can repeatedly check this to make sure it never breaks (and notify us if it does).
I think modelling is a really cool idea for game systems – I especially like the cleanliness and satisfaction of being very specific about how a part of your game design works. Ceptre can be set up like an interactive game where player action is performed interactively by someone, which makes me wonder if it might be possible to sketch out a game in Ceptre and get people to playtest it in this super raw state. With very simple and clean code, it would make the prototype very fast to develop and reason about. You could almost design and redesign a prototype while people were playtesting it.
Ceptre isn’t the first project to try and build languages to describe games, but I think it’s noteworthy because it’s such an active and evolving project, and it’s trying hard to be open, responsive and usable by as many people as possible. There’s a lot of thought going into the project’s future trajectories and I’m really excited to see what kind of things it ends up being capable of. It’s a really general system right now, and if it can retain that as it grows it’ll become something super-powerful.
Where To Find More
Chris tweets and blogs about her research on a regular basis, as well as maintaining a great public repo of her work. This is open research in the strongest sense, and I think it’s really worth supporting, so go read, download, fork, follow and feedback if you’re at all interested in the kinds of goals Chris is working towards.
We’re halfway through Season 2 of TSP! Three more parts left. If you have any requests for papers (or kinds of paper) do let me know on Twitter. Thanks to all who have shared these posts in the past – it’s a huge boost for me.