1. When an issue is reported, the first thing to helping the team find the issue is to try and reproduce it, and gather logs to track it down. The closest thing I can think of to this process is losing your car keys in your house and having someone move them to a location they don’t remember. You try to retrace your steps, and find out any information you can on who moved it, in order to help you find it sooner.
If you’re experienced with the game code, you know the house. If not, then it’s like staying at a relative’s place; it’s even more difficult, but you get the general idea of how the house is laid out. Sometimes the code was changed by another programmer that was working on that section, so you may have to dig a little, and track that person down to understand the changes they did. Etc.
- i. Sometimes these issues aren’t seen in a QA environment for some reason, or they can’t be reproduced on a debug build, so the developer must review a crash log taken from the live build (or whatever information they can get to try and figure out what is causing it).
2. Depending on the issue, there would need to be a code change, which requires a full release to update. This is usually the case for the majority of issues. Sometimes a patch can be pushed to adjust something and address an issue, but typically a full build will have to be created.
There are two parts to a live mobile game like Marvel Puzzle Quest or Magic the Gathering Puzzle Quest: Data patches, and Server patches. Patches that do not require a full submission to first party can fix things like text, and sometimes art. Sometimes code level fixes can be done, but there are times when a code change could bring live build down. When this happens, it halts all work outside of the live game (new features, new content, bug fixes, etc) to a grinding halt, as everyone that is able to jumps in to help.
3. When a major issue is found, we usually look to roll the fix into the next release, because the next release is already being worked on. It’s less efficient to stop all work on it just to replicate the current live environment, fix the issue, release a fix, then finally set the next version back up for everyone to work on it again. Depending on the issue and its severity, we may be able to release the next update sooner than planned, but that’s not very often.
4. Once the new build has reached gold master candidate, we then have to submit it to various first party groups for approval, either at the end or near the end of the final acceptance tests, to make sure the project is ready. Each of the first party groups’ review processes usually take a few days, so we have to submit at least one and a half times the review duration. The reason we do this is to give ourselves room to adjust in case the build fails, and we need to re-submit a new one before our intended release date.
- i. We do our best to cover a variety of devices and saves, but we do end up adding new scenarios to our test-case list quite regularly.
5. Once the update day is upon us, we release the build for players to download. We give players a day or two to do this before we have to force the update, so players do not experience any bugs with the latency of being on an older build.
