Keith Burgun writes about his “core mechanism” as a tool for ensuring elegance in game designs: the core mechanism is the main mechanism in a game, and other mechanics are included in a large part based on how related they are to the core. By excluding mechanics unrelated to the core, we screen chaff from the game as we’re designing it. Just as we shouldn’t add in random new melodies over the top of our songs, or paint random shit over the top of our paintings, we shouldn’t add new systems besides the core system into our games.
However, due to the nebulous nature of the word “mechanic” and the theory’s inability to describe systems as basic and elegant as Tetris, I’ve modified it slightly to better fit my own practices. Instead of core mechanisms, I propose that core decisions should be the basic core of our interactive systems. After all, games are all about decisions, so it makes intuitive sense to put types of decision at their cores.
Simply put, a core decision is a type of decision that’s made in a game. In Tetris, the decision is where to put the blocks in order to best clear lines. That’s the only type of decision made in the entire game (since the holding mechanic showed up that’s not really the case, but in old versions of Tetris it didn’t exist). On the other end of the spectrum, Final Fantasy XV has many types of decisions: what to buy in the shop, where to walk, what moves to use in battle—the list is fucking enormous. That’s an example of a system that isn’t elegant, because it has so many different types of decisions, instead of one type of decision that perfectly anchors what the game is about, like Tetris does.
To determine what the win or loss conditions of your game should be, look at the repercussions of different choices available when making the core decision. Some of these should be designated to lead towards a win and some towards a loss. Do the consequences of one choice advance the gamestate towards the win condition? Do some other consequences advance the gamestate towards the loss condition? If the same conditions that bring victory also bring defeat, that creates tension between the need to avoid losing immediately and the need to eventually win. For example, in Tetris, a repercussion of placing a block is that the basin is now closer to being filled, advancing the game towards its loss state. Simultaneously, placing a block brings the lines that the block was on closer to being full, bringing the game closer to its win state of clearing 150 lines (that’s the win state I use). If instead placing a block a certain way moved you further from the loss condition AND closer to the win condition, there would be no tension in deciding whether or not to place the block that way. It would be like a combo in a fighting game, all execution and no decision making.
When determining whether or not to add a mechanic to your interactive system, simply look at how it will interact with your core decision: does it make the decision more interesting? Does it add context that will change the relative value of available choices? It’s those questions that determine whether something needs to be a part of your game. By confining each decision to its own separate game, we can ensure that each game contains no chaff, and properly emphasizes the decision the game is supposed to be about. When games are made to feature different types of decisions, conflicts and inelegance arise as a result. In deckbuilding games, players select cards from a common pool, and then they add those cards to their deck and subsequently choose which cards to play and what order they play them in. While decisions about which cards to add to the deck are relatively interesting, decisions on which cards to play are usually flat and one-dimensional. Because deckbuilding games use different types of decision instead of just one type of decision, they’re filled with decisions that aren’t compelling or enjoyable.