Woodchippers! Postmortem

About the Author: Cyrus Kasaaian is a co-owner of the indie game company Castor Games. His passion for mathematics, programming, innovative gameplay, and unarmed combat drive him ever forward in pursuit of his two loves: creating new gaming experiences and being a martial arts instructor. To learn more about his work at CG check out CastorGames.com or follow @CastorGames.


(1200x600) Woodchippers Postmortem

In 2012, my college friend and I decided to start making mobile games. Like many people, we heard about the big success stories and thought “hey, why couldn’t that be us?” Last year we launched our first title, Woodchippers!, after a mountain of work and great test results and reviews. So why is this the first time you’re meeting our hero Axel? Well, chances are you’re not one of the 300 users that downloaded the game. In this postmortem we looked back at almost three years of work and attempted to explain why the title was such a smashing failure, and how we’ve applied these lessons in our new puzzle game, Project: sHE.

1) Tools

The first big mistake we made was not picking the best tool available to build our game. We decided to build Woodchippers! without the help of a pre-made game engine, because we thought we would learn more from doing everything ourselves. While that’s probably true, we also wasted many, many hours on developing things that products like Unity allow you to do in one line of code.

We built the game in Java, exclusively for Android. We created the entire UI system from scratch, with a few native Android elements thrown in. Unfortunately, as first-timers, our engine wasn’t very robust and adaptable; every iteration or attempt at adding polish resulted in hours of extra work. First lesson: use the best tools for the job. Most of the work has already been done before! Investigating and transitioning to Unity was the first thing we did when starting our new project.

Our original idea was to make a very quick, simple game, to learn from and then move on. If we had stuck to that plan, building our own engine might’ve been fine, but this leads us to the next topic.

2) Overly Ambitious

What started as a simple point-and-shoot game kept adding more and more features until it became a full title, with complex weapons, upgrades, enemies, menus and so on. We developed multiple playthroughs, leaderboards, achievements, and social media functionalities. This was our first game, first major project even, and we created our own graphics, UI, and physics engine, all from scratch – none of which we’d ever done before. Woodchippers StoreThe visuals in particular were difficult, because neither of us had experience in digital art or graphic design, and it showed.

As a two-man team, this was way too much to be able to focus attention on making any given element great. Combined with the fact that our homemade engine made iterations take forever, we became completely incapable of giving the game true polish. The final product contains mostly first and second attempts at any given thing, because we didn’t have the time or experience to develop them better.

To any aspiring game developers out there: make your first few games quickly, and then move on from them. They can’t possibly be perfect, because your craft isn’t perfect – practice, practice, practice.

With Project: sHE we had a much better idea of what we were getting in to, so we broke our features into categories: “Launch,” “Post-release updates/DLC,” and “Expansions.” This allowed us a lot of flexibility, plus a natural marketing thread. This format is just as good for indies as it is for major AAA games.

3) Usability

In terms of actual gameplay, we planned out Woodchippers! to a large degree and we actually love how the game turned out. All our players who’ve learned the basics have loved the game and gotten sucked in. It’s incredibly addictive.

However, that “who’ve learned the basics” caveat is huge. Woodchippers - Player Retention V1Most people who turn the game on don’t get past a few levels before giving up, because they find it too difficult and they don’t understand what they’re doing. Between the lack of polish and the unintuitive interface, people’s initial reaction to the game is largely negative, and they don’t last long enough to get to the fun part.

Our first attempt at a tutorial was interesting. We just wrote out, in a text box, instructions for how to play. Then we gave it to friends and asked them to test the game. They literally did not read any of it. And, of course, they were lost. At one point there was a menu where a giant flashing arrow pointed to the next button to press – a friend said “I don’t know what to do next” after tapping every other spot on the screen (incidentally, we added an achievement to the game titled “Why Won’t It Read?!” for ignoring the directions enough times).

The point is, we learned that we can’t just tell people what to do, we had to design our interface to make the correct options be obvious and natural. We came upon a dialog system that was a much better way to communicate, and made a number of other interface improvements so that players stopped getting completely lost. After many iterations and rounds of testing, we finally got the interface to “usable.” Sometimes even “fun” (due to the dialog)! But never quite “natural.”

In Project: sHE, we made a specific point to simplify the user experience as much as possible. For example, Woodchippers! has 3-4 menus before you can shoot stuff. This time around we designed our game to launch directly into the gameplay, without so much as a title screen. The overall polish and design of the game push the player naturally to interact with it how we intended. For each menu and button we ask ourselves “is this necessary, or are we falling into doing things how they’ve always been done before?”Woodchippers Screenshots

Lesson: plan your interface and your tutorials early on, they will need a lot of development, and they can sometimes shape the gameplay itself. Also, keep the tutorials as flexible as possible – as the designer, it’s hard to tell what’s intuitive for someone else. You probably won’t get it right the first time (or the second, or the third, or …).

4) Marketing

Our initial idea of marketing went something like this: “If our game is awesome, people will give us money. Otherwise, they won’t. Fancy marketing speeds things up, but if our game is awesome then everything will work out.” i.e. the “Field of Dreams” strategy.

This, of course, was wrong. There are tons and tons of great games out there, and most do not get any attention. Now, it’s unfair to say that Woodchippers! is an unqualified “awesome” game, for the reasons mentioned above (though it really is fun when you get the hang of it). But no one would even know, because no one knew it existed. We didn’t talk about it, even with friends, until after the release. We had no social media presence, until after the release. We had no public testing of any sort. In fact, this is the first real online discussion of the game – and it was released a year ago.

There are plenty of other resources online that know more about mobile marketing than we do, but a couple of things are clear: we didn’t start early enough and we didn’t do enough overall. Not that it would’ve mattered, because of our last point…

5) Monetization

Of the ~300 people worldwide who’ve played Woodchippers!, the only ones who created any revenue were our families. It’s almost embarrassing to think about the number of years we put in to this game.

Our first mistake was thinking that we could just tack on some in-app purchases to monetize the game. This is hugely wrong. Effective IAPs should be designed into the game from step 1, with the rest of the game design planned around it. Adding IAPs requires answering too many questions that you will be too far along to pivot on at the end:

  • How does the transaction flow fit within the context of the game?
  • What resources should you sell in the store and how do they impact gameplay?
  • Can the player also obtain premium content in-game without spending money?
  • How can the game be designed to maximize the appeal of the premium content?

Even when considering IAPs that don’t affect gameplay, early planning is still needed. For example, buying a new costume for a character is more appealing in a game where other players will be able to see it. Effective IAPs are profoundly linked to the details of the game itself, and by adding them at the end we ignored this fact and it was a big mistake.

One thing that Woodchippers! does well is drive players to the in-game store – it’s a prominent button on every screen, we have our own internal advertisements scattered through the game, and you’re prompted to visit the store whenever you run out of a resource. This is a strong element. PremiumUnfortunately, the conversion rate is virtually zero, because none of our IAPs are interesting enough (or necessary enough) to buy.

In the end, IAPs are a really hard thing to get right. A first-time developer probably won’t pull it off. For Project: sHE, we knew that the game we wanted to make wouldn’t mesh with the freemium model, so we avoided IAPs altogether and made the game a direct purchase. It was clearly the best monetization strategy for the game we were creating, so we planned it that way from the start.


Woodchippers! is a fun, addictive, unique game – but most players fail to realize it, because the lack of polish (due to a custom game engine and massive scope creep), awkward interface, and challenging learning curve prevent players from investing in the game in the first place.

But even if the game were perfect, it wouldn’t matter, because no one would’ve heard about it with our negligent marketing strategy.

And if by some miracle the perfect game created a storm of word-of-mouth advertising on its own, we still wouldn’t make much money due to poor IAP design.

Having fun gameplay is obviously important, but it’s easy to miss all the other factors that affect the game experience, and even then, marketing and monetizing during the current mobile app rush is incredibly difficult, a topic that we still haven’t figured out. But hopefully through sharing our learned lessons we can help some aspiring developers avoid the mistakes we’ve made so far.

Feel free to share:


Please enter your comment!
Please enter your name here