Applying Abstract Models to Game Design

[In this post, I demonstrate a method of practically applying abstract models (as demonstrated by Raph Koster) to a simple game design in order to improve the game's core mechanics, gathering influence from other games in similar genres.]

In my most recent project, I've been struggling with the fundamental design of the core mechanics.  I've been reading lots of game design strategies and I understand them, but practically applying them has been difficult for me.   This post examines the use of an abstract model as a way of thinking about your game's core mechanics and how to build a better game with that knowledge, specifically applying it to my current project.

Raph Koster's Abstract Model

I discovered the idea of representing a game as an abstract model by watching Raph Koster's speech at GDC Online 2012 titled A Theory of Fun, 10 Years Later.  In his presentation, he arrives at a slide titled: "Instead games are like this, abstract models".  He uses these models to design games because it simplifies the game design into the core activities, actors, objects, verbs, and statistics and gives the designer an "at-a-glance" understanding of how the game will function, whether it is deep enough, and how complicated the game really is.  In his presentation, he demonstrates this model by illustrating the abstract model for the Facebook game "Island Life" by MetaPlace.

IslandLifeAbstractModel

Abstracting Pivot's Core

I really liked where he was going with the abstract model concept, so I decided to try and apply it to my current project, Pivot.  So, I developed my best interpretation of an abstract model for Pivot in its current state. I arrived at the following diagram:

Pivot Abstract Model 1.0

Ultimately this graph confirmed the reason why I began this exercise in the first place.  The core game model is too simple and to be blunt...it's boring.  The truth is, I don't think I understand enough about these "abstract model" diagrams to really know how to fix the problem with Pivot, so I decided to do the same analysis on a game that already exists and is quite successful.

Pulverizing Pivot with Offspring Fling

I chose to decompose the core mechanics of Offspring Fling by Kyle Pulver because the game, its marketing, the developer, and the simple fun at its core have inspired Pivot's development.  For those of you that may not have played Offspring Fling, you should go buy it (available on Steam, Desura, OffspringFling.com).  I'm not a game reviewer, so my wording may not sell you the game, but I want to illustrate the concept before going any further.  The game is a 2D puzzle platformer featuring over 100 levels where the objective is to get yourself and all of your babies into the door by carrying, throwing and/or dropping them.  The game is full of juice like timing, developer scores [with ghosts!], replays, control subtleties, level editor and my 5 year old son's favorite: dandelion like flowers that poof when you jump on them.  It would also be a shame not to mention the music by Alec Holowka.  The game had enough awesomeness to get featured on a ManVSGame cast where Kyle gave out plenty of codes and MAN agonized over the strategies to unlock and achieve the best score possible, replaying levels until he achieved perfection on every one.  This really got my brain ticking and I wondered:  what was it about this game that is really drawing people in?  On the surface, it seems really simple, but like most things in life, the best things are simple but elegant.  So let's try to find that elegance...  The graph below illustrates what I believe are the core mechanics of Offspring Fling.  The game has more sub-systems (like switches and bounce pads), but this model is at the core of every level.

Offspring Fling Abstract Model

With this model and understanding in hand, I set out to improve Pivot's core gameplay mechanics, starting with the key...

The Key to Pivot's Future Success

In the current model, the player can collect key objects, which increase the key statistical resource (the number of keys you have available to use in the current level).  Collecting keys does not impact anything other than this statistic.  This statistic in turn is used as a currency for unlocking chests.  Chests contain gems, which are completely worthless in the current model.  Unlocking chests is also the ultimate objective of the game right now, so it has some intrinsic value to the player (finish the level to progress).  But some parts of this model are broken.  The chain is linear and has very little impact on player choice or rewards.

I decided to start from scratch and throw away the key idea for now.  Perhaps this can be a supplemental mechanic, but the core mechanic needs to be better.  I referred back to the Offspring Fling diagram from above and realized that the much more interesting core mechanic lives in the avatars interaction with the babies.  So I decided to use this model, changing some of the verbs and their impact on the player as a starting point.  With this idea in mind, I re-imagined the key as a gem object.  Instead of granting statistical resources, the gem is a manipulative object in the world.  This gives a lot more tactile feedback with in-game objects, which feels great for starters.  But I also wanted to use 1 key takeaway from Offspring Fling.  The objects you interact with impact the players choices.  When carrying babies in Offspring Fling, the player is afflicted with several detriments.  The player cannot jump as high and they cannot travel through narrow spaces.  This allows the designer to create interesting puzzles where you have to carry the baby, but you also have to jump a gap, so the benefit of carrying impacts the need to jump, forcing the player to make interesting choices.  Armed with that knowledge, I decided that carrying a gem either needs to prevent the player from pivoting or jumping.  But since pivoting is such a critical part of the game's idea, I didn't want to limit pivoting (yet), I wanted to encourage it.  So I decided that carrying a gem should prevent the player from jumping.  Making this design decision really improved the gameplay.  I feel now like I have choices to make every time I pickup a gem (do I need to be able to jump or do I need to be able to pivot to reach my next objective?)

I also had to decide what I wanted to do with the gems.  At this point, the game is being built as a Point A to point B game, but I now have a resource in the level that I care about.  I decided that I wanted something a little more complex than "take the gem from point A to point B", so I added an additional object, an Exit Portal which is activated by the crystal.  The player must then navigate back to the exit portal after placing the crystal.

The game's core abstract model now looks something like this:

Pivot Abstract Model 2.0

puzzle_keys

puzzle_gems

New Ways of Forward Thinking

With this small exercise out of the way, I feel like I've practically applied a game design strategy to one of my projects and I hope to continue iterating on Pivot's design.  I still have a lot of things I want to do with the abstract model of Pivot's core mechanics, but I feel better equipped to try out new ideas after doing this exercise.  If you are struggling with a core mechanic design and you are heavily influenced by another genre of games, I would encourage you to do some analysis of that game, break it down, graph it, and use abstract models to really break down how the game works.  Then apply the same approach to your own design or significantly tweak the existing model, applying your own spin on the verb/object interaction to achieve something more awesome.

Good luck!

Editor's Note about Pivot:
Pivot is an experimental 3D action-platform-puzzle game where the player must restore "color" to a fragmented world by rotating around the world's edges, finding gems and putting them back where they belong. 

Development progress will be tracked on my personal blog at http://www.redclovergames.com/blog