Guess My Game

Reginald Braithwaite a while back posted his favorite interview question:  "sketch out a software design to referee the game of Monopoly."  My interest in his question starts with game "nouns and verbs"  and ends up this muse:  would Martians wishing to understand the rules of the World of Warcraft (WoW), say,  be better off trying to read its source code or watching video of millions of hours of screen capture?

Also mentioned, the "Vietnam of Computer Science" and the "Grammar of Gameplay..."

Reginald's interest in the game of Monopoly as the subject of an interview question centers on how to represent games well with object models (see Object Oriented Programming).  While I suggested in Hot Blooded Objects (and Troubles with Tribbles), software objects present a number of challenges to virtual worlds, the challenge that Reginald picks up on is different, though a most interesting one:  how to model the virtual world effectively in code.

Interestingly, he starts with a noun/verb lingo with parallels to how it is used by game developers.   But he also suggests of the challenge in mapping an easy (and perhaps even imperfect vernacular) into software.  Listen:

...Now let's talk about 'object-oriented programming' for a second. 99% of the stuff you read discusses modeling real-world physical objects. Things. Nouns. It is a Kingdom of Nouns. Most candidates start every design by dutifully listing all of the nouns they can think of and then they spend the rest of the time available thinking about piling them into phyla, hierarchies of "IS-A" and "A-KIND-OF."

This approach, which I will call "noun and verb," is so limited I'll dare to call it brain damaged. In fun. But seriously, competent software developers spend much more time on relationships, responsibilities, and constraints than they do on trying to prematurely optimize reuse through inheritance.

Now let's ask a question about Monopoly (and Enterprise software). Where do the rules live? In a noun-oriented design, the rules are smooshed and smeared across the design, because every single object is responsible for knowing everything about everything that it can 'do'. All the verbs are glued to the nouns as methods...

For those of you who want to dig deeper into a related topic, consider Ted Neward's superb essay describing the object-relational mapping problem as the "Vietnam of Computer Science. "  It is a fantastic read (though perhaps a little heavy-handed with the Indochina analogy) that I will try to relate to our non-technical readers as follows.

The best state-of-the-art mainstream software engineering can offer to build applications - virtual worlds included - is object-oriented.  Developers, designers, tools, and training is geared towards modeling the world-as-a-computing-problem in terms of objects.  Problems occur when what goes on in the real world may not be easily communicated in terms of objects.   One area of impedence occurs with trying to map a relational data model (e.g. databases) into an object model.  The challenge is this.  How to reify an intrinsicially relational real world problem, say a social population of players, with an object design without engineering a solution that  is either impractical to build or impossible to maintain?

Now, for our technical readers, were Reginald to jump in he might suggest that instead of using an all-purpose programming language (e.g.  Object Oriented) use something highly specialized to the problem you are trying to solve (see Domain Specific Languages - DSL).

This, however, only brings on the next challenge.   What would be the ideal game-oriented virtual world programming DSL look like?  Perhaps it would involve something like Raph Koster's ambition of a Grammar of Gameplay (see [1.] , [2.] ). 

To return to our Martians.

Let us suppose our Martians don't care about players or player culture.    They simply want to know how the game is played so they can decide whether WoW could be as big a hit on Mars as the macarena.

Would they be better off directly observing the game - sourced by its code.  Or would they be better off reverse-engineering it from the behavior observed of human players?  The challenge of Reginald's interview question is this simple - "If someone were to read the source code, do you think they could learn how to play the actual game?"

In some ways this challenge hints of the reward of "downhill synthesis" over an "uphill analysis":  who really knows what the rules of WoW are (say) except by grace of the analysis of a million fan websites and trial and error.  Do the developers really know?

Comments

[Andy Havens]

1.

O chestnut-tree, great-rooted blossomer,
Are you the leaf, the blossom or the bole?
O body swayed to music, O brightening glance,
How can we know the dancer from the dance?

- From "Among School Children," by William Butler Yeats

* * * * * *

Do we understand a cake better by baking it or eating it? A car by building it or driving it? Tattoos by getting them or giving them? Colors by mixing them, painting with them, seeing them or knowing how they reflect and refract light?

If I was the martian, I'd want to look at Blizzard's books...

[Greg]

2.

OOP is fundamentally a methodology created to enable a) improved code reusability, and b) larger teams through black-boxing code (others don't need to know the details of your object's implementation, only parameters passed to methods exposed to external objects).

Sub-classability also has the virtue that you don't have to reinvent the wheel, e.g., you can inherit methods and values ascribed to objects from which you inherit.

I'm old enough to remember when "structured programming" was better and newer than the spaghetti code that preceded it. And attached enough to it to often think "why can't I do this in one big loop instead of a having all this class definition crap?"

The point is that I wouldn't necessarily read too much into currently-fashionable structures of code. I'd bet that ten years from now, OOP will be old-fashioned and something else will be the emerging paradigm.

That that "nouns" and "verbs" is a bad way to think about games, in general... The player initiate verbs, the nouns are his avatar and the objects in the environment.

[Krumpit]

3.

I am pretty sure someone has just scammed 790 billion ISK in Eve-Online.

Links:
http://i54.photobucket.com/albums/g114/dentararast/newwallet-1.jpg

15 minute audio confession:

http://dl.eve-files.com/media/0608/The_confessions_of_an_EIB_ceo.avi

from site mirror
http://www.eve-search.com/index.dxd?thread=381324

Sorry for posting in the wrong place! Dont' know where to submit news. Anyway 790b ISK is $100,000 I think.

[Richard Bartle]

4.

Nate>What would be the ideal game-oriented virtual world programming DSL look like?

Well, in my case it looks like MUDDLE.

MUD1 hard-coded most of the physics of the game in BCPL (a forerunner of C), but defined the world objects and non-general verbs in a data file using a language of Roy Trubshaw's design called MUDDL ("Multi-User Dungeon Definition Language"). This was OK to begin with, but it wasn't expressive enough to handle many of the concepts we wanted. I had to extend it by a series of hacks, and in the end it reached its limit. If I wanted to do anything more sophisticated, I'd have had to code it in BCPL rather than MUDDL, which would have meant that it was there for all users of the game engine, not just me (other people had written games in MUDDL too, eg. ROCK, MIST, UNI).

I therefore decided to rewrite MUD from scratch. I had to decide, though, how much to code in C (or, as it turned out, Pascal - thanks, British Telecom) and how much to put into a data file. The more I thought about it, the more obvious it became that everything should go in the data file. If I wanted a generic virtual world engine, how could it be otherwise?

Thus, I created MUDDLE. MUDDLE is data for the MUD2 engine, but code insofar as the programmer is concerned. In other words, it's a domain-specific language. Whether you want to call it a scripting language or a programming language is up to you; I see it as a programming language. I even have a MUDDLE-to-C compiler, so it runs quite quickly, too.

It's not perfect, though. For one thing, it still leaves too much to the run-time system (eg. command parsing is done in C, which means that if you want to write a virtual world with no command parsing, or a non-English one, you can't do it just with MUDDLE). Last year, I designed a new language called Clear (based on MUDDLE but not muddled), although I got bored writing up the manual so never got around to implementing it.

I'd thoroughly recommend writing a domain-specific language for virtual world coding, though. If nothing else, it means you have to understand what it is you need to be able to say in your virtual world design.

Richard

5.

Andy,

imho your comment is not nearly as dismissive as you may think yourself ;D.

In my mundane language:
"the object-relational mapping problem" i view as one of the "hard problems" in AI research because afaik complete human beings (not being reduced to idealized *minds*) are perhaps the only ones who are able to solve that problem efficiently and effectively. Why? Because only humans have an "exit option" to break out of the trap of circular reasoning resulting from the above problem: they simply decide how to act and move on. Of course, one would be well advised to consult a primatologist or an experimental psychologist on this thesis (btw these two disciplines would make the already exciting TN authors list even better).

Following this thesis I would propose to you

Richard,

to discuss your "domain-specific language" with a neuro-scientist. Maybe you will see that the metaphors you use to describe the "concepts" built into your system are similar to the metaphors neuro-scientist use to describe the interaction (or patterns thereof) they observe between selected "sub-systems" (or "domains") of the human brain during specific task like spatial orientation, language or image recognition and so on...

[Hellinar]

6.

Nate>What would be the ideal game-oriented virtual world programming DSL look like?<

‘A Tale in the Desert’ has its own programming language, called Babelscript, in which most of the game is written. I’ve always thought that was one of the reasons the game succeeded where many other indie projects failed. The game is pretty strictly designed around an object oriented model. Most ingame actions are an avatar interacting with a ‘building’, which has a very limited number of inputs it can take, a limited number of actions it can apply, and an limited number of outputs. I suspect you could derive much of the gameplay by starting with any one building, looking at the code, and determining what buildings the inputs came from, and where the outputs went. Then continue on looking at the code for those buildings etc.

I think this limiting of interactions between objects has made that world feasible to maintain with a very small development team. Indie projects with more complex interactions between avatars and NPC have had much less success. I recently took another look at Runescape, looking for some hints as to why that project was so successful. At the coding level, its very noticeable that combat is a one on one affair. Neither PCs nor NPCs assist each other in any sophisticated way.

Contrast this with the hugely elaborate interactions between classes of PCs and NPCs in something like EQ. Its pretty clear gameplay can’t be predicted from the code with this level of interaction. As I recall it, several major gameplay elements, like pulling and kiting and twisting, were emergent results of the code, quite unexpected to the developers. Even where the basic gameplay is quite predictable from the code, as in A Tale in the Desert, there is a whole layer of emergent gameplay that was unpredicted by the developer. That is because the interactions amongst the players are complex, even when the interactions amongst the code objects are fairly predictable.

[Andy Havens]

7.

@?: I didn't mean to be dismissive as much as to remind the crew that the discussion of art as "created" vs. "experienced" has been going on as long as anybody has had a meta-thought. I have writing students and mentees who ask me, "Is it valid to have an interpretation of a poem that the poet did not intend?" as if only those enjoyments/understandings specifically "inserted" by the author/poet are correct. As if art, literature and poetry are mazes or puzzles that must be completed or finished or won. I keep going back to the final two lines of this piece by Yeats, over and over again in this discussion, in art and business:

O body swayed to music, O brightening glance,
How can we know the dancer from the dance?

We dance, and we watch. Which are we watching? A dancer or a dance? Are we looking at the execution of excellent code? Or at people playing roles? Am I seeing, when I watch my wife sleep, a somnolent bag of mostly liquified, carbon-based chemicals? Or the compound, shared experiences I've put together with someone I've known since we were 16? Both are true.

The question was: "Would Martians wishing to understand the rules of the World of Warcraft (WoW), say, be better off trying to read its source code or watching video of millions of hours of screen capture?"

I ask: Would anyone wishing to learn how to a very, very complex dance -- from scratch -- be better off reading all the background on music, dance and the cultural context that goes into it, or just watching people do the dance? It depends. If you just watch, you'll never understand *why* they do certain things. If you just study, you'll never understand *how.*

Dancers vs. dance. Players vs. game. Creation vs. experience. You can't have one without the other.

[nate combs]

8.

Andy> I ask: Would anyone wishing to learn how to a very, very complex dance -- from scratch -- be better off reading all the background on music, dance and the cultural context that goes into it, or just watching people do the dance? It depends. If you just watch, you'll never understand *why* they do certain things. If you just study, you'll never understand *how.*

Dancers vs. dance. Players vs. game. Creation vs. experience. You can't have one without the other.
---------------

I don't know. I think it is fair to say that Martians may not be able to grokk the human motivations behind a WoW. However, given a rudimentary player model (I'm not even sure this is needed), I see no reason why that can't get the space of choices and goals offered by a WoW, say.

The idea that one moves around in space and pushes buttons whose effects are modulated by state changes from "gear" one has collected and buffs, then over time grinds through 60 levels and then improves gear via raiding or pvp arenas doesn't sound all that impossible to me. It may be a very abstract game to them, but they may be very smart.

The question is whether reading source code provides a clear and complete enough model to make those inferences.

[nate combs]

9.

Hellinar>
Its pretty clear gameplay can’t be predicted from the code with this level of interaction.

the interactions amongst the players are complex, even when the interactions amongst the code objects are fairly predictable.
------

Sure. However, the more one wishes to represent the gameplay you describe, the greater the software challenge (per post).

[Richard Bartle]

10.

?>discuss your "domain-specific language" with a neuro-scientist. Maybe you will see that the metaphors you use to describe the "concepts" built into your system are similar to the metaphors neuro-scientist use to describe the interaction (or patterns thereof) they observe between selected "sub-systems" (or "domains") of the human brain during specific task like spatial orientation, language or image recognition and so on...

I don't know any neuroscientists, but I did study AI at a time when the early optimism of "if we didn't need to look at birds to figure out how to build aircraft, we don't need to look at humans to figure out how to create intelligence" was turning to "gosh, this is hard; maybe we should copy how humans do it?". It's therefore entirely possible that any AI-based metaphors I use originated in neuroscience anyway.

The way I see it (simplistically) is that there's a brain (hardware) and a mind (software). The hardware is constructed such that the software can self-modify. The hardware can modify, too, but not self-modify, and not under software control.

Programming languages are generally unable to self-modify their code, because this makes them close to impossible to debug. Those languages that do allow it (generally AI languages, eg. LISP, although I seem to recall that COBOL had some ghastly mechanism for it too) tend to discourage it. They also tend to be interpreted, rather than directly executed, because that way you can keep in memory some structure representing the code, such that when you alter it, the next time it's executed then the altered version will be there. For compiled programming languages, it means writing code to a piece of memory that can subsequently be executed (not always possible, it depends on the computer's architecture).

When designing a virtual world, you want some things to be in directly executed code and some things to be in data for that code. As a general rule, if it changes from run to run, it should be data; if it stays the same, it should be code. For most applications, this distinction is fine, but sometimes "from run to run" becomes fuzzy. If, for example, you're writing a program that is only ever going to be used for one virtual world, you could happily hard-code the lot, with only variable data such as whether a door is open or not stored as data (eg. in a database). If, on the other hand, you want your program to work for many different virtual worlds, you have to put a lot more into data. Some of this will start to look very code-like. If you take it all the way, you end up with a game engine that works for generic virtual worlds, plus data that is specific to individual ones. In other words, your scripting language is now a fully-fledged coding language.

This leads to a recursion. You originally separated code and data because data changes from run to run but code doesn't. Now, what once was data is code in a different language; furthermore, that data itself has its own data. It's still the case that you need to record whether the door is open or not. However, the codification of the data has codified all of it.

Hmm, I'm not explaining this very well. Let's go with an example:

1) You can hard-code your entire virtual world in C. This is bad, because it means you need to recompile if you want to change any data.
2) You separate your implementation into code (written in C) and data (written in some format of your own devising). Now you can change the data without changing the program. However, anything that involves execution is still hard-coded; this means that you need to add more C if you want to add a new command to your virtual world.
3) You create a way of describing commands, and store it as data. Now, when you want to add a new command, you only need to modify the data, not the code. You don't need to recompile the program. Some functions are still defined in C, though, and you realise that if you want to use your program for more than one virtual world, these should be soft-coded as data, too.
4) Your data has effectively become a programming language. It's used to define all the functionality of the virtual world. The only things left in the C are used by all virtual worlds, eg. I/O, or support the interpretation of your data. Your data format is effectively a new, stand-alone programming language for writing virtual worlds. Let's call it VWLANG.
5) You notice that if you want to make any changes to your data, you have to change your VWLANG code. This is bad, because it means you need to recompile if you want to change data. Now, we're back at 1), except with VWLANG in the position that C was in.

There are three main ways out of this. One is to decide that yes, you are going to put your data in your code, but you don't care because you do so at the point where your (C or VWLANG) code really is only going to be used for one virtual world. I did this with MUDDLE.

Another way is to separate out the scalar data from your VWLANG code (as in step 2, second iteration) but take it no further. Your VWLANG is sufficiently expressive that you never want to put commands into a new data format. Although the data may differ between shards of a virtual world, the VWLANG code is the same for all of them. This is how LPMUDs do it (I believe; I may be wrong).

Finally, you can make the code self-modifiable (ie. interpreted rather than executed directly), but only modify the data used by VWLANG, not the VWLANG code itself. You can make changes to the code, but you don't need to recompile it, you just dump it to disc every once in a while. This is how MOOs do it.

We thus have a hierarchy of execution and data. At the lowest level is the electronics - the hardware - which takes as its data compiled program code. This code is created either by an assembler or by a compiler (although many compilers drop assembly language code that they then pass on to an assembler). The compiler takes as its data a program in a generic high-level language such as C/C++, in which the programmer has written a game engine. The game engine takes as its data a program written in a domain-specific language, eg. VWLANG, and it either compiles that or intreprets it. The domain-specific language may have its own even more domain-specific language, but eventually we reach a stage where only scalar data remains, which is read and written but never executed.

Where the human mind seems different to today's computers is that its code can always be executed directly on the hardware. There aren't multiple layers of software to go through, and what starts out as data can instantly be objectified and executed as code, with no intermediate steps. Those switches from code to data can be done on the fly. It's amazing stuff.

Something of a pain to program though, I bet.

Richard

[moul]

11.

wow.......What would be the ideal game of mmorpg game .
well, in my case it looks like mythwar. igg

[Andy Havens]

12.

Nate said: The question is whether reading source code provides a clear and complete enough model to make those inferences.

Good question. But then... I have a question a la, "How much of a tiger can you change before he becomes a lion?"

How much of the code can you remove or change before the players are playing something else? Or, suppose the Martian in question -- not reading the code, but in observational mode -- does his observation only of NPCs? Or of just one NPC? Assuming that that is the single player for whom this entire game has been created. RE the old saw about "Maybe Martians would think cars or dogs or bugs are the true rulers of the planet."

A friend of mine wrote a short story in college about an alien philosopher who observed baseball and concluded that it was an elaborate scheme set up by umpires in order to justify their desire to control and judge individuals who were physically stronger. A competing alien philosopher disagreed; he believed that baseball was a pantheistic religious ritual that symbolized the worship of space (the outfield) vs time (the very short instants of at-bat, running, etc.) They (and other observers of their race) sat around, disguised as humans, arguing about this at a bar just outside Fenway for more than 15 years... Finally they decided to ask an old Bean Town native what was the "meaning" of baseball. He replied, "Ya get a dawg, ya get a beeyah, ya get away from yer gahdam wife fuh an aftahnoon."

O body swayed to music, O brightening glance,
How can we know the infield-fly rule from the beeyah.

[Mike Sellers]

13.

Nate said The question is whether reading source code provides a clear and complete enough model to make those inferences.

I and others have referenced the MDA paper (PDF format) by Hunicke, LeBlanc, and Zubek before as in the "nouns and verbs" thread you mention (this article should be required reading for game designers, btw). Hunicke et al basically set up a game design framework separating out mechanics, dynamics, and aesthetics. In chess, the way individual pieces move are the game mechanics; the way these interact to make strategies are the game's dynamics; and how you feel winning or losing are its aesthetics.

What's in the code are the mechanics (actually a sort of sub-syntactic definition of the mechanics); the rest emerges from it.

So if your Martians are super-intelligent big-brain mad scientists, they might be able to read the source code for a game and correctly infer all the dynamics and aesthetics implied by it. But doing so is analogous to reading an animal's DNA and somehow understanding how it feels to hug a friendly yellow lab. The 'source code' and the experience are two entirely different things.

The play is the game. The code is just the substrate on which that's built.

[Bart Stewart]

14.

Mike Sellers: The play is the game. The code is just the substrate on which that's built.

I remember we went round and round for a while on the related question of "what is a 'virtual world'?" back in Ce n'est pas un monde virtuel.

Some held that the game world includes the players; others averred that it's only the code and data stored on a server. That's a little different than the current question, but it's similar enough to perhaps be worth a cite.

WRT to really understanding a game, I also think seeing it through the MDA lens makes sense. Mechanics aren't enough; the dynamics matter, too. Reading the rules that define a thing only gives you a snapshot of a thing as it exists at a singular moment in time -- to truly understand it you have to see how it changes over time.

For a non-random game of any complexity, that's a practical truth. Add rules allowing any degree of randomness and you guarantee that it's impossible to understand the whole thing just from studying its ruleset.

State, as defined by application of the game's verbs, is an emergent property of "the game." Without multiple states, where's the game?

the frozen pond plays
a game with only one rule
not much fun for ducks

[Side question: Is the human perception of the passage of time universal, such that even Martians (other than Michael Valentine Smith) could only grok a game by seeing both its mechanics and its dynamics? Or are we incorrectly assuming that sentience means being wired to perceive time in the same way, and maybe some alien mind could see the possibility space of a system just from seeing the rules and the play environment?]

It seems to me that nouns are replaceable -- verbs are where the fun is. Is that a common viewpoint, or am I missing something important about nouns?

--Bart

[Mike Rozak]

15.

In some ways this challenge hints of the reward of "downhill synthesis" over an "uphill analysis": who really knows what the rules of WoW are (say) except by grace of the analysis of a million fan websites and trial and error. Do the developers really know?

Part of the fun of playing a virtual world is NOT knowing what the rules are. Part of the hell of managing a virtual world is NOT knowing what the rules are, which is a minor inconvenience compared to NOT knowing how the rules interact.

As far as a domain-specific language... very, very, very important!

Some things that Richard Bartle didn't mention:

- Having your own DSL lets you make a really nice IDE (integrated development environment) with the other game bits, which greatly improves scripting productivity.

- It also lets you nicely incorporate the database into your language, as well as a host of other abstractions that developers would rather not deal with.

- DSLs can be designed to minimize bugs, and/or make debugging easier. The most obvious bugs are memory leaks and reading past memory. (Of course, scripting languages in general do this, but DSLs can do extra integrity checks to make sure that the same sword isn't held by two players, for example.)

- Having almost the entire VW in script, while slow, greatly improves design flexibility. This is especially important for virtual world development systems like Kaneva, Multiverse, the Hero Engine, RealmCrafter, and the small project that I'm working on. Without flexibility, what you end up with is all the games built using engine X being essentially the same, except for orc 3d models being replaced by spork 3d models.

[nate combs]

16.

Bart>
Add rules allowing any degree of randomness and you guarantee that it's impossible to understand the whole thing just from studying its ruleset.

----------------------
I'm not sure. This sounds sort of like the inverse AD&D argument: can I glean the rules from the die-rolls? Outcomes may be a different story. But that sounds like a different problem - play testing. Presumably any code the martians would see would be reasonably balanced (as the game has been released for a while) - or at least not perversely out of balance.

---------------------
Mike>
Part of the hell of managing a virtual world is NOT knowing what the rules are, which is a minor inconvenience compared to NOT knowing how the rules interact.

----------------------

Even if for some ruleset complete analysis is intractable, I would like to believe that even just some simulation would improve the odds of figuring out some of this.