Sid Meier once said that a game is a series of meaningful choices. So, before a game is released to the public, the tester needs to make sure that all the choices in the game are meaningful and work correctly— or work at all!
Game mechanics can be defined as a set of rules that a game follows, and the mathematical model behind these rules. Together with level design and the player feedback system, these three pillars make up gameplay, which is what players base their impressions of a game on.
Bugs and mistakes show up in each of these stages, since a game is a multifaceted project worked on by several people (and when it comes to AAA projects, several dozen people). So it’s pretty easy to make a mistake in one of the components of the game.
Today we will touch on not only localization but also functional testing. Our expert and head of the testing department, Andrey Vasilyev, will help us.
To successfully identify bugs, you need to systemize them. Divide and conquer.
So, game bugs can be classified into the following categories:
Bugs related to the game itself:
- Functionality bugs. Some functions in the game don’t work or don’t work correctly. For example, the application crashes when you open the settings;
- Interface bugs. Graphics are distorted, elements are not in the correct places, the text does not fit into the space allotted;
- Localization bugs. Errors in texts, untranslated strings. For example, instead of the translation there are placeholders like “russian_text_001”;
- Performance bugs. The application runs slowly on a device. For example, during a character attack animation, FPS significantly decreases on high-end segment devices;
- Logic and balance bugs. The balance and game logic settings prevent the game from being completed or do not allow players to complete tasks. For example, a character deals 100 damage instead of the 150 promised in the game;
- Technical bugs. The game does not work correctly on an unstable Internet connection, for example, the application cannot connect to the server on 3G networks;
- Compatibility bugs. The game simply does not work on a compatible device or runs with critical errors.
Bugs are assigned a criticality rate—some are fixed with high priority, and some might even be left in the final release:
- maximum priority bugs are ones which clearly prevent the player from advancing, or affect the application’s money-making potential;
- medium priority bugs are visible to users, but do not affect the player’s progress or the application’s revenue;
- low priority bugs are almost invisible to players, show up rarely or only in very specific, limited conditions, and do not interfere with progress or revenue.
Bugs are differentiated based on the affected party. That is, whose usage of the product they will hinder the most:
- Bugs affecting users. These affect the popularity of the application and the average rating in app stores;
- Bugs affecting the business. These may not hinder users. For example, the game is too simple: players love this, but it doesn’t encourage them to invest their money into the game;
- Bugs affecting the development team. This is when a functionality is not implemented as it was conceived by the team, but users don’t notice (they aren’t aware of how it was conceived), and it doesn’t interfere with application revenue.
What determines the number of bugs in a game?
Seriously, what? Why do some games have an absolutely enormous amount of them even in alpha testing (looking at you, No Man’s Sky), while others have almost none? It’s pretty simple.
- First of all, it depends on the development team’s experience.
- The second most important factor is the project’s technical complexity. The chances of bugs appearing are directly proportional to the amount of code and the number of libraries used.
- The third is the number of possibilities in the game and the overall variety of gameplay.
- Network mode and the way players interact with each other is another serious item. For network mode, developers often do closed testing to adjust the balance and look for non-obvious bugs, even in games that have already been tested at the production stage.
- And of course, direct dependence on the effectiveness of testing at an early stage of development. The fact is that the more bugs that are found as soon as possible, the less likely it is that these bugs will later lead to the emergence of new ones.
Connecting the number of detected bugs to genres
In the risk group:
- RPGs with network mode. An expansive world, a lot of scenes where players interact with each other;
- Open world games. An immense amount of player behavior possibilities which need to be carefully tested;
- Any game with a strong graphical component. It is almost impossible to optimize a game equally for all devices, if we are not talking about console titles.
A good example of how players put the game under pressure. Skyrim is a record holder in this sense.
It’s relatively easier to test games where the player’s actions are limited—they can actually be thoroughly tested in the allotted testing time. This mainly includes casual games:
- Games in the match-3 genre. Here the player is limited by the playing field and combinations of pieces, bonuses, and the number of game mechanics;
- Games in the hidden object genre, where the player’s freedom is generally limited
- Fighting games;
- Casual games where the action takes place on one screen: time managers, clickers, shoot’em up, etc.
This is the classification of bugs from our point of view. While writing this article, we found an interesting video from Dmitry Khimion about testing game mechanics in computer games. He аdds one more classification of bugs in a game.
Level design bugs
There are points in a location that are inaccessible by the player. Getting stuck in textures fits in here. And it would be fair to note that we get stuck not in the texture, but in the geometric model, since a texture is just a picture. So, the level designer made a mistake somewhere and made unnecessary doorways and steps, then the hero’s leg got stuck and, trying to obey the laws of physics, starts doing the unimaginable
There is no sound or visual confirmation when the players perform actions, when the players do not receive full information about their actions, when they don’t understand who killed them or from where (there were no visual or sound references for this);
These include all errors related to control and direction elements. They can happen if calibration is incorrect and you cannot change the sensitivity of the mouse or analog sticks in the settings.
Game balance errors
Game balance is a qualitative characteristic that determines the balance of game components and values, and also supports interest in the game. The very creation of game balance is associated with constant testing, so a mistake here can be considered as just incomplete testing.
Some examples of poor balance could be a weapon so strong that it’s pointless to use any other, or a level design that allows you to gain an advantage at a certain point on the map without risk. In short, any miscalculations in the balance that make the gameplay uninteresting in the long term.
So, what bugs have you encountered? Tell us in the comments, let’s have a laugh.
If you are a developer and want to make less of these mistakes in your project, please contact us at [email protected], and we’ll figure something out together.
And in general, put your games in the hands of professional testers, and may you have less bugs in your finished products: not all of them will become legendary, like the famous “Geddan”: https://youtu.be/SP5c_MEs9mo