Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 31, 2014
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Reflections on an Indie Failure – StarLicker Postmortem
by Hayden Cacace on 04/17/14 12:54:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


This article originally appeared on the Heartonomy company blog at


Development on StarLicker began in April 2012, and it was Heartonomy’s first game project as a company. We released it in August 2013 and continued working on it for several months after the release. A total of 5 people worked on the project, and while I (Hayden) had worked with everyone previously, this was the first time that everyone else had worked together.

StarLicker was an unsuccessful game in almost every way imaginable. We made a lot of mistakes on this project, but through this process, our skill, knowledge, and wisdom as game developers improved dramatically. This article is meant to record our experiences so that we improve going forward and to share what we learned with others who walk in similar shoes. In this business, we hear a lot about the success stories, but not as much about the failures. So here we go… 

The Good

Original Concept

Hayden: I began the SkySwitch project, as it was originally named, wanting to build the game around high level design goals. The first goal was to build a strategy game with the aesthetic of a bullet hell shmup. Early into prototyping, the concept of the opposing players “feeding” each others’ economies through aggression emerged, and I fell in love with that as a design goal as well.

To this day, I still think at a high level StarLicker represents an interesting, original game concept with a lot of potential. This is one of the few areas where the released game is very strong, and a lot of feedback we’ve had from players confirms this. However, this was also the first strategy game I designed and the actual game fails to capture the full potential of the concept.

Rudd: Some time after Hayden started Heartonomy and StarLicker but before I joined the project, we were participating in a small hackathon together, and I got a chance to see the prototype. At that point, even though it was extremely rough looking, I could tell that the main mechanic had a lot of promise, and I was seriously impressed. With my naive attitude towards the game industry, I believed that a concept this original and innovative was sure to do well if it could be executed on. The concept is what really sold me on joining the company and risking my livelihood. While there are a ton of things I’d do differently now, I agree with Hayden: I believe that the concept was one of the better aspects of the project.


Hayden: Personally, I find it a bit trifling to celebrate the mere release of a game. Having said that, I recognize that shipping does represent a real accomplishment. It requires crossing the t’s and dotting the i’s and there is a lot to learn just from this process alone. If we had not released anything, then writing this article would hardly even make sense.

Additionally, it was always a secondary goal of the project from the very beginning to create a game that could serve as a portfolio piece to showcase to potential work-for-hire clients. We had no illusions that our first release would magically become a huge hit game that could fund the company for the rest of time. We knew it was likely that we’d have to resort to contract work at some point to stay afloat, and that is exactly what happened. And StarLicker has already successfully demonstrated to clients on more than one occasion that we know how to build and release a game.

Rudd: I disagree with Hayden that shipping is “trifling”. To me, shipping the game was a major accomplishment. The difference between an indie studio that has released no games and an indie studio that has released one game is infinitely large. I’m extremely happy that things like Game A Week are becoming popular, because that mentality would have helped immensely at the start of this project. The months leading up to the first release of StarLicker were extremely stressful for me because I could feel that something was wrong. Even with so many months of work put into the game, I could tell that we hadn’t really done anything. We needed to ship. When we finally did, even though the reception was poor, I felt much better, like a weight had been lifted off my shoulders.

The Bad

Game Design Is Hard

Hayden: I had heard this phrase countless times before but I never truly understood it until recently. In fact, I had heard all of these lessons before, but alas, I am the type of person that learns best by doing (it wrong). At the outset of the project, I had just quit my job and started My Own Company and I was higher on naive optimism than I’d ever been before. For game design, I thought it was enough to establish specific, clear high level design goals (described above) and the rest of the design process would follow naturally and easily from that. This was extremely incorrect.

Nothing about the process of game creation is particularly natural or easy. Every bit of it requires special skills and talents and tons of practice, and design is no exception. I could probably write an entire book about everything I learned about game design from this project, but we’ll keep this to the big ones.


Hayden: Playtest early and often. The value of fresh eyes on a game can not be overstated. It’s fine to start with coworkers, friends, and family, but they will grow accustomed to the game quickly and thus cease to be effective playtesters. As soon as the smallest nugget of the game is playable, start having people play it, and then never stop finding new people to play it at every step of the way.

The Truth About Feedback

Hayden: Really, actually listen to playtest feedback. Playtesters say lots of different things after they try a game. The designer will disagree with all or even most of their suggestions. But do not dismiss any feedback, as I did, with the attitude of “this game is not for you”. It is the responsibility of the game designer to listen to and analyze every single bit of the feedback, and discover precisely what truths it contains. Often, this truth will be far from obvious and often not even directly related to the actual feedback itself. But everything a playtester says, whether its something they like or don’t like, or a new idea they have, comes directly from their experience playing the game, which means there’s something to learn about the game from it.

Rudd: To me, this is the most tragic failure of StarLicker. When we submitted to IndieCade for 2013’s festival, they were nice enough to provide feedback to all entrants. This feedback should have been invaluable, coming from people who understand indie games and what makes them worth playing. But with this feedback, we almost entirely rejected it out of hand, believing we knew what was best for the game.

If I try to rationalize why we thought it was reasonable to ignore, it might be that one of the judges said that they’d love to be able to try the game via multi-device asynchronous play, which was already in the game and in fact the main intended way to play. How deeply can they be looking at this, we thought, if they didn’t even see that? But other feedback cut to the core of what we now know to actually be the issues with the game. “You nailed everything but the core gameplay elements”, wrote one judge, with words that still sting to read.

Perhaps if we had listened better to feedback, we might not have such shocking stats on retention: only 6.8% of matches end quote-unquote “normally”, and almost 65% end in an automatic forfeit due to one player failing to play their turn.

Hayden: While I agree with Rudd about the value of the feedback we got from the IndieCade judges, I remember things differently about why we didn’t take it to heart. It actually began with a playtest session organized by the NYU Game Center specifically for IndieCade submissions. We came out of that playtest with lots of great feedback and some crazy ideas that would have been major changes to the game design.

However, this playtest took place in June 2013, which was already after when we originally wanted to release the game. I’ll get into this in more detail below, but at this point we were panicking over money, and no one was feeling brave enough to make major design changes at that point. This is why such valuable feedback was ignored.

Indie Scope

Hayden: Start as small as possible. A multiplayer strategy game, even a small one, tends to be a very complex game design. To put it bluntly, I was simply in over my head as a game designer. Despite having a lot of experience playing these types of games and the clear design goals mentioned above, I did not have the experience or skillset as a game designer to execute well on those goals in the time we had to develop it.

Rudd: What we shipped was a much larger and complex design than we should have taken on for a first game, unconditionally. But what we originally planned to build before release was significantly more work than we actually managed to do. We originally planned a single player story mode, leagues with Elo/MMR systems for multiplayer, player messaging, and even, perhaps after launch, an innovative system for players to mentor other players. But even by cutting all that, it was too late. The original design necessitated at least some of those things to keep players engaged, but we had run out of time to deliver on them.

Release When It’s Ready

Hayden: In business, time is money and money is time, and we didn’t have enough of either for StarLicker. I originally intended for it to be a 3 month project, but then I decided to make it multiplayer. And then I decided to add 5 variants of each of the 8 units, four unique power-up abilities, etc. In other words, we let the scope grow wildly beyond what we could actually deliver on at the quality bar we wanted. To make matters worse, we were living off of our savings, and it’s frightening to watch your bank account balance dwindle, and this fear clouds good judgement.

We crunched for months toward the end, but while that allowed us to release the game (mostly) as designed, it forced us to rush on many aspects of the production that should not have been rushed. For example, we never created an automated system for integrating art assets. Every time an asset was modified, I had to spend time manually putting it into the game. We never felt like it was okay to slow down and really spend the time on “unnecessary” things like automation. At first this seemed acceptable, but by the end of the project we had thousands of art assets (all the animations are frame-based sprites) and this manual process ended up wasting so much time in the long run. The same was true for a lot of coding tasks that would have resulted in a more polished game. In the middle of a rushed, panicked crunch, it’s basically impossible to slow down to really get the code right.

So, just like in the AAA industry, the best games tend to come from the companies that can afford to say the release is “when it’s ready”, and the bad games always show signs of sloppy, rushed work. Game production is game production, and there is no exception for indie games.

Rudd: The caveat from this lesson learned that I feel we should emphasize is that this comes second to having a correctly-sized scope for your team. Yes, releasing a product that we weren’t happy with was a mistake, but I still feel that we made the right decision in essentially cutting our losses. We had spent as much time as I was comfortable spending on the project, so we basically had to release it before it was ready, because we had failed to scope the project correctly for our resources.

Free 2 Fail

Hayden: This is a big one - the decision to make StarLicker a free to play game. The reasoning behind this decision went something like this: the best way to maximize the number of people that play the game is to make it free. And it would be no problem to design a free to play system that people will like because, well, League of Legends does it! This might be the best example of the overzealous idealism that pervaded the project, a theme you may have already noticed. The problem is that we knew what LoL did to monetize but we didn’t have a good understanding of why it worked, and completely failed to communicate a compelling “why” in our design.

Rudd: One of the biggest problems here is that StarLicker was a niche game. It is not easy to learn or get into. For some games, that is okay. But StarLicker being free meant those that downloaded it had no incentive to give the game a further chance, unless they had a friend bugging them to play it. If they had paid an upfront cost, at least some of them would feel obligated to “get their money’s worth” out of it and learn how to play.

Even for the players who did invest themselves into the game – time-wise, that is – the incentives to pay were extremely low. For the first 6 months of the game being available, we did not offer any cosmetics for purchase; the only IAPs available were XP multipliers and items that were also unlockable via normal play. Some player reviews actually expressed guilt over not paying since they were enjoying the game so much, but not enough guilt to actually purchase anything.

Hayden: Not only was StarLicker a niche game but it also had some design flaws that resulted in a severe player retention problem. This is a death sentence to any free to play game, let alone one that limits the maximum amount of stuff for sale so as to not “abuse” the model. So in the end, we made an extremely small amount of money. With around 11K downloads, the game has earned less than $300 to date (no I didn’t forget a zero there).

Multiplayer Only

Hayden: Since day one, I wanted Heartonomy to focus on developing multiplayer games. So very early in the project, I decided to tackle asynchronous multiplayer as the focus for StarLicker. I enjoyed playing several async games on my iPhone, so it seemed like an obvious good idea. But the problem is we focused on multiplayer features so much that we entirely neglected all the value contained in playing solo.

I eventually came to realize that the value of single player is that most people simply prefer to learn a new video game on their own at their own pace. For most people, trying to learn an entirely new and unfamiliar game in the context of a competitive 1 versus 1 matchup is difficult and stressful. Add on top of that the fact that asynchronous means there is a lot of waiting between turns, and the result is a game that is almost impossible for new players to really get into.

Another side effect of ignoring single player is that we ended up rushing the creation of a tutorial that was little more than an afterthought. I feel like we missed a huge opportunity to make a compelling single player mode for StarLicker that could have introduced people to the game’s unique mechanics at a reasonable pace such that they would enjoy that learning process. And then, hopefully, most players would have eventually decided they were ready for the added challenge of competing against other players.

The Ugly

What’s in a Name

Hayden: Let’s talk for a moment about how we came to name the game “StarLicker”. I originally started calling it this as a new codename that I thought was hilarious and described the core mechanic of the game (tracing along the paths of star-shaped bullets) better than what we were calling it at the time – “Sky Switch”. As we asked more and more people what they thought of the name, we realized it was an extremely polarizing issue. Some people loved the name while others hated it. Those that loved it felt like it was unique, bold and intriguing. Those that hated it thought it sounded gross or perverted and said they would be embarrassed to tell it to other people. Ultimately, we decided to go with it, but I honestly still don’t know if that was the right decision. I’m still getting the same polarized reactions when I tell new people the name.

Rudd: Honestly, I never even liked the name. It always made me a little bit uncomfortable, like it was semi-NSFW. Of course, at the time of its naming, the main player character Lenny wasn’t flying around in a ship, but was flying on his own, with a giant tongue licking up the energy bullets. It wasn’t until later that I finally convinced the rest of the team that that concept was a little too out there. But the name stuck because of the polarized reactions. Our biggest piece of mainstream press coverage seemed like it came entirely from the audacity of the name, and the (NSFW) comments bear that out. At that point, it seemed like it could be one of our “angles” so the name was pretty much set in stone.

Malaise Marketing

Hayden: Marketing an indie game is a ton of work and there is no clear formula to follow to find success. We knew how important marketing was, but we didn’t really know what to do about it. I feel like our marketing effort was halfhearted, and this was a direct result of the fact that we all knew, deep down, that we rushed the game out and it wasn’t good enough. The big advantage indies have when it comes to marketing is their unbridled passion, and by the time we finally released the game, we just didn’t have enough passion left in us to properly promote the game.

Rudd: The biggest marketing push for the game wasn’t even made by us. In fact at the time of this biggest push, I was packing up my apartment to move the next day, unaware that it was happening until it had already begun. Our friend Brian made a post on Reddit’s /r/gaming that made it to the top for a short period of time, even making it to the standard front page of Reddit. By Imgur’s estimation, Brian’s infographic was viewed over 413,000 times. That’s some serious exposure, for sure. By far that was our biggest spike in attention, accounting for almost 10K downloads, about 90% of all of our downloads ever. And we didn’t even have anything to do with it. Ouch.

No One Got Paid

Hayden: StarLicker was entirely self-funded by the development team. This meant basically no one got paid and the plan was that we would each get a slice of the profits after the game was released and the dough started rolling in. For the entire duration of the project, when it came to paying rent and bills and buying food, we each had to fend for ourselves. Rudd and I were full time on the project, so for us that meant living entirely off our savings. For William, it meant periodically taking time off from freelance gigs to focus on StarLicker art in focused bursts. Kurt was wise enough to force me to pay him a little something upfront, but it was a pitifully small amount and definitely less than what his contribution was worth. Zane, having just graduated from college, was an unpaid intern working for IOU.

But then we released the game and money did not start rolling in. It barely even trickled in. And this created a very strange and unexpected set of feelings beyond the obvious disappointment and frustration. I felt really strongly that I just completely let everyone on the team down. It was like I assembled a team of some of my most talented friends whom I had the utmost respect for, only to have them waste a huge chunk of their creative lives. This feeling still hasn’t worn off, and I don’t know if it ever will. This is a huge force fueling my desire to revisit the core concept of this game and the universe we created for it, so that maybe one day I can rest assured that it was all worth it.

In Conclusion

Since long before I (Hayden) started Heartonomy, I’ve felt that making games was my purpose in life, that I had something important to contribute to the world through gaming. StarLicker was not the first time I’ve tried and failed to create a successful game, and it probably won’t be the last. But with each subsequent failure, it hurts a little less, and I learn a lot more. Eventually, hopefully, I’ll have learned enough to make and release a game well enough to succeed.

We set ourselves up to make a lot of the mistakes described above because we shut ourselves off from the world during development. The game dev community, especially indies, can help each other so much. I read once that we are not competing against one another, but we are all competing with obscurity. I believe this is true. So if you read this article and have any sort of reaction at all, we’d love to hear it. Whether it’s a question, something you can relate to, words of encouragement or even discouragement, please share it with us by email (">, twitter, etc. Thanks for reading.

Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer C++ (m/f)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Next Games
Next Games — Helsinki, Finland

Senior Level Designer
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team


Jamin Messenger
profile image
Thanks for posting this detailed and honest post-mortem. I definitely learned a lot from your review with all the issues you found with your project. I am definitely going to check out the game tonight.

Paul Lenoue
profile image
Game design is a skill/talent, just like programming or art. Too many indie developers believe game design is either a subset of programming (code = games) or extremely difficult to quantify (fun = millions of variables). It's strange that indies readily consider art to be a separate talent, thus seek artists to help with the visuals, but regard design as something they have to do entirely on their own. There are people out there with a talent for game design, just as most of you have a talent for programming, yet indie developers never even acknowledge them, much less seek them out for advice/feedback.

I have met many people who are great at designing games, spotting flaws and improving mechanics, yet they can't program worth a damn. This is similar to a programmer who studies the theory of art but can't draw, it's a talent. Yet the bad-artist programmer is still considered part of the indie community while the non-programming game designer is excluded.

Isn't there a way the indie community could change this? Alter the group mindset to accept game design as a separate skill that some have and some don't? Maybe even bring such talent on board early in the development much like you'd seek out an artist?

Daniel Borgmann
profile image
Most indie game developers are probably game designers, who learned other crafts as a means to an end. Also, hiring a separate game designer is a luxury that many indie game developers cannot afford. While game design is a separate talent, it certainly is possible to do the job while also being a programmer or artist on the team.

I think most important is to recognise that game design is hard, and that a team needs at least one person with solid skills in this area.

Ben Sly
profile image
I think that the primary reason why game design and programming tend to be interlinked in digital game development is that game design requires that you understand the tools you have available to use them to their best effect. Programmers are much more capable than non-programmers of understanding precisely what a computer can do and how long a change or mechanic will take to implement; intimate knowledge of both speeds up the development time significantly which leaves more time for the playtesting so critical to a quality game.

But I think that this effect is only particularly significant because the cost of making changes in most games is high. In general, I'm a lot more impressed by the depth of the average German board game than the average video game, and I think that most of that is because tabletop games are much easier to significantly tweak than video games. That line of thinking has been enough to convince me of the importance of designing games to be easily moddable: even if you disregard the benefit of letting fans make their own mods, the mere fact that you've designed the game to support large changes means that you'll also be more willing and able to try out large changes yourself.

Paul Lenoue
profile image
Daniel, it's been my experience talking to many indies and reading articles like they have here on Gamasutra, that most indie game makers _think_ they're game designers. Only discovering they aren't after it's too late, like Hayden did in this article (Great article, by the way).

Who says an indie has to be "hired"? Many indie games are made by one-five people working on their own time, or for very little, because they want to make a great game. Good game designers are the same. In fact, all of the non-programming game designers I've known would gladly work for free advising indies in how to make their games better if only so they can play it.

Also you don't need to know programming to understand how game mechanics work. Just look at the great table-top games out now, providing depth, simple mechanics but complex strategies, and lots of enjoyment. Compare those to many of the indie games you see that are shallow, awkward and flawed due to bad design. A good game designer will advise, describe alternatives, and explain why something will or won't work. I've never run into a game designer who would say "Do it this way! I don't care how hard it is to program!" More likely they would put forth an idea, if it would be troublesome to code the programmers would explain why and the game designer would suggest possible ways around the problems.

Keep in mind that programmers aren't automatically experts on how things can be programmed. I once presented a concept for an easily moddable board game where you could embed simple rules in the board hexes, the playing pieces and the dice. Most of the programmers present declared it impossible, believing you would have to code every conceivable rule combination into the game. Two programmers actually listened to me, understood the concept, and made a working prototype while the rest were telling me that because I wasn't a programmer there was no way I could understand how such things worked.

Ben, you are right, making the game flexible from the start allows you to make better games. Good game design allows for tweaking and modding during development.

Hayden Cacace
profile image
I agree most indies think they are game designers and I think a lot of them, especially in video games, start out making games with programming or art skills, because its hard to even start designing if you can't put stuff up on the screen.

I feel like this is a big part of why many developers become indies in the first place. They want a chance to be the game designer on their own project, the coveted role where you get to decide what game is going to be. I know I was really inspired by the "I am a game designer" mantra from Jesse Schell's The Art of Game Design book.

As far as whether the indie community can change anything about this, I'm not sure. We shouldn't place game design in a special walled-off garden that only proven game designers can enter - that would go against the spirit of this community. But we do need to make sure we all treat game design as an important skill, equally important as art, programming, etc, that can be learned, practiced and eventually mastered.

Paul Furio
profile image
Thanks for the interesting retrospective. I honestly find "failures" more interesting than success stories, because they always provide good learning lessons. Tales of success largely devolve into "I was a genius, that's why we won."

You call out great points about missing feedback and being off on your design, as well as death by a thousand papercuts. One key thing that isn't called out explicitly, although you mention it in your Free-To-Play section, is that utilizing a design decision from another game, without proper context, can be devastating. On a personal project, I was aiming towards a browser-based design, because that's what everyone else was doing. Only after some deep retrospect did I realize, no, I should be creating a standalone PC/Mac game because I know I can make that experience truly shine.

Understand what you want to accomplish, and what core experience you want to deliver. Above all else, this should guide you.

Matt Mirrorfish
profile image
Thanks for the honesty and sorry to hear that your project was painful. I agree with Paul about the danger of combining mechanics or concepts from disparate areas. It also sounds like you guys had some major scope issues. It's so easy to scale up the idea and so hard to cut it down when you run out of time. Thanks for sharing.

Artur Roszczyk
profile image
Thanks for sharing all of this. I wonder how you game development process looked like? I read something about game prototype, but was it a multiplayer game already? Or a single player? When you look at this prototype now how it looks like VS the realeased game? And what did you do next after finalizing game prototype? It's a shame it's not on android, because I don't have any iOS device. Hope to play it sometime.

Jon Draper
profile image
Thanks for the great article and sharing your insight.

I'm currently just over a year into developing my first asynchronous game title (My 4th or 5th small indie game release). Doing it on my own, building my own async server (rather than a 3r party option) using what spare time life passes my way.

As I'm doing it all slowly I've steered away from sharing the core game mechanics or testing it outside of close family or friends. As I worry the idea could be 'taken' by a large team or a full time individual, produced and released before I can even get close to release.

Is it the best idea ever? of course not.. but it is original enough that I feel it has some worth.
I've probably got another year of work before I'll be releasing the game at the level I'd like to.

I've discussed the async setup heavily on my chosen game dev forum but outside of that I'm keeping schtum.

Any thoughts on this? should I be risking a little more to get some highly prized honest feedback.

Andy Wallace
profile image
I think keeping your game secret will guarantee that nobody will steal it but will also guarantee that it is not as good as it could be and that it will have no word of mouth.

As small devs, we cannot afford to do all the testing a game requires in secret. In my own work, I take the risk, share my game early and often. It has always resulted in far better games as well as some coverage/fans for the game before it is even out..

Hayden Cacace
profile image
I really second Andy's thoughts here. As someone who used to worry about his ideas getting "stolen", this is simply not a realistic fear as a small, obscure developer.

It is FAR more likely that, after toiling away in secret for months, that when you finally show your game, you discover that few people finds it all that amazing anyway, despite how great you think it is. It's better to discover that early on before you spend all that time working on it.

Rayco Santana
profile image
Great article, I believe if you learned and gained experience then is not a failure at all, you will have better luck next time!

Rodrigo Wilhelmy
profile image
Thanks for the postmortem. I would like to venture into the world of game design, but I have this innate fear that my focus will not be well received.

I have a masters in AI and I want to bring that into games. This, of course, has time and time been a dreaded and controversial point in gameplay design. Countless experts have claimed that players don't want good AI (i.e. Naughty Dog on TLoU), but I still hold hope that in order to push the envelope, better designed AI is needed for some of today's games genres.

As I am going to start working on game design as a part time, mostly solo affair, this postmortem is invaluable. Thanks again and I wish for your future success.