Congratulations! We have completed the game development. Together, we created a space game, which tasks the player with avoiding the oncoming asteroids using touch. This chapter won't add anything to the game in particular but will show you some of the common pitfalls you will most likely face when developing games using Cocos2d-x and how to overcome them.
We will cover the following topics in this chapter:
- Common issues when developing games using Cocos2d-x
- Overcoming the issues
- What to do with the skills acquired through the course of the book
This section will cover some of the issues that may plague a Cocos2d-x project; it will also cover the methods to overcome them.
A new project, by default, has the debug information situated in the bottom-left corner of the screen; this information should be disabled before publishing a game. However, it is still important, so it should only be disabled once the game development is complete.
The following is what the debug information looks like:
To remove the debug information, use the following steps:
- Open
AppDelegate.cpp. - Change the line
director->setDisplayStats(true);todirector->setDisplayStats(false);, as shown in the following screenshot:
There are several devices the user can use; therefore, developing for a single device isn't a practical route, as it would alienate many potential users, thus reducing revenue. The main problem to avoid is developing using magic numbers (arbitrary values within the code). For example, for positioning, use relative positioning instead; this will be dynamic.
Let's look at an example. A background needs to be added to a scene and should be centered. The developer might be using an iPhone in landscape mode with a resolution of 480 x 320 pixels; in this case, the developer could set the background position to (240, 160). This will work well on their device but not on iPhone Retina, iPad, or most Android devices. Instead, the best method would be to position the background at (screenSize.width / 2, screenSize.height / 2). Using this method, the background will be positioned well on all devices. A similar system should be used for all assets.
When moving objects on different devices, there can be speed differences; this can be due to two main problems:
- Frame rate: This problem arises when more powerful devices can run the game at higher frame rates. This can be overcome by factoring in delta time using an
update()function, as we did when scrolling the game's background. - Screen size: Different screen sizes can cause issues as a moving object could take longer to move on an iPad Retina compared to an iPad. This can be overcome by factoring in the screen resolution; width or height can be used, but it's important to be consistent. This was demonstrated earlier in the book when scrolling the background.
When generating new projects, several issues can arise; one of the main causes is that the setup wasn't successful. Confirm that all the environment variables have been added by running the setup.py command again.
If you try and reuse actions on a node, the game will crash. The only way to overcome this is to create a new action or clone an action (you need to autorelease it for Cocos2d-x 2.x.x) for each instance instead of trying to reuse it.
When running several actions, you might want them to run one after another, that is, when the previous one has finished running. If multiple actions are run using the runAction method on a node, they will start as soon as they are called. However, to run them one after another, the sequence action should be run; this has already been covered in this book.
A general rule of thumb is to not run applications on Android simulators as they are terrible; run them on an actual device. For iOS, the simulators are a lot better but still not as good as a real device, so you should run the application on a real device if applicable. This is due to certain features such as motion missing from a simulator and simulators having poor performance. A very good alternative to the Android simulator is BlueStacks, which is free.
Many users think that because the generated application's folder is over 200 MB, the size of their application will also be 200 MB; it won't as there is all the extra stuff. An easy way to find it out is to build the project and check the application's size. However, this doesn't mean you shouldn't try and reduce the application size. Use the following tips to reduce the application's size:
- Use sprite sheets instead of separate images
- Reduce image size, as high-resolution assets aren't always required for mobile devices
- Make sure that all the unnecessary files are removed, including duplicates
- Try to avoid big images if they are not needed (images above 1024 x 1024 pixels resolution are not good for cross-platform games)