Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

Warning: DOMDocument::loadXML() [domdocument.loadxml]: StartTag: invalid element name in Entity, line: 1 in /usr/home/web/users/a0027295/html/blog/wp-content/plugins/wp-skygreen/filterContent.php on line 52

All along the way we were making full use of Instruments to do performance profiling for memory footprint, input latency and framerate bottlenecks. We already knew from the desktop version approximately what our memory usage was going to be. We found in practice that our memory usage on the iPhone was around 25 MB or so which was comfortably below the jetsamm danger zone of thirty something MB on first generation devices. So it was just a matter of fixing a few memory leaks and converting our assets to more iPhone appropriate sizes. Thus we felt we were in a pretty good spot as far as memory was concerned. The majority of our performance profiling was trying to find CPU/GPU bottlenecks and measure input latency. It was here that we realized that we were truly developing for a small computer as opposed to a console. Performance measurement numbers tended to swing pretty far which we chalked up to either the measurement techniques, other processes in the system fighting for resources or both. We also found that we were greatly at the mercy of the graphics driver and that analyzing what exactly we could do to increase overall framerate was a fun and interesting challenge. One thing we played around with (while we were still using SDL) was how much we would let the run loop go each frame to service input handling and observed how that impacted input latency. In the end after we had completely removed SDL we simply kicked off the run loop, created a frame timer and let the run loop decide how much to spend on input handling. Another impact that removing SDL had was that it lowered our memory footprint by about 2MB which was a nice surprise. One very interesting thing that we found while profiling was that compiling without Thumb (because we were floating point heavy) and with any optimizations higher than -O1 would result in incorrect gameplay behavior and glitches. We did a lot of testing and eventually found the one specific optimization that was the culprit and easily removed it with -fno-regmove (this appears to have been fixed in gcc 4.2). One of the biggest optimizations for graphics performance on the iPhone is to reduce the size of your vertex data by using smaller data types than the typical float as long as the decreased accuracy does not significantly impact gameplay. This was of particular importance on the iPhone because at the time that we ported Caster there was no way to avoid a graphics driver copy of vertex data. We eventually settled on shorts for position (3 X 2 bytes + 2 bytes for padding), chars for color (4 X 1 byte) and shorts for texture coordinates (2 X 2 bytes) which got us a nice and even 16 bytes per vertex as compared to 36 bytes per vertex when we used floats. We spent a ton of time optimizing the various specific systems within Caster in efforts to bring the framerate higher and higher. Another interesting aspect of developing on the iPhone was that because the framerate was significantly lower on average than the desktop versions we became more acutely aware of bugs and issues in general. Some were even present in the desktop versions, but masked because of the high framerate.

iPhone keyboard input was pretty much the only native iPhone OS UI that we made use of. The text input boxes that we were using were in-game and so we (like others) had to make an offscreen UITextField that remained in sync with the in-game text box to handle text input. At one point we experimented with having the device vibrate when the main character got hit but decided that for the time being we would leave it out.

We also needed to decide what our user experience for the pirated version was going to be. We had a lot of discussion and eventually settled on an experience similar to the PC and Mac demo where you are allowed to play through the first 6 levels or so and are then prompted to buy one of the full versions from our website which had a link to the full iPhone version as well as the desktop versions. Perhaps in the future we will send the user directly to the app store listing. This discussion also brought us to issue of the Lite version. We knew we wanted a Lite version out on day one so that people could try before they buy. We genuinely wanted only people who already dig the gameplay and control scheme to purchase the full version and so they needed a way to find out. Post-release we have since decided to discontinue the Lite version because we didn’t see that much of an upsell impact.

We wanted the functionality to send the user to web pages or our App Store listings directly from within the game but because we didn’t know what our App Store URLs were going to be yet we decided to grab a redirect URL from our website that we could change at anytime. This allowed us to point Lite users to the full version, send people to iTunes/App Store listings and gave us the freedom to redirect people elsewhere in the future should we so desire.

As with all good products that make it to market, Caster for iPhone underwent a good amount of playtesting, issue deference, feature cutting and polish right at the end before we were both satisfied enough to give the ok to release. We have learned even more since the release both in aspects of technical development and in navigating the App Store business model. We have more improvements to make and more content to deliver but we look back fondly on the experience that we got from taking on the challenge of porting a game designed for the desktop to the most different and interesting platform currently around.