The Core

You’d be surprised how frequently the issue with a project is a lack of a clear vision for the game. It is relatively straightforward to have a game idea, and it isn’t too hard to actually generate some momentum to developing that game idea, but it is something else entirely to have a game design.

Over the decade that I worked at Vlambeer, I had the fortune of working alongside the incredibly talented Jan Willem Nijman - a designer with a almost scary level of design intuition, honed over two decades of making tiny games. When we founded Vlambeer, I was a programmer with some business sense - but not much design talent at all.

To simplify a lot of the day-to-day operations at Vlambeer, I aimed to create some sort of mental model to allow me to understand how Jan Willems’ brain worked, so that we could cut back on superfluous discussions. While creating a model of how someone else thinks obviously never got me close to thinking the way his brain can intuit game design based on a decade of experience, it did give me a few valuable insights that were not specific to my work at Vlambeer.

One of these insights is the notion of a “Core” in a game. I suggest that the Core of your game should be a feeling or a sensation - it should be very short statement, a few words long at most.

The Core of your game should be a feeling or a sensation - it should be very short statement, a few words long at most.

Draw a circle, then another one around it, and then a third one around that one - each larger than the previous. Write the Core in the middle circle. In the second circle, you would write your Mechanics. In the third circle, you would write the word Declarative. The area outside the outer circle is the Meta, anything that is related to the game - but not quite part of the game.

Let’s run through what each of these mean for the purposes of this model:

• The Core is the purpose of this exercise. What is your game? What truth sits at the heart of it?
• The Mechanics are the ways the player interacts with your game. They’re the rules, the way the simulation is affected by the player. You can write the actual mechanics here, or the way they’re meant to affect the player.
• The Declarative is the way the game declares its state, its (emotional) intent, and the changes of the state, to the player. You could consider art, audio, narrative, themes, and anything like it to be part of the Declarative layer.

Start writing things that you think are interesting or special about your game into these circles. First, write into the middle circle what you think the Core of your game is. This should be one single word or statement. Technically, some games have multiple cores or pillars (which will be a different story, for a different time), but if you’re trying to find these mid-development chances are that finding a single one will be hard enough. Try to keep it to one, and only add more if you really can’t solve the puzzle otherwise.

Then, write the Mechanics that correspond to it into the Mechanics circle, and the relevant Declarative elements into the Declarative circle. Continue from the Mechanics circle: which mechanics are missing that are unique selling points, or define the way your game plays or feels? For each mechanic, write the corresponding or relevant Declarative aspects into the Declarative circle. Finally, do the same for the Declarative layer.

Now comes the tricky part of this exercise: take anything you’ve written into the Mechanic or Declarative circle, and try to imagine what it is supporting in the same circle, or a circle further inwards. For example, if you have a rustic visual style, and a slow-paced game, you could imagine an arrow going from rustic to slow-paced - even if technically, the connection is the other way around.

If you were to draw arrows from anything written anywhere, of what said thing supports, the arrows should always find a way to point inwards, or -occasionally - sideways within their own circle. Complete this for everything in the model, as completely as you can. If you find that you are overwhelmed, see if you can restart the exercise, but limit or group together certain elements (ie. basic verbs like “jump” and “walk” could both just be “move”).

What the game is trying to achieve is the Core. The Mechanics and Declarative layers support that Core. The Declarative layer supports the Mechanics and the Core. And the Meta supports everything else. Any arrows that are failing to point inwards are things to think carefully about. If your game is about -say- forward momentum, and you have a mechanic about slow-motion, you might find that a contradiction. Not every contradiction is bad, but being aware of them is always helpful.

When Vlambeer was developing Nuclear Throne, I kept forward momentum in mind as a Core for the game, and tried to execute whatever I was doing along that line. And it was proven an accurate guess when Jan Willem flagged Chicken’s active ability - slow-motion - as a problem, and we opted to re-design her to be able to throw weapons instead. I don’t think forward momentum was ever agreed upon between Jan Willem and myself - but since we had aligned on it in our design, it allowed us to collaborate on achieving those goals without needing to talk about it too much.

Also note that forward momentum was never marketed as important to Nuclear Throne. Sometimes, you get lucky, and the game’s central conceit is very marketable. For Nuclear Throne, the characters and narrative and roguelike elements made for far more potent marketing material - and you can find the core of the design in the fact that almost everything in Nuclear Throne, from enemies to radiation experience drops, forces you to keep moving yourself into danger.

I don’t believe there’s one correct way to make games, and this is but one potential tool to think about what you’re making. And I believe that-if you’re a new developer, or not quite confident about your design- figuring these ideas out for your own game might help you understand what you’re making, what is supporting that core, and what is contradicting it.

Whether we like it or not, there is often a surprising level of consistency to our sense of aesthetic or our general intuition - and you will frequently be able to find a common thread throughout what you’re making even if it is not an intentional part of your design. Sometimes, when you are stuck, or unsure where to go, all that you need is to figure out what is giving you that gut feeling that something is off. Sometimes, the problem is that the beating heart of a game is intuited instead of understood - and your brain has subconsciously locked on to the fact that something is contradicting it before you consciously defined anything at all.

Being intentional about design can frequently resolve issues that gut feelings cannot - and sometimes gut feelings can solve issues that being intentional can not. It’s not always clear what the issue is, but this model is a tool to help you find the issue, or exclude one possibility from the diagnosis. Either way, understanding what you’re making will help you make better games, and it’ll give you the added bonus that it’ll help you communicate, pitch, and market your game better than you could otherwise.

Actionables

1. Complete the Core/Mechanics/Declarative model exercise for a number of existing games that you’re really fond of. See if you can find anything that could work as a Core statement or feeling for the game. If you feel you’ve got a good feeling for it, try applying it to your own game.
2. Read up on the Mechanics-Dynamics-Aesthetics Framework, which was an alternative model that I found inadequate for my purposes here, but which I still use frequently for specific thought experiments. I can recommend this article by Matthew Gallant.
3. As an additional experiment, consider how everything outside of your game fits the Core of your game. How does your store page point back at it? Or your pitch? What about your key art, or screen shots? The trailer? Your social media strategy?