Bugs Fixing During Game Pre-Release Stage
Unfortunately, games can often disappoint. People are waiting for some game to be released, pre-order it, modify their gaming hardware, plan vacations to play the game, etc. And when the game is finally released, it turns out that it’s full of bugs and unsatisfying mechanics. Players are raging and developers delete hundreds of angry comments on forums. How could that happen? How do publishers allow games of this quality to get published?
A simple and most logical answer would be: because of high competition and booked release slots on various platforms.
And here’s how it happens for real.
It always seems like developers have a lot of time during the early development stages: the release date is so far from today.
But, obviously, days go by and the release date starts pressuring more and more.
Plus it’s a common situation when developers get creative ideas in the middle of the development. There may be many ideas and also changes in priorities. The Agile development process means it’s possible to implement unplanned features and mechanics, and companies often do that, which is not bad at all.
Nevertheless, unplanned mechanics always bring a lot of new bugs, both minor and more serious. Developers put them in a backlog. “We’ll fix it later” is one of the scariest things you could hear while creating a game.
Games take months and years to be developed, especially big ones. The development process may be followed by a lot of closed beta tests and iterational work with feedback from the narrow field of gamers.
It often happens that the release date is being moved multiple times and the company decides to publish at least something playable without properly removing bugs from game during pre-release. Companies hope that fast hotfix patches fix the discovered issues and bring fans' love back. This is the moment when companies set priorities of what can and can’t be displayed publicly. Almost always the development team will have a backlog with hundreds of issues.
This is the moment where the QA team is super important. Their main goal is to help with prioritizing: what should be fixed immediately, and what can be done later. Usually, the first priority goes to performance, stability-related, and platform-related issues. That’s why low priority bugs may stay in the backlog for years. The QA team concentrates on finding and detecting those issues. A more complex game means potentially more need in fixing a bug in video game pre-release.
Another frequent issue is the absence of negative testing. While the main priority is making the game playable and finishable, it doesn’t seem too necessary to spend resources on breaking the game’s functionality on purpose to fix the video game errors in pre-release stage.
As a result, we get a lot of bugs, related to non-standard and unexpected cases. Because we have not been looking for such cases on purpose. And players often find these kinds of bugs when the game is released. Sometimes it breaks the game completely, causing refunds and negative reviews.
Due to all of that, developers often release the unfinished version of the game and call it “GameName BETA”. In this case, fixing bugs in game pre-release is less crucial. Some games stay in beta mode for years, like Dota 2 by Valve did or Realm Royale by Heroic Leap still does (by the time this article is being written). This is a good approach in terms of budgets and human resources. It also helps to get some fresh eye on a game, because hired testers often get tired of playing the same game for months and may miss some details with no purpose.
The beta testing approach becomes more and more accepted by gamers through the years. Players could accept the rough game in exchange for the ability to get the game sooner and feeling themselves involved in the development process. Developers get more time to polish the game and fix video game bugs during pre-release, as well as a lot of quality feedback on support emails and forums.
OK, let’s imagine a perfect situation. We are not concerned about the deadlines and we can plan the testing process calmly, fix all the detected issues, and release the product of truly high quality. To do so, we need to plan testing for every stage of the game’s lifecycle.
Imagine things going well and the release date is a couple of months away. All the main functionality works well, all the major features are already implemented and we don\t expect anything new. That’s the perfect moment for a testing team to start breaking the game in order to see how the game operates during non-standard game cases and on the most unexpected device configurations.
To succeed, we need access to detailed project documentation. The development team should support and update the documentation all project long, including all the updates and new features. And it’s not just about the game: if there’s a new generation of devices or new versions of software appearing on the market during the development of your game, it should be mentioned in the documentation. This kind of change may require additional checks and edits, but it will ease the bug fixing in pre-release game development process.
For example, if a new generation of consoles is released during your development, your game should run on it. Your game should be working on a new console at least in backward compatibility mode, and reflect all the namings and icons to correspond with the new UI and gamepad.
That’s a very common case. Ignoring it awards you with a great chance of failing the TRC certification and moving the release date. The development team should have a clear understanding of what should be done in a pre-release stage and what should never be missed.
Game development companies and publishers often seek help from third-party companies for hire in order to prevent crunches, ineffective resource-wasting, and moving release dates.
The outsourcing company should be able to estimate the state of the project and localize the problematic places, often lost in the depth of backlogged tasks. Teams like that usually specialize in a pretty narrow scope of potential bugs, but this is good in terms of delivery.
Companies often hire multiple teams and work in multiple iterations. The results of working from various independent teams may provide a lot of test results. Comparing them helps to prioritize the attention-worth issues and plan the steps of debugging in game pre-release.
But still, never underestimate the human factor. If a QA team completed testing and found nothing, it doesn’t mean that your release is guaranteed. We know of a case when 4 QA teams from various parts of the world worked on the project, but the eventual build was still full of bugs and failed a TRC certification multiple times, which caused the movement of the release date.
Our main message is the following: lock adding the new functionality as soon as possible, and start testing as early as possible. Test a lot, test properly, test according to the plan. Then polish, and repeat.
Choosing the Bet-test mode option is also a decent choice. But there’s a great chance that an unfinished game doesn’t get enough player’s attention for you to collect the necessary feedback and win time to provide a proper release. That’s definitely a solution not for everyone.
In case you need professional assistance in your pre-release bug fixing, Contact Us and let us lead your game to release!