Designing a game and coding a game often get tossed together when talking about games. I often run into people outside the game world who don’t believe that one can design a game without knowing how to code. Even to those in the gaming community the distinction between designing and coding can be hard to discern.

Over at Gamasutra there are two articles related to both that I want to mention. One article is focused on the technical process of making a game while the other is focused on designing meaningful gameplay.

Meaningful play is a concept that can be interpreted to mean that the player is playing the game for a meaning (purpose) outside of the game itself like learning how to code or acquiring a new skill. The term can also be applied within the game itself, as in the choices that a player makes has to have meaning within the framework of the game.

Evaluating game mechanics for depth looks at the concept of meaning in a game but does so in a way that I feel is still lacking. It’s a good step on a path towards a more thoughtful debate on assessing meaning in a game; however I would have taken a different approach: instead of working from a game-focused approach towards a concept of meaning I would of looked at what meaning means then take a fitting philosophical approach from there and apply it to gaming.

To me, it describes a sweet spot — that point during a game where the player can repeatedly display his mastery of a game mechanic. Challenges never stay the same long enough to be boring and yet they also don’t change so fast that the player can’t enjoy his mastery over the game.

Clearly this “depth” is something we want to achieve in many of our mechanics, but it’s often less clear how to obtain it.

In my experience, in order for a game mechanic to be deep it needs two very important things:

It needs clear objectives, so the player knows what he has to do to succeed. Confusion and obfuscation tend to make players feel like a mechanic is LESS deep once they find themselves needing to experiment randomly to win.
It needs a variety of Meaningful Skills that you, as a game designer, can use to create good challenges for the player and that the player in turn can use to achieve mastery over the game.

So once we have gameplay figured out, it’s time to code right? Not really. More likely designing and coding would be happening at the same time with the two influencing one another. Bane Games’ Alistair Doulin wrote a good article on how to keep gameplay technology agnostic and it’s worth a read even if you don’t program. Obviously it’s not possible to keep code fully separate from gameplay as some systems require it and in some cases the game mechanics have to change fundamentally based on the control options the player has.

I’ve worked on three different game engines and all have had gameplay and engine intertwined throughout the source code. In Unity, all game objects inherit from, MonoBehaviour giving them full access to the power of Unity (and forming a hard link between game and engine).

Recently, I’ve moved away from this approach to a better “separation of concerns”. I completely separate out the gameplay making it engine agnostic. This has worked well and I plan to use this approach for most of the games I create in the future.

Today I discuss this separation of gameplay and why I recommend others make the switch.