The making of SkyridersOctober 4th, 2012 | Posted by in Uncategorized
I noticed that I had quite a collection of Skyriders screenshots in my Dropbox public folder, that I’ve tweeted or posted to Screenshot Saturday during it’s development. And thought I’d write a little ‘Making Of’ post based around them…
So by February this year, I was finished with Little Acorns. I probably should have done the sensible thing, and made another platformer, based on the codebase and experience from Little Acorns. But I wanted to do something quite different. I experimented with voxels and deferred shading on the PC briefly, a 2D rollercoastery game featuring a caterpillar, and a word game, of all things – before starting Skyriders…
The beginning… Let’s get some polygons rendering. I had a decent amount of reusable code from Little Acorns for 2D rendering, but the 3D side of things needed doing from scratch. I was working in C++, with Marmalade, but also had a native Win32/D3D build to maintain. Anyway, the first screenshot… basically a tilemap wrapped around a cylinder. With the old HUD from Flutterpillar (the caterpillar-rollercoaster prototype) on top. Just seeing this rendering really smoothly on my iPhone4 made me want to carry on.
Later in March – the tunnel could now curve left/right/up/down, and I’d written a basic model converter/importer (Export from Blender as COLLADA, and convert to my own custom format. A very simple format that supports hierarchies and basic material properties, but no animation). This was the first successfully imported model – the Blender monkey!
I’d also started to hook up a physics engine. I went with Tokamak, as it seemed fairly lightweight compared to newer engines, and therefore easier to integrate into a Marmalade project, and more likely to perform OK on mobile devices. I had fairly minimal physics requirements – I just wanted a sphere colliding against a static environment. Although the environment did end up having quite a lot of polygons in it.
Textures, and a skybox! And the first experiments with models for the player. I didn’t really know what it was going to be at this point, but you can see the basic shape of the player ship that survived to the final version!
By this point, the tracks were getting more interesting, and weren’t limited to cylindrical tunnels. I could blend between a range of cross-sections, allowing the tunnels, flat sections, and curves like those in this next screenshot. I’d also improved the textures a fair bit, and added boost/slow pads (although they were just textures at this point, gameplay was still fairly non-existant)
Tracks were built using my ‘TwoDee’ editor. This was originally designed for non-tile-based 2D game. Then adapted to support tilemaps for Little Acorns, and then abused to build Skyriders tracks! You can see that the track is 20 tiles across, with a special column of ‘control tiles’ at the right hand side. These control the cross-sectional shape of the track, and also control the curving and banking of the track. It’s nice and simple, and keeps the level data very small, but it’s not WYSIWYG, so can be tricky to work with. Luckily, I could get the edited track back into the game and test it within a couple of seconds/couple of clicks.
Yay, I had a name for the game! And it was time to replace the old HUD. Not sure why I made this a priority so early on, but this was the first mockup of it. And it stayed more-or-less like this until the end:
The player ship had also been updated, looking very much like the final version. But with a fairly rubbish attempt at a character within it! It was also environment mapped, but still didn’t look great.
So where did May go? I suspect that was spent on UI work, and implementing that new HUD layout – sothe screenshots of that were less exciting!
It was either that or the threading woes. I’d decided that I’d generate the track mesh on a thread, as it comes into view – to avoid generating it all up-front as the level loads. I wanted to be able to join up a number of levels into a long ‘Challenge Stage’, and expected problems if I allocated and generated the whole thing at once. Well, I got that all working nicely, or so I thought. It was fine on PC, the Marmalade Simulator, and on an iPhone4. But on an iPad 3 it just crashed randomly. As I’m using Marmalade, I couldn’t do any on-device debugging, and the crash was too random to track down by printf debugging alone. It turns out that Marmalade had known issues with threading on iOS. I couldn’t be sure this was what caused my problems, but I’m guessing that it was…
Eventually, I just scrapped the threading. For normal levels, the loading pause is fairly insignificant. For the (much longer) challenge stages, there’s a noticable loading pause on slower devices, but nothing major. It did require a fair chunk of extra RAM, though. But it improves performance in-game, as it’s not generating geometry in the background.
Here’s a shot showing debug output, just after adding support for mesh entities with collision meshes. The green polygons are the currently active sections being collision tested.
By this point, I’d got a nicer looking player ship, an improved skybox, and the red/yellow colour-switching mechanic was in-game. I’d also added some glow effects (ships engines, and the collectables). The new HUD was also in.
Tutorials… I hate implementing tutorials… I’d prefer to assume that gamers can figure out simple control and scoring systems, but for mobile games, you can’t really even assume that… I also had to explain the less-obvious colour-switching mechanic.
Time for some tech work. I’d been getting the Android build up and running. This needs a separate data build, as iOS uses PVR texture compression, and for Android, I needed to use ETC1 instead. My first attempt at supporting ETC1 didn’t quite work…
But soon that was sorted, and it was running quite nicely on Android – here it is on an Xperia Play, and a Nexus 7:
Oh, look – there’s a ‘Games We Like’ button there, too!
By this time I had a composer helping out on the project, and adding music to the game made a huge difference, as it usually does! We experimented with dynamic music, by playing two music tracks at once – keeping one playing all the time (percussion/bass), and fading the ‘overlay track’, containing the melody, in and out based on how well you were doing. This worked out fairly well, but it’s something that we could have taken further.
(Ogg playback was done via stb_vorbis – This worked well, except for discovering a small memory leak in it, which I only found when my release candidate crashed!)
So I’d spent the best part of 5 months on the game now. Longer than planned – it was supposed to be a quick project. But writing my own tools and rendering code, as well as doing my own art had slowed things down. And I only had half a dozen or so levels built. I was aiming for 40 levels, split over 5 zones. So it was time to start on the skyboxes/textures for the other zones, and get building levels!
Here’s an early shot of Zone 2: Emerald Nebula:
I’d also found time to add the trail effect to the player. I’d been wanting to add that for ages!
One of the biggest late-ish changes was to lower the camera and widen the field of view. This hugely improved the sensation of speed. After doing that, and improving the Zone 1 textures, I was, for the first time, quite happy with how the game was looking:
Levels, Levels, Levels. I really underestimated the time required to build levels. Even after Little Acorns, where we did exactly the same…
But much of September was spent on level design and zone retexturing, as well as adding the upgrade system. Zone 3 became a very vivid orange, but I was quite happy with how the skybox turned out. Skyboxes were created with the excellent SpaceScape, and Genetica was used to help with texture creation.
I also had some playtesters trying out the game, and got some decent feedback, which led to a bit of UI tweaking. The UI was looking a bit nicer now, too:
So by the end of October, I had a finished game! yay, finally!
I’d gathered together all the required screenshots, text, and icons for a submission, and it should have been on its way to the App Store, but plans were somewhat spoiled by Apple’s release of the iPhone 5…
Well, the game runs on an iPhone 5 – look, 1136×640!:
Unfortunately, that’s not good enough for Apple. You’re not allowed to support that resolution with using the new 6.0 SDK. Which isn’t a problem for native developers using XCode, but as I’m using Marmalade, I can’t update the SDK myself, I’ve got to wait for Marmalade to release an update. (And it sounds like they’re still struggling to get hold of an iPhone5! – I must have just got lucky to walk into an O2 store and get myself an upgrade!). It’s a shame that Apple won’t give major middleware providers earlier access to hardware and SDKs, to help avoid such delays.
That update should arrive at some point this month, and I’m praying that it won’t cause any new problems, as I’ve got a hopefully-bug-free submission-ready build here now…
So whilst waiting for that, I’ve been tidying up the Android build. That one will be a free download, with an in-app upgrade to the full game. This makes sure that nobody pays for the full version on devices that won’t run it well. That’s in a fairly good state now, although I’ve still got a couple of issues to track down that occur only on one specific model of phone so far…
And I made a trailer
If all goes well, the game should be arriving on the App Store and Google Play around the end of October, maybe early November!
And there’s some screenshots from the finished game here