Gaming Your Way

Our mate Chris has been working away on his first Unity3D powered iPhone game for a little while, and now it's available for free on the iPhone store his mind turned to pimping, and our's to getting an interview so we could pad things out a little without just looking cheap.

What I do love is the way Chris just ignores the shit in my questions and just answers the core point without rising to my bait, like I'm 12 and best just ignored.

"How did you find moving from Flash to Unity ? They seem to share a common core, but are different enough to make life interesting. How was it for you ( Darling ) ?"

In some ways it hardly felt different at all, as if they were from the same software family, Unity's version of Javascript is so close to Actionscript (for example when working on the Mac now, I even use Unity's code editor 'Unitron' for my actionscript coding) but when it came to structuring the game it really is very different.
Actually building game mechanics, levels, controls etc is really very intuitive in Unity, however there doesn't seem to be any one agreed way on storing things like player data, global game settings.
The way I ended up doing it all is with a 'gameObject' that doesn't get destroyed when moving between scenes (but this
in itself causes problems when testing then, as you don't have to test from the opening scene, and hence the gameObject hasn't been made yet.)
If someone knows a better way way please do tell me  :)

"iPhone dev via Unity, sex or a drunken wank ( Maybe with tears. Why did she leave, why ? )"

Considering what it does I really don't see how it could be any easier. It gets slightly complicated when you finally move the project over to Xcode, but then Xcode is complicated and that's nowt to do with Unity, is it wrong of me to think that maybe Apple have purposefully made this bit hard to keep the kids out?
It really is very complicated and parts of it would try the patience of a Saint, but as I said this isn't anything to do with Unity.
Maybe someone out there can let me know, is it always this convoluted when dev-ing for consoles? Are there just always weird things you have to do due to copy protection / code signing?

"Tell us about going through Apples hoops to get the game on the store, was it just like a great big hug, or more a spit in the eye ?"

It wasn't as bad as I thought it would be truth be told. From first submission to being live in the App Store took around 14 days. We had one
build sent back to us, as we weren't making it clear that the high score table was storing the user's data remotely and also we hadn't specifically requested the users permission to access the internet.
One amazing achievement is though that we have not received one crash report yet, which is testament to how awesome I really am (or that maybe I am working on a lovely high level piece of industry quality middleware with some brilliant engineers...hmm it's probably my awesomeness now that I think about it.)

"It's early days yet, but how's the game doing ? Any sort of trend apparent or is it getting lost in the zillion new releases every day ?"

It's done well for what it is, which is a first game, proof of concept. It spent around one week in the top 30 free arcade games and is now in the top 60 or so. It's been installed around 12,000 times and we've had some lovely reviews off people (many of whom commented that is it better and easier to control the Super Monkey Ball on the iPhone).
One interesting point is that we may have got more installs had we charged. This is pure speculation on my behalf, but something I didn't realise is that many of the very popular review sites and magazines for iPhone simply won't cover free games, so even by charging only 59p or something we could conceivably got in pocketGamer, Edge, RetroGamer etc.  So I guess we will be testing my theory on this for
Snowball's Chance in Hell 2  :)

"If badgers had guns, do you think they'd rob post offices ?"

No they'd rob Mash Potato factories.

I hadn't even considered that, damn he's on intellectual fire.

Now you're wet for the game, here's the all important link http://bit.ly/kill5Snowball

Never one to miss the chance to spread the word Chris told me about Kill5's competition. Let's face it, it's not a competition, it's a bribe, but fuck it, who wouldn't want an iPod Touch ?
Read all about it here, http://www.kill5.com/competition/ but come on, I've kinda earned the iPod with this article, so really don't expect to win.
( What should happen if by some fluke I do win ? Everyone is going to think we're big cheaty cheats, I've screwed myself now haven't I ).

A big thanks to Chris for taking the time to do this interview. I'm sure if anyone has some follow up questions he'll be around to tackle them in the comments.

Squize.

We're really really pleased and proud to present a guest post from our good friend Pany at the oh-so-talented UrbanSquall ( Developers of Battalion:Nemesis amongst other great games ) not to mention the words behind the always essential GamePoetry blog.

Enough of my introduction, on with the show:

Zombieland: Bonesnap Boulevard

Intro:

This is a really late post-mortem for Zombieland which was completed at the end of the first quarter 2007. Zombieland is an endless side scrolling shooter written in ActionScript 3.0. The game was written with the Flash IDE 9 Alpha, and was completed before Flash CS3's official release date. The game is still playable at http://www.newgrounds.com/portal/view/378688

Zombieland was essentially a critical flop. It didn't garner enough eyeballs to warrant a sequel, and despite some really creative ideas, and the flawlessly crafted graphics, people who played the game had a hard time coming to grips with the flawed weapon implementations, gameplay experience and jarring audio. It was a fun project that was executed in a very short time period, but a few missteps ultimately damaged the gameplay experience considerably.

What Went Wrong:

1. Audio. The music in the game is at too high of a volume, and the compression was set too high. The result is that long before you ever see anything approximating a mute button you are assaulted with an overwhelming blast of scratchy static-riddled music. I suspect many potential fans of the game were lost in the onslaught of those first few obnoxious seconds. The great sadness is that the music is actually pretty good. A few minutes could have fixed these problems very easily.

2. Questionable design choices. Random is not fun. The game uses a very basic algorithm for deciding what sort of enemies to spawn and at  that frequency. I think this only barely worked. Static levels would have taken longer to produce, but would have been inherently more interesting. Combined with other design blunders, like the constantly moving forward main character, the weak default weapon, and shoddy collision detection, Zombieland scared off most players long before they could come to appreciate some of the funner aspects of the game.
I'd say our rushed development schedule was partly to blame here, but it was also partly a lack of objective oversight.

3. Syncing gameplay and animations. In Zombieland, the majority of events are queued off animations. Firing, reloading, taking damage are three examples where I let the speed of the action be determined by animations. This could have been fine, except it clashed horribly with the fact that the character is supposed to be constantly moving forward meaning we had to do ugly tricks to maintain the illusion. The result is that most core actions in the game are very unresponsive which multiplied the negative effects of poor collision detection.
This was just a naïve misstep that was avoidable with a very simple design change.

What Went Right:

1. Graphics. Tim Wendorf, the artist for Zombieland, nailed the visual aesthetic. The 2x look, combined with the slick character designs really make the graphics the best thing about this game. There is a distinct possibility the game got away with its crappy core gameplay mechanics during development simply because of Tim's quality graphics.

2. Inventive zombie designs. Again, I have to credit Tim's warped sense of humor for coming up with some of the more memorable moments in the game, like going toe-to-toe with a wheel chair zombie, or having to face a stream of zombie porcupines tossed by an angry zombie cowboy. The Zamboni Wamboni was all mine, though.

3. Quick turn around. The game took less than 5 weeks of near full time development. We didn't hit any snafus along the way and we delivered the final build ahead of schedule, despite the fact that I was still coming to terms with a new programming language (ActionScript 3.0) and a new content pipeline (bitmap tilesheets). We shipped the game with gameplay flaws that only became clear after the dust had settled and it was too late to do anything about it.
Scheduling wise, though, Zombieland was about as good as they come in terms of everything just coming together right.

Conclusion:

The hindsight of almost two years since the game's release has given me some time to reflect on why Zombieland failed to achieve the success I thought it was due.
The most valuable lessons I can take away from Zombieland, at this time, is that I should avoid integrating slick graphics early in the development pipeline, and instead focus on prototyping and nailing the core mechanic and avoid getting seduced by a pretty presentation.
A part of this is getting more feedback on the gameplay mechanic, especially in those earlier stages, which can help identify issues with a poor random level generation algorithm, or crappy engine limitations, like bad collision detection and animation-based timing dependencies.
I'm hoping fate allows me another opportunity to revisit the Zombieland setting, as I think it was under served by a few key bad decisions that spoiled an otherwise solid game.

Panayoti Haritatos / UrbanSquall