It’s been a year since the game was released, and it was quite a journey to get to this point. With this article, I want to talk about that journey. Planning, developing, communicating, and publishing the game.

I will post some lessons that I have learned from making this game.

The Beginning

Everything began with a discussion with Gonzossm – a popular animator from youtube, a really good friend of mine, and the future artist/animator of Deadly30. We had never worked on a game together prior to this, but the eagerly awaited event was right on the doorstep. The idea we had in mind is to make a simple flash game, playing as a character surviving in the wild that would involve tower defense elements and exploration for resources.

We thought the idea was interesting and unique, which would probably take us less than a month to make and get us some quick cash from a sponsorship and licensing from flash game sites. Plus we had nothing better to work on anyway.

Trying To Design

The first design was actually based on a completely different theme from the final. You would play as a king who builds up his castle with resources he finds outside, to defend from crazy animals at night.

I don’t really remember exactly how we went from that to shooting zombies with guns. But I remember we liked the idea of having special kinds of character classes for different tasks, think of TeamFortress2.

• Assault – The one with powerful firepower.
• Engineer – A mechanic who builds turrets and repairs walls.
• Medic – This one is obvious. Hint “healing”.

Not long into the design, it showed that it would be impossible to play the game if one of the classes wasn’t around at all times. So we instead mixed the abilities and went only with a weapon class system.

• American – Uses automatic machine guns.
• Russian – Uses long-range and sniper rifles.
• German – Shotguns, can’t miss these in a zombie apocalypse.

The problem with the design is that that’s all it was – three characters that utilize different weapons, who upgrade and defend their base at night from evil zombies, and go out searching for resources when the day comes, oh and make it last 30 nights!

At the moment it seemed fine, what more did we need to know? Well, how about the huge amount of technical details that were completely overlooked. Our “design” sounds more like a scenario from an action movie.

For Example:

• Controls? What moves can the player execute?
• Any distinct enemy types? cool mechanics?
• How do enemies spawn? Different for night & day?
• How long does a night & day last?
• How far can you explore? Any limits? Endless repeating background?
• What resources can you find? What can you do with them?
• What weapons and tools do we have? Are they all interesting?
• Do we have enough progressive content to last 1 – 30 nights?
• How about balance? and strategy?
• And a million more things!
• We blindly began working on the game from a simple concept, as if we knew exactly what we were doing.

I strongly feel this was a prime factor that crippled the whole game. We began noticing huge design flaws halfway in the game. A good example would be at the moment in development where zombies were all kind of.. the same and plain boring, walking and attacking with their hands.

This is when we decided to add drumroll a crow! A sad attempt at trying to add a new gimmicky gameplay element, with different movement and attack.

Adding it to a system that was designed only for walkable enemies caused tons of bugs. Turrets and AI companions were terrible at dealing with something that wasn’t on the ground. The attack of a crow was pointless too, once it got close to a survivor it died by getting slashed, doing no damage.

This was only one of the problems when adding a new feature in the middle of the game to a system that doesn’t support it. If only we had invested some time into thinking about technical design it would have paid off immensely.

Lesson 1. Games are much cheaper to make on paper.

I should, however, note that you can’t design a complete game from the start. You will get interesting ideas as you go along, sometimes it works, and other times it’s like a dead-end in a labyrinth. Which will cost you dearly once you decide to turn around.

Let’s Get To Work

The first few weeks of work kept steady progress. One thing I really liked is how Gonzossm presented the artwork to me. It was a bunch of simple sketches that quickly gave the feel for what the game might be. It also allowed us to make any graphical changes without sacrificing a lot of hours as it would if the artwork was finalized.

The code was in ActionScript 3.0 with decent object-oriented principles. I spent no time thinking about a game architecture and got right into the code (Again a poor decision).

1. Clashes in Development

When you have two people working together on a single game – an Artist, and a Programmer. I think it’s important to have both members doing game-specific elements.

For example:

• How much health do green zombies have?
• How many zombies do we spawn at night 8?
• How much scrap metal can you find each day?
• Properties / Statistics / Balance etc.

This was not the case with Deadly30. I did blame Gonzossm for it, as if his thinking was “I’m an artist I do art and animations for the game, Iggy is a programmer, he will deal with all the numbers”.

But I come to realize that in fact, it was my mistake as a programmer who failed to give the right tools to the team. Game scripting is what I’m hinting at, which would allow anyone to edit simple text files that store properties for game elements with no need to recompile the game. Deadly30 had no scripting. Everything was hardcoded, only for my eyes, yet I was angry at Gonzossm for leaving me on my own in this area.

The final game turned out to be coded and balanced all the way by me, with some feedback from a few testers. Gonzossm took care of the aesthetics – art, animations, cutscenes, he also licensed music and voice actors. Which was great, I couldn’t have done better, however, I strongly feel we did a poor job working as a team.

Lesson 2. Work closely with your team members.

2. Hopeless Hope

A few weeks into the project you have your player running around, shooting zombies and repairing the fences. You think to yourself “Yeah this game is definitely going to get done by the end of the month”! And right after that think, “Oh why don’t we add this feature, it would make the game so much better”!

Well, that’s pretty much how the entire development process went on until the end. Lack of direction but a constant stream of new ideas on the go. My list wasn’t getting any smaller, and I could not predict the next thing to expect on it. This was very bad, because how can you design a system for something like that? You’ll have buggy code, or end up spending hours rewriting it again.

Worst of all it feels like this hell is never going to end. The problem here is you never estimated how long the game would take you because quite honestly you couldn’t have, not with the sort of design we had. A month seemed reasonable back then, which at the end turned into 7 months.

3. The Hellish Phase

I think most game developers can relate to me here. Yes! That moment when you’ve been working on the game for longer than you should have. You start to HATE everything about your game, it just seems plain stupid and boring. Why are you working on this? The code is a mess, the design is flawed, the best thing that comes to mind is to start a new project. Start with clean design and clean code, that’s a very strong temptation!

I think after the first month of working on the game that’s when I felt it. It’s very demoralizing when you can’t trust your own deadlines anymore.

I have to say that the hardest part of making Deadly30 was this hellish phase of development. I almost gave up a couple of times. What got me through is the support of the people who believed in the potential of the game.

The only thing I can recommend in this case is to keep yourself motivated. Work on the things that you enjoy, work fast and keep a steady progress.

Lesson 3. Progress is a powerful ingredient to motivation.

4. Unexpected Surprises

If you started out to make a simple flash game, then do that and just! We didn’t and it bit us.

We chose Flash because it’s easy to use and a great platform for simple lightweight games. But once we turned our small game into a big game, this was a bottleneck we found ourselves stuck in. Something of Deadly30’s size and requirements really pushes the border of Flash. All graphics were stored inside “Movieclips” as vector graphics which are rendered using CPU (I can’t stress it enough how slow this is). This problem is tightly related to design and careful planning for your exact needs.

Another thing is that we used a non-standard resolution (750 x 460) because it doesn’t matter as much for games you play on the web. Imagine the surprise on my face when I figured we had to be able to run the game in full-screen.

The biggest question people are still asking is “Why isn’t this game multiplayer?”. Because quite frankly this game looks like the kind of game you would play with your friends online. Unfortunately, this was another case of poor planning and another one of those things we couldn’t foresee in the beginning. In hindsight, we were limited by the capabilities of Flash, something we should have looked into earlier.

Publisher / STEAM / Greenlight

When the game was nearing completion, or rather a state it was mostly playable, it was looking a lot better than something you would play on web portals.

Games like VVVVV and Binding of Isaac were both made in Flash and had success on Steam. This is when we decided to try our luck with getting Deadly30 on Steam.

Gonzossm and I put together a little trailer for the game to raise publicity for the game, in hopes get good feedback from the community and be able to show it to Steam.

Gonzossm is very popular on youtube, so we used that to our advantage with the trailer. After around 120,000 views and lots of amazing comments on the trailer, we sent out the application to Steam, to which they never replied. Not even mentioning any reasons why this might not be a game for their platform. I understand they are big and probably have too many applications to go through each day, but I felt it was very unprofessional. Like an option to answer or ignore an incoming call there should be a reject button, so people wouldn’t be waiting for many months in hopes.

Not long after that Gonzossm received an inbox message on youtube from a publisher by the name of Headup Games, they were very interested in publishing the game. They were so sure the game would get on Steam as if they knew someone on the inside. I personally thought that was a great catch, maybe that’s how all games get on Steam in the first place? I wouldn’t know. I’ve never dealt with retail publishers before, all this was completely new to me.

So they asked us for a 50% cut of the profit. I spoke with Gonzossm and a few friends about it, and it seemed like a reasonable cut. “They get us in, we both make a lot of money!” So we agreed on it, signed a contract and got to work.

Many months in and the publisher had no luck in getting the game on Steam either, what a shame. Now we were pretty much self-selling the game on Gonzossm’s advertising power. The only people buying the game were his fans from youtube and facebook, and we were giving away 50% profits for what exactly?

Now I’m not saying the publisher didn’t do anything at all. They spread the product to sites like Amazon, Desura, Gamersgate. They also got many review websites to write about Deadly30. It’s important I just don’t think it’s worth fifty percent.

Also many thanks to everyone for buying the game, it keeps me independent for the time. In total, I believe the game made over $100,000+. Not very sure of this though because all the sales information goes straight to the publisher, I only get my cut later. I have no control, no stats, and this is very bad.

There are serious costs to pay when you surrender control. There are definitely times for publishers, but I’ll be self-publishing my next game.

Lesson 4. Do it yourself first.

Final Words

Sometimes when I look back at this game I think of failure. Probably because there were more mistakes made in development than there should have been. Still, regardless of the faults, this is the biggest game I’ve made, and I’m proud of it.

It was an expensive learning experience which I’ll never forget.

Thanks for reading!