Hey guys, decided to bring you all a new guide written by yours truly.
This guide will especially be of interest to you if you happen to somehow be involved in running an MMO (massively multiplayer online game).
Please note, that while I have some basic understanding of how coding works, I do not know any code languages, and I can't really give any tips in that regard, so this guide will adress what should be done once the intial patch coding has been done.
Anyway, let's get started without further ado.
2. The guide
Well, it's done, so just get it out there, right? wrong. There are several steps to consider first.
2.1 Internal testing
Now what the heck does that mean? Internal testing? Does this mean showing something up someone's behind? No, don't worry. It simply means that you test your new patch internally in your company. This internal testing is usually carried out by a department called QA - Quality Assurance (from wikipedia: Quality assurance (QA) is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers; which ISO 9000 defines as "part of quality management focused on providing confidence that quality requirements will be fulfilled".). Employees working with internal testing are often called QA testers.
To boil this down: first step is to let some employees mess around with the patch on an internal server, to see if they can spot any errors.
Now, internal test enviroments are very different from the live enviroment, so it can be hard to catch everything. Hence, why you will often have a:
2.2 Public Test realmHappy Lemon? (and beta)
Next comes the PTR (Public Test Realm) - not all games have this, but many do. But what does it mean? Public??? Test??? One can get a migraine just from trying to figure this out - worry not, I will swiftly bring you the answers and save you any worries.
Public means that the server is available to everyone (the public). It's hard to figure out at first, but if you give it a minute to sink in, it starts making (somewhat) sense.
Test means... Well, this one is a bit harder. Test means something with sitting in a room with pen and paper with loads of other people, trying to figure out some more or less complex task right? Well, not in this case... It means to test (try) something out - in this case a patch.
So basically it's like QA testing (see above) except that this time it's the public that test your patch for you - which means that it's closer to a live enviroment, with a much larger amount of testers. Cool huh?
Some games will also have "beta" servers. This does not mean that the server is timid, and afraid of alpha-servers. It's a server used to test (generally) larger updates to the game, that make serious adjustments to gameplay. But well, if you have one of these, you might as well roll out any smaller patches here first, and see if it works out.
Well, that's a lot of testing... But what if the tests show that something is messed up?
2.3 Initial bug fixing (re-writing the patch)
It's time to put those coders to work again. Something got borked in the first code-version of the patch, and they need to find those mistakes. Luckily, the extensive testing by both the QA testers and the users have caught the bugs, and it's now a question of figuring out what parts of the code causes these issues. Again, I do not have extensive knowledge of coding, so I will not write more on how this is done.
Right, so your coders have done their job, and all is good now, yes? No - we repeat the above steps again, this time with the re-written patch - it goes through both internal and public testing again. This is done until no major bugs are found (some minor ones can be left in, if they are practically unoticeable and can be fixed whenever a new patch is being worked on).
Now we start getting closer to the
2.4 Full patch implementation on the live servers
Phew, that was a lot of testing. Now it's just rolling out the patch for all servers right? Well... You can do that - or, if you want to be a tad bit safer, and piss off as few custommers as possible, you can implement the patch only on some live servers. Maybe your servers are divided into regions? Something like "domains" or something? Well, you could always schedule the patch for some domain(s) first, and then for the rest later. If any issues occur with the first implementation, the global implementation of the patch can be put on hold, so only a smaller sub-section of the playerbase will experience issues, and you can re-write the code before implementing it, meaning that less users will experience the bugs.
But what if we'd rather roll the patch out globally all at once, and keep all servers on the same patch? Or if the issues don't show up until rolled out everywhere? Well, you can either take your time and prepare a new patch, if the issues aren't too severe, or you can implement a
Hotfixes are meant to deal with severe bugs that majorily disrupt gameplay or user experience - things that should be fixed sooner, rather than later, and thus might be better to fix asap, rather than roll them out with a whole bunch of other stuff in future patches. This means that hotfixing only aims at dealing with specific (severe) bugs, and nothing else.
That's it for this guide. With this guide in hand, you should have at least a basic understanding of how to implement patches for your game. Thanks for taking the time to read this guide, please leave any feedback below.
Please feel very free to share this guide with anyone you know, especially if they by chance happen to work in Munich, Germany.