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

6 comments:

  1. Sorry! I actually am really interested in this, but have been distracted by my own projects. I will check this out soon!

    ReplyDelete
  2. lol it's cool, i've been crazy-busy too :)

    i really need to get to work on some more serious hi-fi prototypes - i'm not entirely sure that this is even useful except for laying out my thoughts.

    ReplyDelete
  3. Nice!

    I _really_ like the idea of object creation/modifying happening in-line, rather than as a completely separate interface like in most game editors. Especially if that is combined with lots of built-in 'clip art' objects that you could pick from, I think that removes one of the nasty barriers to using these tools.

    Maybe the same could be done for rooms/levels. Your rules could say "go to [level]" where [level] can either be your dropdown of created levels or the inline editor for a new one.

    I basically read the event sheet in tools like Klik & Play, MMF, and Construct as rules. They are all "When X happens, Y happens" type rules, but it's hard to think of game rules that could not be rephrased in that form. So I wonder if that model is actually fine and it's just that it needs to be presented to the user differently.

    Regarding the direct questions: I don't remember GameMaker's room/object editors well enough to comment on those specifically. As for how it could be implemented, that's a bigger discussion than I would want to fit into a blog comment. (a forum, im, or email would be good though!) I don't think you need functions as first-order functions (if I understand what you meant by that). C# is great but I think you would be creating a list of rule objects, each of which has a condition and action object, which themselves will have internal objects that do the selecting of game objects, and performing of the verbs in the rules. Pretty much any OO language can handle that fine.

    ReplyDelete
  4. Yeah, lately I've been fooling around with Kodu game creator and it's also very "rules-based" but it has that neccessary conditional.

    I find the "When [x], [y] structure to be really bad for the "always" case - it doesn't make any sense to anyone but a programmer. Most rules thrive off that structure but if we want to design from ground-up to be user-friendly, we need to take the language of the rules super-seriously even if it seems like a minor semantic issue. But SINCE it's a semantic issue it seems like it could be hacked onto an existing framework like GM, etc... along with the inline editing. which i agree is killer-important.

    I don't think any gamedev suites are open source though, which seems dumb. didn't know about MMF or construct though, checking those out now.

    Rules-as-objects would be good, yeah.

    ReplyDelete
  5. Nice!

    I _really_ like the idea of object creation/modifying happening in-line, rather than as a completely separate interface like in most game editors. Especially if that is combined with lots of built-in 'clip art' objects that you could pick from, I think that removes one of the nasty barriers to using these tools.

    Maybe the same could be done for rooms/levels. Your rules could say "go to [level]" where [level] can either be your dropdown of created levels or the inline editor for a new one.

    I basically read the event sheet in tools like Klik & Play, MMF, and Construct as rules. They are all "When X happens, Y happens" type rules, but it's hard to think of game rules that could not be rephrased in that form. So I wonder if that model is actually fine and it's just that it needs to be presented to the user differently.

    Regarding the direct questions: I don't remember GameMaker's room/object editors well enough to comment on those specifically. As for how it could be implemented, that's a bigger discussion than I would want to fit into a blog comment. (a forum, im, or email would be good though!) I don't think you need functions as first-order functions (if I understand what you meant by that). C# is great but I think you would be creating a list of rule objects, each of which has a condition and action object, which themselves will have internal objects that do the selecting of game objects, and performing of the verbs in the rules. Pretty much any OO language can handle that fine.

    ReplyDelete
  6. Sorry! I actually am really interested in this, but have been distracted by my own projects. I will check this out soon!

    ReplyDelete