Friday, July 16, 2010

language of game design II

I GOT SOME ‘SPLAININ TO DO.

First! A formal definition of what I was talking about last post.

A game {G} is defined as a set of rules {R} and artefacts {A} which interact on a set of boards {B}.

{R} consists of  statements about the beginning and ending conditions of game G, as well as valid player moves and responses. A statement r ε {R} may refer to any other member of R, including itself.

{A} consists of unique objects within the gameworld that have specific properties. (Properties may be, but are not necessarily, rules).

{B} consists of a finite arrangement of artefacts arrayed in a specific fashion. The rules may alter the appearance of B.  (Rules may govern how a board b behave at its border. Rules might create an infinite population of artefacts.)

Some changes! First, “player actions” aren’t really necessary as a specific category, since they’re essentially special rules. Consider a card game: The rules specifically state how many players may engage, what actions they may take, and when. It is useful to call out player actions as a sub-category of rules, but in the end they are still contained within the set of rules that govern the game.

In place of player actions, you really do need a “board”. Yes, this is exactly the same as GameMaker’s rooms. Boards can also be levels or stages or whatever. YOU WIN THIS ROUND, GAMEMAKER MODEL.

Anyway. I’m still convinced this model is powerful and all-encompassing enough to subsume the category of “games”. Let’s talk about something more interesting now!

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

I can clarify a bit why a rules-based system is better than a GameMaker-type system. Besides being “more natural”, rules give two main advantages. Instead of iterating repeatedly to import new sprites and turning those sprites into objects, the creator simply iterates over one set of items: rules. And the cool thing about rules is they contain implicit definitions of the artefacts, and sometimes even the boards!

Check out this series of rules:

1) The game ends when time expires

2) Picking up the “timer” artefact will extend time by 5 seconds

We have actually just defined a timer inline with our rules. What if our tool looked like this?:

rules


Editing rules should look as close as possible to natural language. That means providing a bit of a dictionary for concepts that are nearly universal in games: timers, score, lives. Rules obviously need to govern when the game is over – so we should suggest the creation of this rule up-front. “Time” should be a prepopulated noun, like “lives” or “score”. Because rules are programmatic statements, it isn’t hard to translate the first rule into:

while (timer > 0) continue;

or whatever.

The second statement is a bit trickier because it essentially becomes an in-line definition*. From a user’s standpoint, we already know (having thought about the design of our game previously) that we need an artefact that increases the timer. Instead of importing a sprite, creating an object from that sprite, and giving that object the event “Collision with player => timer gets 5 (relative)” , realizing you never created a timer object & scrambling to define that before you can complete editing your rule, we simply create a rule that says what an artefact a does. Our magic game-generating program recognizes we are trying to govern the properties of an artefact, and automatically creates one for us – even giving us a space to sketch a quick doodle of what the artefact looks like (allowing for the quick insertion of programmer art!).

rule_editor

Here’s a quick look at how the rules screen might be organized. There would be sub-categories for player actions and artefacts (since they interact with the rules quite often). Of course, the artefact rules here would be equal to artefact rules in the individual artefact interface (which, so far, still looks like GameMaker’s object interface in my head – less the events and plus an in-window sprite editor). And changing the sprite in either interface would reconcile that in both interfaces.

So how have we improved the GameMaker design?

1) A more natural language suited to how we actually talk about games

2) Repeated iterations on the rules, instead of on sprite+object+event.

3) In-line generation of objects based on rules, instead of  forcing the creator to pre-create every object and sprite they need beforehand.

Sound good? Are there any interface improvements GameMaker badly needs to their room/object editors? How would this system work at an implementation level? ALL QUESTIONS I NEED TO ANSWER, OR GET SOMEONE TO ANSWER FOR ME.

=-=-=-=-=-

*Obviously this poses a problem because, at a programming layer, we need to define objects before they’re actually used. So there is some resolution that needs to occur before compile-time here – shuffling around objects defined in rules to be defined previously to the actual rules themselves.

Incidentally, I am not sure what form the rules themselves take in the actual implementation of this engine. They almost need to appear as first-order functions for maximum flexbility – which suggests an implementation linked to .NET’s C#, or even F# if you are so brave. Scheme or LISP if you are more of a traditionalist who wishes to forego XNA

Wednesday, July 14, 2010

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.