TL;DR: By analysing and modifying the data types involved in other games’ mechanics, one can generate interesting new ideas and train one’s ability to “break” conventions. It can also shed light on *why* certain choices are convention in the first place.
Why you should consider focusing on the “data types" of game mechanics
Games are a fascinating medium, because it is relatively new, and the aspect that makes it stand out from all other media - the game mechanics - seems endless with possibilities. Game mechanics are interesting to design, because designing good ones requires a lot of exploration and experimentation, and a good intuition for how mechanics will result in interesting challenges and decisions for the players.
Being a creative endeavour, there are countless different ways to explore and construct new concepts. In the past year, I have started exploring game mechanics concepts based on the mathematical data types or data structures involved in them, and I find that approach quite effective on multiple levels. First, it trains the intuition when it comes to brain storming, because of the larger “arsenal” of concepts to choose from. Second, it increases awareness of conventions in game design, which is always a good starting point if you want to innovate.
So, what are these data types I am talking about? Data types are simply the mathematical type of object that describes an aspect of the game/mechanic. Some examples would be that health bars can consist of whole numbers (i.e. the number of hits you can take), fractional numbers (like partial hearts in Zelda, although one can reduce that simply to the whole number of quarter hearts in principle), and floating point numbers (like most shooters, even though HP might be shown to the player as whole numbers).
Examples of common data types in game mechanics
The space the player moves on, or on which the player moves objects, units etc. on, can have various dimensionality, and also be either discrete or continuous. For example, in Darkest Dungeon, motion across corridor with your squad takes place in continuous 1D, even though the corridor’s events or intractable are placed on a discrete 1D grid.
In XCOM, units move on a discrete 3D grid. In Platformers, Shooters etc. one moves about in a contiuous 2D or 3D space.
Skill Trees/Graphs are graph- or network-like structures, with discrete nodes (abilities) connected by edges (requirement relationships). But also the overarching map of a particular dungeon in Darkest Dungeon is in essence a network structure of Rooms, connected by corridors, laid out in a 2D plane. Another great example of a game that heavily relies on network structures is Democracy 3, where policies have various effects other policies’ outcomes.
Other important types are lists, e.g. lists of objects in your inventory, or lists of tasks - both with fixed order or variable order, and booleans and enums/finite state values.
There are probably many others more, but you get the idea!
With each of these data types, you can go in depth and explore the many specific sub types that exist. For the example of 2D grids, there are square grids (Civilisation 4), hex grids (Civilisation 5), triangle grids (could not think of an examples, can you?) and inhomogeneous/arbitrary grids (like the progress maps in Bad North and Faster Than Light). Graph structures can be with or without loops, directed or undirected, with redundant edges or without, etc…
You can also always combine data types for complex data structures. E.g. some 2D platformers have multiple layers of a level that the player can transition between, such as in Rayman Legends. This could be regarded either as a stack of 2D continuous spaces, or as a 3D space that is continuous along two dimensions, and discrete along the third.
How "data types" can help generate new ideas for game mechanics ...
Now that we are thinking in terms of data types and data structures, it is easy to go and do one of my favourite things: look at conventions and come up with ideas to change them. Of course, often we will end up with something that somebody else has already come up with, but that’s not the point here.
Just for fun, let’s consider health bars. Usually they are represented by one or more integer or floating point numbers for health, shield, mental condition (RimWorld, Darkest Dungeon). But in principle we could instead use a list of objects, e.g. body parts, of which the player loses some when getting hit, but can obtain replacement ones (e.g. by collecting, buying in a shop, crafting, …).
Or the health bar could be a 2D continuous square that the health meter indicator moves on, touching certain regions (black border and circle in the picture above) of it means death, and different enemies move the indicator in different directions or increase the size of the indicator.
Or the health bar could be a series of states the player traverses when getting hit, each coming with different effects on the player’s abilities. …
These are ideas are quickly generated, and not necessarily all of them lend themselves to fun mechanics. But the point is to be able to quickly come to a more diverse set of ideas for solutions to a particular design problem, and to have a way to get out of the “every other game does it this way”-trap. The next step is to consider how this new choice would interact with the rest of the game, whether it creates interesting decisions or challenges, how it could be augmented by interesting rules, etc.
… or help you understand design choices better
One of the most fruitful aspects of this approach is that with simple though experiments about altering a mechanic, one can realise why things have come to be convention and what assumptions went into them. For example, health bars as integer or floating point numbers are a simple way to increase the room for mistakes by the player compared to single-hit deaths. Adding more dimensions to the health bar creates more complexity, that can either be a benefit because the player could strategise, weighing taking one type of damage versus another, but for a fast paced game such as a first person shooter, that complexity would be overwhelming. In Darkest Dungeon, a turn-based game, that complexity creates interesting decisions for which enemy to focus first, since taking health damage with a character risks their immediate, permanent death but could get healed for free at the end of the run, whereas stress damage is costly to remove after the run, but taking stress damage rather than health damage could save a character. Simply using one number here would have taken that kind of choice from the game and made it much less interesting.
Where else to go from here?
Lastly, instead of doing “innovation by modification”, we can also do “innovation my construction”, i.e. we could start out with a particular data type or structure, and build the game / mechanics from there, combining several data types, what they may represent and with which rules they are associated. This is considerably more complex and maybe the topic for another blog post. But I like the approach, even if it is very difficult, it can lead one to a lot of interesting places one would have never considered otherwise, even if those turn out to be dead ends - parts might make it into a proper project some time!
Thank you for reading! If you have any thoughts on this topic or my article, I would love to hear about them either here in the comments section, or via Twitter @hallgrimgames!