[MMO] Updating/patching game servers

Started by
7 comments, last by Palidine 16 years, 1 month ago
When you have new data... do games normally get taken down before updating the DB, or do they tend to be able to cope with new data (like quests & items) while running? The project I'm on caches a ton of frequently used data in memory, which means any updates to static DB data at runtime would require functionality to detect and respond to this. In my mind, during beta phase at least, it is quite acceptable to go offline for an hour a couple or three times a week since the game is changing so fast. But once the game is stable, new data is often added so how do players expect this to work?
Advertisement
I'm not aware of any MMO that could make any changes to either code or static data while the server is running. Dynamic data, such as certain objects or scripts may be slightly modified - but nothing that changes structure.

The problem has a lot to do with integrity - let's say you change a quest giver, and change the items it handles.

How will you transition all people who are currently engaged in this quest?

Or let's say you change an attribute of very base object. You need to propagate this through entire cluster and entire database, possibly billions of entries - during real-time, or risk nasty bugs.


There's a term: "Patch Tuesday". That's when servers go down, they push new patches, administrate the database, clean-up, update hardware/software, etc.

Patching code during live is possible - that's what enterprise application servers are capable of. But they require capable architecture and platform that supports that.
OK, so to summarise: it's entirely normal to have regular (scheduled) downtime. Cool.
I would say "it depends". The ideal is to keep your server up, but you simply have to balance that against the costs of being able to do so. It easy to take the server down, upgrade things, and then only let people reconnect once they've patched up to the version that matches the server. Implicit in this is a process that can identify whether a change requires client-side data or not, and whether that needs to be stored on the client before use or not. It may be the case that you can get a long way with a default placeholder asset and have the game patch itself in the background, swapping the asset once it's downloaded.
I've been designing my server to never have to go down for content updates like texture/world changes. It takes a lot more code and I would say that it's easier not to. Really have to design it from the start to be able to handle this though.
Quote:I'm not aware of any MMO that could make any changes to either code or static data while the server is running.


For There.com, our "world editor" can edit the live world, which obviously means there's no downtime. It is, however, not standard practice, as you can't do QA in that sense.

For our newere OLIVE technology, we made our file system abstraction re-deliver data if a file changes on disk, and the asset system transparently replaces assets in RAM when the file data gets re-delivered. It's pretty cool -- edit a texture, save it, and you immediately see it in-world. We also have live re-invalidation of data from server to client. We don't yet have the step where we automatically replace the files on the server, though -- that's a manual process.

It turns out that, if you're writing your own file system abstraction and asset system anyway, doing it "live" without requiring reload can be designed in from the start. You just have to want to do it. If you don't design it in from the start, going back later is very hard.

And, yes, things like "scene layout xml files" or "environment scripts" are also assets, and update live, on change.
enum Bool { True, False, FileNotFound };
I seem to recall that A Tale in the Desert was able to make many changes on the fly.

I think it depends on the nature of the change. If you're just adding stuff it should be relatively easy to do it dynamically. If you're making changes to existing things that people might currently have state against this you might want to take things down.
-Mike
Quote:Original post by hplus0603
Quote:I'm not aware of any MMO that could make any changes to either code or static data while the server is running.


For There.com, our "world editor" can edit the live world, which obviously means there's no downtime. It is, however, not standard practice, as you can't do QA in that sense.


Games that I have seen with live editors tend to take advantage of the live editor on a "build" server (basically a server set aside for developers to just build content and test it), allowing multiple people to work in the same area without having to expose it to the public before testing. This approach has seemed to be one of the best that I have seen.

Quote:Original post by hplus0603
It's pretty cool -- edit a texture, save it, and you immediately see it in-world.


Very nice! :D

Quote:Original post by d000hg
OK, so to summarise: it's entirely normal to have regular (scheduled) downtime. Cool.


Normal? Yes. Desirable? Not especially. I think people get more irritated with just getting kicked off more than they do with waiting to get back on when it comes to scheduled downtime. But people who like the game will most likely just put up with it unless it becomes pretty bad. MMO players are used to being treated a certain way and even though they always complain about it, they still play. ;)
NetGore - Open source multiplayer RPG engine
GuildWars updates live... kinda. What they do is this:

If you're playing and an update happens your client alerts you and allows you to update at your leisure.

They stamp the build numbers and close out a couple servers; when a server is closed, no new instances spawn there and no new players can enter zones hosted by that server. When the closed server is empty (happens over time), the server is taken offline and updated.

People on the new build go to updated servers. People on the old build continue to play until they want to update.

It's a very graceful process that ensures no one is ever interrupted by a build push.

-me

This topic is closed to new replies.

Advertisement