Defining persistence better!
Still confused about this use of the word persistence; coming here with the dictionary meaning and trying to understand a seeming contradictory concept.
The technical sense of the term arises from “persisting something to the runtime database.” The base states are usually in a template database of some sort, along with all the other static data. The template database is read-only as the game is running, and only developers get access to it. The runtime database is where everything that players do goes. (See here and here for more).
The base data in the static template database doesn’t count as “persistent” or “persisted” because it’s actually baked into the world’s rules in some fashion, as a starter state. Delete everything in the runtime database, and that map will still be there, usually. You will have playerwiped WoW, but the world of WoW will still be there: every loot drop, every monster, every quest, every house.
The virtual world definition of the term means “to save changes on top of the base dataset.” So a base character starts with no real gear and newb stats, and a designer sets that up in the template database as the definition of a newbie character. But we save their advancement. That’s persisting a character to the runtime database. The stats and gear might go up OR down, but they are different from the base.
Same with the map — terraforming in Wurm Online, or leaving a house on the landscape in UO or SWG, are persisting changes to the base map.
The definition of persistence in MMOs and VWs is a tricky one, as there is an awful lot of crossover with dynamism.
Exactly; without persistence, there isn’t any dynamism, basically, because nothing you do affects a state in any permanent fashion. There were early virtual worlds that didn’t even have character persistence.
Then there are virtual worlds where the base state is basically next to nothing, and all the stuff the designers added is in fact done via a set of tools that modifies a persistent world. For AAA MMORPG stuff shipping to the public, usually that state is “snapshotted” to create a new base once the developers are done building. And plenty of worlds are not built that way at all — the static stuff is imported into the world, perhaps built in a 3d modeling program, and exists as a base assumption in the simulation.
Other worlds just rely on the accumulation of persisted data over time; Second Life is an example of one of these. (Metaplace is a weird hybrid — the tools are editing a “stylesheet database” that is in fact a static template database — but via script yo ucan actually insert changes to ths on the fly. So it’s like a classic split database model, but with blurry edges).
And that is why using the acronym “persistent state world” or PSW is inaccurate for most MMORPGs. It technically means a vritual world where the world state is dynamic and persisted — not just the character state. Most examples aren’t even of ALL of the possible world data… there’s a spectrum. UO didn’t let you change the terrain, but let you change objects. SWG let you change both, but terrain only to a limited degree. SL lets you change everything.
The only reason to have persistence to the runtime datbase is to track change caused by players. And the less changes you track, the less persistent a world your MMO can be considered to be.
22 Responses to “Defining persistence better!”
Sorry, the comment form is closed at this time.
I think improving the definition of “persistence” by relating the use of the term in a technical context is impractical. Most consumers don’t care about base states, runtime databases, and dynamism. As used by consumers, “persistence” refers to play that is meaningful — play that simply has a lasting effect on a game world.
Yeah, but some of us readers are developers, too. 🙂
Hard to see what the real difference is between those early worlds that didn’t have character persistence and pretty much every FPS available 5 or 10 years ago. Today, even most FPS’s have more character persistence. So, why are those early games referred to as MMOs/MUDs/worlds whereas FPS games aren’t?
–matt
Well, back then it was because
a) the FPSes had a much lower concurrency, which made them not count as “massive”.
b) FPSes shut down the map after every match, and therefore nothing persisted between sessions.
These days, FPSes have increased both persistence and concurrency. They still “instance” the world, however.
But this is basically the same logic by which the Battle.Net system as a whole was often termed a VW in its own right.
Interesting clarification on the technical definition and its origins. Enjoyed reading this — thanks, Raph.
Is there acknowledged to be a part of the world that exists persistently but is not recorded to data? A non-engineering manifestation of this notion of persistence, which even in the case of hard template-database environments, exists and persists? Does all persistence, to fall under this definition, have to be manipulated by a database or manifest in one? Or, even in the case of data that is generated in the system (by, say, dialogue in the performance of an interactive story) but not recorded (or, even if logged, isn’t used to re-interpret a “state” of the game other than in the minds of those who read the dialogue live), is that interaction part of the game’s persistence? From a player perspective, this is the nature of the online game that continues evolving and manifesting even when I am not playing it, when my piece of it is not turned on. I realize this kind of design definition probably doesn’t help in your objective for this post…
The point is that “defining persistence better” ought to really be “redefining approaches to persistence” or “solving the problem of persistence” or something more accurate that doesn’t say “persistence really means something else.”
Except, Morgan, that these aren’t MY definitions — they are the ones in common usage among VW developers.
Erin, I know EXACTLY the sensation you mean, and a lot of it IS captured in the web between users who are persistent themselves — as returnees, even if not as database entries.
Thanks for expanding on the original article, have a good working understanding of the concept now, that linked Massively article definitely confused things with it’s interpretation of the word. 🙂
Ah, I see, so this falls under character persistence, or maybe a “persistent story” emergent multi-character thing, whereas for the _world_ to be persistent it is defined as the “physical” characteristics of the environment. So maybe (some of) the confusion here isn’t over the word “persistent” so much as the word “world”…
And of course we as players are dynamic and persistent, we hope… 🙂
Yes, players are really persistent. They never cease to go on about bugs, missing features, class imbalances and the like. =P
As I understand it, it’s like a transparent overlay on a printed map. The “persistent” overlay can be modified, saved, or erased with no alteration to the “static” map beneath.
What I’d like to see more of are instances where some of the player markings on the overlay, subject to QC criteria, are incorporated into the next printing of the underlying map.
Here’s an example; what if particularly famous or infamous players had a mechanism to retire their character and have that character become an NPC, either a quest-giver, a mob, or just a random townsperson? I’m thinking of Johnny Wilson’s infamous immortalization in UO, though perhaps in a somewhat less slimy fashion. Since players outnumber NPCs in most game by an exponential amount, you’d have to have some way to either filter the applicants down ruthlessly or rotate them in via a list (and characters with inappropriate/borrowed names would either be disqualified or modded to fit the mileau). But what better way to acknowledge the contributions of long-time players than by making their characters a permanent part of the world!
Why go half way? Why not track persistence of NPC MOBs who travel and build their own cities, like players? Maybe King Orc wants to build a defensive wall in front of the dungeon he’s taken over!
Extend it out to web-as-a-game-of-relating-quasi-persistent-values and it becomes obvious why the web isn’t the oracle of delphi but has become the most gamed in the history of communications systems.
It’s an interesting problem for fans of coherentism as applied to control theories using very large cybernetic systems, or simply, versions of truth. Despite the snickering, one gains considerable insight looking at coherence and evolution as a result of systems entanglement. For example, from the discussion at XML-DEV:
Why is this
more common than this
One answer is entanglement by dominant use (amplitude strength of feedback increases the occurrences which in turn increase the feedback – so frequency modulation) and that seems to support the connectionists.
If persistence in games behaved as persistence in the physical world, I wouldn’t find the tree but I could find the rotting stump and phases would be so long as to be irrelevant. This is one way to differentiate games and virtual worlds, of course, dynamism as phase length and interference given multiple sources of change and change rates.
Then again, one could reduce it all to the cost of state maintenance and drift off into server-centric vs p2p (fry the server or fry the wires).
Rats. Frikking reserved literals…
Why is
<div class=”warning” />
more frequent than this
<Warning />
I’m having a bit of difficulty making out the distinctions that you are alluding to. In specific, I don’t see the practical difference between these two quotes:
In both cases – assuming the second type of world has any updates at all – it seems like the designers are editing content offline with a variety of tools (some bespoke, some not) and then pushing the eventual data to the live servers to become new, ‘static’ data. What is the distinction you are trying to make with the first quote? That changes are made online? That the changes are made with a bespoke tool? That the storage for that data is conceptually more similar to that of characters, who evolve as the game goes on, rather than similar to traditional game assets, which are generally fixed until patch time?
Quick two cents:
It’s a semantic point, but I read the current term of “Persistant State World” as a world where persistence is possible, and not necessarily ever-present. That is, not that the entire world (inclusive of everything in it) has this trait, but that enough of it does that it significantly defines the nature of the experience of the world.
More subjective, but I feel more descriptive of the current use of the term.
Ben, the difference is that worlds where everything is built statically outright don’t HAVE a persistence mechanism for that stuff. It is incapable of having changes made by players. It lives in a read-only source, and said source may be writable by developers, but not by the game world.
“Persistence” just means that state is preserved across reboots. Trying to define it beyond that is going to be confusing in the general case. If the game world does not store all state, then it effectively is based on at least partial “resets” (not in the general case, but in the common case).
A well-designed generic server will automagicall persist everything on a low level with no effort, but most servers aren’t well-designed… So yes, it is and should be a technology term. I don’t think this originate from the application-level, it comes from computer language runtimes that provide persistence. *sighs* Beyond that I view the term as a poorly chosen and highly confusing marketing term…
Is the state maintenance problem (what persistence is and a general problem), somehow worse or better or just different in world simulations vs. say, enterprise databases, and is that by kind, quality (rate of update) or technology applied? Is this just the versioning devil at one extreme and cache management at the other? Is this just ‘changes we care about and changes we don’t and why we can’t agree or do agree on what do and don’t care about’ or ‘what we can afford’?
Wow. One could get a master’s thesis with that one, but I doubt one can get a speaking slot at Siggraph.
Raph, so the key distinction is that in the first instance, the toolset is modifying data that can be changed by the game during execution, right? It’s interesting to consider how DIKUs with online creation fit into this, since the boundaries between tools and gameplay are blurred, as are the boundaries between developers and players.
Is there accepted terminology for these different sorts of data? I’ve been thinking about the masses of data associated with an MMO and strategies for coping with it when it comes to patch time and other upgrades. I don’t think a simple division into ‘static’ and ‘dynamic’ data works very well when designers are likely to change the static data as the game develops. I can imagine that systems where designers modify the persistent world directly can be especially difficult to manage in this regard as assumptions can’t so easily be made about data that is prone to change at a later date.
The typical terms are the ones I used — static and dynamic, runtime vs template database, etc.
Diku OLC still fits fairly neatly into this; the OLC is editing flat text files clearly designated in the code and in practice as the template database; playerfiles are saved elsewhere, and are persisted in the course of play. The perception of blurring comes from seeing players become admins, but that is not a small transition in a Diku; it unlocks a large array of new commands and capabilities.
Why? By using the word “patch” you are already acknowledging the difference. One does not “patch” dynamic data. One changes it. The word patch refers to applying a modifier on top of a static construct.
But yes, updates can be difficult to manage in a persistent world. The entire UO “rares” economy was born of attempting to fix some bugs in this manner. 🙂 Might make a good blog post… hmm.
I like to reference Newton’s laws of motion: a persistent world is one that continues as it is until some change is effected, and that changed world then continues as is until further changes are affected.
So much better than the daft definition as used in Massively’s post.