The Language of Game Design

PREVIOUSLY I mentioned the view that the language of game design is kind of undeveloped. I also mentioned that the tooling for amateur game development kind of sucked.

I decided it was time to put up or shut up . I downloaded GameMaker. Surprise: The tooling sucks AND the language sucks!

First: The tooling. GameMaker operates on a “Game”. You add “Sprites” – pieces of art, which can become “objects”. Objects can have “events” attached to them, which govern their behavior. Then sprites and objects are added to a “Room”. Essentially, it’s a thin layer over the programming approach, where you import art, create (programming) objects, and write event handlers to govern their behavior. Which is mostly fine – although I’ve yet to see a graphical approach to programming work well.

The real problem is the work flow. Sprites, objects, events and rooms are all handled in separate windows, so you constantly switch back and forth, interrupting one task to start another. Creating events is repetitive and there seems to be a lack of macros to automate the beginning process of importing sprites (you need a LOT of sprites and objects, even if you are dedicated to the timeless principle of shitty “programmer art”).

I think part of the problem here is the language being used. Games are formal systems and need a strong, deterministic language to describe them, but if you asked me to describe  Bejeweled, I wouldn’t tell you it’s a collection of  objects represented by different colored sprites, and when you click one gem it triggers an event… Only a computer (or, a programmer) would describe something in such a perverted way.

Let me describe Bejeweled in my own words: There is a gridded board full of a random arrangement of gems. The rules are:

1. 3 or more similarly colored gems in a row or column will disappear and give the player points
2. any gems above the disappeared ones shift downwards, awarding the player with an increasing number of points
3. any empty slots on the board created by disappearing or shifting gems are filled with a random gem coming in from the top
4. The player can only move gems to create matches
5. The game ends when there are no valid moves for the player to make

The player is easy to describe: there is only one player, and the only action the player can take is to swap 2 gems according to the rules.

There are various artifacts*, especially dependant on what version of the game you’re playing – there might be a “wildcard” that can match any color, there might be a “bomb” gem that, when matched, makes several gems in the surrounding area disappear, etc.

If you stick to these 3 ideas, you can describe any game perfectly adequately. Mario is a game whose player actions consist controlling an avatar across several “boards” or “screens” or “levels”by walking, running, jumping, or using power-up artifacts.

And the rules are:

1. If the player falls off the screen, they lose a life
2. If the player is touched by an enemy, they lose a life
1. Unless the player has a power-up artifact, in which case they lose the artifact
2. Unless the player has jumped on an enemy, in which case the enemy dies
3. The above rule is negated if the enemy has spikes
4. If the enemy has a shell, the shell artifact is left behind
3. If the player collects 100 “coin” artifacts, a “1up” artifact, etc, they gain a life
4. If the player reaches the end of the level, they are allowed to proceed to the next level

I left out a lot of the rules about how the powerup artifacts work – fireflower gives the player ability to create fireballs, which kill enemies of a certain class, etc. Overall, it’s a bit of an oversimplification, but the point is it is easily recognizable as Mario! We’re looking for the minimum necessary system that expresses a game adequately, because people who aren’t programmers don’t care about “events” or “sprites” or “objects”.  I think this system is more intuitive and equally powerful to the GameMaker model, and I challenge you to find a game that is not expressed as a series of rules, player actions and artifacts**.

And if this system is powerful, then it should be possible to create a tool that wraps the programming layer in a intuitive and useful way. A pre-generated set of common rules would be ace– at least enough to cover all the significant genres, from match-3 to FPS (PLAYER ACTION: Multiple players move forward/back/left/right and consumes artifacts as a means of doing damage. RULES: Players struck by artifacts take damage according to properties of the artifact. Players who have 0 health die and lose the game. Last player standing wins. ARTFACTS: Guns, health, ammo) to RPG (PLAYER ACTION: Player navigates avatar and selects choices to interact with computer-controlled enemies and scripted allies. RULES: Health, MP, exp, damage dealt, turn-based or real time actions, level-up. ARTIFACTS: Healing, weapons, etc). And with these common rules, it’s easy to mash up genres so you have an RPG-platformer or whatnot. New rules can still be hacked in through the sprite/object/event implementation underneath, but this should at least as expressive as Game Maker. It’s Turning complete, after all…

=-=-=-=-=-=-=-=-

* I like the principle of calling artifacts “gems” but it would be confusing since I brilliantly decided to use Bejewled as my first example.

**It’s also tempting to say “goals” are a necessary part of this system, but I think goals are largely player-driven and defining them as part of our formal system would be too constraining. It’s not neccessary to state that Metroid can be played with the goal of collecting all the artifacts, or with the goal of completing the game as fast as possible – those arise naturally from human interactions with the rules within the boundaries of the player actions.