I'll be doing a series of blogs posts shortly about the iOS puzzle game I just designed ("Connectrode") and submitted to the App Store this morning. For now I thought I would "detox" from that project, and ease myself back into blogging, by writing about something else that interests me.

Warning, this is a fairly off-the-cuff attempt to express some very abstract ideas about both game design and programming - I haven't necessarily polished these ideas into the most comprehensible form... I'm mostly just writing this to get the ideas out of my head and onto "paper."

I've been a "Gameplay Programmer" in one form or another for most of my career. A lot of this has taken the form of my designing games myself, and then proceeding to implement them myself - a process which I love both sides of. Not very many game designers actually do the coding themselves; and not many gameplay programmers do a great deal of game design. I feel like it's given me a unique perspective, and in particular it's led me to conceive of a new type of game engine - one that would minimize the need for even having a gameplay programmer, and put the implementation directly into the hands of the designer.

The idea started to come to me as I worked on card game and board game design prototypes - this, I realized, was a very pure form of game design. Though "table game" design gives you a limited set of tools compared to those you have on electronic games, it can really open your eyes as to what the core of game design really is.

I've believed for some time that, structurally, a game is comprised of only 3 things:

1. Nouns - Elements of your game system, and variables related to them. Example: Players, avatars, NPCs, items, a map, a world, locations, tiles, cards, XP, HP.
2. Verbs - The actions that agents (players or player stand-ins) in your game can enact; the "things you can do." Example: Attack, jump, move, bribe, play card, roll dice
3. Rules - Rules, which limit the nature of the existence of the nouns and create relationships and interactions between them; and which limit which verbs can be enacted when and in what context. Example: "draw a card at the start of every turn"; "when a unit attacks another unit, it does damage equal to the attacker's base damage value"; "when Mario is not on the ground, gravity pulls him down at a rate of acceleration of 1 pixel per millisecond".

Every game has these three elements, and I think that games (in terms of a formal structure) are solely comprised of these three elements. (In fact I theorize that all systems can be defined by these three elements, and that the "engine" I'm about to propose might be a new approach to developing not just any type of game, but any type of software. But for now I'm sticking with the domain I understand best: games).

Given that this is the structure of any game, shouldn't a proper game engine be focused on, first and foremost, modeling these three things, and making the creation and modification of them as straightforward as possible? A few game engines seem to do this, but in very specific ways which don't seem to get to the heart of the matter.

What this comes down to is that I feel that current programming paradigms do not provide an appropriate language for expressing these structures. This may not be true for the "nouns" element - Object-Oriented programming, as its name implies, is very good at representing different types of objects ("nouns") and the relationships they may have between each other, with minimal duplicated code or wasted work.

But both verbs and rules are hard to express clearly in any programming language I know. In particular I think that rules (which I see as the more important and often-changed element of game design) can often be difficult to represent in existing programming/engine paradigms.

Let's say I'm developing a platformer and I want to add rules that say "when you jump on any enemy's head, it dies", but then add an exception that says "when you jump on a porcupine's head, it survives and YOU die". In current Object-Oriented programming paradigms, I'm probably going to express this by 1) adding a "jumpedOnBy()" function to the Enemy class with a body of "die();" ... and 2) overriding that function on the Porcupine enemy class with a body that says to kill the player instead. (This is not exactly how I would actually implement this but it's close enough for the point I'm making.)

The point is that the habits of Object-Oriented programming lead me to instinctively express this rule as properties or behaviors of the nouns. I think this habit is inappropriate: each rule should be represented as an object in its own right; and conceptually the rule should in fact be an element that "controls" the nouns and can modify them. But our current typical representation of rules doesn't do this at all.

Instead they find themselves poked and prodded into various places in code. It's rare, in gameplay code, to find a rule that is even concisely expressed in exactly one place in code - in other words, it's rare to find a 1-to-1 relationship between "a game rule" and "a chunk of code."

As I think this through now, I think that perhaps the biggest, paradigm-shifting implication of coding this way would be thatnouns do not have behavior of their own. In a game of Monopoly, the Thimble on the board has no behavior of its own; it just has the capacity to rest on different locations on the board. It is verbs that put the thimble into motion (a player initiates a "move" verb), and it is rules that restrict and define that motion (a rule states that the player performing a move verb must roll the dice and move the thimble that many game spaces in the forward direction).

If we believe that our code will be cleaner and more maintainable if it structure matches the structure of the conceptual objects that we're actually representing, then we should move gameplay code to a paradigm in which Nouns have no behavior of their own; and push to make Rules and Verbs first-order objects.

Furthermore, this should be extended to the point that Rules are entirely data-driven, and can be defined entirely by designers using engine tools. My ideal game engine looks like this:

• The Gameplay Designer can add Rules into the game engine using a straightforward but robust engine for expressing those rules. (They also define Nouns, and have some capacity to define Verbs.)
• They can then immediately play the game with these rules being applied by the game exactly as defined. They see where the rules fail to create the behavior that they want, and can easily modify those rules and run the game again.
• That's it. There is no Gameplay Programmer in this workflow. It's kind of like the Game Designer is sitting down and defining a board game design, playing it and iterating on the rules... except that this game happens to automate all the enforcement of the rules, allowing them to make much more complex games. Because that's all that video games are.

All right, this is a grand high-level vision of intentions, but how exactly do we go about it? I gave a counter-example with the "jumping on the porcupine head" rule and how we shouldn't be representing that; but where's my example of exactly how weshould?

I'm afraid I haven't gotten that far; I only have the glimmer of an idea at this point, and I feel like throwing out my half-baked answers wouldn't help anyone. But, it's something I've thought a lot about and would like to spend more time researching. Googling for "Rules-Based Programming" has been encouraging, as it turns out that there's a substantial amount of existing knowledge for programming frameworks that work along these lines; but I haven't yet explored them thoroughly enough to determine whether they truly apply what I'm trying to get at here.

The "hard problem" here is representing rules as abstract entities. The fact is that a "rule" is something that we as humans have a very loosely-defined idea of. I don't know if there's a single language that can be used to express any and all possible "rules"; perhaps the only language that can actually do that is human language itself.

But perhaps it's not as hard as all that, and we need to simply sit down and take this abstract ideal and determine what concrete form it could take. Or perhaps someone out there has already made significant strides in this direction, or an entire engine based around this, of which I'm unaware.

My main hope is that this blog will spark more thought and discussion on the topic; lay out a (very vague and high-level) ideal we can work towards; and hopefully that someone will even point out to me a paradigm that already represents gameplay code in this way, or at least is a step in this direction!

[Shay Pierce is a guy who started making games at a young age and has never been able to stop, in spite of his many years in the professional games industry. He is currently the Lead Game Developer at OMGPOP Austin, a newly-formed social game development studio. This post was cross-posted from his game design blog at http://www.DeepPlaid.com]