Geekly Articles each Day
📜 ⬆️ ⬇️

IPhone game development

IPhone game development



Start

In October 2008, at a regular meeting with two friends, I learned that both of them are engaged in the development of games for the iPhone. At that time, I already had an almost finished shareware project under Windows.
Burning with the desire to port it to the iPhone, I started working in this direction.

Goals

Create and customize development tools for Windows platform without buying the device itself, Mac and related development tools. The purchase of a Mac has been postponed until the moment of complete understanding of what and how it works.
Almost finished project and tools for it were under Windows, so it was decided to do everything under Windows.
A few days to search the Internet and I started to implement this idea.
')
Step One - Setting up the environment and compiler for Windows, or rather, for Cygwin

It took about a month to build a toolchain under Cygwin. The result was a huge makefile for the assembly toolchain and the compiled HelloWorld application, which had nowhere to run, since I did not have a device. When I say that it took a month, it does not mean that I worked on it for 8 hours a day, mostly work was done on weekends and after work. It took a lot of time to recompile, fix problems with paths, fix compile problems, and set up the CygWin environment (I only rearranged Cygwin three times).

Step Two - Recompilation of the finished Windows project under the iPhone toolchain

This step also took about 1 month. I first met GCC, the command line, makefile, as a Windows programmer learned a lot of interesting and useful things. Separately, I want to highlight the time spent on changing the code for the needs of the GCC and iPhone SDK. It took a lot of time to disassemble the header files, to search for functions under the Unix environment (sometimes they did not coincide or were absent). Bringing your code into a portable form via #define and interfaces went pretty painlessly, as well as building the Third Party libraries that I needed, such as Lua. Very much with saving time on the fact that the project was originally tied to OpenGL and OpenAL. Both my friends warned me that there were a lot of problems when working with sound on the iPhone, in my case, OpenAL started working right away; moreover, I didn’t even touch the audio code. It also helped that at one time the engine core (each game programmer should have its own home engine) was tested under Embeded Visual Studio for smartphones. During this period, the development and testing process itself is less established. It is very convenient to make changes in Far or Visual Studio and check the compilation for iPhone toolchain. Check the performance of the game after changing the code was checked in Windows. At some point, it was decided to test the performance under Linux, for which Fedora Linux was installed on VirtualBox. I would especially like to note that the presence of Unit tests allowed us to quickly identify and fix most of the problems (I could only run on Linux, but this was already enough). I also want to advise you to include the maximum level of varnings and stop compiling if there are varnings (-Werror for GCC), and fix them all, only because of this a few cunning bugs were fixed. Objective-C was used only in 3x files, everything else is written in C ++. So it was not possible to understand the processing of dependencies between source files (.cpp) and header files (.h) for correct recompilation if only .h files are modified.
Total:

Step three - buying a device and developing it for the device itself

To check the performance on the iPhone, the iPod Touch 3g 8GB was purchased (as it turned out later, the 8gb version of the iPod Touch is 2g hardware). A jailbreak was made, and it all worked the first time. Added a few lines in the makefile so that he uploaded the compiled project to the device. For apload, scp was used from the command line, in order not to enter passwords, authorization via keys was constantly enabled.

Step Four - Optimization and Debugging

Almost immediately it turned out that the processor on my iPod Touh 2g does not cope with the simulation of physics, while it does not cope so much that the question of ending the development of this game for iPhone really became. On large scenes, the simulation could take up to 300 ms per frame, which is naturally unacceptable. In the end result, I separated the rendering from the physics simulation. Rendering went with a maximum FPS if the detonation of the charges was not started, and was limited to 10 FPS at the start of the detonation. Physics after launch was considered to be ahead and to the maximum, that is, as soon as you pressed the explosion button and you started playing the sound of a siren, physics could already have been calculated 1-2 seconds ahead. Of course, I had to reconfigure the simulation of physics in order to somehow get into performance, as a result I got a small slow motion. For the future, activity was planned for the final setting of physics, so that there was exactly as much performance on my iPod Touh 2g. Accordingly, iPod Touch 2g devices were taken as the minimum base. After playing around with the GCC optimizer settings, -O3 was selected. Of course, the 3D scene was optimized, the number of DrawCall was reduced, a proxy was added for OpenGL states, the buffer vertex (VBO) was bolted, the number of drawings with AlphaTest turned on was almost zero.
Debugging was done through logs and gdb installed on the device. Taking into account that the code under Windows was licked and well tested, there were no problems. Memories were cleaned under Windows through Visual Leak Detector. Possible problems with OpenGL and profiling with geDebugger.

Step Five - MacOS and xCode

In principle, in this state it is already possible to upload a project for sale on Cydia, but I very much wanted to get on the AppStore, for this, of course, you need to collect it under a Mac and compile xCode. MaOS 10.6.5 and xCode were installed on VirtualBox.
A few days were spent on the assembly under the iPhone simulator and the project was completed.

Step Six - Buying a Certificate and Passing Certification

In order for xCode to build an application for a device, a developer must purchase the “iOS Developer Program” - this privilege costs $ 99 per year. I ordered and received a credit card, and in full confidence that everything would start to register well as a developer for the iPhone.
Apple does not accept credit cards from Ukraine. They need to fill out a form and fax it (for Russia, as I understand it, the situation is similar).

Step Seven - Mac Mini

After a while, the Mac Mini was purchased.
For several reasons:

Nevertheless, I did not refuse to use the toolchain. The main development is carried out on a Windows machine. Tulchain is used to check compilation.

Step Eight - Release Lite Version

Since the game mechanic is not at all casual, it was decided to release the Lite version first.

Step Nine - Feedback on the Lite Version

As it turned out, some of my user interface solutions were not as intuitive as I thought.
For example:
Windows version

The picture is old and new interfaces
The Play button (arrow below) was clearly incomprehensible to the players, many simply did not guess to press it. Solution - click on the level starts the level immediately, the Play button has been removed. The page switching buttons were redrawn and replaced with simple arrows.

Technical details

Gamecenter Integration

Passed without problems thanks to the example of GKTapper - developer.apple.com/library/ios/#samplecode/GKTapper/Introduction/Intro.html
GameCenterMenager.h and GameCenterMenager.m passed to my code without changes

OpenFeint Integration

I spent the day searching for the problem because of which the OpenFeint dashboard did not show up, after reading the documentation it turned out - I forgot to hide my window by event
- (void)dashboardWillAppear
{
self.hidden=YES;
}
- (void)dashboardDidDisappear
{
self.hidden=NO;
}

Facebook integration

It was made as written in developers.facebook.com/docs/guides/mobile .
But there were problems due to the fact that OpenFeint already used some old Facebook sdk and there were errors during linking. The solution was very simple - in the Facebook headers of the sdk, I had to add the following defaines #define FBDialog MFBDialog
Also in the process of testing, it turned out that Facebook shows a captcha if your links to images are outside of the facebook domain.

Twitter integration

MGTwitter was used - github.com/mattgemmell/MGTwitterEngine
I also had to add a dialogue for a pre-show on Twitter (it was not in this sdk). I got out through UIWebView in which the page was shown in the input form, pressing the Post and Skip buttons were intercepted and then forwarded to MGTwitter.

Rate me

A small library was chosen https://charcoaldesign.svn.beanstalkapp.com/source/cocoa/iRate/trunk/
For the light version, an interval of 7 days and 7 launches was chosen.
For a full 20 days and 20 launches.

Multi touch

To debug multitouch under Windows, a small server was written for the device, to which the Win32 game joined at the start and received all the touch events of the device.

Control of faith

Svn for code and data. On Mac, the code is taken from a shared directory from a Windows machine. While I work alone this is not a problem and saves time.

Expenses


Result


What was good



What was bad



References:


Part two


Part Three



Source: https://habr.com/ru/post/122351/

More articles:


All Articles