Development of OpenGL games for the Android platform
Some time ago, I finished porting the game iDracula - Undead Awakening, which was developed by Moregames Entertainment from the iPhone platform, to the Android platform.
I am ready to share with you my thoughts and problems that I have encountered.
I want to warn that I worked much more with the Android platform (based on the specifics of the task :), but I also have experience in developing smaller games for the iPhone platform. I also developed games for the iPhone on cpp, not ObjectC.
A complex topic, given the difference in languages and operating systems. Therefore, briefly and IMHO.
unfortunately, in my opinion, xCode can hardly be called a modern IDE, especially when you have to work hard and refactor other people's code. In this regard, the advantage of IntelliJ IDEA, or Eclipse (there is a plug-in for Android development under both IDEs) is felt very strongly. In some cases, it was easier for me to transfer the code as it is, and then already do a certain refactoring of the code already in the java version. Debugging under xCode also requires much more skill and knowledge of a certain specificity. The disadvantages of the Android platform tools include some instability of plug-ins (especially eclipse) - they periodically forget adb.exe in memory, which makes profiling through DDMS impossible. It is necessary to observe a clear order, first ddms was launched, then we are already debugging. A significant disadvantage is the emulator’s heaviness - it takes a long time to start, works slowly. At 35 fps on the device, I have 15 fsd on the emulator on my MacBook Pro, and even less in debug mode, which makes it impossible to fully test many things. Simulator for iPhone starts almost instantly, and is not inferior in speed to the device.
The only problem I encountered when developing for iphone was the lack of ogg support. The problem was solved by simply porting the appropriate library.
Unfortunately, the Android SDK is not so simple.
The most serious problem is memory leaks when using the OpenGL glXXXPointer functions. In fact, for every function call we have a memory leak of sizes in the array that we install. Those. what do not do when using these functions, sooner or later we will receive a call to gc, and this is from 200 to 1500 ms lag. Here there have details. Also, the cost of calling glXXXPointer functions is much higher, which is what is expected.
The high cost of processing a touchscreen - i.e. stupidly you have 50 fps, put your finger on the screen you have 30 fps. For MotionEvents multiply and load the system. The decision to do sleep after receiving MotionEvent does not completely solve the problem.
Lack of multitouch support. Moreover, at the SDK level, i.e. even if you have firmware that supports multitouch, or HTC Hero which also has multitouch support, you cannot currently use it in your application.
Unfortunately, at the moment we have quite different devices. The main problems are related to HTC Dream (G1). The G1 has a much worse trackball sensitivity compared to Magic and Hero. Where the player will play comfortably using the trackball on Magic, he may have problems on Dream.
There are problems receiving data from position sensors when music is on. If you are playing a music track with a volume of 0.5 from the maximum, then even when stationary, you will receive chatter of sensors from -40 to +40 from the possible range from -90 to +90 (-180 / + 180). In fact, with such bounce it is not possible to use position sensors to control the game. Only when the volume is reduced to 0.2 from the maximum, the bounce decreases to the range of -4 / + 4, which is already acceptable.
G1 also has problems with a small amount of memory, they are compounded by the fact that widgets that the user places on his desktop can consume my memory (up to 15 megabytes), but it is not obvious to the user that they are running programs. Therefore, you can receive different reviews from users with the same devices. From “wow the game flies” to “it is impossible to play, only lags” (see paragraph above on memorials).
Problems with G1 with a small amount of space for installing programs, on average on a zero system the user has about 30 megabytes. After installing the application less. If the application is large (the full version of iDracula takes 13 megabytes), then there may be problems with the installation. I will write below in more detail.
Unfortunately, the Android Market loses the AppStore in all respects.
At the moment, there is no way to specify the devices for which your application is developed on the market.
Those. if your application needs a hardware keyboard, or multi-touch (when it is introduced), then the application will be visible to device owners without these options and you will receive a negative rating from them.
Problems installing large applications. As early as five years on all cell phones when installing the application, the user, after downloading the application in case of lack of installation space, in addition to the warning receives a dialog with the ability to delete the current applications and battle to continue the installation. On android, he is forced to call a lot of menus for this action. Moreover, if your application takes up 10 megabytes, then it requires a minimum of 20 megabytes to install (the downloaded file, and space for installation).
One solution is to install the application without resources, and downloading the resources by the application itself and saving them to a USB flash drive.
I would like to see this as a standard feature of the SDK - the ability to mark part of files for placement on a USB flash drive.
Also, there is really not enough opportunity to get, in addition to the recall (for example, about the crash of the application), information about the device on which the user leaves a review, and ideally the log of the application as it is done in iphone.
There is not enough Entertaiment section - games are forced to compete in tops with applications like “Beautiful fire on your screen”.
Well, the lack of screenshots leads to the fact that the game is mostly chosen based on the name (as you know, no one reads the description), such a problem was, by the way, on the BREW market. Plus there is still a limit on the size of the description.
To summarize, you need to develop applications up to 3 megabytes in size, using, preferably, no more than 15 megabytes of memory and make a margin for brakes when working with a touchscreen.
Initially, there was a desire to write a more structured review and devote more time to the iphone, but I feel like this article would have lain in the draft for another month. I hope the folded will be useful in this form. I am ready to answer questions in the comments.
PS If you have a ready-made game for iphone or another mobile platform and you want its port for Android with the condition of shared revenu or fixed payment, then I will be happy to talk with you. :) For example on skype - youngskipper. I’m also ready to chat with other developers - to discuss the platform.
I am ready to share with you my thoughts and problems that I have encountered.
I want to warn that I worked much more with the Android platform (based on the specifics of the task :), but I also have experience in developing smaller games for the iPhone platform. I also developed games for the iPhone on cpp, not ObjectC.
Development Environment and Tools
A complex topic, given the difference in languages and operating systems. Therefore, briefly and IMHO.
unfortunately, in my opinion, xCode can hardly be called a modern IDE, especially when you have to work hard and refactor other people's code. In this regard, the advantage of IntelliJ IDEA, or Eclipse (there is a plug-in for Android development under both IDEs) is felt very strongly. In some cases, it was easier for me to transfer the code as it is, and then already do a certain refactoring of the code already in the java version. Debugging under xCode also requires much more skill and knowledge of a certain specificity. The disadvantages of the Android platform tools include some instability of plug-ins (especially eclipse) - they periodically forget adb.exe in memory, which makes profiling through DDMS impossible. It is necessary to observe a clear order, first ddms was launched, then we are already debugging. A significant disadvantage is the emulator’s heaviness - it takes a long time to start, works slowly. At 35 fps on the device, I have 15 fsd on the emulator on my MacBook Pro, and even less in debug mode, which makes it impossible to fully test many things. Simulator for iPhone starts almost instantly, and is not inferior in speed to the device.
SDK
The only problem I encountered when developing for iphone was the lack of ogg support. The problem was solved by simply porting the appropriate library.
Unfortunately, the Android SDK is not so simple.
The most serious problem is memory leaks when using the OpenGL glXXXPointer functions. In fact, for every function call we have a memory leak of sizes in the array that we install. Those. what do not do when using these functions, sooner or later we will receive a call to gc, and this is from 200 to 1500 ms lag. Here there have details. Also, the cost of calling glXXXPointer functions is much higher, which is what is expected.
The high cost of processing a touchscreen - i.e. stupidly you have 50 fps, put your finger on the screen you have 30 fps. For MotionEvents multiply and load the system. The decision to do sleep after receiving MotionEvent does not completely solve the problem.
Lack of multitouch support. Moreover, at the SDK level, i.e. even if you have firmware that supports multitouch, or HTC Hero which also has multitouch support, you cannot currently use it in your application.
Devices
Unfortunately, at the moment we have quite different devices. The main problems are related to HTC Dream (G1). The G1 has a much worse trackball sensitivity compared to Magic and Hero. Where the player will play comfortably using the trackball on Magic, he may have problems on Dream.
There are problems receiving data from position sensors when music is on. If you are playing a music track with a volume of 0.5 from the maximum, then even when stationary, you will receive chatter of sensors from -40 to +40 from the possible range from -90 to +90 (-180 / + 180). In fact, with such bounce it is not possible to use position sensors to control the game. Only when the volume is reduced to 0.2 from the maximum, the bounce decreases to the range of -4 / + 4, which is already acceptable.
G1 also has problems with a small amount of memory, they are compounded by the fact that widgets that the user places on his desktop can consume my memory (up to 15 megabytes), but it is not obvious to the user that they are running programs. Therefore, you can receive different reviews from users with the same devices. From “wow the game flies” to “it is impossible to play, only lags” (see paragraph above on memorials).
Problems with G1 with a small amount of space for installing programs, on average on a zero system the user has about 30 megabytes. After installing the application less. If the application is large (the full version of iDracula takes 13 megabytes), then there may be problems with the installation. I will write below in more detail.
Content delivery to user
Unfortunately, the Android Market loses the AppStore in all respects.
At the moment, there is no way to specify the devices for which your application is developed on the market.
Those. if your application needs a hardware keyboard, or multi-touch (when it is introduced), then the application will be visible to device owners without these options and you will receive a negative rating from them.
Problems installing large applications. As early as five years on all cell phones when installing the application, the user, after downloading the application in case of lack of installation space, in addition to the warning receives a dialog with the ability to delete the current applications and battle to continue the installation. On android, he is forced to call a lot of menus for this action. Moreover, if your application takes up 10 megabytes, then it requires a minimum of 20 megabytes to install (the downloaded file, and space for installation).
One solution is to install the application without resources, and downloading the resources by the application itself and saving them to a USB flash drive.
I would like to see this as a standard feature of the SDK - the ability to mark part of files for placement on a USB flash drive.
Also, there is really not enough opportunity to get, in addition to the recall (for example, about the crash of the application), information about the device on which the user leaves a review, and ideally the log of the application as it is done in iphone.
There is not enough Entertaiment section - games are forced to compete in tops with applications like “Beautiful fire on your screen”.
Well, the lack of screenshots leads to the fact that the game is mostly chosen based on the name (as you know, no one reads the description), such a problem was, by the way, on the BREW market. Plus there is still a limit on the size of the description.
To summarize, you need to develop applications up to 3 megabytes in size, using, preferably, no more than 15 megabytes of memory and make a margin for brakes when working with a touchscreen.
Initially, there was a desire to write a more structured review and devote more time to the iphone, but I feel like this article would have lain in the draft for another month. I hope the folded will be useful in this form. I am ready to answer questions in the comments.
PS If you have a ready-made game for iphone or another mobile platform and you want its port for Android with the condition of shared revenu or fixed payment, then I will be happy to talk with you. :) For example on skype - youngskipper. I’m also ready to chat with other developers - to discuss the platform.