World Persistence: One In A Series of Queries

For me, the holy grail question about MMOG design centers on the vesting of persistence in the world itself rather than in the characters. Almost everything I find unsatisfying, both as player and as scholar of MMOGs, has to do with the almost complete lack of dynamism in synthetic worlds themselves, that the only thing which changes, grows, reflects persistence, is the character.

When I've ventured out before on this topic, I've found a reasonable degree of consensus on this point among scholars, developers and players, that dynamic, changing, responsive synthetic worlds are what we need. I've also heard on many occasions that they simply are not technically possible at the present time.

My basic problem is that I like to think about synthetic world design but lack the technical background to go past thinking fairly abstractly about what is and is not possible. So I want to start a series of fairly focused posts on applied world-persistence where I ask the technically adept among our readership just how difficult a particular fairly precise design would be to implement, especially in comparison to existing designs.

I want to approach this problem strictly as a problem in technical feasibility from the programming and server architecture side, not about whether or not this would pose difficult problems in management of the player base.

Applied design problem #1, then.

Let's say a design document calls for the following. I want to simplify this down to the basic essence of the problem, so wherever you might balk at graphical requirements, etc., imagine that the graphics and so on are highly rudimentary.

Let's project the space in which this problem takes place onto a hex map.

A series of ten interlinked caverns, roughly speaking running in two parallel lines from a common entrance that goes to two entry caverns.

In the caverns are one hundred orcs, initially spread evenly over each distinct cavern-room and remaining within the cavern to which they are initially designed. Each cavern-room is roughly circular, ten hexes in diameter.

An orc's hearing range extends for two hexes around the hex it occupies. An orc's visual range extends for five hexes around the hex it occupies.

An orc can move a maximum of two hexes per time step.

Each orc is an autonomous agent with the following rules governing its behavior.

a) If catches sight of non-orcs, each orc-agent has a variable weighted probability (e.g, at creation, each individual orc has slightly different weightings on each of these actions) of doing the following:
     1) running in a random direction and making no noise until non-orcs are no longer visible
     2) running towards the nearest orc and making an alarm noise
     3) moving directly towards non-orc at maximum speed and attacking once they are in range
     4) begin to build a defensive fortification.When finished with fortification in one hex, continue to build in random direction unless non-orc sighted. If non-orc  still sighted when fortification finished, attack with ranged weaponry from fortification; fortification offers major defensive bonuses to ranged attacker. Fortifying orcs will not respond to alarm noise orcs.
     5) move directly towards one of the two connecting caverns. Once in this cavern, build traps in each hex, moving in random direction when completed. Continue to build traps until non-orc sighted or alarm noise-making orc interrupts trap building.

b) If an orc hears an alarm noise, it moves towards orc making alarm and then makes alarm noise, unless already engaged in combat with non-orcs or building fortifications.
c) If alarm-noise making orcs are in hexes proximate to each other, they will move in same direction from that time step on.
d) If more than 5 alarm-noise orcs are proximate to each other, they will move directly towards visible non-orcs and attack once in range. If non-orcs are not visible, they will move towards nearest visible orcs and continue making alarm noise. In neither are visible, they will move in a random direction.

Fortifications prevent movement of non-orcs until they are destroyed, but orcs can move through them with no penalty.

Each trap space can be traversed with no penalty by orcs; non-orcs take damage unless they first detect and demolish the trap.

Ok, up to this point, this has no major dynamic world-persistent aspect to it--it's just a really simple AI routine with some obvious design problems. The next part, however, is this:

a) When non-orcs (e.g., players), leave the caverns altogether, record the number of remaining orcs. If more than 65% of the total cavern population remains, all orcs in caverns will move towards one of the two entry caverns and remain there. They will now have only one ruleset: attack all visible non-orcs.

b) If less than 65% but more than 45% of the total cavern population remains when non-orcs leave the area, the entire remaining population will move to (or remain within) the entry caverns and construct fortifications continuously. When the entry caverns are completely full of fortifications, each orc will occupy a single fortified hex and attack non-orcs from range if they enter the caverns. Any orcs which do not fit in the two entry caverns will move to adjacent caverns and revert to the "standard" ruleset.

c) If less than 45% of the total population remains, the orcs will construct traps continuously in the entry caverns and then retreat to the most distant interior caverns once the entry caverns are full of traps. Once they have retreated, they will stay tightly clustered and if they sight non-orcs, all will attack at 150% effectiveness.

d) Once all the orcs are dead, the caverns will remain empty save for whatever traps and fortifications were not destroyed by the players.

-----------

Here's my basic technical question. Compare this design with a static world design where each of those caves have 10 orcs who respawn at a set rate and who never change their basic AI routine in response to changing circumstances.

How much harder and more expensive in technical terms and in terms of burdens on underlying infrastructure is it to design and maintain the dynamic design than the static one? Twice as hard? Ten times as hard? One hundred times as hard? Like I said, for the moment, don't worry about what happens when the players run out of orc-filled caves to attack, or similarly large-scale problems of dynamic world design. I'm interested in just the narrow scenarios and how they compare.

Comments

[Alistair Riddoch]

1.

The first thing that strikes me is obvious, and in your question. You now have to persist much more than in the simple static case, and this new persistant state is part of the world, not tied to the player. This means entire new systems are required to track and persist changes in the behavoir of the orc community in the overall location, and to persist what are effectively changes to the map caused when the orcs build fortifications and traps. These changes in the map are going to have to be communicated to the client software of any players approaching the vicinity, and depending on the details of your design, the collision detection code will need to deal with the new obstructions.

My feeling is that the complexity of the code has increased significantly, but probably not by as much as a factor of ten. The network load of the game has been increased, but probably not much, and almost certainly not as much as a factor of two. Server storage throughput will also have increased, but I am far from sure by how much.

All this should be qualified with the fact that I am an amateur backend programmer for an as yet incomplete MMO.

[Mike Rozak]

2.

I don't think the problem is technical at all. Your solution doesn't sound technically difficult to me, assuming that you don't worry about what happens when all the orcs are gone (which is a design issue, rather than technical).

The problem is that players want two contradictory things: To be able to change the world, and to not have anyone else change their own world. Some more detailed thoughts on http://www.mxac.com.au/drt/FracturedReality.htm

[bllius]

3.

When do the orcs say to themselves "forget this, we're getting slaughtered", and proceed to go on a pilgrimage to some place safer.

I've always wondered what a game world would be with absolutely zero NPCs, just player characters?

[Chip Hinshaw]

4.

Alistair's comment makes me think about what happens to Timothy's "scenario" when spread over multiple shards/realms/etc. Seems to me that such dynamism(?) suddenly results in fairly vast discontinuity between shards. Players on different shards are no longer playing the same game. And if the results of the dynamics you've introduced are perceived as negative on one shard and different results are perceived as positive on another shard you then at least have the potential for some very dissatisfied customers.

[Andrew Krausnick]

5.

re: Bllius -
Second Life? Either that, or I've always thought there would be some market for a cooperative puzzle/Myst style game in a persistent world.

In response to the original post:

I'll admit that my own experience with coding client/server applications like this is casual, however by all indications what you propose doesn't seem like a significantly difficult problem, at least from a software design point of view.

The main problem that I notice is scalability. With the 'spawn 10 orcs' design, it's easy to make little changes in the design that your players can easily comprehend and still approach as a challenge. For example, maybe your 10 spawning orcs have bows, or are on fire, or throw exploding chickens. In any of these cases the players can apply what they learned as newbies (orcs are mean, orcs generally respawn) and apply additional information in a way that isn't frustrating, but rather inspires fun game play in the form of a new and exciting orcy challenge.

As a consequence there needs to be a compelling design reason behind the change. If you will, take the current batch of MMO's, which are largely derivative in nature; consisting mostly of 'powering up' an avatar. Balance suddenly becomes very important, your players are going to choose the easiest (probably the dumbest) orcs to take on, and that's all they're going to do.

So what do you do, make there be better rewards for the smarter orcs. Well, now you have to fulfill that second objective, fun. If your orcs are just too good at winning, there's no fun in it for your players. You can always design something that can win out over your players or something that can easily be beaten. The challenge is designing something that is, well, a challenge.

As the complexity of your AI increases, so does the complexity of balance, and when major MMO's are being pushed out the door incomplete and with limited AI these days, it's going to be a long time before you see this sort of thing develop in any of the mainstream derivative games.

So what it comes down to is developing a type of MMO that is designed around this type of interactivity, and will most likely be a basic part of the design. I imagine you're probably heading in that direction anyway with this series of queries (good title by the way). In fact, my thesis work is on sustainable virtual societies of autonomous agents (basically communities of agents that can withstand outside forces and have predictable output), which I started work on so I could get a chance to work first hand on this sort of problem. I look forward to seeing what direction this goes in and your further thoughts on the matter not to mention that I’d love to hear some ideas for this sort of design that has compelling game play in mind.

[Duncan]

6.

The problem with persistence is that you now have to hold the whole world in your head (assuming that you are the server). Even when there are no players in the area. You can't just save the data and forget it to make room for other data. It has to be kept active and there are tens to hundreds (to thousands) of operations in a single area that would have to happen even when there is no benefit to a single player.

The reason that the shard/instance solution is used so often is because it closely resembles the much more common area/level scheme used in most games. You have a set of data. The server loads it up, as is, and after the players defeat the Large Boss holding All The Cool Stuff, it can unload it.

There are only a few common areas that are always loaded, and they have very little that needs to be "managed" by the server because they are occupied primarily by PCs.

Persistence is hard to do because the demands are not so much in the design as in keeping the world persistent. In small cases, this is doable, but when the world gets large, it requires far more resources, and far more time. Oh... and writing an AI that could exist without interaction in any sort of form would be the next challenge.

I think that persistent worlds may start to show up in the next few years, but they will be heavily sharded and small to begin with.

[Michael Chui]

7.

I'm not really qualified to answer the question head-on, but at a guess, it really is extremely basic.

What you'd need that is atypical is:
(1) extra stored procedures for things like construction or flee for other-orc,
(2) orc-initiated triggers (for alarms),
(3) tracking new fortification locations and current health (probably the biggest server load, though it's possible to simply regard them as another creature type: one with no attack and no movement and a special "You will not pass!" flag),

In other words, none of the persistence-inspired stuff is actually new.

Re: the persistence stuff.
a) Simple to implement, if you already have a trigger range on each orc. You attach a path-finding function, turn it on, and flag its target as the first PC that triggers.
b) A little more complex to actually DO, but a decent code monkey should find it a piece of cake, once they've understood the particulars. I.e., it's a communicate-to-coder issue, not a can-you-do-it issue.
c) More complex than (b), but same thing. Not hard to actually implement.
d) Simple. Honest. But it does mean that it's (probably) space that will remain unused for a while, so it's taking up database room that could be used somewhere else.

World persistence is do-able. It always has been. But (most of) all MMORPGs don't do it.

Can you honestly say the above scenario is impossible to implement, on your own, in Second Life? I think not: I think I could do it, with incentive, time, and sufficient land. And an artist.

[Timothy Burke]

8.

Everybody's jumping to the next problem--scalability across many servers, scalability across a single synthetic world--and I can't blame them. Trust me, I'm going to get there. I'm just curious about whether, if you push scalability off the horizon for a moment, a single basic programming problem built around world-persistence rather than character-persistence is instrinsically or significantly more technically demanding or resource-heavy.

[randolfe_]

9.

Assuming that the system follows a standard object-oriented, event driven architecture (to scale such a theoretical system, it almost certainly would need to be); and assuming that we are ignoring the derivative load increases caused by the world-physics and netcode layers:

Your scenario would be certainly implementable; many non-graphical implementations of similar experiments exist in various genetic algorithm models and AI agent subsystems.

The problem is, as mentioned by Duncan, the system must now manage, execute, and continually persist a much increased magnitude of objects, all of which must handle a much increased magnitude of events regardless of client (player) interaction/observability. This could be implemented without concern for the constrained scenario you describe, but would grow roughly in load as a geometric progression when you attempt to scale. And that's ignoring the physics and netcode layers, which would also grow in load as a factor.

A more reasonable solution would be to only execute the real-time sequenced scenario when a client can observe the world area. When clients leave the area, instead forward compute a series of future states (these can be based on probabilities emmited from the unique objects). When clients re-enter the area, activate the closest computed time-state, and respond to events in real-time.

This granularity could then become a tuning dimension to allow for more granularity as the infrastructure is scaled (and processing power/throughput is increased).

[mjh]

10.

The obvious answer is: no! So long as you don't get into some kind of n-squared scenario where every orc needs to know about every other orc in the world, of course. The processing costs of handling orc motion and orc combat when a pc is around will dwarf the higher-level orc ai. Particulary if, as you describe it, you're basically switching between several low-level orc behaviors based on the orc headcount; counting orcs is cheap, as is swapping behaviors.

Games are all about cheesing it anyway; you could keep the fortifications in the exact same place each time so players say, "See! It's the same! The cave's permanent!" when everything but is regenerated from the headcount.

There's the problem that a lot of simulated stuff has: when you're doing stuff under the hood that's poorly communicated to the players, it appears random or worse than random; witness the crop of unsatisfying a-life games 5-10 years back.

[Michael Chui]

11.

I'm just curious about whether, if you push scalability off the horizon for a moment, a single basic programming problem built around world-persistence rather than character-persistence is instrinsically or significantly more technically demanding or resource-heavy.

The key part is "resource-heavy": that's dependent on scale, unfortunately. The general rule is that, the more you track, the more resources are required, and thus the more resource-heavy it is. What you ask for is, quite literally, more than there currently is. Therefore, it's more resource-heavy. How much? Well, what's the scale?

But the gist of the answer is simply that you haven't asked for anything special in terms of resources. You've asked for a bit of code complexity, as other posters have mentioned, but to say it's impossible is to call the programmer incompetent. You've already done the majority of the legwork; the programmer merely needs to implement the AI. And all the tools already exist. (If they don't, then either they're genius-like insane crazy ninja coders doing things beyond my ken, or they're still incompetent. =)

[RedKnight]

12.

The one thing I thought of when reading about the various responses of the overall orc horde that depended on the number of orcs left alive was, "but how would they know that's how many of them were left?" Somehow, that knowledge would have to be communicated between the orcs and if that means of communication isn't apparent to the player then you have an interesting phenoma. The orcs are metagamming.

Organizing in game events through out of game channels is inevetiable for any game. But do you reall want mobs takeing part in an activity that's often considered a questionable practice?

[Auz]

13.

"I've always thought there would be some market for a cooperative puzzle/Myst style game in a persistent world."

Seems to have been a small market though...

http://en.wikipedia.org/wiki/Uru:_Ages_Beyond_Myst#Uru_Live

[Daniel Speed]

14.

It seems to me that the question about world persistence is being confused with one about world persistence and dynamic behaviour.

Persistence comes in many shades, down from just about nothing (WoW?) to something like Eve where there's deployable structures and claimed territory, and right up to SL.

Absolute answers aren't always the best ones anyway if you're trying to just achieve a specific effect, so I'd expect it's almost always going to be better to make specific compromises in order to get the effect of persistance in all the ways that it matters to players.

[Artheos]

15.

Redknight, whose to say that they aren't in a guild/raid/group?

Timothy Burk, The actual scripted response to incursion in a specific zone based on an individual orc seems fairly straight forward (I'm not specifically a game developer thought)

It would increase storage and processing power on the server side, but the client would still recieve the object at location moving in direction executing action message they do now (in other words the scripting and persistence would be only server side impact). In most recent games, there are this large number of objects being communcated already to the client (in my thoughts).

This next thing though, kind of has me scratching my head.

Andrew Krausnick > "With the 'spawn 10 orcs' design, it's easy to make little changes in the design that your players can easily comprehend and still approach as a challenge. For example, maybe your 10 spawning orcs have bows, or are on fire, or throw exploding chickens. In any of these cases the players can apply what they learned as newbies (orcs are mean, orcs generally respawn) and apply additional information in a way that isn't frustrating, but rather inspires fun game play in the form of a new and exciting orcy challenge."

This is exactly what I don't find exciting about MMORPGs. Orcs that act like the orcs I fought at level 10 when I'm at level 60 are uninspiring and boring. Attaching a new skin/weapon or armor model doesn't help in the least other than superficially.

World change and persistence is one huge problem in MMORPGs, and another is that even in new areas, against new opponents. you're facing the same challenge over and over again.

I suspect as long as the overall physics model is consistent, the behaviour model has more room to change than is hinted at there.

[Ken Fox]

16.

Michael Chui has really nailed the answer to this post.

Spawning orcs and "spawning" traps is equivalent -- they're both NPCs to the software. You can have different implementations for different types of NPCs though. For example, traps won't have drops or move, so the persistence mechanism can be relaxed. If the server crashes, nobody cares if some traps disappear (the orcs must have rebuilt their city while the server was down...) Nobody will try to dup a trap either. ;)

Changes to terrain are harder to handle without cheating because you have to give the client more than the player can see. If you don't care about cheaters being able to see where the fortifications are, you can have the server send geometry updates and treat the dynamic world exactly like a static world in all the downstream logic.

Scalability (with parallel agent servers, i.e. trusted clients) for these advanced NPCs seems fairly simple, but I'd worry about the server cost -- you're going to need more CPUs to handle the more complex agents, so more power, more heat, more A/C. What's the monthly charge going to be?

[alan]

17.

bllius>>"I've always wondered what a game world would be with absolutely zero NPCs, just player characters?"

I think something like this would make for a very intriguing design.There is nothing interesting or challenging about camping a respawn of creatures that will respond the same way every time. I would, however like to see a twist on the idea of all player characters, by giving the player the ability to "order" NPC characters. If you could leave a group of NPC's with a set of instructions to perform actions such as patrolling an area or guarding a keep, it would really add a level of excitement that is missing. These NPC's actions would be unknown to the attacker because they depended on the "programming" of a player.

[Ken Fox]

18.

I forgot to answer the original question though. :)

10% harder to build. 50% more expensive to run.

alan> I would, however like to see a twist on the idea of all player characters, by giving the player the ability to "order" NPC characters.

I had high hopes for Dungeon and Dragons Online because of the rumor I heard that everything was instanced and designed for groups. It seemed like the perfect design for player-run (an online GM!) content. I guess the game didn't turn out that way, but I haven't played it so I don't know if the idea is feasible for an expansion.

[Timothy Burke]

19.

This is very, very useful, and to me, the technical simpleton, very illuminating.

I especially find one of Randolfe's suggestions useful as a technical strategy for producing a similar result. Rather than requiring the system to recall exact placement of fortifications, traps, orc-positions at the time that players leave the caverns, and then requiring it to carry out each-time step of an agent's actions during player absences, just have the following:

Interval between player exit and next player entry
and
Number of orcs remaining

and use that to construct a "future state" that is predefined (e.g., if players have been gone for 4 hours, build X number of fortifications and Y number of traps and place orcs in appropriate defensive or offensive postures with appropriate new rulesets).

--------

You could extend that idea further to try and find a non-computational way to "simulate" dynamic persistence even in a narrow scenario like this, but I'm less satisfied with that, because I think players see through such strategies fairly readily. The first time you see NPC mobs interacting where it appears they have a dynamism, it's enthralling, but pretty quickly you'll realize that it's just a repeating loop of some kind or some other fixed routine. If on the other hand, there is a genuinely (and partially randomized) dynamic routine involved, even if you come to understand how it's done, or the patterns underlying it, it's still going to feel somewhat life-like and dynamic.

[Hellinar]

20.

As the Irishman is reputed to have said, if you want to get to a persistent world, I don’t think I would start from here. In a sense, a war torn world is the very opposite of persistent. All that was built up and made orderly is being torn down and reduced to chaos. If you are want a persistent world, I think you need to focus first on NPCs that build stuff. The fighting over it is the final stage in the game. I can’t see your Orcs having anything like natural behavior unless they have some lives going on that gives them reason to defend their caverns.

We already have worlds where player characters build stuff. A Tale in the Desert and Second Life come to mind. The next step, in my view, is a persistent world where NPCs build stuff and carry on productive lives. Finally, when NPC interests clash due to the steady growth of their civilizations, you can have a realistic war. But I don’t think tinkering with the current model will do much to make MMORPG believably persistent. A world in which all people do is blow stuff up is quite unnatural. The need to re-spawn stuff at five minute intervals flows from that. Persistence doesn’t really fit with a world in which most NPCs are fighters.

[Charles]

21.

Thus far, to me, this scenario seems entirely feasible and not overly taxing on the systems involved. However, as many peope have mentioned, looking at this absent scaling is sort of meaningless from any kind of practical perspective. If you abstract out scaling, you're abstracting something that can't be safely abstracted out in this case: its an integral part of the design. There's a fair chance you come to the comclusion that X is possible, but later find out that X isn't even what you were looking for. Of course, I'm not currently involved in development of any sort of online game, so others may be far more qualified to answer this question than I.

As far as making worlds persistent, there have been some attempts in various MMO's. First in my mind was an area in one of the many expansions to the original Everquest that (I believe) was non-instanced. It featured 3 NPC villages that were at war, and the player could help any 1 village gain dominance over the others. Of course, after a while the villages would be reset, and the entire process would start again.

However, this also faces the problem Timothy brought up just above, that players will almost immediately exhaust any illusion of real change in the world. Timothy seemed to be referring to small loops of interaction, but I think that the same principle can be applied even to longer more complex recurrences. The players _will_ figure out how to repeat the most beneficial interactions in time unless a real emergent system is used in the world, which is certainly beyond our current technical limitations.

[Franek]

22.

To answer the resource question we might first tease the elements of the design apart.

In the naive design you can classify actors into two categories: driven and directed. Though Ken Fox rightly points out that both mobs and objects are actors to the underlying engine the distinction is still useful. Driven can be those actors that change state only when some outside agent (like the physics system) changes them. Otherwise, they perform scripted actions. Some current NPCs fall into this category. Directed actors can be those, like player characters’ toons, that change behavior through some conceptually external agent.

In Timothy Burke’s target system we could make the Orcs directed and have software implement (as both Timothy and Andrew Krausnick suggest in their posts) appropriate agency.

So now we have three design decisions each with some implementation and operational cost:
1) To what extent can a directed actor change the world?
2) How complex do we want the behavior of directed actor agents to be?
3) How many directed actors do we want active at the same time?

These are familiar problems.

Should actors be able to blow up bridges or build walls? Should rocks roll down hill when pushed? Should bullet holes in walls stay there forever?

Should directed actor agents learn over time? Should they take into account the strategies of their opponents?

Do we want to support a handful of actors, dozens or hundreds in a single coordinated environment?

And there is an existing arsenal of optimizations / design decisions for dealing with them.

Limit the number of active objects in the environment. Allow construction of only simple objects that are animated by the physics engine. Do not retain transient changes like bullet holes.

…

In Timothy’s orc example the baseline (the “static world design”) isn’t completely specified – so incremental costs may be hard to describe. But we could ask questions like “How much harder is it to implement a smart orc than it is to implement a dumb orc?” (Ken suggests 10%) How much more expensive is it to instance and activate a smart orc than a dumb orc?” (Take into account the computing resources, storage, etc – Ken suggests 50% - I would suggest 2X PC cost at a minimum).

As to the world, we have to allow for construction of barricades and traps rather than just having them statically placed. They already exist, so it is the incremental cost of dynamic placement that needs to be estimated. Also, there are about 3500 hexes in the dungeon. Assuming that orcs could fill up 50% of them with barricades or traps, what would the cost be of managing another 1750 driven actors?

So we are sitting on 100 smart orcs, 1750 additional driven actors, and some undefined number of active players all interacting in this dungeon. Worst case situation, 100 orcs and 250 players each occupying one hex in a single room.

This may not be the best analysis of the problem. But some similar analysis is needed to answer the questions of “how much harder”, “what will it take?” and “can we even do it?”

Folks with experience in the various engines / environments / development systems can flesh out the range of values for these variables as they have experienced them. And they can take into account common optimizations like limiting computation and communication on the basis of room boundaries. But it may be that level of detail is inappropriate to the forum.

[Nathan Mishler]

23.

One of the biggest problems with this sort of senerio is that players metagame a lot. As soon as they come up upon this cave, some of them are going to figure out the exact numbers needed to cause each of those senerios. They will spread the world and pretty soon a good number of players will know exactly how the cave works.

That isn't a bad thing, but it will have a tendency to make your more interesting cases not happen that often. That's the big problem with npcs that can act in very interesting ways: people will discover that very interesting things happen and that at least in this case interesting = harder.

Most players in the know will kill all the orcs so they have to deal with traps or fortifications as little as possible. Other players will figure out how to cause the fortification / trap thing to happen and will trigger it just to make it harder for other people.

The problem isn't just a technical one, but a design one, the "We just spent a month on this cave and no one sees the cool edge cases because they just roll right through it" problem. Or the "No one goes to that cave because it's always full of traps so they just go to the easy cave instead" problem.

[Matthias]

24.

How heavy your proposed design is on the resources, depends very much on how serious you take the persistence (from your last post i get the impression that you are ok with "faking" persistence to quite some degree).

I think that a good point of view for the degree of persistence is a server-restart.

Lets assume that there was a raid on the caves and 80 orcs are left, also they have set 10 traps and built 7 fortifications.

If you want the exact state of the caves back after the restart, you need to save each orcs state (could be they suffered some permanent damages, at least they are exhausted or lost some health or projectiles or whatever).
You also need to save the positions/dimensions of the trap-spaces and fortifications of course. And as some have mentioned already that traps/fort. are partly to be handled like npcs, you might also need to save some state on them.
An example might be for traps: dangerous to humans,elves,dwarves,... not dangerous to: orcs. Of course this list can be extended seemingly endlessly (what about other orc-factions for example). Also you need to save/restore the type of trap (poison, fire, ice, whatever) and their strength/damage-dealing-capacity (which will probably have been generated randomly or depending on some stats of the orcs who created/set it.

The easy solution is, what randolfe said. For the restart it would mean that you load up a state of the caves (80 orcs, 10 traps, 7 fort. and randomly generate "new" ones.

It should be obvious that those two are totally different beasts.

There is no single factor you can "put" on these scenarios imo.
I would split it up into categories and even then it depends very much on your implementation. For example there could be a standard fort. that orcs build then you only need to save position/orientation. The more variable they get, the more state you need to save and you could even go so far to save the changed height at each point in the cave).

So for the exact persistence, using simplified state for fort.) id guess:

Bandwidth: a factor of 1.2-1.5 (each trap and each fortification has to be sent to each pc that enters the region/caves and im just assuming that theres up to half as many of them combined than there are orcs). Of course this would be probably much higher if players were also allowed to "litter" the surface of your world with traps and such.

Database: since you now need to save all existing npcs additionally to your pcs id say 2x the space you need for your pcs. The traps and fort. prolly are lower in numbers and have much less state that needs to be saved. so add another 0.5 times pc-space for them.
Of course this also means twice as many database-transactions so the database-server load will also go up and since this usually doesnt scale linearly id say a factor of 3-5 for that.

Server-load due to AI: i dont have enough experience to take an educated guess. i see it much higher than what was written in the comments until now, though, because imo by having to make the orcs aware of the state of their fellow orcs and not only in their cave but in all caves and the need for them to constantly monitor that state id think its quite some extra load.

[Ken Fox]

25.

Timothy Burke> use that to construct a "future state" that is predefined

Yeah, I liked that too -- it's a great idea. I'm not sure it's better than real-time all the time.

First, you're going to frustrate your scenario designers by forcing them to build two behavior models (agent-based real-time vs community-based statistical) and keep those two behavior models consistent enough to fool the players. That seems really hard.

Secondly, if you have enough hardware resources to run the real-time model with players, you've already scaled for peak activity and should have the hardware to run it all the time. It's easy to reduce the computational demands for non-combat agents by switching algorithms based on the presence of players. Of course, this depends on your player-to-NPC ratio -- if you have a huge world with a couple players then the statistical model becomes very attractive. You're already out of business if that happens though, right?

Charles> The players _will_ figure out how to repeat the most beneficial interactions in time unless a real emergent system is used in the world, which is certainly beyond our current technical limitations.

If players couldn't do that, it wouldn't be fun! :)

I disagree with your opinion on emergent systems. Very simple systems (cellular automata in Conway's Game of Life for example) have emergent behavior. The rules for orcs given above are very simple and rigid -- they will probably never surprise the scenario designer. However, the scenario designer could define individual agent goals that elicite the desired scenario, but also combine in surprising ways. Simple change: instead of the 65% threshold, nudge an orc towards agressive defense if he sees another orc kill or chase off an attacker, or if another orc nearby displays an active defense.

[Chris Lloyd]

26.

Charles has already mentioned 'Hollowshade Moor' in Everquest. Three competing factions in three different camps that normally sit in equilibrium, but can be temporarily unbalanced by the players. When a player aids one of the factions to dominance, the faction in question will take over a fourth camp, normally containing friendly traders, with noticably higher level monsters. When this camp is cleared again the entire zone resets.

Given this was, as far as I remember, a unique set-up in Everquest I wonder what problems it had that caused it never to be repeated. Were they technical or political? As an example though I think it goes to show that what you're asking is clearly technically possible.

One of the problems it is going to cause, that may be viewed as a technical one, is how much extra content has to be designed and added to this style of encounter. How much cheaper in terms of level-designer time would it have been to say 'Here we will have ten linked caverns containing 100 orcs on six-minute timers, and over here we will have...' How many extra content developers would you need to populate a world of the same size? Given that you are trying to add a number of extra persistant states to the world, each of which is mutually exclusive, who is going to want to pay for the development for all those states that are not currently visible to the players?

bllius>>"I've always wondered what a game world would be with absolutely zero NPCs, just player characters?"

Face of Mankind?

[Chip Hinshaw]

27.

I don't know ... I hate to keep jumping ahead, but I think that the case Timothy is presenting points eventually (perhaps inevitably) towards an AI layer the complexity of which scales up significantly and I find it hard to ignore (but that's my problem :) ). What you suggest requires an awareness for every one of your agents that must continually be monitored and updated. Butterfly effect potentially ... and I think that's what would become particularly resource-heavy. I have to look for interview I did with one of the geniuses at CCP before the launch of Eve. He had some very interesting comments on just this sort of thing. Now that I think about it maybe it was one of the Origin guys. I'll see if I can find it.

[randolfe_]

28.

Further thoughts on the computation of future states. It occurred to me after thinking about this a bit more that we must assume that the only perturbing actors are player-driven. We are ruling out other AI-driven actors from disturbing the "orc state". If that is the case, then we also are assuming the "orc system" is mean reverting, towards some sort of probabilistic equilibrium. (This equilibrium could decay over time, also, but this is less of a design concern, which I'll attempt to demonstrate).

The approach of precomputing future states isn't really "faking" persistence anyomre than basic quantum principles. To the observer, it is dynamic and occurred in real-time. (Is the cat is alive or dead until we observe it?) Again, since the system reverts towards a mean equilibrium, we only need to forward compute future states as a weighted moving average decreasing with time.

The elements contributing to the computation of the future states would be emmited from the present objects themselves. That is, depending upon who the player-actors were, how many of them were present, and what their persistent stats/characteristics were while present, and dependent upon the mobs left alive (perhaps even those killed as an influence on those left alive...'they killed our leader!' kind of effects) the system agent will compute dynamic future states upon player-actor exit from the "zone".

The problems, as correctly pointed out in many responses, is that players will be able to recognize the patterns and meta-game the system. Never forget that the human brain is a neural-net capable of extraordinary pattern recognition. Creating a system capable of fooling a human into perceiving dynamicism will require a fairly complex computational state processor. I fear that the load will grow geometrically as the number of mutatable variables grows.

I can conceive of a dynamic persistent system, even given your constrained scenario, and even assuming "future state caching", that would require overwhelming (unreasonable) resources. Simply trying to implement "orc emotion" on any realistic level would add an order of magnitude to the complexity.

[Matthias]

29.

randolfe, im sorry for wrongly calling it faking (it was mainly because of the lack of a better term).
The "problem" with computing future state the way youre proposing is that you dont have a clearly defined state at each and every moment.
So instead of only making the state of the existing objects persistent you would have to make the basis/variables of your computation persistent additionally to the current state i.e. you have to save "80 orcs, 10 traps, x fort." and "last player visit at 07:00 server time (and maybe further needed information for the calculations)" to be able to make the correct computation after a server restart.
You could, instead, do all the computations at the time of saving - but that would not work with "unexpected server downtimes" (crashes).

Oh and i found a better term now: "compromising" :)

I think its actually a very good compromise (just to make sure this post isnt misunderstood)

[randolfe_]

30.

Matthias,

Thanks for the clarification. Yes, I was assuming computation and persistence at the time of last-visit-exit. *Unexpected* system aborts, whether software or hardware, would be tough to handle because you could only roll back to the most appropriate time-sequence stored, which in the worst case would be the long-run equilibrium from the most recently stored player visit. This could have the effect of "turning back time" to a point before a player/group had visited the areaa.

I'm not an expert when it comes to the hardware side of this equation, but even assuming a massively over engineered hardware platform that "never goes down", there would still be significant problems with software level errors causing such time-blips.

[Tom H.]

31.

Most of the techincal discussion above ("feasible, maybe not scalable, designer-intensive") makes sense to me (PhD in networked VR). Two minor points:

If I recall correctly, Neverwinter Nights, running single-player games with worlds smaller than many MMOs, had to do serious "level of detail" on AI which came down to not running AI code in zones with no players. Not directly applicable, since I assume they were spending most of the CPU on graphics and UI.

Didn't Ultima Online early on experiment with a persistent ecology, which crashed? Google shows reviews and Origin's ad copy from 1997 touting persistence and a virtual ecology. If we have anybody from that crew around they ought to have lots of insight. (That was before I was in work-avoidance mode in my dissertation.)

[Raph]

32.

You don't get to push scalability off. Otherwise, what you've made is a nice single-player game encounter, not a virtual world.

UO's ecology didn't crash in a technical sense, it crashed in a design sense -- there were bad feedback loops in our design.

That said, it was also too resource-intensive. The reason AI is dumb in these games is because we can't run too many smart ones.

And the reason encounters are simple is because we can't handcraft too many cool ones.

Absent scale, you're not actually addressing the design problem.

FWIW, the single biggest problem with real persistence right now is that the DB gets huge and nobody outside of Linden seems to want to pay to run it. :)

[Chip Hinshaw]

33.

I found some of my notes: Rick Hall had said to me (re: the difficulty of implementing "smart" AI in these MMOs) that you eventually have thousands of these agents throughout the gamespace carrying out their various activities and that quickly bogs down resources (as Raph mentions above).

On the other hand, Kjarten Emilsson of CCP had suggested to me that "large-scale coherent patterns emerge from lower-scale simple processes ... Natural Stupidity rather than Artificial Intelligence." So maybe there's some simple schema that results in the type of behavior you're looking for, but again I still think it ends up costing you alot across the server. If we're talking persistence then changes become permanent (at least to the extent that we don't likely return to the initial state). And (sorry) paste this across multiple shards and your customers are not playing your game in the same space. One shard becomes very appealing based on a persistent state that has arisen due to behavior of AI on one shard, whereas an unappealing (or at least dull) situation persists on another shard because those same events did NOT take place on that shard.

[randolfe_]

34.

Raph wrote:
FWIW, the single biggest problem with real persistence right now is that the DB gets huge and nobody outside of Linden seems to want to pay to run it. :)

This point is very important. Persistence costs grow very quickly with scale; moreso than most (unfortunately) designers and architects usually plan for. A complex system like this isn't a simple, procedural DB storage question, but a problem of persisting complex object graphs. The cost of serializing deep graphs is expensive in terms of processor, memory and throughput. Rehydrating these graphs quickly is of even greater expense. There is a derivative problem of either garbage collection or debug-cycles of reference counting and memory management. Anyone's whos ever implemented a deep-graph object system and found they ran into significant persistence scaling problem knows what I'm getting at. Unfortunately, the answer is usually to revert to non-object approaches which, while fast and efficient resource-wise, yield far less flexible designs that result in systems that are prohibitively expensive to maintain and enhance.

[Daniel Speed]

35.

Chip - Eve's NPCs are highly simplistic and not persisted. On the other hand, Eve persists a huge amount of data about player states.

Mattias - Exactly what I was suggesting earlier. What you generally want is the minimum data, computation and effort to achieve the effect that you want. When you're trying to get a sense of orcs that build up defences and grow, you dont *need* to persist every single orc and simulate them individually to achieve this effect. Persist what's important, and you can get 95% of the effect at 5% of the cost. Store the number of orcs, an indication of the level of the defences, and use formulas or a simple algorithm to simulate how that changes over time. The derivative of the formula for the number of defences will even give you a guide to what they're all doing at any one time. You could then create the entire cavern scenario by putting together a number of authored archetypes to achieve the balance of numbers and activity that you want, and you've done it for the cost of a few templates, some quick calculations and a very minimal DB footprint.

It's critically important in MMOGs to work out what you want, and find an elegantly simple method of getting that, not the 100% accurate simulation.

[randolfe_]

36.

FWIW, the single biggest problem with real persistence right now is that the DB gets huge and nobody outside of Linden seems to want to pay to run it. :)

Not to detract at all from LL's accomplishment. Are there any complex non-player directed AI in SL aside from what people have implemented in LSL, which is initialized-volatile except for data that has been exported outside of the grid?

[Hellinar]

37.

Daniel Speed> It's critically important in MMOGs to work out what you want, and find an elegantly simple method of getting that, not the 100% accurate simulation. <

The problem with the Orc example is that it implies a kill, loot and level game. Which implies that all encounters be challenging, and all shards equally interesting to play on. Otherwise players will focus only on the easy encounters, and play only on the interesting shards. That seems like an enormously difficult result to achieve with a simple method. In a Diku type game, I think players are looking for dynamic quests, that spawn well balanced encounters with a sense of evolving backstory. A bunch of AI NPCs following their own agendas will likely lead to encounters that are badly out of balance for risk/reward.

We already have persistent, dynamic worlds in Second Life and A Tale in the Desert, to name a couple. In ATiTD at least, the database problem is made tractable by the persistent objects being buildings, which don’t run around and interact with each other. Perhaps the next step up from that is NPCs who build stuff, with some way for Players to select for NPCs who build interesting stuff rather than boring stuff. Isn’t that something like Spore is aiming to do?

[Michael Chui]

38.

You could then create the entire cavern scenario by putting together a number of authored archetypes to achieve the balance of numbers and activity that you want, and you've done it for the cost of a few templates, some quick calculations and a very minimal DB footprint.

This is a bit of a tangent, but that made me think of Christopher Alexander's "Pattern Languages", the idea of being able to make things from scratch from a few basic ideas. He's in the field of architecture, but it's a reapplicable idea.

Also, it might be worthwhile to point out John Arras' genmud.

[Samantha LeCraft]

39.

Chip Henshaw said, ...paste this across multiple shards and your customers are not playing your game in the same space. One shard becomes very appealing based on a persistent state that has arisen due to behavior of AI on one shard, whereas an unappealing (or at least dull) situation persists on another shard because those same events did NOT take place on that shard.

Why is it a problem if the different game servers are not carbon copies of each other? We've been working under the assumption that they should be, pretty much from the beginning, but IMO, that sort of thinking has limited what we're willing to try. Players aren't playing in the same space anyway -- what you do on Server A does not affect my game on Server B -- but we like to pretend that it's all one large game. Why do that?

Each server could have a different starting state, and the state of each server could diverge wildly from there. If players had the ability to affect the state of the world in a meaningful and lasting way, would it be so wrong for Server A to be different from Server B? Don't like the state of things on Server B? Well then, start effecting change in the world. I truly doubt that players would jump from Server B to Server A just because Server A's state is seen as "better" somehow. Players hate leaving their developed characters and their stuff behind, so if they were given the option of changing their own server, I think they would do that before jumping ship altogether.

Beyond the added work for the dev team of keeping up with the different situations on each server, why would this be a bad thing?

[Franek]

40.

We seem to have centered on the implementation of orc behavior as the activity most important to evaluating complexity. Raph and others suggest that throwing computational resources at the problem is not economical. Similarly, dynamic designs drive statefull instancing, that drives database size and that leads to economic tradeoffs.

By way of optimizations to reduce cost we have been having the pure vs optimized discussion for both cellular automata and object oriented storage.

Do we really mean our limitations are economic rather than conceptual? Are we saying that if we could justify the computing power and storage we could make fully interactive persistent worlds given the knowledge we have now? Or are there some problems we can’t solve even if our resources were unlimited?

Casting Timothy’s question in light of economic feasibility changes the scale question we’ve been kicking around. Does the computational complexity of persistence justify the cost of supporting it? Perhaps that can only be answered if we know the population to which we are designing. If that is so we will have to discuss not only our ability to optimize our costs and ride the curve of computing cost reduction but also reopen discussion of our how much people will pay for persistence.

Taking these two questions together and twisting them a bit, are there some things we don’t know how to do now, like communicate compelling interactive story arcs in an MMO context, that would be enhanced by dynamic persistent environments and justify their greater cost?

[Charles]

41.

Hellinar> Which implies that all encounters be challenging, and all shards equally interesting to play on. Otherwise players will focus only on the easy encounters, and play only on the interesting shards.

I don't think this is necessarily true. I think that for the majority of players there is a great deal of identification with the shard and resulting community that inhabits that shard. Having different states in each shard might increase that sense of identification. People might have pride in their server's unique accomplishments, others might like the idea of a realtively untouched land that they can develop. As long as you can ensure that the servers will be different enough to identify, but not so wildly different as to be an entirely different game experience, there should be little danger of people abandoning "uninteresting" servers.

[Mike Sellers]

42.

Very interesting discussion.

Timothy, despite what's been said above about technical issues and scaling, I think the primary reason the kind of thing you describe above hasn't been implemented is due to design rather than technical considerations.

First, current and past MMO designers tend to think individually ("what is the player doing" or "what are the quests and encounters"), a throwback perhaps to pen-and-paper RPGs. The alternative is designing systemically, which is what's required for the sort of scenario you outline. Consider that you could run WoW today with a text interface and it would almost indistinguishable from a MUD made twenty years ago. That's not a knock against current MMOs, just a statement of where we are in terms of what's been done. The gameplay tropes have changed very little.

Second, to a large degree we have this design stultification because it's what the vocal player base have gravitated towards (the rest is that evolution in the designers and publishers of MMOs has been glacially slow). Persistence and systemic design haven't been rewarded in the marketplace by hardcore gamers. They more often want predictability of outcome instead of a smart opponent or a dynamic world.

This isn't to say that the scaling issues in particular aren't real. They're just not the critical bottleneck in preventing this sort of design from being implemented and deployed.

The AI question is also at the crux of this issue, I think. What we want is not just persistence, but the feeling that the world really is going on while we're looking elsewhere. This requires something beyond static respawns, and definitely requires something beyond what we currently have as game AI (it's telling that most game-AI discussions quickly divert from anything goal-oriented and focus on low-level behaviors like path-finding).

Raph said, The reason AI is dumb in these games is because we can't run too many smart ones.

Only partly. Mostly I think to date MMOs have been focused on old-MUD-style individual play and so haven't invested in robust, goal-oriented AI that contributes to gameplay. Creating robust AI that doesn't eat CPUs is a very difficult problem, no doubt about it, but also one that can contribute hugely to moving MMOs off of their flagging style of gameplay and onward to something more dynamic, persistent, and rewarding to (more) players. Doing so sets up (and requires) a different kind of design ethic, and for example requires that you be comfortable with tuning emergent systems rather than proscribing mechanistic ones.

In terms of scalability, in addition to novel AI architectures, there are a variety of "LODAI" (level of detail AI) techniques that can be applied -- variable time-slicing, forward computation, representative computation (i.e., maybe you don't need to calculate the state of every single orc), etc. But as I said, these are a secondary issue -- a form of optimization more than huge innovation.

Overall the point is that creating a persistent, dynamic, textured world is possible, but not if you stick with the current MMO design methods and goals. It's going to require something different, especially in the area of more believable AI (which is ultimately at the heart of your example, Tim). Moving to a more satisfying degree of persistence requires and creates new kinds of gameplay -- and of course entails certain risks until we know the terrain better.

[Chip Hinshaw]

43.

Semantha>Absolutely valid and good points. Truthfully, I don't know that it would necessarily be a bad thing. I certainly agree that it could lead to some very interesting possibilities (namely that chunks of the subscriber base are playing vastly different games in potentially vastly different worlds "ruled" by the same mythos).

I guess I'm focusing too much on the potential for imbalance, and I suppose that could be mitigated to an extent. If you go back 10 million years in time, one little mistake could completely undo the future of the world. Whereas if you go back 10 minutes in time ... your actions aren't likely to have much effect outside the very local. So, you could certainly control the extent to which AI behavior would have a deep or lasting effect on the overall world. But, then it's down to perception. And if a good portion of your subscribers feel that other players are getting more for their money on another server (perhaps one that they cannot join due to population) then you've probably got a not insignificant service issue on your hands.

I agree with you, though, that it would make for some very interesting alternative worlds.

[Michael Chui]

44.

Do we really mean our limitations are economic rather than conceptual? Are we saying that if we could justify the computing power and storage we could make fully interactive persistent worlds given the knowledge we have now? Or are there some problems we can’t solve even if our resources were unlimited?

That's exactly what I'm saying, certainly; and not presuming to speak for the others, the gist of what I hear is much the same.

The thing is: persistence has been DONE. It has been achieved. The problem is that none of the game-like worlds USE it to the degree suggested (and that's a very small degree). The belief Tim presents in the OP is that persistence is the necessary key; this, I also agree with.

The problem has never really been technical. Sure, it's more work, technically, and you need better coders and better designers... but these people exist, and these people are willing. No one's made the choice to do it. Would it take more money? Yes. It'd take more servers, better networking, etc., etc. All of that. And the bigger you scale, the more you need. Fine. But is it possible? Hell yeah. Like Raph mentioned: Linden is doing it. Now. Like I said in my first post, you can achieve all of the above features by spending some time in Second Life. You can theoretically program the next MMORPG in Second Life. Of course, you'd also probably crash their servers... =P

[randolfe_]

45.

Like Raph mentioned: Linden is doing it. Now. Like I said in my first post, you can achieve all of the above features by spending some time in Second Life.

I don't think there is any level of AI implemented in SL by the VW itself (correct me if I'm wrong). If the suggestion is that you could use LSL and code your own persistent MMO, then you have to get around some serious limitations.

From the LSL wiki:

In LSL, each script runs in its own seperate 16k memory "sandbox", meaning there is 16k of space to store your program and all it takes to run it.

Of course you could use linkage and non-linked mechansims to expand upon this (essentially having lots of 16K processes interoperating), but this will reduce to an effort of optimization overriding design in short order.

Secondly, how exactly do you persist? LSL and many object attribtes are volitile from initialization state, so you'd have to export data out of grid then reimport it for reinitializations.

Lastly, even though LSL is an event-driven paradigm, it does not allow you to efficiently implement dynamic event handling. This will make creating an autonomous agent pretty tough.

[Mike Sellers]

46.

Michael: Would it take more money? Yes. It'd take more servers, better networking, etc., etc. All of that.

Hardware costs aren't a determinate factor in the scheme of things. One question in terms of cost is, would it cost more to create a dynamic persistent world with autonomous agents, and from which gameplay emerges, or to have an army of scripters creating reams of quests and instances? We know something about the spiraling costs in the latter case, and how quickly people rip through static content. The methods and costs of creating a dynamic persistent world part are a lot less well-known. But to me this looks like the way to move beyond our current first-generation MMOGs.

[Hellinar]

47.

Charles> I think that for the majority of players there is a great deal of identification with the shard and resulting community that inhabits that shard. Having different states in each shard might increase that sense of identification.<

Good point. Perhaps you could run each shard with just an NPC civilization for a hundred years before the player characters get there, then players have some chance to see how things are going in each shard. I still don’t see the model fitting well with the kind of character power curves we have in current games. If character development was more about the journey than power gained, then balancing the encounters would be much less of a challenge. And the diverging histories more of a benefit.

[Timothy Burke]

48.

Mike completely groks my ulterior motive here, as he has learned to from long experience with looking past my smokescreens.

In a nutshell, I'm trying to figure out with this and some subsequent entries I'm cooking up whether the problem with world persistence is:

1) technical in the sense of programming
2) technical in the sense of server loads or other hardware considerations
3) economic in the sense of, "We already know how to do it, but it's too expensive"
4) conceptual in terms of "We just don't think that way because the path-dependent nature of MMOG design so we really don't know how to think through this"
5) philosophical in terms of "It's a shitty idea"
6) managerial in terms of "it places huge burdens on live development teams and players will dope it out and exploit the hell out of it"
7) marketing in terms of "players say they want it, but they don't really".

I'm going to keep at this, so we'll see. I readily grok that I don't get to evade scalability; I'm just curious about the relative granularity of the "technical" or "conceptual" problems, about where it is that those questions really start to get ugly.

[function]

49.

Plenty of MMO players are already hopping between multiple characters, server, and even games that they play in parallel. In search of variety, or rather in search of respite from burnout from the eternal treadmills of their immutable (dare I say... "persistent"?) worlds. In that context, orcs who vary their reactions to attackers based on population are neat, but aren't shards that evolve to differ wildly from one to the next even neater?

[RedKnight]

50.

>>>I've always wondered what a game world would be with absolutely zero NPCs, just player characters?

If you want to see what a world with no NPCs is like, go check out Urban Dead (www.urbandead.com) a browser based zombies vs humans MMOG. Very fun.

[Barry Kearns]

51.

I'd strongly suspect that the scaling problem wouldn't be quite as much of an issue with an implementation using something like Stackless Python (as I understand Eve Online does).

It would still add overhead, of course, but the ability to have a sickly-large number of lightweight actors all going at once might make this more palatable than at first blush.

I recall reading an article not that long ago that keyed off of many of the same concepts.

I'm trying to focus a lot of my current effort on the inclusion of procedurally-generated and emergent content where-ever practical... and I agree with Samantha that allowing shards to diverge (even substantially) can be treated as a feature rather than a defect.

So determining the "cost" of this sort of approach may largely be a function of the overall engine/game design you're using. Designing it from the ground up with that goal in mind might make it quite attractive.

[Raph]

52.

Those orcs are not lightweight. Nothing doing A* is lightweight.

An interactive object in SL may well be a MORE complex state machine than these orcs.

Are we saying that if we could justify the computing power and storage we could make fully interactive persistent worlds given the knowledge we have now?

Yes. Or, at least, we could get a hell of a lot farther than we have now. I've done stuff myself in R&D that had extremely interactive worlds based on persistence and simulation, at small scales. I'm talking stuff well beyond what you've seen in games.

Keep in mind that when we're talking AI most of us other than Mike do not really mean AI. We don't even mean cellular automata. We mean simplistic event-driven responses and basic state machines.

[Timothy Burke]

53.

That's another direction I mean to nod towards: what kinds of practical and technical burdens would a MMOG that was built around agent-based AIs entail? I'll be poking at that problem too with subsequent posts.

[Ken Fox]

54.

MMOGs already have an architecture designed for thousands of independent, intelligent agents -- they are called "players". Artificial agents would be easier to build using a trusted client (to bypass anti-cheat and anti-bot devices).

Somebody smart should solve the trust issue with peer-to-peer architectures. That would be a great next gen MMOG platform to experiment with -- no central investment is required and storage capacity scales with the players.

55.

Ken Fox>MMOGs already have an architecture designed for thousands of independent, intelligent agents -- they are called "players".

But their actions aren't (currently) tracked any more than any intelligent agent. I think if players actions were to have a real dynamic effect on the persistent state of the world you would be looking at just as much complexity if not moreso. At least AI follows rules.

[Barry Kearns]

56.

By lightweight, I was referring to the overhead of massively multi-threaded implementations. You can scale the number of objects much higher when the overhead of launching a microthread for them is only a couple of bytes instead of 1 meg or more per thread.

You can get a lot of power out of a relatively small set of code per agent... if you don't have a prohibitive overhead cost. You can build an awful lot of logic into, say, 8-16k of instructions per character, and taking advantage of emergent properties when they interact.

Ants collectively exhibit behavior that is significantly stronger than many proposed AI implementations, despite having a fairly small set of coded behaviors. Even FSMs, a few sensors and some storage might be able to achieve some amazing things... if we're willing to let the emergence occur.

Throw in a layer of agent-driven Genetic Programming for self-modification, and we might end up with the NPCs gaming us instead of the other way around. ;)

[Chip Hinshaw]

57.

Barry Kearns said: Throw in a layer of agent-driven Genetic Programming for self-modification, and we might end up with the NPCs gaming us instead of the other way around. ;)

THAT could be most amusing! I wonder if they would adhere to the reward-driven model? Seems that they should since their "survival" would depend on evolving good behavior (unless, for some reason, that wasn't rewarded. That might be interesting: a karma system that effects your character's health/constitution. I digress.

This is just a question because I really don't know: would "evolving" (verb) NPCs/AI/ecology/etc. be a viable strategy since the unpredictability of emergence could lead to very undesirable results? Or would that be controllable? Obviously you would seed your world with the most desirable agents and program in (I assume) rewards for positive emergent behavior, but if you let the generator generate you could still wind up with a world of cannibalistic NPCs (which might not necessarily be undesirable I suppose).

Or am I thinking too broadly? Would the evolution be much more specific, testing for particular desirable traits while the base design of the agent remains unchanged?

Should I go back to bed?

[Timothy Burke]

58.

This is moving in an important direction: one of the things I'd contend about vesting persistence in the world that makes it undesirable for many developers is that it would almost certainly have to allow for "unwanted" outcomes in order for it to exhibit the interesting outcomes that might be possible.

[Daniel Speed]

59.

An evolving orc cave sounds like a lovely idea, but at some point it's got to be fun and balanced for players if it's part of a MMOG.

In my experience it's very dangerous to forget what you're trying to achieve, and not put regulating behaviour into a dynamic system to do it. It can be *very* conceptually difficult to achieve high level design goals while working at the level of complex dynamic behaviour arising from a society of individually simulated agents.

Further, I really don't think that this is what players are actually looking for. Traditionally, I think, at some point players just want to go out and get a certain level of managed risk, without spending hours looking for it. You want to make sure, that if newbies are reliant on bunnies around their low level area, that you don't end up with the entire bunny population being culled and your newbies ending up in a bind.

The other question that's worth asking, is if it's actually worth trying to simulate players using NPCs?
You get all the benefits of advanced AIs reacting dynamically and maintaining their internal state by using players themselves, so why not give your players the tools and advantages for building a settlement and defending it against other players? It seems at least partly ridiculous to go to extreme lengths in introducing PvE complexity in a game world that's based on player interactions (that'd be the MMO part).

[Franek]

60.

We want them to be dynamic, but within bounds. We want them to exhibit emergent behavior but drive to our pre-established goals. In some social game, for example, Alice and Bob (real people) sign up with the goal of finding the perfect mate. The underlying engine, from among all the people in the game, determines that Alice and Bob are perfect for each other. So all the NPC interactions are structured to bring them together and to allow them to exhibit the behaviors the engine has matched them on. But because of faulty programming, Alice finds an NPC more attractive than Bob and then sues the game developer for emotional damage. Interesting :)

[randolfe_]

61.

Throw in a layer of agent-driven Genetic Programming for self-modification, and [...]

Any GA self modifying system would need to be goal-seeking, or else the vast majority of "outcomes" would be unsatisfactory. This begs the question as to whether the complexity and economic tradeoffs required to implement such a system are valuable, when compared to the various pseudo-dynamic state machine solutions we've discussed. It well may be that theoretically dynamic persistent virtual worlds are an intensely interesting solution in search of a problem that isn't demanded (at least not in economic terms).

[Hellinar]

62.

Ken Fox>MMOGs already have an architecture designed for thousands of independent, intelligent agents -- they are called "players". Artificial agents would be easier to build using a trusted client (to bypass anti-cheat and anti-bot devices).

Somebody smart should solve the trust issue with peer-to-peer architectures. That would be a great next gen MMOG platform to experiment with -- no central investment is required and storage capacity scales with the players.<

You can bypass the bot device problem by making the programming of the agents the central theme of the game. You can constrain the behavior of the NPCs by limiting the operations in your programming language. With that kind of structure, a peer to peer MMOG is quite feasible.

In a sense, that is what I am doing with the gardening based MMOG I am developing. The NPCs in this case are the flowers. They don’t do much but grow into beautiful shapes. Players “program” the NPCs by altering their genetic code. The code is then “interpreted” into a growing flower. Coding is done offline, then players upload their flowers to gardens for others to admire. With a game objective of “Creating Moments of Beauty”, that leaves a lot of space for players to produce “good” NPC behavior.

Even with such a limited NPC behavior set, I still worry about intentional and un-intentional “griefing”. In particular, I figure I will have to build in some mechanisms to protect minors from visiting gardens of erotically suggestive flowers. Given any medium of the Net, someone is bound to use it in sexually suggestive ways.

[Timothy Burke]

63.

Randolfe's last comment is something I definitely want to take up eventually in this series of discussions. It seems possible to me that emergent approaches might not be right for creating dynamically persistent synthetic worlds (or they might be what we're looking for); but I'm sure that emergent approaches are a major way to create the impression of organicism in the environment and AIs of a synthetic world--that human beings have a really deep cognitive tendency to read systems governed by emergent designs as being "life-like".

[Mike Sellers]

64.

Randolph said: It well may be that theoretically dynamic persistent virtual worlds are an intensely interesting solution in search of a problem that isn't demanded (at least not in economic terms).

This is a vital consideration, and one that echoes Daniel Speed's remarks that "players just want to go out and get a certain level of managed risk, without spending hours looking for it." It's all too easy to get wrapped up in cool technology (AI or otherwise) that doesn't contribute to gameplay. OTOH, it's also easy to constrain what we consider might be good gameplay to what people already know, and so miss out on some new forms that increased dynamism in the world enables.

Also, one of the intriguing things that we've found in our explorations is that often, especially in the case of agent-based AI, "pseudo-dynamics" break down quickly: they create brittle behavioral modes that don't "feel" right, are easily gamed, and aren't as robust or flexible as are behavioral dynamics grown the old-fashioned way. I don't think this argues for maintaining a high-verisimilitude simulation at all times, but instead that shortcuts and optimizations must be tried out carefully.

Tim: human beings have a really deep cognitive tendency to read systems governed by emergent designs as being "life-like".

I've come to believe that our tendency to anthropomorphize (given sufficient basis) goes beyond things that are human-like and extends well into things that are life-like. And that, "Uncanny Valley" issues aside, the greater basis people find for this, the greater their immersion in and attachment to the world. Which can only be good for gameplay, community, and ultimately commercial success in an MMO.

[Franek]

65.

I’m gong to make one of those back-to-basics kind of appeals. There’s a difference between simulating a situation – which is at basis a modeling effort and an exercise in abstraction – and creating a situation which need not have fidelity to an external ideal. I believe we sometimes confound those two objectives in our designs. In implementation we must confound them. But analytically it is important to keep them separate.

Creating the “impression of organicism” is a simulation effort. Having fun, overcoming slightly challenging obstacles and the like are creations in and of themselves. Gaming usually makes the second objective primary, using the first to support it when appropriate, sacrificing the first when appropriate. Mike’s comment about sacrificing good game play because we don’t consider some classes of alternatives points, it seems to me, to our tendency to mix these two design threads too early. Perhaps a requirement for persistence can be best evaluated in terms of it’s support of the gaming objectives.

We often take as a given Mike’s observation that life-like environments are good for “immersion in and attachment to the world. Which can only be good for gameplay, community, and ultimately commercial success in an MMO.” While in many situations I certainly agree, we should be careful in our designs ensure that is true.

[Franek]

66.

I am indeed gong! :) Apologies. Going.

[Hellinar]

67.

Randolfe>Any GA self modifying system would need to be goal-seeking, or else the vast majority of "outcomes" would be unsatisfactory. <

So long as your GA is of the type that responds to evolutionary selection pressure, you can use player driven selection as a method of weeding out unsatisfactory outcomes. The nice thing about the Darwinian approach is that it can create interesting outcomes that you wouldn’t have consciously designed. A significant problem though is ensuring player delight at finding satisfactory outcomes exceeds player boredom at weeding out unsatisfactory ones.

[John Arras]

68.

Timothy Burke: Mike completely groks my ulterior motive here, as he has learned to from long experience with looking past my smokescreens.

In a nutshell, I'm trying to figure out with this and some subsequent entries I'm cooking up whether the problem with world persistence is:

1) technical in the sense of programming
2) technical in the sense of server loads or other hardware considerations
3) economic in the sense of, "We already know how to do it, but it's too expensive"
4) conceptual in terms of "We just don't think that way because the path-dependent nature of MMOG design so we really don't know how to think through this"
5) philosophical in terms of "It's a shitty idea"
6) managerial in terms of "it places huge burdens on live development teams and players will dope it out and exploit the hell out of it"
7) marketing in terms of "players say they want it, but they don't really".

I'm going to keep at this, so we'll see. I readily grok that I don't get to evade scalability; I'm just curious about the relative granularity of the "technical" or "conceptual" problems, about where it is that those questions really start to get ugly.

OOoooOOO my favorite subject. :)

1) technical in the sense of programming

2) technical in the sense of server loads or other hardware
considerations

3) economic in the sense of, "We already know how to do it, but it's too
expensive"

I think it is technically possible in terms of server load and hardware to
make progress on this. At least by progress I mean having an ecology that at
least makes things spawn in reasonable places and which can be depleted slowly
and locally over time. Along with the ecology, having a way to have NPCs that
have some sort of goals that can be communicated to players that the players
can understand and help or hinder. The basic idea was to make each NPC as
simple as possible and make the heavy lifting occur within the societies. The
model has translated well at least so far into my thinking about larger
systems, since the goal here is to have a central location where all of the
smarts are, so that the distributed pieces of the system can occasionally get
updates from the central location to tell them what to do.

I've implemented a simple version of something like this in a text MUD, but
never anything commercially. The simple text MUD had world with about 60k
rooms with a few exits each and about 50K NPCs in 300 or so societies would
run fine on a 1-2 GHz machine with about 512 megs of RAM. But again, things
were kept very simple.

I never really played MMOs until last summer when I started playing WoW, so I
had no idea what kinds of things were required for MMO's but having seen WoW,
I don't think the technical issues quite as bad since there are things that
players are willing to put up with in terms of the presentation that make
things easier to do than I had feared. It's probably too expensive to do it
the way I would like, but oh well, there's also room to scale back more. I'm
thinking that 1 and 2 will be ok to make progress, but 3 will be a problem. I
am assuming ~100 computers per shard. But, then again, computers keep getting
more and more powerful...so maybe it won't be too bad? I dunno.

4) conceptual in terms of "We just don't think that way because the
path-dependent nature of MMOG design so we really don't know how to think
through this"

As for 4, I look at most games as simulations of slices of reality or altered
reality. Just because everyone tries to simulate something some aspect in a
certain way, it doesn't mean it's the only way to do it. I see this as a
hurdle for people until they realize it isn't a hurdle.

5) philosophical in terms of "It's a shitty idea"

7) marketing in terms of "players say they want it, but they don't really".

Yeah, these go together I think, and they relly suck. I guess I am in denial
and I try not to think about these issues :), or at least I tell myself that
huge numbers of people can't be wrong so if they SAY they want it, then some
of them must want it.

6) managerial in terms of "it places huge burdens on live development teams
and players will dope it out and exploit the hell out of it"

This is another bad issue. I think players will exploit anything, and my
philosophy is to put throttles on things the players can gain to try to deal
with this, but I don't have any idea how to deal with it.

Now, regarding the first few questions, I think the resources can exist, but
you have to be willing to give up on total control and do things
statistically. If you want to explicitly instantiate your whole ecology, I
think you're going to be sunk.

But here are some estimates I've tried to work out. I will assume we have a
server farm set up for a shard with 1 ecology server, 1 society/reputation
server and N (=100?, =10?) game world servers. The bottleneck seems to be the
network bandwidth between the game servers and the central servers. I think
that the trick is to do coarse, important, global updates on the central
servers and then send infrequent updates to the game servers as needed. When I
type IIWOW below, I am saying "I Invoke World of Warcraft", which means that
since WoW does something in a certain way and people seem to tolerate it, we
can make things cheaper and simpler by approximating. My guiding philosophy
about how precisely or accurately to do something is "WINAC": Would I Notice
And Care? So, if something can be done incorrectly and cheaply, and I
wouldn't notice and care about the difference between that and the "correct"
version, I will stick with the cheap and incorrect version. Another piece of
the philosophy is to not worry about dirty or incorrect data. This is an
approximation.

I also haven't dealt with collision/pathfinding/los and such so YMMV, and it
probably will.

Some numbers, mainly dealing with expected bandwidth.

For the ecology:

The world is a 200x200 grid with each cell representing a few hundred yards
across. (Would really like 1000x1000 but maybe not possible atm. :(.)

There are 100 different animal types. (IIWOW -- Use different levels of
animals in different cells, so we don't have to update 30 kinds of boars or
wolves in the ecology server.)

There are M mineral types.

There are P plant types.

The central server updates the grids making the populations grow and shrink in
some coarse manner every hour or several hours cycling through the different
grids, and having rolling checkpoints saving things. I don't think DB will
work with the central server, but flat files with RLE seems to work pretty
well (since most of these grids will have big blank spaces and small nodes of interest...).

The N game servers keep local caches of parts of the ecology populations. The
idea is that every hour or so, the cell sends a request for an updated
population sample. The main server sends back a set of numbers representing
approx 2 pct +small amt of the values for the various objects. The game server
then sends back any remaining things left over from the last hour's update,
and replaces the values it uses with the values it just downloaded. Assuming
we even send things in text, the bandwidth to send an update for one animal
type for one cell is under 10 bytes tops. The update consists of a population
and an id number. Put some overhead and bookkeeping and lets assume an update
going one way or the other will be 1k. There are 40k cells, and if we update
each cell every 4000 seconds, that's 10 updates per second, or 10k per second
bandwidth*2 for each direction....and only dozens of packets going in each
direction each second. And, the expense isn't that bad on the server, either.

Within the game servers, the cells get rolling updates every N minutes? 1? 2?
something like that and the cells take a census of their contents and decide
how much and what to spawn in there. I am also assuming that it's possible to
track players who enter and leave a cell so if nobody has visited it in a
while, it will reabsorb things. Similarly, if it is marked as having nothing
spawned in it and a player comes near, then some things could be instantiated
as they get near. There are issues of creatures wandering into areas
controlled by other servers, but there are some ways that theoretically those
can be dealt with. Not sure what the cheapest way to do it is.

IIWOW and say that things like plants and minerals can be represented simply
by saying there are N mines and N plants in a given region, and hardcoding
their locations, then downloading the contents of those locations to the
client as needed, without needing to actually instantiate the objects in the
world.

Anyway, the point of this is that I think it's possible to have a changing
ecology by keeping large numbers of implicit objects stored in a central
server where infrequent, coarse updates are performed, then dole out
infrequent, representative samples to the different game servers, which then
dole out frequent representative samples of the representative samples for the
players to actually see in the world. (Whew!)

What needs to be persisted is the central server which has rolling updates, so
if things die it may be an hour off, but oh well the numbers are designed to
be large enough that it won't matter in the long run if it crashes once in a
while. The game servers should store their representative samples, and we're
talking a total of 40k*1000 bytes of data to be read in over all machines to
and from the DB. If we have 100 machines, and maybe 20 creature types on
average per cell, then you're looking at 400*20=8000 rows to read in/store on
each server for that. Then you have the representative sample creatures, and
that sucks, but I am hoping you can store their type and xy coords (cheaply)
so if there are 100 creatures per cell instantiated, that's 40k rows to
read/save but again remember these things don't have to be perfect, and maybe
this isn't the best place to spend so much energy on persistence. And, the
mines and plants will require up to 400*(number of mine + plant locations per

cell) (10k max?) rows to store...blank ones being left blank. It will be
important to delete things from the DB before giving players a benefit,
however, but I think games already do this which is why it takes 10 seconds to
gather in WoW...so they can delete the object from the DB to prevent dupes
before the player ever gets a reward. So, assuming fewer servers, like 10,
we're still looking at a few hundred thousand rows to persist the ecology on
each server, but if there are more servers, then it's only tens of thousands
of rows to read in in batches.

I will assume there will be about 100k NPCs and about 1000 societies. The
NPC's of course have to be saved, and their type and level and position and
some other stats should be stored. I wouldn't give them equipment, but I would
give them some customization that could be stored simply using a few
variables. They should also have their current task stored, and probably some
more, but I don't believe that NPC's should be really intelligent. So, if we
have 100 servers, this is 100 NPC's per server, so tens of thousands of rows
per server.

The NPCs have different jobs that they are assigned when they are
generated. So, they go about doing their jobs with some information downloaded
from the society server, but every 5 minutes or so they send a request for an
update on what their job should be. This will require the group-group
loyalties to exist on all servers so that they know how to react to other NPCs
and PCs more easily, but this should only be 1000*several pieces of data
downloaded from the central server on bootup. But, if they request help every
5 minutes or so, then we are looking at 300 requests per second or so going
into the main server. The requests come in the form of the NPC id, so its
groups can be looked up (and these NPC-group loyalties are stored on the
central society server, too), and then the society server determines what the
next task for the NPC should be, and sends the data back. Assuming 100 game
servers, we send 3 updater requests from each game server each second, and if
there are 10 servers, then it's 30 per server per second. Each update request
will be on the order of 10's of bytes, so it's on the order of tens of
thousands of bytes per second for this. Other than those updates, the NPCs try
to follow the job they were given. Some exceptions will occur such as
shopkeepers needing to download a representative sample of their society's
goods that they care about. The real society AI is a whole big other mess
which I haven't worked through yet, but it will be based on items and other
spheres of influence that the societies will care about.

So, the idea is that it seems possible from a bandwidth perspective to
make progress on this, but it should be clear that this is theoretical, and
that it will NOT be a fully dynamic world where everything is correct. It is
trying to put dynamic things and persistence in where it is most likely to be
noticed, and then it is done as cheaply as possible.

That was a long post, but I enjoy rambling on about this and I try not to
inflict it on people irl too much. :)

John

[Michael Chui]

69.

I really don't think that this is what players are actually looking for.

Come on, now. No one was looking for an MMORPG until the first one came out. =P It must be made, played, and, in terms of business, succeed or fail. The players' desires are unpredictable, here. And from another perspective, what was Picasso's audience, to whom he catered? =) There's sufficient reason from sufficient perspectives to look into it.

one of the things I'd contend about vesting persistence in the world that makes it undesirable for many developers is that it would almost certainly have to allow for "unwanted" outcomes in order for it to exhibit the interesting outcomes that might be possible.

What I'd respond to such an outcome with is a Deux Ex Machina. Is the orc civilization overruning all the possible PC cities? Have a faction rise within them that creates a civil war that rampages their civilization into the Dark Ages. Have the wrath of the gods manifest desctruction upon them. Have them change their philosophy of life, such that they have conquered sufficiently to sate their appetite, and now want a more culture civilization in harmony with their former victims. *shrugs* God-magic and Poof can make it viable, even if we shouldn't need such things.

The easiest thing might simply be to make orcs a playable race.

[Daniel Speed]

70.

Michael -

Assuming that you'll end up with something fun just by throwing persistence and authonomous NPCs that haven't been vested with any guiding rules for fairness / fun / balance just seems horribly naive to me.

Among other things, I used to play with neural networks doing relatively simple stuff. The truth of them was that you never got what you wanted on the first evolutionary itteration, it used to take hundreds or thousands of passes through training data to evolve the network into the sort of state you wanted it in. The sort of complex situation like "evolve me a fun a balanced MMOG" (that professional game designers can have trouble with) is a wildly complicated problem involving the interplay of a lot of variables, and crucially, players who are *terribly* unpredictable. It's a bit like assuming that AI will arise from the creation of a huge neural network which had audio inputs and outputs and someone talking to it.

If there's a reason that AI programmers are in increasing demand over the last few years, it's not because you can read a book and construct the technology and throw it at something to get a solution unless you know what you're doing, what the technology is suited to and understand the problem you're trying to solve.

Resorting to Deus Ex Machina to solve every single one of your problems with unpredictable behaviour is going to get very expensive very fast as the problems pile up, especially if you need to codify something like a change of philosphy into an evolved society by changing small variables in individuals (when complexity tends to take over and dictate you'll never quite be sure what a change to those numbers will do).

[randolfe_]

71.

Daniel,

I couldn't agree more regarding neural nets and GAs. My experience with such, in an environment far more predictable and constrained than an MMO with player-agents, was similar to yours. We found ourselves continually reevaluating the economic tradeoffs of using the evolutionary approach versus the "big ugly state machine" approach. Of course, I recognize that as these techniques are refined and computing power increases, the economic arguments will diminish; but we aren't there yet and may not be for a while yet.

Further on the economic rationale: appealing to MMOs as art (who was Picasso catering to?) is naive in this context. We are talking about commercial ventures which must justify these projects as having positive NPVs given risk-reward assessments and FASB-driven accounting considerations. This is why advancements in MMOs are largely incremental, rarely revolutionary.

[Bart Stewart]

72.

I was thinking along the same lines as Ken Fox and others: mobs-as-cellular-automata. This seems to be where mobs are weakest now, and thus the point of greatest payoff for effort invested if your goal is increasing the dynamism of a game world through its actors.

Maybe looking at some of the details would shed some light on the scope of such an effort. (Is such an effort worth making? Separate question, addressed later. ;-)

First of all, mobs in the current batch of MMOGs already seem to be implemented as simple state machines. They just don't have many states:

critter mob behaviors: move, fight, flight (and maybe stalk)
NPC mob behaviors: move, fight, converse, give quest/reward, trade

To generate more interesting behavior, it would probably be necessary to expand internal states (and transitions between states), available behaviors, and interactions among groups of mobs. It might also be interesting to allow social mobs to have roles.

Here are some possibilities that roughly follow the initial set of activities Tim described for an orc camp, along with some of the ideas others have mentioned in this thread:

internal states: curious, expansive, normal, alerted, panicked, defensive-group, defensive-self, enraged, losing, terrified

behaviors: explore, build, fiddle-with, fortify, broadcast-alert, defend-friend, defend-self, attack-nearest-enemy, lay-traps-and-retreat, flee

interactions: send orc runners to other allied orc camps ("we're being attacked!"), mass for counterattack, counterattack nearest non-allied (orc or other enemy) population center

roles: warrior, maintainer, builder, communicator, leader

There are tools that could help design behavioral mechanics (I can't bring myself to call that AI, either), such as Deterministic Finite Automata graphs. I suppose these are already being used by some developers.

Even with such tools, however, implementing more complex mob behavior still carries some risks:

* feedback loops -- positive feedback (in the technical sense) can be destructive
* player metagaming of complex systems
* potentially large storage requirements for retaining "state" for many mobs
* potentially significant processing power required for detecting state change conditions for many mobs

Deciding whether to have more dynamic mob behavior has to take those potential costs into account as well. In particular, detecting state change conditions for many mobs could get really nasty. If your conditions aren't well-defined events on which triggers can be applied, then you have to poll for condition changes. That's usually bad news for performance.

So I concur with Mike Sellers that systems-level thinking is the only hope for making something like this work. I can't imagine successfully approaching it as an isolated game feature.

Finally, there's that pesky question of whether the current very Achiever-oriented population of gamers actually wants a more dynamic world in their game. "Unwanted outcomes" look good to Explorer-types like me, but someone whose satisfaction depends on having a controlled gameplay experience is not likely to agree.

--Bart

[Steven Wartofsky]

73.

Lots of interesting thinking here, but I think it _all_ gets away from a very simple, and fundamental problem: what is interesting for the player? What's the maximum bang for the buck, in terms of sustained, tangible interest?

This is not it. This kind of experiment has already been conducted in the past -- in the AI for air combat sims, for instance, as well as the AI work for some of the more sophisticated RTS out there. The results tend to be far more subtler than the sophisticated, buggy, difficult to balance systems are capable of handling well, and subtle enough that, nine times out of ten, they ultimately, don't really matter to the player, and to the dynamics of the game.

If you're looking to build an interesting game experience, providing simple, discernible -- and thus, often, static -- elements for the player to analyze and make decisions around, you're better off "hard-coding" -- in other words, writing pre-defined sequences triggered by a traditional event system -- a specific combination of evolving results for the player to work through. You can craft a much more dimensional, interesting, vivid experience for a player this way, and especially in an MMOG environment, you can prevent the "it's my turn to get on the theme park ride" syndrome that other, more "emergent behavior" approaches tend to result in.

My two cents. :) Hi Tim! We corresponded eons ago when I was starting out doing turn-based historical wargames (Great Battles of Alexander et al).

Steve

[Mike Sellers]

74.

Steven: what is interesting for the player?

This topic has been touched on above, and it's certainly at the core of any innovation in a commercial game.

If you're looking to build an interesting game experience, providing simple, discernible -- and thus, often, static -- elements for the player to analyze and make decisions around, you're better off "hard-coding" -- in other words, writing pre-defined sequences triggered by a traditional event system -- a specific combination of evolving results for the player to work through.

While what you say may be true for many (mostly male) hard-core players of shooter or strategy games, the AI that some here are contemplating is a different animal from that tried in combat, flight, other sims, or even MMOs in the past. In fact, the closest analog to the the dynamism being considered here is that found in The Sims -- which, you may recall, has sold well over twenty million copies, or roughly 100x what the typical military flight sim game has sold. No one thought it would sell anywhere near as many as it has before it was released, so maybe there are gameplay and demographic lessons to be learned there.

[Steven Wartofsky]

75.

Mike, oh I'm intimately familiar with The Sims, as well as The Sims 2, fear not. :) I won't spend any time here going over the details of how completely broken the very superficial AI is in the latter game, but.... I do know that the kind of response you've offered really isn't to the point. Why the Sims games sold as much as they did is a separate topic, and not, methinks, much related to any issues of AI at all. You can't really go very far with the Sims games before you run into how shallow their AI actually is -- and I say this from direct experience.

I should also note that your characterization of an event-triggered system as only applicable to shooter and combat games for males strikes me as completely inadequate, as it's exactly the system used in _most_ games, including semi-popular ones like World of Warcraft, and more popular ones (at least in Korea) like Lineage -- to keep to our genre here.

What's being described in this thread instead, is in fact really much more like the AI system in Falcon 4.0: a system with a series of cascading, inter-related, complex state machines producing emergent behavior that's different every time it's initiated. And you know how long it took that one to be made right (about eight years), for the remaining (very small) audience. :) Unfortunately, while the results may be impressive from a scholastic point of view, they're not particularly fun for all but a very few entirely males.

I just think such an approach -- witness the extensive discussion here -- is more attractive to the people who want to make, or imagine making, such things than it is to the people who would be the victims of it. There's a general tendency in game design, whether it be in the area of story, AI, systems, UI or animation: the more time spent concentrating on the designer's satisfaction, by allowing her or him to produce ingenious, over-elaborate solutions to non-existent problems, the more the player is crowded out of the experience entirely in the process.

In fact what makes the Sims games enjoyable really mostly has to do with a mass quantity of very simply implemented scenario scripts, all of which concentrate primarily on sequencing through short, entertaining events animated for the player. That and its mild architecture/ interior design/ landscaping possibilities.

Another, more recent design does all of the above in similar ways, but much better: Animal Crossing, on Nintendo DS. Again, not very complex AI going on, but an extremely successful game saturated with a bunch of simple event triggers.

I continue to believe it's best not to use an elephant gun to kill a mosquito, Elmer Fudd to the contrary.

Steve

[Lee Sheldon]

76.

Why is it that when discussions like this come up Horizons is never mentioned? (Forgive me if it did get mentioned somewhere up above, I may have missed it.)

Horizons had:

1) Dynamic content that players affected in a big way

2) The experience was different on different shards due to how players were progressing on each, and there was no problem with that

3) In fact different shard states added a meta game of shards competing against one another

4) The community-building aspects of the dynamic content were stronger than I've ever experienced in an MMORPG

5) It didn't cost an arm and a leg to produce that content. The engine, with its ability to update content on the fly without taking the servers down, was built with dynamic content in mind.

What they didn't have was a staff who understood lead time or could handle the speed at which players chewed through the content. Still, the first couple of months worked extremely well. Nobody seems to have noticed.

Oh, and I'm using past tense here because I only played Horizons for those first few months until they got into financial trouble. I know the game is still around, but I have no idea if the content is static or dynamic these days.

Even though it's a pale shadow of what could be done, in its handling of dynamic story-driven content Horizons remains the only innovative MMORPG that has actually made it to release.

Lee

[Mike Sellers]

77.

Steven, we appear to differ based on our own "intimate" knowledge of The Sims and TS2. I think you misunderstand the value of different types of AI and the success of The Sims entirely, but so it goes.

Lee, games like Horizons are probably not mentioned much because so few people had the opportunity to see what you saw before it vanished beneath the waves the first time around. I also haven't checked it out in its renewed state (available here with a 14-day free trial) -- it looks lush but (perhaps to Steven's point) dauntingly complex. Frankly, the idea of taking on another high-fantasy MMO post-UO-AC-EQ-DAoC-WoW is a little tiring to think about.

I would be very interested to hear from anyone with more in-depth experience with Horizons or other large-scale graphical games with similar dynamic-world features about how well they work(ed), or not.

[Kelly Rued]

78.

Fascinating thread! I wanted to pose a couple questions about the original design query.

First, it was proposed that the design engendered some move toward a persistent world offering "dynamic, changing, responsive" content for the players but then the design focuses entirely on this AI routine with the orcs in the cave and players are only given a slight mention when they somehow trigger states in this AI routine. How does the AI routine make for a more responsive world for the player?

I don't see the point in implementing so much complexity per orc when the gameply is essentially going to devolve to players observing this tech demo for patterns, solving or gaining the solution from the community and then the player goes on their merry way trying to get past these complicated orc behaviors for whatever loot or quest goal they require. Did you really improve the player experience? It seems more fun for the designer than the player to create solutions like this.

And second, is better AI the answer? We can't match the dynamism of player vs. player with player vs. bot. Why the obsession with making better bots in online worlds where you have *other players* as tools for the designer? Furthermore, why not more talk of creating systems where NPCs in the world "learn" or simply record behavior strings from human players placed in similar roles (ie human players must fortify thier *own* caves with minions whom they control via metrics much like the rule set above describing the AI orcs- human players test and develope different strategies in a limited system of choices across the world and then later the data can be used to generate more interesting behaviors for the AI orcs). Do any MMOGs now make use of player data or design the game so that player data is useful in improving or at least *varying* AI behaviors in interesting ways that can't be metagamed anymore than human player strategies could? Even the smartest designer can only think and implement in patterns to create these systems- but it's the players who will do brilliant and brilliantly stupid things that are simply amazing in the confines of the pattern-based systems. Why not harnass the player's ingenuity (and natural tendency toward non-pattern-based and naturally interesting behaviors)?

[vlad the insurance saleman]

79.

"Did you really improve the player experience?"

Since real AI cannot be used yet and realtime behaviors of NPCs/Monsters will be limited in their complexity and variability, then at least combinatorics or rearranging the props (the fortifications) and the actors (the orc spawns)
and having some modal behavior modes (defend fort,attack,runaway) and interacting subsets of orcs can lead to frequently different experience for the players on each visit.

That is: versus the static spawns, clockwork spawn cycles, static terrain of most canned content you find in MMORPGs. Yes you might get different situations in those if other players have been there recently, but the result of that is usually that the same monsters are nuked. Players often want to handle the situation themselves (and gain the rewards) without interference of other players (outside their party...)

The rearrangeable/dynamic scene for MMORPGs will eventually come out (using smart generator scripts and situation templates) and likely will save the companies alot of money when players demand more content to keep them interested in the games.