 |
UO’s resource systemJune 3rd, 2006 |
Recently, some readers asked for posts that were more game-design centered. Since there was talk recently of the virtual ecological modeling that a Second Life user created, I thought I might talk a little bit about how the original resource system in Ultima Online worked. It’s more virtual world design than game design, but it has a lot of implications for game systems. Pretty much everything I am writing here has been published before in one place or another, but a lot of the old UO interviews and articles are not on the Internet, so it’s all been lost, and I imagine folks newer to the whole virtual world thing may never have heard about it.
This will be long, so I’ll break it into a few posts, probably.
I’ve written before, albeit briefly, about how the system came to be. Kristen and I conceived of it in rough form during the long car drive from Tuscaloosa to Austin, or on the way back — I can’t recall which. Somewhere, I still have the notebooks for it all; we were talking at the time about how to make a new MUD with a better form of crafting.
This was in early 1995. Neither The Sims nor Thief had come out yet, but for those of you who have played those games, much of the underlying design principle is the same, even though the game mechanics wrapped around them are radically different.
The way crafting had worked in the earlier Diku-derived muds, and in fact still does in many of them, is via a recipe system. First, understand that a given item in a typical MMO system will be identified by its template name or number, which is a unique identifier for the “master copy” of an item. All actual items are spawned by creating an object with the characteristics of the master copy. The master copy will sometimes have random factors in it.
A recipe simply says “if you have any of the item IDs in list A, and any of the item IDs in list B, you can use them up to create an item from list C.” List A may be a set of things like kindling, logs, lumber, or planks; list B may be nails, screws, metal rods, and metal bands; and list C will have in it things like chairs, tables, barrels, and so on.
Generally, each possible item in list C must have its own custom recipe designed, specifying which item templates can be used and in what amounts. If someone adds a new type of wood building material — such as wood blocks — then every recipe that uses wood must be updated to permit that as a new ingredient.
The the system generally stops; it’s used for the purpose of creating craftables, after all. There’s no applications towards larger-scale systems such as AI.
The core of what Kristen and I had talked about on that road trip was putting abstracted properties onto objects. Rather than building a recipe out of the item ID numbers for every object that worldbuilders had made that was “raw wood,” we would instead track that the object was made of wood. And then the crafting code could just query, “is this wood?” and if so, do things with it.
In the end, we ended up with slightly more than that. Big kudos here go of course to the rest of the original core UO team, who all contributed to one degree or another on these concepts.
We ended up saying that a given object (which was still defined in a template) could have as part of it, a set of resources. A resource was just a label — nothing more and nothing less. (Much later, in SWG, that team would introduce the concept of resources with stats, but that’s a post for another day.) The server had a list of the resources that existed in the world, and designers could create new ones fairly readily. Resources were things like METAL, WOOD, and CLOTH. But they were also things like MAGIC and PLAYER and other such abstract qualities.
A given object was capable of treating resources in the following ways:
- It could have a PRODUCTION of a resource — as many as it needed to. This meant, effectively, that the object was “made of” this stuff. Each production entry consisted of the resource tag, the current amount of it, the max amount, and the regrowth rate. If there was no regrowth rate, then the object would not replenish itself when the resource was removed. If there was, then it would grow back that resource should it be consumed in some manner. All objects, pretty much, produced something. The other three types of resource fields were mostly only used by AIs.
- It could have a list of FOOD resources. The foods had a stomach size, a bite size, and a minimum amount that could catch its interest. Basically, it would try to find objects with the resource it wanted to eat, as long as the amount there was above its interest threshold; then it would eat away at it at a rate based on the bite size, until it had so much that the stomach was full. If the object in question was alive (eg, a mobile and not just an object or a corpse) it would attack it first and kill it, then eat. If it ate all the resources on something, we would actually delete the object.
- It could have a list of SHELTER resources. The desired behavior for SHELTER was that it just hung around near the object producing stuff. The parameters on this one were basically like food, but there was one other wrinkle. Instead of a stomach size, it had a “home” flag, which meant that once it found a shelter that satisfied it, it would remember where it was and go back there. In the case of many monsters, I had hoped that once they picked a lair, they would actually drop whatever goods they had acquired somewhere near their lair.
- Lastly, there were DESIRES. Again, there was a total amount of a resource they wanted, there was a minimum amount they would try to get in one go, and then there was a flag called “aversion.” If they found something that was big enough to want, and they still wanted more, they would try to pick it up. If they couldn’t pick it up, then they would just hang around near it. If the aversion flag was there, then the opposite would occur — they’d be scared of it, and try to stay away.
You’ll notice that this is darn close to ripped straight out of Maslow’s Heirarchy of Needs. And in fact, AI attempted to satisfy its FOOD needs first, followed by its SHELTER, followed by its DESIRES, just as in Maslow. Alas, we didn’t get around to allowing our AIs to have self-actualization.
A rabbit, then, might look like:
- PRODUCE FUR in a small amount, and doesn’t regrow it; and MEAT
- EAT GRASS, FLOWER, and VEGETABLE, up to a small stomach size, in small nibbly bites.
- SHELTER in GRASS or BUSH, but treat BUSH as home if they’re a decent size
- DESIRE nothing, but have an aversion to anything that produces CARNIVOREMEAT
Conversely, a wolf might be
- PRODUCE FUR in a medium amount, and doesn’t regrow it; and CARNIVOREMEAT
- EAT MEAT, up to a small stomach size, in medium bites.
- SHELTER in TREE or CAVE, but treat CAVE as home if they’re a decent size
- DESIRE nothing, but have an aversion to anything that produces CARNIVOREMEAT
Stuff like pack behaviors were layered on top of this, so wolves, being pack animals, could have a DESIRE to be near other wolves. When animals were in a pack, they were supposed to add up their needs, so that a pack of wolves would start ignoring bunny rabbits and start being willing to tackle bigger game.
Lastly, the (in)famous dragon example:
- PRODUCE SCALES in a medium amount, and doesn’t regrow it; and a huge pile of CARNIVOREMEAT
- EAT MEAT or CARNIVOREMEAT, up to a huge stomach size, in big bites.
- SHELTER in MOUNTAIN or CAVE, but treat CAVE as home if they’re a decent size
- DESIRE GOLD, GEM, and MAGIC
I’ll post later about how this was supposed to work in terms of AI behaviors, the way the world populated its data, and why it all didn’t work.
You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site. [?]Type in a relevant tag, and click the button, and help organize this blog's information.
[More Help]
[...] Last time I wrote about the basic structure of how the resource data worked in the original design for Ultima Online. Now I’ll talk a bit more about applications of that data. A world with properties [...]
[...] Raph Koster has a series of articles on aspects of the AI that was intended (but not fully realized) for Ultima Online (my first graphical MMO and a game for which I still have fond memories). [...]
[...] Raph Koster weighs in with a fascinating discussion of what went into UO’s gloriously failed ecology design. (Part 1, Part 2, Part 3 to come). Ultima Online still has one of the most advanced economy models, years on. Only Eve currently comes close. Suffice to say I’m stealing like a bandit taking notes. [...]
[...] I’ve now written two posts that were far lengthier than I anticipated, about the way that UO’s resource system was originally intended to work. The first dealt with underlying data structures, and the second with applications of those data structures to the actual world. I want to talk a bit about future directions that we didn’t get to pursue. Cool ways to use what we already had [...]
[...] I loves me some Raph Koster. He has a discussion of Ultima Online’s resource system that spans three articles, and is completley worth a read. He references the ‘Playing to Bake Bread‘ article he wrote a while back in the article, and I should point out that’s well worth a look too. We ended up saying that a given object (which was still defined in a template) could have as part of it, a set of resources. A resource was just a label — nothing more and nothing less. (Much later, in SWG, that team would introduce the concept of resources with stats, but that’s a post for another day.) The server had a list of the resources that existed in the world, and designers could create new ones fairly readily. Resources were things like METAL, WOOD, and CLOTH. But they were also things like MAGIC and PLAYER and other such abstract qualities. [...]
[...] Raph Koster wrote an interesting three part post (post one, post two, post three) about the resource system in Ultima Online, how it was suppose to work, and why it didn’t. What is really interesting, at least to me, is how the resource system was suppose to tie very heavily to the behavior of creatures. [...]
[...] I’m a few days late on this, but Raph’s recent three post series on how the original resource system for UO was developed is worthwhile reading(part 1, part 2, part 3). I recommend these articles not only for the obvious reasons of examining what was attempted before and why it failed, but because these links will be of particular interest to anyone who has taken the time to read my thesis and found the material within of value to them. What was tried in UO is a practical example of some of those ideas, and I certainly would have included this work as a reference had I been aware of it at the time. [...]
[...] One such solution was 8×8. I’ve mentioned before how UO internally divided up the map into “chunks” of 64 tiles, 8×8 square, and stored the invisible resources on a “chunk egg,” an invisible object that represented the amount of wood, grass, and os on to be found there. This also meant that the chunk egg was a unique object with an id. [...]
[...] Ultima Online’s Resource System I [...]
[...] In thinking about the UO resource system in recent posts (1, 2, 3), I also got to thinking about other things that we either wanted to or tried to get the NPCs to do. Today, NPCs have gradually evolved more and more towards being quest dispensers. Originally, we wanted NPCs that would give the illusion of life. [...]
[...] 08:47 PM here’s a nice one i’d like to see: Raph’s Website » UO’s resource system ______________________________ Use the middle mouse button on Here for forum rules, if [...]
[...] UO resource system articles (1, 2, 3) have been translated to Hungarian over at the new site [...]
[...] UO’s Resource System (part 1) UO’s Resource System (part 2) UO’s Resource System (part 3) [...]
[...] design differences, such as whether the underlying systems are simulationist or not. Arguably, for example, one of the weaknesses of Second Life is that it began from [...]