
What I Learned About Failing from My 5 Year Indie Game Dev Project - zarfius
https://www.dylanwilson.net/what-i-learned-about-failing-from-my-5-year-indie-game-dev-project/
======
didibus
I'm wondering if he'd still feel like quitting had it been making ton of
money.

One thing I've noticed is any passion project that becomes too much like work
starts to feel like a chore and the passion for it disappears. I don't think
making money off of it would change that.

I've learned that when I do side projects, I need to think of it as having fun
and playing. And with that, you accept to stop something and move on to
something else as soon as the enjoyment is gone, and maybe come back to it
later if the interest shows up again. It's hard, because you can let this
feeling of "failure" creep in, like you haven't finished anything, or
accomplished any of the projects you were excited about. But if you accept
that your goal isn't to actually get anything accomplished, but only to
entertain yourself and have fun doing things you're interested in, it helps
with that, and makes the whole thing much more healthy.

~~~
dpcan
I had a game reach about $600 per day in revenue for a few months way back in
2010. Overall I think it made around $100K, and another game made about $30K.

So, even though I was making money, I still wanted out. The reasons came down
to those listed below:

1) Taxes.

I wonder if it's easier now, but back then, I had to manually pay individual
counties in my state, I had to pay individual states, and and then there were
countries. I chose not to sell my game in any non-U.S. country just because of
this. So, the tax nightmare wasn't something I was interested in, and was a
big part of exiting the game selling business.

2) Make updates or create something new?

I originally did well updating my game. It kept people interested, and seemed
to spur new sales somehow, but working on the SAME game for months and months
and only making minor updates was not fun. It was work. So, I decided to make
more games. I had one game make about another $30K, but everything else didn't
sell at all. This was incredibly discouraging.

3) Reviews and Customer Support

When you are dependent on game sales, you check your reviews daily, and you
freak out about anything less than 5 stars. Every mean comment hits hard.
Customers start writing you, and some of them are crazy. I received death
threats for removing a small feature for example. I also received CONSTANT
questions about getting my game to work on different devices and computers. I
couldn't keep up efficiently.

4) Daily Sales Stress

I would watch daily sales like a hawk. If an hour was slow, I'd stress. If a
day was slow, I'd panic. It all had to just end. I couldn't market all day
every day and work on new features and new games, so I was at the mercy of the
app stores and it made me nuts.

5) Sales slowed

Finally, sales started slowing because of all the competition to my game
(maybe). Other devs saw it doing well and a bunch of clones started showing
up. Some even used my assets. Some Just added an "!" after the name of my game
and were somehow using my code. I wasn't getting sales because my game had
been out for a while, and then there was pirating and fakes. I know some
people have their own opinion about pirating, but I would get emails from
people telling me my game gave them a virus, then when we got down to it, they
had stolen it from some shady site and still wanted support and to blame me
for installing an infected game.

So, all that being said, yeah, making okay money in the game industry just
wasn't enough to make me want to continue, but I REALLY like to make games, so
part of me wants to try again anyway. Perhaps learning from these experiences
will make the next adventure a little easier, who knows?

~~~
bdowling
> 1) Taxes.

What taxes are you talking about? You mentioned that you were selling through
app stores, which I assume handled sales taxes for you in the few cases when
they may be required. Your business income taxes would be the same as any
business in your city/county/state/country. What else is there?

~~~
dpcan
Google Play is starting to remit taxes by state, but they haven’t always done
this. It was/is up to the seller. And if you sell with PayPal or something on
your own site, check all the laws of where your product is being downloaded,
you’ll be surprised. My accountant ruined my year that year.

~~~
dpcan
I'm not still selling on Google Play, and haven't for a while, but if you're
interested in seeing where Google currently remits taxes by state and country,
the link is below:

[https://support.google.com/googleplay/android-
developer/answ...](https://support.google.com/googleplay/android-
developer/answer/138000?hl=en)

------
imtringued
I'm really confused. The goal is making money yet there has not been a single
attempt at monetization. Patreon is basically equivalent to donations. There
is no obligation to pay you. Your highest tier is $5 a month. Even with
hundreds of backers you're barely going to earn anything worth the effort. You
could have easily added a much higher tier that charged at least something
like $40 a month for support prioritization on Github. You need to some basic
market research and find customers that are willing to pay and give them a
reason to give you money. There are lots of ways to monetize an opensource
project. If you want money you'll have to focus on money, not on your project.

Your project was a success, only the (nonexistent) business strategy failed.

~~~
zarfius
Thanks for reading!

In hindsight I totally agree with you. Unfortunately when I started the
project I wasn't in that mindset. It started as a passion project, mostly an
experiment in building an audience around something I enjoyed creating.

More recently I've been getting some help to understand the things I did wrong
and to start with the business strategy.

------
skizm
Does the article ever actually mention what he failed at? He developed an open
source game engine and... what? Did he expect people to donate to him or
something? What was the monetization plan?

~~~
hhas01
“What was the monetization plan?”

From reading the article author’s failure was failing to ask that question of
himself. With no clear objective or milestones, the project ate a huge amount
of manpower for no material gain and left him thoroughly burnt out.

It doesn’t matter if your project is for-profit or Free. Identify your
deliverables, identify your schedule, and _never_ turn a blind-eye to your
failures to meet both.

Oh, and never mistake makework for productivity either. If your product isn’t
selling, what it _doesn’t_ need is more features. What it does need is better
marketing and sales skills. Quite frankly, building the technology part is the
least important part of building a successful Product. Being geeks, it’s
awfully easy to work on (i.e. fiddle with) the one bit that you’re naturally
good at, when what you should be doing is working on all the parts that you’re
not.

~~~
tomxor
The thing is... the alluring thing about side projects _is_ not having that
clear objective. Most of our jobs are directed by clear objectives, side
projects are great for experimentation without clear potential for personal
gain (fun, fame or fortune), often you will at least gain a unique experience
and learn, which is a good trade for a little time.

Perhaps what happened here is a side project grew into something larger, it's
now just a project, and he fell into putting more time and effort into it
without making a conscious decision due to popularity - perhaps that's when it
can bite you, when you realise you don't enjoy it anymore and it's become one
sided.

I think side projects should stay as small as possible unless there looks to
be a real potential for both yourself personally and the rest of the world -
even then failing fast feels like the best idea.

~~~
hhas01
For small personal projects, I think a fair rule of thumb is: is anyone else
using it? Once that answer turns to yes, you need to get your exit plan in
place.

And +1 for failing fast. It is failing slow that’s the disaster.

~~~
the_af
What's an "exit plan" in the context of small personal non-corporate projects?

~~~
dkersten
It depends on what commitments you made to your users. It could be as simple
as just abandoning the project or it could be something more elaborate like
handing it over to someone else.

~~~
the_af
But why do you have to think about this "as soon as you have your first user"?
Not every project is a business and not every project needs an "exit plan".
Not everyone doing a project needs to think in entrepreneur terms.

~~~
tpxl
If people are interested in your project, it's courteous to let them know
what's going on, even if just to tell them the project won't continue.

~~~
the_af
I fully agree. I'm just questioning the use of entrepreneurial terms such as
"exit strategy", _especially_ early in the life of your project.

    
    
        "What are you doing?"
        "I'm painting, some people bought my pictures"
        "So what's your exit strategy?"

~~~
dkersten
The terminology doesn’t matter. It’s used here because this is a very
entrepreneurial audience and most people understand what is meant by it. I
don’t think anyone means to imply that you need to treat your hobby/side
projects like a business.

~~~
the_af
Well, the terminology matters to me. The language we use tends to frame how we
think about issues. I find the language of entrepreneurship distasteful when
used outside a business context.

------
citizenpaul
My experience is that anything that spending significant amounts of your time
on anything that assists others with building their thing is a total waste of
time. Tech or otherwise. Those people are mainly doing it with the goal of
making money for no one but themselves. The fact that they don't have money
already proves that they likely are not good at making money. One of those
primary early ways to make money is that early on you may have to strike some
potentially less favorable deals when you have no money to get your first
projects off the ground. Which of course they are NEVER EVER are willing to
do. ie profit sharing or something.

~~~
makeee
My experience has shown me that tools that help others build faster can be
quite profitable. Currently make my living from one such tool and most of my
customers are indie hackers ([https://divjoy.com](https://divjoy.com)).

~~~
bermanoid
Game engines are different. It's a tiny market relative to web, and really the
only people in the market for an engine other than Unity or Unreal are indies,
who have near zero revenue and even less willingness to spend it. Those two
are so far ahead in terms of features, support, and battle-hardening that
you'd pretty much have to be insane to pick anything else if you had paying
users.

Always be wary of any market where someone's willingness to try your product
is in itself a negative indicator of ability to pay. Hit-driven markets that
attract large numbers of non-serious dabblers are extremely difficult to sell
tools profitably to, but it's easy enough to get minor attention that makes
you think you might have something worthwhile (music production is another one
that scatters corpses all over the place despite seeming large at first
glance).

~~~
zanny
And Godot. You know, the 15 year old totally free engine of 30,000 commits 2.5
million LOCs that also does pretty much everything.

~~~
imtringued
What I noticed is that it's actually much harder to use Godot than expected.
Yes it does significantly reduce the amount of code you have to write for your
game but it opens up questions of how to structure your project because the
scene editor doesn't actually match how I would make my own games if all I had
was SDL2. For example if you just straight up write code to add nodes to the
scene graph it will create a disconnect between what is displayed in the
editor and the actual game. Figuring out how to keep the editor and code in
sync is a problem unique to Godot and this is very disconnected from general
software development.

~~~
PinkMilkshake
> What I noticed is that it's actually much harder to use Godot than expected.
> Yes it does significantly reduce the amount of code you have to write for
> your game but it opens up questions of how to structure your project because
> the scene editor doesn't actually match how I would make my own games if all
> I had was SDL2.

I agree. But what I've learned in my short time using Godot is embracing
Godot's scene system and not fighting it seems to help.

This area in the documentation is helpful:
[https://docs.godotengine.org/en/stable/getting_started/workf...](https://docs.godotengine.org/en/stable/getting_started/workflow/best_practices/index.html)

You can also bypass the scene system. The scene system is a optional
abstraction on top of a seemingly more data-oriented core where everything is
just a RID (Resource ID).

More here:
[https://docs.godotengine.org/en/stable/tutorials/optimizatio...](https://docs.godotengine.org/en/stable/tutorials/optimization/using_servers.html)

> For example if you just straight up write code to add nodes to the scene
> graph it will create a disconnect between what is displayed in the editor
> and the actual game

You can solve this to some degree by putting "tool" at the top of your
scripts. See
[https://docs.godotengine.org/en/stable/tutorials/misc/runnin...](https://docs.godotengine.org/en/stable/tutorials/misc/running_code_in_the_editor.html)

------
temporama1
> the downside of adding more features is that it becomes increasingly time
> intensive to fix bugs, update demos, deal with pull requests and respond to
> questions.

Thibaut Duplessis, creator of Lichess, talks about this in a talk he gave
(YouTube somewhere). He says that he's very reluctant to add new features due
to the huge cost. The feature must be something very special to overcome the
cost.

~~~
baxtr
People totally forget that new features add maintenance costs later. And I’m
not only talking about business folks here but also devs.

Regarding adding features, I like the approach here:
[https://www.defmacro.org/2013/09/26/products.html](https://www.defmacro.org/2013/09/26/products.html)

~~~
gfodor
This is a solid post - I would say tho that sometimes the right way to view
product development is through the lens of media. The bucketing approach in
the article breaks down somewhat if you are not directly targeting solving a
problem, but creating a medium for people to solve problems using their own
creativity. So the question of features reduces down to how far the feature
enhances the reach of the medium, not if they are (together or in aggregate)
game changers wrt solving problems, because you as the product designer are
not in then business of solving the problem, the customer is.

------
zanny
My problem with this is the assertion that failure == not making a profit. For
the OP, yes, if your goal is to make money off your code then writing free
software is pretty prone to failure on that front.

Free software is philanthropy. Even if you somehow are getting paid to write
it, it _cannot_ be done _for_ profit. If your objective is revenue discarding
the burgeoning international IP regime as a source of income is foolhardy.

That being said, software for _profit_ is hugely contrary to software that is
_used_. Its infinitely harder to see anyone else use your code and you must
always be cognizant that your proprietary for sale code is always going to see
orders of magnitude less utility and adoption than free code.

So when you write software from day one the objective is going to be to either
maximize money or maximize utility. They are contrary to one another. Some
would argue that making money == ability to do more work == more utility but
no amount of time invested into software used by a few will compare to less
software being used by orders of magnitude more people.

And there is also no guarantee of success. Its why proprietary, popular
software exists. Making a proprietary or free product does not guarantee money
or use. But depending on which you want going for one will hugely limit your
ability to obtain the other.

This axis also comes up in free software itself between permissive vs
restrictive licensing. If your code is MIT / BSD / Apache / etc you will
almost _certainly_ never make money from it. Anyone can just use it however
they want with no restrictions and will do so. It will maximize its
utilization with no regard for the ethics or objectives of said use.

If you license it restrictively, IE GPL or CC-SA, you will reduce your
potential adoption audience to not include those that want to distribute it in
propriety without providing their users the same freedoms they got from you.
This can, however, be the same exchange of utility vs money, or, more often,
time. Infectious free software propagates slowly but does cause the general
amount of freeness to increase through permeation. It also lets you sell
licenses for proprietary use and is one of the only major ways to monetize
free software consistently, see Qt.

------
chii
A project is doomed to fail unless you setup a specific target success goal
before you start.

Perhaps one can get lucky, and stumble into success - monetary or fame or
something. But more often than not, a project that didn't initially define
what success looks like would be doomed to fail (and meandering is also a type
of failure under this model).

------
komali2
It's only a failure if you judge success by monthly income. I'm not saying
that's not a good way to measure success, just pointing out that it doesn't
have to be the only measure. A therapist told me this recently when I was
struggling to find meaning in life.

Success can be tons of stars on GitHub - I would feel very good if I had
positively benefited that many people. I think a major downside of capitalism
is how it attempts to attach a price tag to both the concrete and the
ephemeral - how can you put a price tag on the good feelings one gets for
creating something useful from the world? But nah every side project has to be
a hustle and if it isn't making you money, drop it in a second.

As for support requests, you don't really have to reply to them. You have
control over your level of involvement in a project.

How much less enjoyable does your backyard garden become if every weed you
pull you think "excellent, I've just increased the value of my house by .12$.
Ah shit there goes inflation, hold on, my weed pulling nets me less than a
dollar an hour, maybe I should do some contracting with this time instead?"

~~~
slfnflctd
Backyard gardening is riddled with inefficiencies in every imaginable way, and
is not for everyone. The only tangible benefits I see are for people who
receive positive benefits from the actual experience of doing the hard work
_and_ somehow use it to benefit others (directly or indirectly). If you're not
sure that applies to you, stay away.

Same goes for a lot of other things. Sometimes you have no choice but to do
stuff that sucks and really isn't helping anyone, yes. Try to keep it to a
minimum.

~~~
nonbirithm
Maybe the stuff doesn't universally suck, but would be soul-crushingly boring
for one person yet completely engrossing for another. It might not change the
fact that doesn't help anyone, but I would say there's no need to say it's
always the goal to be productive in working towards something or have it be
helpful to others in the end. Sometimes I just enjoy building things in
itself.

~~~
slfnflctd
I guess I'm coming more from the perspective of someone who's played with a
whole lot of different things and is starting to realize the personal value
(for me) of targeting my efforts better. I tried to be clear that I'm not
saying it's a bad idea for everyone, but that at this point in _my_ life it's
counterproductive. There are other ways I can get the same benefits micro-
scale agriculture provides with much greater potential rewards attached.

------
barrenko
Failing is hard. I'd definitely try to get my kid into sports so he can learn
to lose early and often.

~~~
nogabebop23
>> I'd definitely try to get my kid into sports so he can learn to lose early
and often.

So nobody, kid or not, wants to fail/lose all the time but after watching my
three kids play lots of different sports the pain they feel after a loss is
very fleeting and minor. The parents hold onto it for much longer; the kids
just want to know if they can get ice cream.

~~~
CorruptVoices
I wish I could have figured out if I was good at Football. There were 120
people on the team and unless you were friends with the coaches kid, you never
played. I was always first pick when doing 5th grade football because I could
catch and was fast.

Defense had 0 tryouts. There was literally 2 attempts at being a wide
receiver. 0 attempts at being QB or lineman.

I remember catching both passes, but maybe I wasn't fast enough? Whatever the
case it was obvious it was hand picked. And our team won 2 of 8 games.

At least no one can dispute how much I sucked at track lol.

~~~
wolco
You needed to join a real team to find out.

------
fourseventy
Game engines is a really tough market to compete in given Unity and Unreal are
now basically free. When I built the game that I launched on Steam I made my
own game engine with the idea that I would open source it. The engine is now
open source but when people ask about it I recommend they just use Unity
instead.

~~~
mrlala
Also Godot being 100% free, and while I haven't used it crazy extensively the
2d portion I have used it for was amazing.

~~~
didibus
Yup, and now also Defold engine and Amazon Lumberyard as well.

------
timavr
It depends on the mindset. From my point of view, it is a huge success,
because now when you apply for normal game jobs, you will massively stand out
for creating something that people used and supported it over time. Basically
you will have job for life. Most developers can only dream of that outcome.

From business side, I don't think it has anything to do with you. Quite often
it is down to luck, ability to predict where market is going next and
execution.

It is tough for Monogame C# framework to compete with Unity. Your tool is
basically build on top of their Monogame funnel, so if their funnel is tiny,
then you screwed. But at the time it is hard to see how it was going to go,
because Unity has so many problems and closed source didn't really help.

Number of problems increased exponentially on the Unity side, but it became
industry standard, so today if you making games and not using Unity/Unreal and
not AAA studio, it is super risky to get funded.

~~~
zarfius
Thanks for reading and thanks for the kind comments.

It's true, having this project under my belt has already helped my career in
many ways. I'm pretty sure it was a big factor in landing my last job. Not to
mention the many hours of practice I put into coding outside my day job.

I never really wanted to compete with Unity but in hindsight I may have been
better off piggybacking my library on Unity rather than MonoGame.

------
ldd
I've been developing a game full-time for the past few months. I've sort of
thought about how my journey will end.

In the meantime, I got to write a couple of VSCode extensions that are used at
least by some people and React dependencies that I personally find cool.

I never really thought about it, but my open-source projects usually end up
having 15-40 stars and that means 1 or 2 support tickets every 6 months. I
guess not being popular has its upsides.

All that I can personally say is that, more than passion towards my current
project, I feel as if I didn't make it, I would regret it deeply. So I wake up
early every day to advance a little bit each day. I deeply enjoy the process.

I hope you someday look back at your project and see it as a success. A
failure commercially, maybe, but a success in many other ways.

Anyways, thanks for the link to
[https://www.indiehackers.com/](https://www.indiehackers.com/).

------
notadonut
"failure disguised as success" is a profound insight.

The Silicon Valley version of this is raising a lot of money when you don't
have product-market fit or the right co-founder or both. Getting other people
to commit millions of dollars to a bad idea or the wrong team is a great way
to waste years of your life. It leads to what I call perverse persistence --
not letting go until long after you should have.

------
gameswithgo
thank you for the monogame contributions dylan!

~~~
zarfius
You're welcome. Thanks for reading!

------
kabacha
I'm so perplexed by people like this. You start something with no goal and...
Act surprised you hadn't reached some goal?

~~~
zarfius
I had goals. Some of those goals I did reach but having goals and knowing how
to reach them are very different things.

Thanks for reading.

~~~
kabacha
Sorry didn't mean to offend you. However I'd urge you to stay optimistic — you
made a great thing that inspired and taught a lot of people and probably had a
lot of fun while making it! Not everything needs to be measured in shekels.

The only mistake you seem to have made is that you didn't quit soon enough
which is a story as old as the idea of collaborative project itself and I
think people will continue making it.

~~~
zarfius
No problem. You're absolutely right. I did have fun making it and learned a
lot in the process. No regrets.

Goals change over time. Even now I'm making new goals that will no doubt be a
bit different in years to come.

------
daodedickinson
How did you get married and afford rent?

~~~
macspoofing
It was a side project. OP mentions he has a full-time job ... also, is
marriage contingent on an income level?

~~~
brianwawok
Both marriage and divorce rates have a very strong correlation with income in
the US.

It also makes being unprofitable and living in your parents basement harder.

(Obviously GP missed that this was a side gig)

~~~
searchableguy
> Both marriage and divorce rates have a very strong correlation with income
> in the US.

[https://onlinelibrary.wiley.com/doi/10.1111/jomf.12629](https://onlinelibrary.wiley.com/doi/10.1111/jomf.12629)

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5464617/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5464617/)

