Annihilator Out Now!

Annihilator coming 21.03.13

Annihilator is a top-down action shooter for iOS devices and will be available from 21st March on the Appstore as a free download. Check it out!

Mobile Game Shop Screen Design

With my latest game soon to be released it seems a good time to start the post-mortem on what went right and what went wrong. In this post I'm going to talk about some of my UI design and show the stages it went through from bad to polished and nice.

I found the design, layout and art style for the UI to be sometimes one of the most frustrating whilst also one of the most joyful parts of the development process. On mobile platforms the UI is so important. The appeal and look of it as well as the flow and control are vital to keeping users engaged. Frustrating the user in the initial menus is likely to stop them interacting with your app fairly quickly and can quite easily lead to a straight deletion from their device.

Below are some of stages the shop/profile screen went through in development. You can see the huge progress in layout, appearance, neatness, symmetry, consistency and my art UI skill development in general.

The first version of the profile screen with an old very simple green and black UI style, similar to in Annihilation Arena. The screen is pretty poor and unintuitive at this stage. The items you select are set on the left in the slider. The categories for these items are on the far right (attack, defence, special). The description and image of the item on the tank were to be displayed in the middle. Unordered and messy, it needed to be improved dramatically.

This design shows retina graphics with shine added to the buttons. I was having issues with sliders at this point so had opted for arrow buttons to move the set of displayed shop items up and down (this was a bad idea and eventually I switched to a slider).
The items are now in a larger block, there is no category selection and the buy/equip buttons are underneath the description of the current item and image of the ship with the new item.

The equip button is now removed and a tick is used to indicate which item button was last clicked to equip it. The buy button is in a box with the item information contained in to make it a bit clearer. The buttons texture and style are coming closer to the final design. The ship is visible to display the current items. The main problem at this stage is it's difficult to tell what the items are by the icons alone. The image items need to be more than clear, they need to make players want to click on them and find out more.

A major overhaul happened here. I wanted attractive and obvious item images so I blew them up with prettier pictures to look at. Of course now the images are way too big! Only three could fit on the screen at once. I was forced to switch back to the slider again to account for the larger item images. To buy items now you just clicked on their image and then a popup would prompt you. There is no room to display the ship.

More major changes. The players tank is now the main focus, showing off the currently selected item in full 3D. The items have been reduced in size but kept large enough to look nice and clear still. They are kept on a slider which obviously suits the iPhone very well. A less obvious change is the back and next buttons frame shape changing to point in a direction.

The final design is a fully integrated shop/profile screen (previous designs had these areas seperated). Item category is selected at the bottom between weapons/armour and specials. The camera moves around and views the ship from different angles dependant on the item category. Different information is displayed depending on the current category. In this shot we are viewing armour upgrade items and so we can see the currently equipped armours durability and other stats. Items that aren't yet purchased have their prices displayed inside their container and glow golden.

High Definition Player Tank

Having decided on displaying the Player's vehicle in the Front-end it became apparent that more detail would be required, especially for high-end devices such as the iPad3. I recently upped the poly count slightly but more importantly recreated the combatant textures at 4x the size.

Tutorial

I've decided that I will feature a tutorial level, which the user will be forced to play through (for now). Lots of different views on how the tutorial should be done and the current one I've knocked up is subject to change at the moment. Forcing the player to do it means that they will definitely learn the mechanics, however, it also means you can annoy some users who really just want to play quicker.

One way to alleviate this is to keep the tutorial level very easy and lightning quick for someone who knows what to do already whilst also integrating it into the setting/story as much as possible to keep it interesting - sort of like the Half-life hazard course.

Lava Planet

It's been a while since my last update but I have been busy as ever working away on the game. I'm fairly pleased with the way the Egyptian campaign plays and looks these days. Progress on the lava world has been great, the art and test level has gone through a couple of iterations and reached a fairly decent dark/hot atmosphere! Lava worlds are common in computer games but I still find them awesome to look at. Trying to think a bit more about how I can perhaps put my own spin on the environment.

Asynchronous Resource Loading

After reading about Alex Okafor's difficulties with CGContextDrawImage on separate threads for loading graphical resources I decided to just load the textures on the main thread and save myself the hassle of changing my png lib.

The main bottle neck at the moment is the level geometry data and models so I've shifted that to load on a separate thread and permit me to add a loading animation. I decided to use posix threads for compatibility reasons rather than Apple's NSThreads api.

I thought I'd save texture space by using a single frame of animation and rotating it in code but this didn't work very well. The texture pixels were slightly off at different rotation values, so I opted for animation frames to keep a polished 'locked in' look to the animation.

The loading screen now has a loading bar for overall progress with an animation that gives the user some feedback whilst only stalling slightly initially for the texture loads, which are non-threaded. I feel this is polished enough and fully threading the loading screen is not worth the time investment at this stage.

Update 01/10/11:

I tried adding the OpenGL shared context stuff anyway and it all worked fine with my texture loading code, wasn't much of an effort to add either. All loading is now entirely done on a second worker thread. Shout out to BigMac for the sanity check!

Progressing after Summer

I've been out of action the last three months mostly due to enjoying the Summer and life in general but I'm back on track now and working away to see if a Christmas release is possible.

The majority of recent work has been pipeline tools and gameplay related but I've done some more graphical polishing again as usual. Lots of gameplay things such as objectives/destructible items and better dynamic lighting have been improved ten-fold. I've also added a very basic material system to allow me to have glowing lights on meshes and models, a small addition but looks pretty cool (screenshot below shows the Player's tank and the teleporter using this).

My current target is to work towards a clean and fairly polished first level. I've made enough levels now to know it's better to completely finish one rather than having to iterate changes over several at once. Once I have a good polished level that's fairly representative of what I imagine the final game to somewhat play like I'll make another couple, which will be quite easy and quick and start looking at the upgrade/shop system.

Voice-over and music

Stage one of recording voice-overs, such as 'multikill' and 'vicious'.  We're going for a deep, impacting voice style; there's probably going to be a lot of crazy effects needed for these.  Hopefully we'll getting it sounding as exciting as possible.

Music-wise, the Egyptian theme is half done: the basic sound and structure is down, we're just working on hyping it up a bit and polishing it off.  AA2 will hopefully combine the fast-paced action game style of music with a film aspect as well: orchestral elements and a slight cinematic feel.

A lot of work needs to go into this in the following week...

Baked lighting and Environment shadows

I decided to kill the dynamic lighting in favour of baked vertex colours. The speed improvement from this should let me keep 60fps whilst having a naturally looking lit environment. I never really needed 'dynamic' lights anyway and they didn't enhance the look of the game that much more than 2D texture lights have done. I've implemented shadow maps, which have transformed the way the world looks. Buildings and architecture pop right out of the screen now to great effect, looking more 3D than previously.

Levels are no longer designed via simply placing tiles, instead all the static geometry in a level is modelled from existing objects placed together in Blender. This means I can still use the tiles but have the flexibility to add new objects as I please. I'm also using Blender to bake in the light vertex colours and create the shadow map. I will continue to use my old editor to place triggers and game items/entities.

There are some left-over texture seams and no shadow on the player's vehicle yet (hopefully I will be able to overlay the shadow multi-texturing onto combatant ships too in the end) but quite a visual improvement nonetheless.

Some of the mesh processing needs to neaten up various things still like texture seams and shadow map texture artifacts. I'll also soon set a minimum ambient light level based on the sun diffuse light being used - as some polys not facing the light source are currently rendered in complete darkness. Finally, I could consider blending ambient occlusion in with the existing shadow map.

Lighting, HD textures and campaign building

The last few weeks I've been concentrating on polishing the presentation and graphics whilst trying to put together some sort of story/setting/theme to the game as a whole. Although the story is not the most important thing in a shooting arcade game but you do need something to tie it altogether still.

I've set up a lighting system to give the scenery some more ambience and am now using high definition mip-mapped versions of the old textures. The lighting looks quite nice, smoothes out the bright flat appearance architecture used to have and will allow me to do some cool effects too but it has come at a performance penalty, I may have to consider going down to 30FPS.

Art pipeline, from asset to in-game

I've added some new generic metal alien building models to the game. These are going to be used to add a bit of feel for the theme of the enemies. The background setting is that they've set-up small outposts in various areas they've invaded. Half of them are destructible with destroyed models, which allows me to add another gameplay element/mission objective such as destroy all enemy buildings or similar.

It's so important to have a fast asset pipeline as an indie developer. In my case, as it is at present with me doing all the art, it allows for certain shortcuts. Developing tools to automate an efficient asset build pipeline has so far not being considered worthwhile enough for this project but the increasingly large amount of typed-in data is certainly pushing me to have a proper data-driven tool chain for my next project of similar scale.

First textures are created/modified if need be for the new models. Typically I just draw them straight into the relevant mega texture. Layered art backups are kept when appropriate for more complicated textures, such as scenery textures with baked lighting.

The textures are done, next we create some new models in Blender. I'll typically save all the models using one texture or belonging to one world in the same Blender file.

The next stages should ideally be automated by a tool but I have yet to find the time to build one and so I enter new data for the models (enumerator/ID, material, GameEntity type etc) by hand in the code. I also use a mesh optimiser tool I made to extract and build the exact data I need for my game from the Blender export file.

Now the new assets are ready for the editor. A little further data entry is required to get the new models to appear in the editor's GUI before they can be placed into a scene.

Save the level, boot the game up and load the level. More data entry and possibly coding required if the new game entities are to have new behaviour or functionality (this is always the case when adding a new weapon or enemy atm).

Finally, tick off the task in the spreadsheet! An ESSENTIAL design and planning aid in any project, let alone an indie game of any significant scale. Being able to get an instant visual feedback on progress made is important from a motivational point of view as well as for planning. Looking at the overall process for my current asset pipeline, they're are obvious areas for optimisation and improvement. There are currently many parts of the process where I need to enter data, where a tool could do it. It's all about the cost/benefit ratio between the time to develop a nice tool to sort this stuff and me just quickly entering values. As it is now, I don't imagine a tool is going to favourably enhance timescale on this project but creating one for multiple future projects is certainly a sound idea.

More enemies and three new weapons

New pic showing off the Rocket Launcher delivering a nice pay load. This was for screenshot Saturday on Twitter - will do a proper post update soon.

Mighty Dogbroth awakens

A good friend and fellow developer recently started his own GameDev blog. It's got some good content - check out The many guts of a think-box impact at http://dogbroth.tumblr.com/.

HUD Additions, various data optimisations

Recent work has seen the game become far more robust in handling level data. I've moved the project towards being more data driven since the editor was reworked and the benefits are mounting every day as the quantity of data for the game expands. Having spent a number of recent weeks improving how core systems in the engine function under the hood, it's nice to get back to some more 'shiny' work.

I've added another two weapons, three more enemies and some additions to the HUD, like the kill counter (inspired by a 'hit-counter' from another popular game) and an in-game message system for notifying the player of objectives, secrets and other things. The kill-counter spices up gameplay a great deal, a shaking combo award comes on screen when enough kills are accumulated in quick succession and the player receives an energy bonus.

A great many other less glamorous tasks have also been done recently. A more robust storage system for managing level data and creating it on the fly as and when needed was created to cope with increased level data complexity. A rather annoying A* pathfinding bug was fixed and the method for managing AI updates for enemies has been dramatically optimised.

New Editor

Just over two weeks ago I set out to remake the central tool used for content creation in Annihilation Arena II, that is the level editor. The main problem was the underlying data structure system that was just not designed for the expansion and new ideas that have been taken on as the game development has progressed. Whilst fixing this it also appeared like it would be a good idea to give the whole user interface a re-design too. If this tool was to be used to make many levels it had better be fairly efficient to use.

The old editor simply showed a 2D tile layout depicting the level. This becomes unclear as you put layers of tiles down. I originally got round this with blending but it's still a bit of a nuisance. A trigger zone was laid out by placing four points to define the rectangle... could get confusing as the number of triggers grew. Item and tile placement was slightly restrictive due to the fixed 2D view, no zoom. The UI system was far from intuitive but just designed on the go. The 2D editor did it's job at the time allowing me to quickly build some basic test levels to play around in but was obviously not going be adequate for the rest of the project.

The old 2D level editor

The new editor supports everything the old did and more. It will also be FAR easier to add new things to, should I need it, as the development proceeds. The new 3D view can be moved around with much greater scope. It gives you a far better feel for how the level will look in game. I've kept the scenery tiles as buttons as I prefer the quick human visual look-up rather than clicking on a drop down box. The editor is actually a pleasure to use now!

New 3D Editor

note the trigger box in red

gluUnProject fun

The old level editor I'd made was a bit of a hack that had been created to get a few concept/test levels out for Annihilation Arena II in early development. The lack of design had really began to show and it was time to make a new editor. The main difference was a push to make it use the exact same data and engine as the actual game, bringing the two projects closer together. Since I was starting afresh I thought it a good idea to do things properly from the get go and make it display everything more or less as it would look in game, in full 3D.

Having re-worked the XML level and model file formats to be far prettier and more adaptable for the future and built the core systems for handling editor objects etc. I moved onto the new graphical display for the level editor.

AAII uses a sort of 2.5D isometric view, which means some sort of coordinate transformation has to be done converting mouse coords to in-game 3D coords. Luckily for me I had the full glu libraries available since I was developing the editor in OSX rather than iPhone (there's actually iPhone versions of gluUnProject around the web if you care to find them) and this meant I could simply use gluUnProject rather than do the maths manually (although it's actually not the trickiest maths if you've got time).
Perhaps it was from working too late whilst fatigued but this coordinate conversion has managed to eat up a good few hours of time. It's very important to set up the correct OpenGL state before using gluUnProject if you want to get any sense out of it. I spent a lot of time searching around for examples for this function and whilst they are out there, they didn't take into account various things and often left users still stumbling to get it working for their own situations. So here is some commented code, highlighting the key things, which I hope helps anyone else who is finding screen to object space coordinate conversion using this function a nightmare.

// Enable depth test
glEnable(GL_DEPTH_TEST);
glDepthMask(1);
glDepthFunc( GL_LEQUAL );

glViewport(0, 0, backingWidth, backingHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(35, backingWidth/backingHeight, 1.0, 1000.0);
 
//Push the gluLookAt projection matrix onto the stack
glMatrixMode(GL_PROJECTION);
glPushMatrix();
gluLookAt(m_fcamEyeX-65.0f, m_fcamEyeY-65.0f, 100.0,
   m_fcamEyeX, m_fcamEyeY, 0.0f,
   1.0f, 5.0f, 0.0f);

// Update and render the scene
Update();
Render();

if(mouseClicked)
{
   // Remember this must be done after rendering our scene as otherwise
   // there will be no polygons there to detect depth for!
   MouseToOpenGLCoords();
}

So next I check if the mouse was clicked that frame and if so convert it's coordinates to OpenGL world coordinates. We need to call glReadPixels to supply the zDepth of the polygon that was clicked on in the view. Clicking on empty space will result in a zDepth of 1.0 i.e. maximum depth of the view frustum.

void MouseToOpenGLCoords()
{
   GLdouble dMatrix[16];
   GLdouble dProjection[16];
   GLint iViewport[4];
   GLfloat m_fDepth;

   // We need to grab the projection and model view matrices along with the viewport
   // for the conversion
   glGetDoublev(GL_PROJECTION_MATRIX, dProjection);
   glGetDoublev(GL_MODELVIEW_MATRIX, dMatrix);
   glGetIntegerv(GL_VIEWPORT, iViewport);

   m_fWindow[0] = m_mousePoint.x;
   m_fWindow[1] = m_mousePoint.y;

   // Read the zDepth of the coordinate where the screen was clicked. Will simply return
   // 1.0 if you don't click on a polygon.
   glReadPixels(m_fWindow[0],m_fWindow[1],1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&m_fDepth);

   // use gluUnProject to get the OpenGL world coordinates
   gluUnProject(m_fWindow[0], m_fWindow[1], m_fDepth,
  dMatrix, dProjection, iViewport,
  &m_dOpenGLCoord1[0], &m_dOpenGLCoord1[1], &m_dOpenGLCoord1[2]);
}

Egypt Art Push

 

With a little help from my friend the GIMP (not the leather bound type but rather but rather the GNU Image Manipulation Program) texture production has moved along at a relatively fast pace. I started using GIMP at uni because getting hold of PhotoShop or whatever other image editor of choice was out of the price range at the time. It's proved great for in-game textures but I'll stick with FireWorks for doing the UI graphics in the front-end.

Once all the tiles, wall painting and general Egyptian textures were finished they were put into a mega texture to minimise draw calls and then Blender was used to create the Egyptian Architectural models. A fair few new models have been done mainly consisting of Pillars, Obelisks, Tombs and Archways. I want the atmosphere of the Egyptian world to start coming together now in-game, so the aim was to get approximately 90% of the scenery done. It's quite likely that a bit more will be done on these later though, especially touching up of textures.

Architectural models for the Egyptian world

 

AAII Quadtree improvements

 

The Quadtree class has been made slightly more robust. Although Annihilation Arena II uses a 3D engine, it's really only 2.5D as it uses a fixed isometric view point. This changes only for cinematic NIS's on occasion but for the most part a quad tree is ideal for visibility culling as it's been relatively simple to implement and works fine within the 2.5D view point.

A Quadtree is a tree data structure with four children. They are useful for a number of things but AAII uses them to calculate which static level geometry is in screen space. To see if an object is visible we test which quad at the top of the tree it is contained in and iterate down. This means we quickly eliminate testing in large areas such as the upper-right quad, in-fact, we can probably eliminate testing on three thirds of the entire level area in the first iteration.

The Quadtree of a small level in Annihilation Arena II