Patch installation during gameplay
Author
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)?
Oh look, it's Tuesday... Someone missing their WoW fix?
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.
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.
Quote:Original post by AntheusGuild Wars tends to patch through game updates - I'm not aware of it ever patching live.
Guild Wars, ....
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).
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?
Author
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.
Quote:Original post by SappharosWell, 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.
Fair enough. Changes to, for example, the collision detection code while collision tests are being performed might be kinda lethal.
Quote:Original post by SappharosThe 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.
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?
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
