Development of Gaming Application for the iPhone
In October 2008, I have found out at an ordinary meeting with two friends that they are involved in the developing of games for the iPhone. At that time I already had almost completed shareware project for the Windows. I was inspired by the desire to port it for the iPhone, I started working in this direction.
Create and adapt the development tools for the Windows platform without the purchasing of Mac device and related the development tools. Mac purchase was postponed until a full understanding of how it works. Almost finished project and tools for it were for the Windows, so I decided to do all for the Windows. I started implementing this idea after I spent a few days searching the internet.
Step one - Setting up the environment and compiler for the Windows, or to be more exact for the Cygwin
I have spent about a month to build the toolchain for Cygwin. The result was a huge makefile to build the toolchain and the compiled application of “HelloWorld” which I could not run, because I did not have a device. When I say that it took a month, it does not mean that I have spent a month for 8 hours a day working on this project; mostly the work was done on the weekends and after the work. A lot of time was spent on the recompilation, fixing problems with the paths and compilation setting up the environment for the Cygwin (only, I rearranged Cygwin three times.)
Step two – Recompilation of the finished Windows project for the iPhone toolchain
This step also has taken about a month. I first found out about the GCC, the command line, makefile, as a Windows programmer I learned a lot of interesting and useful things. I also would like to separate out the time that was spent on changing the code for the needs of GCC and iPhone SDK. A lot of time was spent on disassembling of the header files and the searching of function for the Unix environment. Bringing the code in a portable form went quite smoothly through # define and interfaces, as well as assembly of the Third Party libraries that I needed, such as Lua. I saved a lot of time, because that project was originally tied to OpenGL and OpenAL. Both of my friends told me that there could be many problems, when working with the sound on the iPhone, in my case, OpenAL started working right away, indeed,I did not even work with the sound code. Also it helped that the core engine was tested on Embeded Visual Studio for the smartphones (every game programmer should have own home engine). The process of development and testing became well-established during this period. It is very convenient to make changes in the Far or Visual Studio and to verify compilation for the iPhone toolchain. Verifying the working ability of game after changing the code that was tested on the Windows. At some point, I decided to verify the working ability on Linux, so I set the Fedora Linux on VirtualBox. I would like to note that the presence of Unit tests let quickly identify and fix the most problems (I could only run on Linux, but it was enough). Also, I would recommend to enable the maximum level of warnings and stopping the compilation if there are warnings (Werror for GCC), and correct all of them, only because of it there were corrected several insidious bugs. Objective-C only was used in 3 files and everything else was written in C + +. I was not able to sort out the processing of dependency between the source files (. cpp) and header files (. h) for correct recompilation in the case of changing only . h files.
• The game runs on the Windows and it is compiled for the iPhone platform. I could run a game that worked almost like on the real device using so-called configuration platforms including the resolution as the device has, for example: the landscape orientation and size of textures, etc.
The example of platform.cfg configuration
, true device
maxTextureSize = 256
touchInput = 1
hideArrowCursor = 1, disabled tracks for iPhone
defines = PLATFORM = IPHONE
fixedVideoResolution = 1
; game for Windows in “compatibility mode”
maxTextureSize = 256
SupportNonPower2 = 0; on Windows these textures are possible
touchInput = 1
# hideArrowCursor = 1, the cursor appears for Windows
fixedVideoResolution = 1</i>
• Windows version
• Toolchain is runnable for compilation of a program on the iPhone. Then, unexpectedly, I found CygwinPutty modification to run for Cygwin, I made it Portable and placed a link on the Quick Launch
Step three – Purchasing a device and development for this device
I bought iPod Touch 3g 8GB in order to test the workability on the iPhone (as it turned out later the version of iPod Touch 8GB is 2g hardware). I did the jailbreak and everything worked at the first time. I added a few lines in the makefile to upload the compiled project on the device. I used scp from the command line to upload, so I do not have to enter passwords, therefore, the authorization always was enabled through the keys.
Step four - Optimization and debugging
Immediately it became clear that the processor on my iPod Touh 2g cannot handle the physics’ simulation so badly that there was really the issue to terminate the development of this game for the iPhone. Simulation could take up to 300 ms per frame during the big scenes, which is naturally unacceptable. Finally, I have separated out the rendering from physics’ simulation. Rendering went with the maximum FPS if detonation of charges was not started, and it was limited to 10 FPS at the start of detonation. Physics was calculated in advance after the launch at the maximum, once you have clicked on the explosion button and you heard the sound of siren, physics has been calculated for 1-2 seconds in advance. Of course, I had to reset the simulation of physics in order to keep the processing power, as the result I got a little slow motion. In the future, it was planned to do the final setting of physics to make it as much as my iPod Touch 2g has. Respectively for a minimal base were taken the iPod Touch 2g. O3 has been chosen after working with settings of GCC optimizer. Of course, there was done optimization for 3D scene, reduced the number of DrawCall, added the proxy for OpenGL states and vertex buffer (VBO), reduced almost to zero the number of draws with enabled AlphaTest. Debugging was done through the logs and gdb that was installed on the device. Considering that the code for Windows has been polished and well tested, there were no problems. The memory leaks were cleaned for Windows using the Visual Leak Detector. There could be possible the problems with OpenGL and profiling through geDebugger.
Step five - MacOS and xCode
In principle, it is possible to put the project in this condition for sale on Cydia, but I wanted very much to get on the AppStore, so for this I have to build for Mac and compile xCode. There were installed MacOS 10.6.5 and xCode on the VirtualBox.
Several days were spent on mounting for the iPhone simulator, and the project was completed.
Step six - Purchasing a certificate and certification
In order that xCode will build the application for the device developer should buy “iOS Developer Program” - this privilege will cost 99$ per a year. I ordered and received a credit card, and started to register as a developer for the iPhone.
Apple does not accept the credit cards from Ukraine. They require filling the registration form and sending it over a fax (as I understood for Russia the situation is similar.)
• On January 28th, 2011 – I filled and sent registration form over PamFax
• On February 2nd, 2011 – I got the answer
Step seven - Mac Mini
I purchased Mac Mini after some time.
For several reasons:
• Speed of compilation was very small for the virtual pc.
• Searching stage and inspections were over - I had to start legalization process.
Nevertheless, I did refuse to use the Toolchain. The main development is done on the Windows. Toolchain is used to verify the compilation.
Step eight – Release of Lite Version
First, I decided to release the Lite Version since the game operation is not casual.
• On June 1st, 2011 – I placed for Review.
• On June 8th, 2011 - Ready for Sale
Step nine - Implementation of the feedback on Lite Version
As it turned out some of my decisions in the user’s interface were not as intuitive as I thought.
On the picture are the old and new interfaces, a Play button (arrow down) clearly was obscure for the players, many of them simply just did not know that they have to click on it. Solution - click on the level right away runs that level, the Play button was removed. Switching buttons of pages were redrawn and replaced with the simple arrows.
It passed without any problems thanks to the example of GKTapper - developer.apple.com/library/ios / # samplecode / GKTapper / Introduction / Intro.html
GameCenterMenager.h GameCenterMenager.m came into my code without changes
I spent a day on the searching of problem, because OpenFeint dashboard was invisible, but after reading the documentation it turned out that I forgot to hide my window on the events
- (void) dashboardWillAppear
self.hidden = YES;
- (void) dashboardDidDisappear
self.hidden = NO;
I did everything as it was written in developers.facebook.com / docs / guides / mobile. But there appeared the problems due to the fact that OpenFeint already used some old Facebook sdk and the linking errors occured. The solution was simple – in the headers of Facebook sdk I added defines similar to # define FBDialog MFBDialog
It turned out that Facebook shows captcha in the process of testing if the links on pictures lead to the domain of Facebook.
MGTwitter was used - github.com / mattgemmell / MGTwitterEngine
So also, I had to finish writing the preview dialog for posting to Twitter (it was not in the sdk). UIWebView showed the page in the entry form, when clicking on the Post and Skip buttons events were intercepted and redirected to MGTwitter.
My source codes at http://sites.google.com/site/gameimplosion/posttotwittersc
There was chosen a small library at https://charcoaldesign.svn.beanstalkapp.com/source/cocoa/iRate/trunk/
For the lite Version I have been selected interval of 7 days and 7 runs
For a full will be 20 days and 20 runs.
For multi touch debugging for Windows was written a small server for device to which was attached Win32 game at the start and getting all the touch events of device.
SVN is for the code and data. On a Mac pc the code is taken from Windows shared directory. As long as I work alone with code it is not a problem and saves the time.
• iPod Touch 2g 8GB - 270$
• iOS developer - 100$
• MacMini - 800$
• My free time
• Lite Version in AppStore - iTunes Link
• Full Version in AppStore - iTunes Link
What is went good
• Choice of the main platform on Windows. Ability to run and test as well as reload assets by pressing “R” button saved me a lot of time. My work experience as a programmer with Visual Studio 10 years, I have no time to learn xCode.
It is very easy to catch gameplay video.
• Objectives - this is one of my home projects, which was finished. Almost all my home projects were frozen. For that project I had very strong target to finish it.
What is went bad
• Art - I did it myself and you can see the results.
• Interface - originally came from Windows game and was too complicated, I left only 1 main screen for iPhone.
• Playtests - I did it on myself. In most cases, I did not see any problems, which was visible for other people.
• Rhythm of work - work in such pace is very hard.
• Implosion Lite - ITunes Link
• Implosion - ITunes Link
• Implosion - Game
• Useful link for the registration in iOS Developer Program – www.iphones.ru/forum/index.php?showtopic=31536&st=0?s=3988650a9a235fc5021ea885f11572f5
• stackoverflow.com - almost all solutions of my problems with the code were taken from here
• www.raywenderlich.com - sourcebook is on the integration of Tweeter and Facebook.
• www.saurik.com/id/4 - Toolchain alternative, which started working
“Translated from another resource”
|Vote for this post
Bring it to the Main Page