Android device debugging is the most important part for any Android game development process. Let's divide this topic into two sections:
- Device testing
- Device debugging
The main challenge for a game developer is to run the game on a large number of different devices. These different devices include different displays, different resolutions, different Android operating system versions, different processors, and different memory capacities. Due to these reasons, Android device testing is important and has to be carried out with great effort and planning.
Normally, in a game development cycle, first-point testing is carried out by the developer. This process makes sure that the game is running on devices.
Then, the tester or a group of testers test the game on different devices from various aspects. This is the main part of device testing.
Generally, the main testing phases are divided into four parts according to game development stages:
- Prototype test
- Full or complete test
- Regression test
- Release test or run test
In other words, a similar kind of distribution in each category is termed as follows:
- Pre-alpha test
- Alpha test
- Beta test
- Release candidate test
There are many other testing procedures that may follow typical software testing. However, in game development, usually, these approaches are followed. Let's describe these stages in brief.
The developer and designer together develop a playable stage of the basic game idea with an initial set of game rules. These rules and gameplay are tested during the phase of prototype testing.
Ideally, core gameplay is tested in this phase to analyze the feasibility, potential, and scope for the game concept.
Prototype testing is probably the most important part of the game development process. This phase determines the future of the game concept and also helps in developing a meta game and monetization model for the concept.
Usually, whenever the first few builds are submitted to testing in each phase, full testing is conducted. This reveals each and every possible issue with the game, including crashing, freezing, visual issues, playability, game rules, and design faults.
Most of the issues are usually reported during this phase, which eventually implies the possible completion time and effort for that game build.
Regression testing comes after full testing. Developers, designers, and producers take a call on each and every issue reported during full test. They select issues for resolving, and after the issues are resolved, they are submitted back to the testing team for regression test.
In regression testing, a tester usually picks the issue and specifically checks whether it is actually solved or not. If the issue occurs in a fixed build, then the testers reopen the issue for the next regression cycle. This cycle continues until all the reported issues are addressed.
This is probably the most mechanical testing phase of game testing. In this phase, the tester runs the regression test passed builds on various target devices, just to check whether the game is running on that hardware or not. This is the reason this phase is often called a "run test".
As many physical devices as possible are used for this segment of testing for a compatibility check. The final device support list is created after this testing phase. It is almost impossible to arrange all the available devices and perform a run test on them. So, the developer groups the devices according to their configuration and performance. Devices that behave in a similar manner are put in the same category, and only one or two devices are actually arranged for run testing for the whole group.
We have already seen that device testing is mainly the job of a tester. Now, we will see that device debugging is basically the job of a developer. However, commonly, it is done by both developers and testers.
In the game industry, device debugging is mainly used to find out runtime crashes, freezes, memory issues, networking issues, and performance issues. Through device debugging, the developer gathers the following information:
- Runtime maximum heap consumption
- Average FPS on various devices or multiple set of devices
- Unnecessary loaded objects
- Hardware button behavior
- Network request and response
Breakpoints are very useful and handy in the case of device debugging. The game thread is paused at breakpoint, and the state info can be achieved through DDMS. Game programming is mostly about customized algorithms, which might produce some unusual behavior during runtime. Breakpoints come handy in this situation. The developer can debug the logic line by line after a breakpoint so that the root cause of the behavior is found and fixed.