GamingYourWay - Post Mortem

Ionic: Post Mortem

Squize — Fri, 30 Jul 2010 15:49:54 GMT

More looking at the past as a filler whilst we wait for the future to become the present.

Ionic, our first ( And quite possibly last ) crack at a Tower Defense game.

What went right:

Visually I think it's very strong. It's a good looking game. That was helped a lot by Lux jumping on board really late in the development and giving everything a lot more love, as well as designing the baddies.

It's not a typical tower defense, which was the objective all along. I played a lot [ Of TD's ] when developing Ionic and I was amazed by the number that allowed you to fast forward during the actual "Combat" part. That to me defeated the object totally. I'm placing my towers so I can see them shoot the crap out of the baddies, it's the money shot and that's what I want to see, the pay off for saving up for a nice new tower.
Any game which allows you to bypass that just strikes me as strange, you may as well just reduce it to a text response, "2 creeps got through, 12 were killed, next wave in 3,2,1...".

The game feels arcadey, which was the one design philosophy that ran through it's dna from the very start. I could see the appeal in TD games, but couldn't really enjoy them. The plan was to make it feel like a strategic R-Type, it needed to feel like a real battle as part of a much bigger on-going war. Every shot, every explosion counts.

Adding in the management and repair aspects, although I see those as a plus, I think we're going to touch on them again in the negative pile.

There's a lot of love in there, I really like the empty shells coming off the cannons or the blue flame in the flame thrower or the 10 or so frames of animation when the coin collecting droid is launched or the wolf growl that's mixed into the cannon shooting sample to create that guttural raw feeling.

The ADD blendmode. It's a thing of beauty and even though it has a performance cost it's worth every cycle it steals. Using pixel bender for the RGB split worked really well too, much quicker than the one in cronusX, allowing us to use it real time rather than just for transitions.
Two pluses for Adobe there then, rather me.

I got the word bitches into the end credits. Rock 'n roll baby.

What went wrong:

The asset management was done early in the development. I got it working, it felt nice, with the idea being that if people wanted more depth they could tweak things to their liking and get more out of the game.
If you just wanted a pick up and play, then you didn't need to touch it and still be able to complete the game.
With doing it early on it was counted as done and dusted. I never touched it once after that. That was quite a mistake as it transpires that just be setting one of the sliders to max straight way ( I can't recall which one, I'm guessing R&D ) you can unlock all the cool weapons really early and basically skew the difficulty level in your favour.

Bollocks.

The coin collecting droids. Although I love this feature, it was a headache to code. Every week or so I would notice that the previous fix hadn't fixed it. They were literally the worst bug throughout the entire development.
So I did what all coders should do, I put a nasty kludge in there. If a coin wasn't collected after a certain amount of time I assumed that the droid was going to ignore it, so I just killed the coin and added it to the players credits.
What a mistake. Even though it was explained in the docs, people still noticed it and wouldn't have it that they hadn't lost out. Also people assumed that if a coin went off screen by the player scrolling they would lose it as well.
Players like to see something happening to confirm it's happened, implication doesn't work well in games. Another lesson learned ( cronusX had a similar issue, with baddies teleporting in on the player. Even though a shield appeared and the player was never ever punished for that, as that would just be really poor design, because it wasn't communicated well enough people still thought they were being punished unfairly, i.e. poor design ).

The walkthrough. Our mate RobotJam warned me about doing one, saying they're a waste of time. At the time we weren't getting the interest in selling it that we expected, so producing a walkthrough was a final role of the dice, a way to give extra value to the sponsor.
Rob was totally right. A complete waste of time, and painfully boring to make.

Balancing a TD is a complete bitch. It is so so hard to do. I looked at so many TD's to see how they did it, and very very few do it well. A lot just extend the game by adding far too many levels compared to the actual content. I think we had 25 levels in this as any more would just be grinding and slow the whole progress of the game down.
I think we got the balance quite good in the end ( If you ignore the bug mentioned above ), and it's here in the negatives as it impacted badly on the development time. It's one of those things you know are going to be tricky to do well, but it's far harder when you actually try and do it.

Similar to the balance was the whole GUI. I think we did a good job, but trying to please everyone is impossible. The best example is scrolling the dreadnought. I added 3 methods, arrow keys, clicking the radar and a drag bar. In total there was 7 suggestions on how it should be done, including some borderline venomous comments about it not supported A/D, as if by omitting those I was somehow spitting in the players face.
Getting a large amount of information to the player without forcing them to sit through pages and pages of text is very difficult, and something we spent so much time on.

Crisis of confidence. This is a tricky one for a developer to admit to, you very rarely see it. I have certain comfort zones with development, some genres I can piss all over without a thought Not that I'm especially good, just some genres click better than others. Ionic was well outside my comfort zone, so I found myself taking on board what everyone said which created a lot more work, and the more I listened the more I felt I was missing the mark and going out of my way to compensate.
When you have a lot of peers you really admire giving you suggestions, and your image for the game isn't a 100% clear, then it's very difficult to just shut down and pick the most relevant ones, they all seem relevant.

The attack waves, something I should have been strong at doing, were average. By that point I was getting sick of the whole thing, so I rushed through them to get them done. They're ok, but they should have been a lot better.

We're nearly at the point where I wrap this up with a "I couldn't give a fuck if no one likes it, I still think it's the best thing I've ever done" type comment.
Firstly I want to express how much I dislike devs who feel like they have to defend their games too strongly, you create entertainment and put it out there for people to enjoy. Not everyone will, like not everyone you meet in life will like you, no matter how cheeky your grin or funny your words. It's part and parcel of putting something out for public consumption, if you want the praise you've got to silently and with dignity swallow the crap that comes with it.
All that build up is of course there to explain that I'm going to break that rule, I'm going to be a whingy little bitch. Our blog, our rules. I'll regain my dignity tomorrow.

"we can't imagine why the developers neglected to offer the [A] and [D] keys to pan from left to right—it would have made a substantial difference in accessibility".

"Substantial" ? Really ?

"this is turning into a clickfest"

Yeah, it's murder isn't it, having to click things, in a game of all places!

"flamethrower in space void?!"

Fuck off.

I thought I'd feel better for that, but I don't really.

Let's finish this off now. Never do a game with a complex GUI. Everyone has their own favourite way of interacting with things, as I've mentioned there were in total 7 ideas for something as simple as scrolling the dreadnought. Let me clarify that slightly, do it, but expect people not to be happy so have a thick skin ready.
Conveying lots and lots of information is extremely hard to do in an non-obtrusive way, it has to be filtered out gradually and you've then got to take into account a lot of people will still just ignore it. Nothing can be implied, everything has to be spelt out ( Thanks Nintendo for creating a generation of gamers who don't want to fill the gaps ).
In terms of how the games performed, it's had 944,316 plays, which is poor. It received so-so reviews most places, 3.72 on NG, which isn't great.

Overall I'm disappointed with it's performance, I really do think it's the best thing I've ever done. It has faults, in amongst the feedback which pissed me off there was some really good points which I've taken on board.
Like cronusX I can still enjoy playing it even now, it has an almost emergent game play which as a developer is great, it makes it very hard to get sick of which helps development a lot.
I think it's great, it's fun to play and I learned a lot from it. I think that's as good as it gets.

Squize.

cronusX: Post Mortem

Squize — Thu, 22 Jul 2010 21:04:49 GMT

A post mortem on cronusX is well over due. Even though the files aren't online right now ( The webhost the files were on got hacked, and it turns out their talk of backups was a big fat lie, so they just closed rather than restoring things. Nice one ) we did document every day of it's development.

I will re-upload all the files when I get chance.

What went right:

The development diary, which I've already mentioned. It's something we're definitely going to be doing again on the right project ( So many are covered by NDA's, others are quite risky and there's no need to fail in public ).
It really gave us focus and allowed for really quick and great feedback from you dear reader.

The look & feel. I'm really pleased with how the game looks. The screen shake when the asteroid hits the screen during the attract mode is pretty sweet ( And if you've got a 360 joypad plugged in you get a cheeky rubble ), the rgb split transition works nicely ( There were some comments that it took a little long, some comments I just choose to ignore ), the between level tips are a nice touch too, even though one was broken that no one noticed which got hidden with a nasty 11th hour kludge.
Olli did great work with the players ship, the asteroids and the title screen animation. Funnily enough it's the closest we've worked together on a game, and it was really smooth ( I'm sure I'm looking at that with rose tinted spectacles though, I'm pretty positive I pissed Olli off untold times ).
The curved text was a pain though, as I didn't use code to curve it, so it meant using the art package for every text amend. Painful.

Code. It's a really solid game code wise, it uses our distance based broadphase collision routine which worked perfectly for this game. Also procedurally generating the background was really cool, something I'm proud of. The data mining in there is pretty good too, with Olli doing the clever server side stuff.

The game itself. I really enjoy playing it, it's a good game, and that's the best I can ever hope for.

What went wrong:

We had this really good data mining system, and just failed to use it. I did code up some widgets but they never went anywhere.

A real waste, but there comes a point of diminishing returns.

The sponsor requirements meant that we had to rename it, which I wasn't over the moon about, and actually remove some features. This meant that the version on Candystand isn't as good as it should be, which is a real pity.
( Just for the record, Dave @CS was a joy to work with, I'm really not criticising Candystand in any way, it's just frustrating removing working features ).

We experimented adding twitter support, being all web 2.0. Total waste of time, it was badly implemented, took far too long to add and no one used it. Lesson learned there.

Old wip grab

Survival mode. Another important learning point. I thought adding a half arsed feature to increase the "value" of the game was a good idea. It turns out that players expect things to be good, rather than just tacked on, crazy talk I know. The perception isn't that it's a bit more to the game, which is how I saw it, it was treated as integral part, and seeing how it was weak we suffered because of that.
Fair enough, it's not something I can argue against.

No one liked it. Ok, a little bit exaggerated for dramatic effect, but it did fall between two stools. Old gamers were expecting Asteroids controls, and were disappointed that we'd gone "Dual stick" with it. New gamers who didn't grow up with Asteroids felt it was lacking in other ways, such as a lack of bosses ( Amongst many other things ).
Basically we hit the middle ground perfectly, which pissed off both sides ( Spoiler alert. The Ionic post mortem is going to end the same way ).

It got an ok-ish 3.80 on Newgrounds, died it's death on Kongregate ( Naturally ). I honestly don't know what it's done traffic wise, we weren't allowed our own tracking in there, the moch-ad figures say just over 385,000 impressions, so add in the skips and the site lock plays and we're looking at a piss poor million or so hits. Nothing really.
This is why the widgets never saw the light of day, there's only so much time you can throw at a project that's not going anywhere.

Before this gets too pessimistic and ends on a low, it's a game we're proud of and it's still fun to play even now. I'm more than happy to have it as part of the GYW back catalogue, it represents us well ( A technically good, pretty game that no one likes aside from us ).
If this was the last game I'd ever written I wouldn't be upset.

Squize.

Invaders Must [ Explain The Process ]

Squize — Fri, 13 Feb 2009 20:07:22 GMT

We couldn't let a Friday the 13th pass without some sort of post.

If you've got any interest in the process of making an adver-game, the always lovely gamepoetry ( Check out the 4K comp there, there's a link under our logo above, see it ? Yeah, give that a little clickity click click ) have an exclusive post mortem from us ( As pay back for their great one for Zombieland we presented here just before Christmas ) about our recent Invaders Must Die game.

And hopefully that's the last time we mention Invaders here, as it seems to be all we've spoken about in the past couple of weeks, and we're bored of it too now.

Squize.

Post Mortem ZombieLand : Bonesnap Boulevard

Squize — Tue, 23 Dec 2008 15:50:12 GMT

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