I'm afraid the downtime of the Apple developer services which happened a few weeks back and lasted over a week have caused us a setback in testing the mobile version ready to submit! The services are back up now so we're back on course to submit to Apple for review this coming week.
So, I promised a look under the hood of Detective Grimoire! The version you'll be playing was made in Adobe Flash/AIR, but Grimoire started life as a native app, just for iPhones, being written in Objective-C and using the Cocos2D library. The plan was to animate and draw everything in Flash, then export as png sequences and use them in Cocos2D. I spent a month learning Obj-C and Xcode, then started putting the basics of the game engine together while Adam started work on the characters and other art.
We were about 6 months in, working in our spare time, when Adobe released AIR 2.7. This release was a huge improvement over previous versions, especially when it came to performance on iOS - up to 4x faster! After having a quick play with it, we decided to scrap all the Obj-C code and start again in Flash/AIR. Since all of the art, except the backgrounds, was being made in Flash, and our experience lies almost entirely in Flash, it was a natural platform for us to work in. Now that it could actually perform well, there really wasn't a better option for us!
So I started from scratch on the code, and Adam continued on with the art as he had been. The game's conversations could now be left as Flash vectors, which ran just fine on even the iPad 1 and took up a tiny filesize compared to the old png sequences.
The animated backgrounds though, they always caused a problem. AIR started to struggle with moving fog, rippling water, waving reeds, all the things we added to make the world feel alive. If left in their original Flash vector format, they had a tiny filesize but would run at about 10 frames per second on the iPad 1. No good. If made into png sequence spritesheets, the filesize and runtime memory requirements were huge, sometimes crashing the iPad 1, and the framerate still wouldn't be all that impressive, sitting dangerously close to the 30fps we're aiming at. Still no good!
I had resigned myself to these slightly lower framerates on older devices, when Adobe added to Flash/AIR a technology called Stage3D. Stage3D works in the same way as libraries like Cocos2D do, by feeding image data directly to the GPU via interfaces like OpenGL. This low level access boosts speeds and performance hugely, especially on low powered devices like phones and tablets. Despite it's name, Stage3D allows you to work in 2D just as well, by just moving around flat images at a depth of z=0.
On top of Stage3D, you can use the 2D Starling library. Starling takes away a lot of the hassle of working in 2D with Stage3D, and feels a lot like working with ordinary Flash graphics. That made it perfect for our needs! Sadly, Adobe took some time to release Stage3D for mobile devices, so we stuck with our old graphics for the time being.
Now I want to briefly mention our Playstation Mobile/Vita game Haunt the House: Terrortown. I promise it's relevant! For this game, there were a huge number of animations to produce and use. Again, png sequence spritesheets would have caused enormous filesizes and runtime memory requirements, and on Playstation Mobile you're only allowed 90MB of runtime memory before the game will crash out on you. So, wanting Adam to still be able to animate everything in Flash, I created a library of my own that takes Flash animations, breaks them up into their component pieces and checks to find the smallest number of pieces it can use to recreate the animation. It then spits out those pieces and a file containing animation reconstruction data. This can then be read by Playstation Mobile, and the animation played with minimal memory use! The library worked really well, and every graphic in the whole game was exported using it. I called this library the FlAn library.
Now back to Detective Grimoire. Stage3D came out for mobile devices, and now I have a library to export Flash animation optimally for mobile devices... You can imagine what happened next. After polishing up the FlAn library and adding a few more handy features, I started to work on exporting all of the game's areas in this new format, and on a FlAn player for Starling/Stage3D. Suddenly, the game could run at a full 60FPS if I cranked it that high, and the runtime memory was much lower than before! True, the filesize is slightly bigger, but the increase is most definitely worth it.
So there you have it! In the final game, all the games areas are rendered with the FlAn library using Stage3D, and all of the conversations and menus are Flash vectors. Cutscenes are rendered with the StageVideo API, which is similar to Stage3D but for rendering video very fast on the GPU.
I hope this little look at how the game works was interesting. These issues have been frustrating during the development of the game, especially coming from pure Flash development where you can do so much more complex things graphically without it dropping a frame. Now that they're solved though, it's very satisfying to look back at where we were and how far it's come!