This is a postmortem for Garden Wars - it can be summed up as a definitely-not-profitable project, that almost pays for itself in other ways (but not quite).

The Game:

Picking a new project

After finishing Swing Racers, I thought I'd have no problem finding another project to commit to - I had about 75 game ideas jotted down over the last few years. Sadly, when it came to pick one, none of the ones I could actually make fitted my current view of what could be successful. So I ended up feeling a little bit panicked. I worked for a couple of months prototyping a freemium Cat Drifting game where you had to flick toys around on a slippery surface and make a cat smash into things for points. I decided my design was a bit flawed for a touch screen and abandoned it (and I'm glad I did).

Months had come and gone - the wife is going to work and making money like a normal person and I'm not achieving anything. I had to commit to something and I had to learn UE4 while I was at it. I thought I'd better develop something "easy" as practice (with UE4 and other platforms) - so I decided to pick an existing game mechanic that I knew worked, boil it down to the basics and apply it to a unique theme. At the time I thought it'd be a good idea to simplify a strategy game and theme it for a casual, "not-usually-gamers" audience.

So it became a toonish-styled garden strategy game called Garden Wars.

How did it go?

Even though it was a "practice" project, it took waaaay longer than it should have. I was aiming for something more like 6-8 months but it took about 13 months to get it Steam-ready, then it was another 4 months until the mobile release (I probably could have released it simultaneously but it just felt a bit rushed, and I didn't want to release with the Christmas flood).

The intention of the Steam release was mostly to get my head around releasing on Steam - units sold there would just be a bonus. Good thing too because it's sold bugger-all there (matched in the first 3 days of being available on the App Store). At this point, based on the time spent, I'm expecting it to make about 20% of what I'd call a successful total (across all platforms)... and my standards are pretty low, too. It'll make about 20% of what the previous game did (Swing Racers was a UE3 game that I released on iOS only, that took maybe 6-8 months to make).

Why did it take so long?

Quite a few reasons - I'll try to put them in order of significance:
 

1. Multiplayer

Multiplayer makes everything take 5 times as long, maybe more, in my opinion. Every little event or action that happens, you have to go through exactly what's happening on the server, what's happening on the client, and control it explicitely. It takes even longer when you've never dealt with multiplayer before, and you're on your own. Sheesh what a headache. It probably added 3-4 months of development time in total, I think.

Multiplayer was really only there to add value to the Steam release (and again, as practice). In the end, I don't think it even got used at all, not even once (except during testing).

BUT, it was quite a fun challenge to get my head around it and release a multiplayer versus game to the public, and it has provided me with a ton of experience that I really need (see conclusion).

2. Steam & Greenlight

Games being released on Steam I think require a bit more polish and attention than your average mobile release, so I spent a long time adding small features and polishing the game in general.

I also spent I'd say a good 2 months creating really basic promo material for greenlight (though it shouldnt've have taken that long).

3. Being a "compiled" (code) project

Nearing the Steam release, I was running into multiplayer issues and leaderboard limitations, and the only solutions seemed to involve code changes and plugins. What that meant for me was: I needed to actually make UE4 C++ changes and compile the engine.

Of course, this adds compile times to the mix, along with a more complicated engine upgrade process... and I don't really know what I'm doing with visual studio either which was a tad scary. But even worse was: it meant I needed a Mac just to build and package for the iOS version (you can do everything from a PC if you don't recompile the engine). So that was more new territory for me. On top of that, there seemed to be a bug with deploying directly to my device from the Mac, and I really couldn't be bothered going through the steps needed to get support. So I just uploaded builds to testflight and installed it that way... which cumulatively added a lot of time.

To rub salt in the wound - I probably didn't need the code changes in the end, and the extra plugins I used were for very small Steam/PC/Multiplayer features anyway, so I could've avoided being a compiled project altogether! Next time, although it'll have to be a code project eventually, I'm going to avoid it for as long as possible to keep things simple.

4. Being a Strategy game

Even though I had taken an existing strategy mechanic, it still took quite a lot of time continually balancing things. Energy generation rates for different difficulties, scaling for multiplayer, making sure the AI was always balanced enough (because that's all I had to test against). Developing a full RTS would be extremely hard even if you were just remaking something - I can't even imagine how hard it would be to balance if the mechanics were completely original.

5. Toon art style

Being more of a designer than an artist, I find it easier to re-create realistic or real-world stuff than actual drawing, so doing something in a toon art style was very hard and time consuming. I spent a fair bit of time learning Inkscape so that I could create all of the art in a scalable fashion.

6. Cowboy development (& not reading my previous postmortem)

Despite writing a concise postmortem for Swing Racers and having the best intentions, I basically ignored most of my own advice and developed with very little planning or discipline. I didn't have tasks lined up and ready to go each day (nowhere near as well as I had on the previous project). This resulted in a lot of wasted mornings, only getting productive toward the afternoon because I'd spent the first half remembering what my priorities were, or working on things that didn't really need to be done. It's amazing how quickly time disappears in thinking.

7. Developing at home

I wrote a fairly honest blog post about laziness and procrastination, but it seems I am still not extremely disciplined myself.

It's quite hard to develop on a fine day at home when there has been a lot of bad weather and there is a lot of work outside that needs doing. And if I'm honest, I have to say that when development gets tough, it's much easier to just play a game of Age of Mythology than to actually solve the problem! I'm also partial to a round of golf, which is very easy to come by here.

I shudder to think how much time in total was spent on these kinds of things - I don't think it could all be cut out and replaced with actual development, but a lot of it could.

8. Distracted by the next project

I spent quite a lot of time expanding on ideas for the next project, and doing prototyping. Particularly when I had run into a tough problem on the current game, it's much easier to just think about something else. It took a lot of development time out of Garden Wars, but this is one thing I wouldn't change... see below.

Conclusion

In the end, if I actually addressed all these things, I think the game would've only taken 4-5 months. Releasing on Steam (and thus with multiplayer) made development take an extra 6 months, and it added basically nothing financially.

So I wish it didn't take so long, and I will try to heed my own advice next time around BUT...

It has definitely achieved it's goal as a "practice" project - I now feel, moving into the next game, that I have a really good grip on UE4 and it's capabilities. I gained a ton of invaluable experience with multiplayer and Steam (which both feature heavily in the next game), AND I have the next project design very well-fleshed-out so I can hit the ground running (which is why I don't regret spending a lot of development time working on the next project).

Some good positives, but not quite enough. Onward to the next challenge I say.