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?:
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!).
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
