Last Minute Hero: Beta and Submission

September 23rd, 2010 by Shaun Milne

So I've not been doing the whole development blogging thing lately *slappy handy* But my first appstore game is complete and submitted to Apple for review. Hurrah! :) It was submitted about a week ago, so that means total development time from concept, prototype to production and public beta testing took 10 weeks and a day. It'll probably sit waiting for review for a while, not sure how long these things usually take on Apple's side.

So much development stuff has happened over the past month it's been hard to keep a note of it all, so I'll post the highlights.

First of all, we have a finished game, it's titled "Last Minute Hero". The aim of the game is to survive as long as possible with limited ammunition. You can't be killed in the game, but if you fall within the range of a spider attack (or hug) you'll be stunned for a short period of time. See, unlike other survival games, in Last Minute Hero, you will not survive. A Happy Nuke clean-up missile is on it's way, and you have 60 seconds to make the most of it! For every spider you take down, you delay the missile's progress, pushing the clock backwards. There are 4 unlockable weapons in this release, all designed to be used tactically against the spider horde. For example, freezing them with the laser rifle, will lower their defence against other weapons! An online leaderboard keeps track of your current best time ranked among all players in the world!

The beta testing was a huge success; I initially opened up a small amount of limited slots for testers to apply through iBetaTest.com, a really good free service that makes test management easier. The slots filled up within 20 minutes of me posting, I also had a few people contact me through the toucharcade.com forums who wished to participate also. The feedback was really varied; some people commented on the game speed, others on graphic improvement suggestions, while others on the difficulty curve. Overall, their impression of the game was positive, so this gave me a bit of confidence to make changes and polish the game before final submission to Apple.

Polish is a bit of an understatement; at some points I completely recreated some of the textures I felt did not really capture the style I imagined. I also added support for bloom lighting on opengl es 2.0 devices, which adds to the Tokyo/neon lighting vibe I was after. The results look pretty good. The graphical changes and the implementation of the changes suggested by all the beta testers, pushed the game back by two weeks from my 8 week deadline. I think it was well worth it though. A huge thanks to everyone who took part in the testing, I owe you all a cold beer.

All that's left to do is prepare some information to send out to certain blogs, update this webby with game information and wait for Apple to hit the big old acceptance button.

I've started prototyping for my next project as well, so we'll see what comes out of that. Will post up my favourites as they are done. :) I'm also working on Game Center support for Last Minute Hero, for the next update, as well as a new game mode with achievements.

I'll have an in-depth project retrospective posted soon as well, in the form of: "5 things done well, 5 things to do better".

Almost forgot to mention, the game features a tune by the very talented Sabrepulse, he makes music on the gameboy. It's awesome! It also fits the game perfectly, as I was playing the track almost constantly while developing the gameplay. Creates an added sense of urgency, when you spot you have 10 seconds remaining, and only a few rounds of your shotgun left!


Dev Snapshot 03: Problems Sir?

August 7th, 2010 by Shaun Milne

Game development is risky. There's a risk there might be a pipeline problem half way through. There's a risk there might be a game breaking bug. There's a risk the end product might not actually be fun. There are hundreds of risk factors.

Most likely, no matter how hard you prepare or think you are prepared in advance - something will go wrong. It might be small, but it will happen. It's like our brains force it to happen.

My method of risk management initially involves imagining all the possible problem areas that can go wrong before the project starts. I do this partly by imagining the complete development process, the tasks that need to be completed, the pipeline and flow and order of tasks. This also acts as a sort of vision, a goal that I'll work towards, day to day, to keep me on track. Our brains can work a lot faster than we can physically, it won't solve it for you, but it might make you more aware of potential pitfalls - on a subconscious level or not.

There are some risks you can't avoid however, and these are usually third party risks out with your control. My problems this week have revolved around the Unity beta crashing almost constantly when building for the device, and the implementation of OpenFeint for leaderboards. The unity bug is now resolved with the latest patch, but I think I won't be implementing OpenFeint after all, as my initial tests proved it to be slightly sluggish on the iPhone 3G. I hate implementing leaderboards, it feels like I do them at least once a month!

Next week, I'll be doing the dreaded sound design of all the enemies, designing and adding some sweet weaponry and hopefully finishing up the user interface and overall flow. The gameplay is coming along nicely, just needs some balancing work and more behaviours. I think this is the end of week 6, and my planning is only for a total of 8 weeks broken up into 4 smaller, 2 week sprints, so I guess this will be the final push. \o/

And then it begins again.


Dev Snapshot 02: Lightmapping

August 1st, 2010 by Shaun Milne

StarCraft who? Actually, before you jump to conclusions, no, I haven't been playing it instead of working. In fact, over the past week I've managed to get heaps of stuff done. Too much to even bother listing here, and some of it is pretty boring code stuff* anyway. So I'm going to talk about object management.. hell no! Here's a pretty video of the lightmapped environment I made last week with the beginnings of gameplay thrown in.

*Actually, the boring code stuff is actually pretty useful object management optimisation stuff, that'll I'll create a separate post about in the near future.


Dev Snapshot 01: Animation and Skinning

July 22nd, 2010 by Shaun Milne

Blogging a bit early this week as I've made some good progress with the character animations as well as working on the feel of the character as the player navigates her around the battlefield. It's no way perfect but I'm learning a lot about animation as I go, especially for low-poly, 1-bone-per-vertex animations. It can be tricky to make them look and move naturally with such restrictions.

Uploaded a quick video snapshot (because still images are boring) :) Ignore most of the things in the video, they are pretty much all temporary. The controls aren't shown, but it's basically a joystick to control movement, a button to jump and a button to fire your weapon. To lock on to an opponent you tap them.


Prototype Development

July 17th, 2010 by Shaun Milne

Has it really been two weeks already, wow, I need to update this more often.

I've been busy making concept art, and playing with ideas these past weeks and have settled on an idea for my first iPhone game that I'd like to make to break my app store virginity. I'm sure it won't be as painful, or full of the horrors that I've read about on the rest of the Nets. Think happy thoughts, and pray.

Received my beta copy of Unity 3.0 a while back and it is truly great. The Beast lightmap generator/renderer is awesome, and saves you having to bake your models the old fashioned, more time consuming way. Just setup your scene in Unity, flag all the game objects you want to bake as static, and hit the bake button.

Unity 3 Feature Preview - Beast Lightmapping from Unity3D on Vimeo.

Prototype development is always fun, you get to try out new gameplay styles without feeling like you're fully committed. In fact, a successful prototype will probably tell you more about what doesn't work in terms of gameplay than what does. Of course, you just discard what doesn't quite work and use what does to refine a better prototype.

One of the biggest design challenges on the iPhone, I think, is the control mechanism for a game. A lot of simple, successful games on the app store are single touch or tap based games, usually revolving around a simple, well-defined gameplay mechanic. I wanted to have a more complex gameplay mechanic (but involving intuitive gameplay) that would be based around controlling an onscreen 3rd person character, so a virtual thumbstick and buttons seemed like a good choice. Having just played through MikaMobile's OMG Pirates! I feel the virtual thumbstick works pretty well as long as it's super responsive.

So, after making a semi-successful prototype of the gameplay, I moved on to the fun part of fleshing out the original character concepts with some 3d artstuffs. Blender is my new BFF. Seriously. It's hot-key heavy, but damn, when you learn those hawt keys it makes you super productive, like some sort of vertex pushing ninja or something. This video on youtube gives a no-bullshit speed walkthrough of most of the hot keys. It's for blender 2.5 alpha but it still applies to the current full release. Oh, and blender is 100% free. A few hours in and I'd mocked up a low-poly concept of the main character and unwrapped it. I'm going for a cell-shaded anime style look for the game, but without the outline borders so it'll be more subtle.

First character unwrapped and base colours were applied.

Rigging the character was a little more difficult. IPhone performance isn't too hot on the best of days, so I was aiming for a one bone per vertex ratio to keep things speedy, and also to be able to support the iPhone 3G, which is my minimum target platform. Unfortunately, I couldn't find an easy way to initially automatically weight my character using a restriction on the numbers of bones per vertex. Blender has a great scripting API available through python, which unfortunately for me is a language I'm not too hot with. Still, 2 hours later and I'd hacked a simple script that loops through the mesh's vertices, extracts their weight/bone influences and reduces the bone count based on the weight ratio of the currently attached bones, culling the lower weighted bones until the target amount is remaining. I'll post the script here later for anyone looking for something similar, after I give it a bit of a clean up and maybe a rewrite or two. I still suck at python. I keep trying to read through the documentation but the Monty Python references might as well be links to the youtube sketches, as that's where I usually end up!

Test animation of rigged character in blender.

So a good start overall, and I've learned a lot about my asset pipeline and hopefully reduced any potential risks or worries I had about the gameplay in the beginning with the prototyping. This week I'll probably be throwing my prototype code away, and setting up my sprint plan for asset creation and coding tasks. I'll be using a free web tool called Pivotal Tracker for my project management, as it is really great and has a sweet API. Also, I switch between Mac/Windows so a web tool is ideal. Check it out if you're into agile, even if you're a one man show like me, it really helps planning your time out and keeping track of tasks and bugs.

Recent Comments