UO’s resource system
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.
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.
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 Hierarchy 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.
Ah! Glad you’re posting this. Nice to have a handy reference to point people to show what I mean when I tell people, “Your first version of that ecology you’re coding up probably won’t work the way you expect.”
Ironically, the first version did work as expected. But that version didn’t survive alpha, because it was, well, alpha-level code. The second version, which is what we tried to get working during beta, is what failed. And we never did do a third try. 🙁
Since I’ve never had the chance (or desire, honestly) to play UO, I’m in the dark. Did a system anywhere close to resembling this AI actually make it into the game? After that second failed version did UO end up settling with the tried-and-true “monsters wander around the area that they are spawned in, and may or may not be aggro” AI?
God, I hate that AI.
While reflecting on this, I realized that you could use mutation to simulate evolution using this model. And the chaos theory stuff would apply: different starting conditions would likely (but by no means certainly) produce wildly different ecological systems, and a lot of them would outright fail just because of pure chance.
Oh, and you need to elaborate on “work as expected”, because when it does and then fails in beta, something happened and I’m sure everyone who read that wants to know what. =P If I remember what little I know of UO correctly, it was a human element, no?
What I remember about the early UO ecology was:
1. You’d go into the forest and see an eagle fighting a deer or a wolf fighting a bull.
2. You could never find much of whatever animal you were looking for, because they would be hunted to near-extinction by other players.
3. It was eventually taken out when you guys couldn’t get it to work right. 🙂
It would seem that it could work with proper balancing of the numbers. But I suspect that whatever those proper numbers are, the result would be a system that looks pretty much like any other, with lots and lots of fairly predictable spawns so players can get what they want and not have to deal with the fact that what they’re after has become suddenly rare because something else threw the ecosystem out of kilter. And then you have to ask yourself if all that work on a dynamic ecology is really worth it, if you’re going to have to constrain it to such an extent that it never has a big impact on gameplay anyway.
Raph wrote:
Ironically, the first version did work as expected. But that version didn’t survive alpha, because it was, well, alpha-level code.
What got added into or left out of the beta version? Do you think the alpha system would have worked even with the player behaviors you saw later? Or, would you have had to make more adjustements?
Intersting stuff, Raph. Keep it coming. 🙂
It’s been a while, but my recollection is that the alpha version had all of the above data structures, but maybe not the pack behavior. It had creature skill advancement, and it had AI hunting and stuff. I don’t think the full lair behavior ever worked. It did have the desires, even down recursive container searching — orcs would kill you for gold you had hidden in a backpack. It did not have spawning as described in the second post.
The beta version had more or less the same functionality, but it had the “spontaneous generation” spawning and the closed economy loop. But it also had creatures in sleep mode, and incredibly slow behaviors (I distinctly recall watching the programmer show me a demo of a bear seeking honey and shelter — and watching it take multiple minutes to find the honey that was right there on screen with it).
Too bad none of this was around by the time I got to play UO. It would have been interesting to see in action.
Dark and Light tried (or is trying) some simulationist mob behaviours. In my brief experience, mobs would migrate away from dangerous areas (where they tended to be killed) to safer areas.
Unfortunately, this resulted in there rarely being mobs of the appropriate levels within a day’s march of the starting area. And I mean ‘day’ somewhat literally (travel required effort, albeit boring effort on the part of the player). Maybe they’ve addressed this issue now though, I haven’t played recently.
It’s interesting that you’ve brought up Maslow’s heirarchy in the context of AI, considering it was a theory of human motivation (players = human). Perhaps you’ve already written on it, but I’ve always though Maslow’s heirarchy is prime territory for the design of features for engaging PLAYERS. Sorry for the tangential comment (I do think its an important topic, though).
I’m not an expert in psychology or Maslow’s theory (and certainly, I’ve read much that suggests his theories have weaknesses), but games can include features that help to satisfy at least the top three needs from Maslow’s heirarchy, thereby providing powerful motivation to play.
Belonging: Features which allow and reward participation in group structures such as player towns; guilds; economic associations.
Self-Esteem: Features that allow players to excel or be superior. In a massive context, this implies a need for massive opportunities for excellence. Examples include having variety of professions or abilities (or customization of broad professions or abilities) and segmentation of the population (regional, product type for crafting).
Self-Actualization: Sandbox games can provide players with the opportunity to express themselves in their own way and do so to a degree not possible in the real world, letting them virtually be all they (or more than they) can be.
Most games include some of these aspects, but I haven’t played a game recently that does many of these things well. SWG did well, for a while, imo. EVE (I haven’t played) sounds like it might also do well on this front.
It would be interesting, for me, to see a game design focused on psychological factors. I have a sense (as an outsider) that many games start first with concepts of game mechanics, theme or backstory, or worse still, graphic engine, rather than from the first principles of human motivation.
My fondest memory of the UO fauna were that they took very measured steps — bear, wolf, or rabbit … they all took one step at a time … one sloooow step. You were never in any danger of being chased down and mauled.
Which really isn’t any different than today in games, but the “UO One-Step” was always an amusing dance to me.
Another interesting discussion would be ore spawning. That was an interesting science to follow. And, yet another amusing UO dance — walk eight steps, mine until depletion, walk eight steps …
I’ve seen Maslow’s Hierarchy cited and used in relation to explaining player behavior. Running a blogsearch on Terra Nova yielded this, which is vaguely interesting. (I could’ve sworn there was a much more interesting post on the subject, but I guess not.)
What I haven’t seen is using Maslow’s Hierarchy as a basis for creating gameplay, as you suggest. I’m sure it’s been suggested before, but it hasn’t happened to my knowledge.