KAMI RETRO - Asset creation case study

Saturday, 11 January 2014 3 comments

In September 2013 Steve and Antony started as Games Mentors for the University of Chester in the UK and as part of their roles they have been providing a number of talks on various aspects of games development. Yesterday they gave a talk on asset creation using KAMI RETRO as the main case study with a section on Swashbuckler to illustrate HUD considerations for varying resolutions. To accompany the embedded presentation there is a summary of the talk content below.

KAMI RETRO : Development Overview

KAMI RETRO is a single screen 2D puzzle based platforming game that was developed by a team of four as a spare time project in 2010. Although the engine was being developed to support multiple platforms the initial target platform for the game was to be the iPhone and at that time the highest resolution available was that of the 3GS at 480x320. The asset creation process for KAMI RETRO involved modeling all the assets including characters and environments in MAYA then rendering them out to PNG sprite sheets and in some cases additional post effects were then added. So as the game was being developed the assets were being rendered out for the 480x320 resolution of the 3GS.

There was no pipeline in the engine at that time for dealing with varying resolutions and as there was never any immediate goal to launch on anything other than iPhone it was fairly reasonable to be doing what we were doing. By November 2010 we had a trailer for the game which we pushed out on to social networks and various mobile gaming forums. Shortly after we began receiving interest from various publishers and ultimately decided to work with Gamevil. In Febuary 2011 the team was full-time, polishing up the game and giving the whole GUI a full overhaul and by March KAMI RETRO released on the App Store. The hard work had paid off and Apple featured KAMI RETRO as their Game of the Week, now known as Editors Choice. However there was a lot more hard work to come.

Asset Creation for different resolutions

As part of the contract for KAMI RETRO we had to deliver iPad and Android versions. This meant we had to support a significant amount of different screen resolutions. If all the assets for KAMI RETRO were hand drawn it would have meant everything would either have had to have been stretched, making them blurry and pixelated which would have been unthinkable or re-drawn everything again which would have been massively time consuming and financially impossible. Fortunately the assets were all originally created as 3D models so we decided to re-render everything out at 2400x1600 (5X the original 480x320) to ensure we could cover all available devices at that time and any future devices to a point. The assets were then packaged up for the varying devices (by downsizing from 2400x1600 to the target platforms native resolution) and in May 2011 the iPad version released with the Android version not too far behind. Apple loved the attention to detail and gave KAMI RETRO it’s second Game of the Week for the iPad and across the App Store it has continued to be featured in numerous App Store collections from Stylish Games, Quick Fix Games, Retro Games, Greatest Platformers, Intuitive Controls in Benchmark Games and has been given an entry in to the App Store Hall of Fame. The Google Play store also awarded KAMI RETRO with a top banner placement on launch. KAMI RETRO subsequently launched on WebOS, BlackBerry 10 and more recently Tizen.

Performance Considerations

To ensure KAMI RETRO ran smoothly across hardware with varying levels of performance we performed a variety of optimisations. One of the main optimisations was to limit the amount of overdraw. Requesting to redraw the same pixel multiple times on any platform will eventually hit the frame rate at some point and on some of the devices we targeted overdraw was a big limitation. To reduce the number of pixels being re-drawn we baked the terrain in to the background so we didn’t draw the background then the terrain over the top. However in some of the levels we had water that needed to look like it was going behind the terrain. To get around this we created what we called a Liquid Layer and drew this in front of the water to give the impression it was going behind the terrain.

GUI Considerations
When developing a game to work on various resolutions whether 2D single screen games, 2D scrolling games or 3D games one of the common elements is typically GUI. On slide 13 you will notice an example of Quake 2 from 1997 running at its native resolution on the left and on the right a much higher resolution. The one on the left has a clearly visible HUD whilst the one on the right is shows some scaling issues with the HUD at the higher resolution. Moving on to slide 14 of Quake 4 from 2005 these issues are no longer present between the two different resolutions. To develop a GUI at Paw Print Games we adopt a screen node anchor system to place elements in certain positions on the screen. By attaching GUI elements such as sprites to nodes positioned for example at either the top left, top centre, top right, centre, bottom left, bottom centre or bottom right then as the screen resolution changes all the assets stay anchored to the associated screen node assigned by the designer.

Paw Print Games © 2011