Sign in to follow this  
Sappharos

Patch installation during gameplay

Recommended Posts

Ok, so this is just a bit of theory, and I'm very far from actually implementing anything of the sort, but I'll put it forward anyway... When a popular MMO is updated, usually all the players are made to logout and download the latest patch before playing. This disrupts the gameplay, and might even be a bit confusing to new or very young players. Well I was wondering if it's possible to create a game which is actually updated while being played. A player would perhaps see an icon pop up near the map, saying "New regions released: Stonebury Forest and Rottenham Farm", or "Bugs in the gardening skill fixed", and be able to enjoy the new content immediately without even logging out and in again. Would it be possible for such a system to be implemented, perhaps through run-time libraries (if that's the right term)?

Share this post


Link to post
Share on other sites
Oh look, it's Tuesday... Someone missing their WoW fix?

Quote:
Well I was wondering if it's possible to create a game which is actually updated while being played.


SecondLife, Guild Wars, ....

WoW also does live hotfixes, but for simplicity reasons, some parts are not patched live. They could be, it's just not worth the effort.


But main reason for downtime is back-end administration. It's just much simpler to take the whole system down and perform everything off-line.

But yes, it's doable, it has been done very long time ago, it's just far from the most important issue, considering it complicates the technology involved, as well as the overall process, at very least, there are few established examples of such design, so there is little motivation to go down this route without any proven benefits.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Guild Wars, ....
Guild Wars tends to patch through game updates - I'm not aware of it ever patching live.
EDIT: Unless you mean that you don't have to have the latest game version to play (It just nags you to updaye every 4 seconds...)

I don't see there being any major problems so long as its just a data change, but if there's any executable code changes, doing live patches tends to be more hassle than its worth (And is likely to cause virus scanners to crap themselves).

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil SteveGuild Wars tends to patch through game updates - I'm not aware of it ever patching live.
EDIT: Unless you mean that you don't have to have the latest game version to play (It just nags you to updaye every 4 seconds...)


Same as WoW, parts are updated live, such as various events.

There was an article published on their back-end, in which they claimed their object caches have uptime of over a year or so. So even if something is patched, you just log out and back in. The actual back-end doesn't get taken down completely.

GW uses interesting approach in that instances are actually versioned state. If something is updated, the server remains alive, but when you log in (probably change zones if no client patch was required), you get put into latest instance. Once all players leave an instance, it is "garbage collected", so old version slowly goes away.

It's very similar to Java's ClassLoader context which accomplishes the same purpose. When you deploy a new class, it gets instantiated in new context, and consequently instantiates the new state, including globals. The old state will remain alive until it gets garbage collected. It's not entirely as simple, but that is the basic idea behind it. It's useful for servers. Debugging also allowed hot-patching the code for quite a while now.

But at the end of the day, is it really needed or desirable? Java servers which had this concepts for many years now relied on lazy instantiation of some external state proxies (databases, file system), which outlives versions. But with large, mutable shared state, applying new version isn't trivial. Assume that a variable (or column, file, ...) gets removed - how do you handle transition from old state to new in transparent manner without establishing some checkpoint for all that have access to it.

Or how do you handle long-running transactions without always keeping them persisted externally - and if so, how do you update the transaction code without shutting down the service?

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
I don't see there being any major problems so long as its just a data change, but if there's any executable code changes, doing live patches tends to be more hassle than its worth (And is likely to cause virus scanners to crap themselves).


Fair enough. Changes to, for example, the collision detection code while collision tests are being performed might be kinda lethal.

Would antivirus software really complain if all actions (downloading, installing and executing the patch) were performed by the client, rather than by an unrecognised (external) program?

EDIT:
Quote:
Original post by Antheus
There was an article published on their back-end, in which they claimed their object caches have uptime of over a year or so.


Could you post a link to that article please? Sounds interesting. :) Don't bother if it's hard to find, though.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sappharos
Fair enough. Changes to, for example, the collision detection code while collision tests are being performed might be kinda lethal.
Well, client-side collision detection won't be an issue - the game will have stopped while it's patching, and server side I'd imagine it'd be the same.

Quote:
Original post by Sappharos
Would antivirus software really complain if all actions (downloading, installing and executing the patch) were performed by the client, rather than by an unrecognised (external) program?
The issue is if the program needs to modify its own code - self modifying code is used by some viruses to hide themselfs or to mutate to hide from virus scanners, and as such, virus scanners are likely to take notice of apps doing that and alert the user.

Another option would be to have the client EXE handle the network code, and a DLL deal with the game code - then you could download a new game DLL, unload and reload it (Assuming the EXE does runtime linking to the DLL), and carry on with the new game code as if nothing happened.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sappharos

Would antivirus software really complain if all actions (downloading, installing and executing the patch) were performed by the client, rather than by an unrecognised (external) program?


No, it would work like browser. You have a generic, content-independent client. You can view web pages with 5-10 year old browsers today. It would work in the same way, there is no distinction between gameplay and update anymore. Whenever you connect, your client somehow obtains the latest state, including UI, rendering software, etc...

Quote:
Could you post a link to that article please? Sounds interesting. :) Don't bother if it's hard to find, though.


Here and here.

Share this post


Link to post
Share on other sites
Didn't A Tale In The Desert also pride itself on live updates? I seem to recall a mechanic where players could create petitions for changes to game rules and mechanics, and when passed through the democratic system, the developers would implement it "live."

The main problem comes with object versioning: If some logic needs a particular property on an object, and the property is not there, sometimes just assuming a default value won't work right.

Also, as a practical matter, you can't generally re-write DLLs or EXEs while they are loaded into a process, and have those changes take effect in the current process. You can do that with scripts, though depending on how extensive the changes are, any currently running script code may suddenly find itself running in an unexpected environment, and either change things it shouldn't, or simply throw exceptions. Some kind of stop-to-patch is pretty much necessary, else there's no way you can reliably test all possible update cases.

Share this post


Link to post
Share on other sites
If starting up the client is fast, you can just shutdown the client executable, apply the update and restart it (assuming you "remember" your session information on the server). That way an update of client code would result in the screen going blank for a few seconds and then coming back with the "new" version.

It all comes down to exactly what is being updated, of course. If your session management code is being updated, it might not be possible to remember the session between updates. In which case, a log off-log on cycle would be required.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Didn't A Tale In The Desert also pride itself on live updates? I seem to recall a mechanic where players could create petitions for changes to game rules and mechanics, and when passed through the democratic system, the developers would implement it "live."

Yup, I can confirm ATITD does live updates. I don't know the mechanism though.

I imagine there would have to be some mechanism to park any threads (whether native or script) so that you can be sure they don't access anything while it's being updated, then swap in the new stuff, and let everything go again. Like hplus mentioned, keep track of object versioning sounds hard.

Share this post


Link to post
Share on other sites
Depends on interdependencies between different parts of code.

If the change is a new server action which requires a corresponding new client
complement action you cannott update both simultaneously (and thus have to disconnect, have patches done both sides and have everything restarted).

If the client rendering (for example) looks different with changes to code but responds the same way as the old code then it doesnt matter which old/new code the client executes (the client can be updated at convienence -- like slow in background). Similarly changes to game mechanics that dont effect the clients operation can be made unilaterally.

You could have a system which has parallel different processing happening
depending on if the client is in 'new' mode or still in 'old' mode (not yet patched) -- most actions in MMORPG are not fixed in their results and the player likely wouldnt detect small shifts. Some players havent yet patched (still waiting for a .exe or dll to finish downloading before instantly switching to the 'new' mode' -- til then it isnt really significant to game operations.

Server would run both old and new for a while and players clients are upgraded
'on the fly' as soon as their background download finishes (you might even get away with a quick restart with minimal down time if you cannot do it seamlessly.

Patches to content in areas the player isnt in can be done in background -- only forcing a shutdown/delay if the player enters a changed area as it is still transitioning (without data cohesion -- changes halfway thru)







There have been discussions here about similar solutions to do things like daily security patches to games where players cheat alot (bots etc...) and having the protocols/encoding for the action/result interplay between server and client change on a daily basis (faster than hackers can fix/distribute hacked clients) or even having each client have a custom protocol which could change 'on the fly' (require th server to modularize to use several flavor schemes at once).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this