Porting an Adventure Game from PC to Smartphones, Part 1

This is the first of three posts accounting of the technical & design challenges we faced while porting the Pahelika Series (Pahelika: Secret Legends and Pahelika: Revelations), originally windows games, to iOS. Part 2 in the series is now available.

In September 2009 we launched a casual adventure game called ‘Pahelika: Secret Legends’ for Windows. The game had no hidden object levels, a rarity at that time amongst casual games. The game did very well, and was our first game to reach top 10 on the casual game portals.

This was also the time when the smartphone craze started picking up. Casual gaming audience began slowly shifting to tablets/smartphones. Two years after the initial release, and after the  sequel Pahelika: Revelations had been released, we started getting offers from a new crop of smartphone-only publishers to port our game to iOS. The offers we got were varied, from being offered 10% (!) of the royalties to a higher, more reasonable value.

Thinking that Smartphones were the future of casual gaming, we decided to jump onto the smartphone bandwagon. Initial plan was to port the Pahelika series to iOS.

It took us 18 months to do the port!

Part of the reason was that we had a had a small team, and because we were porting two games at the same time to both iOS and Android (and by extension, to OSX).

The ports are now well and truly complete, and  Pahelika: Secret Legends is poised to launch on iOS on March 6.

This is the first of three post accounting of  the technical & design challenges we faced while porting the games.

Originally, our game engine was derived from the PopCap Framework. Some folks might remember that PopCap once made their game engine freely available, including the source code. Eventually they stopped updating the public version, and the engine was stuck using the outdated Directx 7 API. This was the engine we proposed to upgrade.

The Heart of the Engine

The engine was based on Directx 7 and used the Win32 API for OS dependant tasks. On iOS and Android obviously the DirectX and Win32 APIs doesn’t exist. Trawling through the source code, we realised that we were facing the prospect of re-writing several major subsystems:

And so on.

This was pretty much looking like a total engine re-write. Not wanting to do that, we looked for low level libraries to do most of these things for us.

Having the source code for the library was an important requirement.

If you don’t possess the source code to your engine then your game is effectively controlled by the engine developer. Whether your game will be available on a platform is a decision in the hands of engine developer, not yours. It gets even worse if middleware is thrown in the mix.

Sometimes this is not an issue, when the engine is already ported to all the platforms you need. At other times it can be a real showstopper.

We evaluated a lot of 3rd party libraries for this, and eventually decided on SDL. This was probably before Valve had decided to port Steam to Linux. At least it wasn’t known to us that something like this is in the offing. SDL1.3 at the time was still alpha, and not ready for prime time. It also seemed that development work on SDL was faltering.

However, SDL supported iOS, and with a little work, Android. It was also open source, under zlib license. Further, we felt that if there were any issues remaining, it would be relatively easy to fix them given that we had access to the code.

But the real reason we liked SDL (and rejected the other libraries) was the elegance of the API. SDL has one of the best designed 2D APIs we have seen. The transition from SDL1.2 to SDL 2 has hurt the elegance of the API a bit, but only a little.

This turned out to be a good decision. It proved to be relatively easy to replace the PopCap Framework internals with SDL. Despite its beta nature, we had no SDL related crashes. There were some minor issues, but those were easily fixed. The development on SDL suddenly picked up, and we later learnt that valve was behind this. It turned out that steam on linux was using SDL.

It was a great moment when the first of the engine demos started working on windows! Everything in the demo looked exactly as before, but underneath the hood everything had changed! The demos, intended as a tutorials for the first time users, also served as test cases for us. In a matter of days we made all the demos work.

Playing music however, was another matter.

Sound And Music

While the popcap framework had code for loading ogg and wave files, to play them it depended on external libraries like BASS and FMod. While these libraries are available on osx & ios and android, they have to be licensed separately for each platform, and in FMod’s case, licensing is expensive.

We also wanted to take this opportunity to improve the very basic sound system currently in place in the engine. We wanted to control sound effects, ambient music and background music separately. We also wanted to fix it so that when playing videos, we could use the sound engine to play music, so the mixer needed to support sound sources which would be filled from the outside.

To my surprise, we found that BASS didn’t support this. SDL already had a mixing library called SDL_mixer, and we realised that this (very basic) library would not support playing multiple music files at the same time. The only solution was to write our own playing code.

We decided to only support loading of ogg and wav files. Mp3 is patent encumbered, which ruled out including mp3 decoders in our codebase. Additionally, it is difficult to make a sound loop well in mp3. Finally, our library did not need to play multiple file formats, as we could just convert everything to ogg files.

The code took a month to write. We had to rip out almost all of the original sound playing code, retaining only the interface. We also removed the music playing code, ending the artificial distinction between sound effects and Music. Now there were no sound managers and music managers - only Mixers.

Re-writing the sound subsystem was the most fun part of the code re-write!

Miscellaneous Other Things

There were a lot of small things that needed to be re-written, such as PopCap framework’s dependency on the windows registry to store game settings, mouse cursor drawing code, displaying FPS and so on.

Eventually, however, these odd jobs were finished. Both the versions of Pahelika were now running under windows! We still needed to handle the ALT+Tab video device loss, but that wasn’t a problem, because osx, ios and android all use OpenGL for graphics.

We thought we had conquered the mountain fort. It appeared that the porting would soon be over.

We thought wrong.

The fun was just beginning.

(Continued in Part 2).