Categories
Game Design Game Development Marketing/Business Personal Development

Six Months As a Full-Time Indie

Mike Kasprzak wrote about his five years as a full-time indie, and it’s a fantastic read. Especially fascinating was how long it was before he made Smiles and his first real income. After years of burning through savings, suddenly things came together for him, and he was winning prizes and being pretty awesome.

In contrast, I’ve been running my business officially for almost five years, but I’ve only been full-time since the end of May. On the one hand, that means my story won’t be nearly as fascinating or interesting as Kasprzak’s, but on the other hand, existing part-time indies aspiring to make the jump to full-time might appreciate reading how things look for me in the short term.

I wrote about some of the reasons why I went full-time indie, but part of it was freedom. Spending 40-60 hours a week on stuff unrelated to my business meant I was giving my business short shrift. I spent so many years learning about game development, but I could only dedicate a few spare minutes to actually doing it? It wasn’t right. So I quit the day job.

Ah, Freedom!

Did I hit the ground running? No. The World Cup was starting, and I was going to watch as much soccer as I could!

I was even writing about it at my new website, Modern American Soccer, which actually got quite a bit of traffic in the weeks leading up to the first game due to the US Central-time specific calendar I created on Google. In fact, that site was going to advertise the soccer-based social networking game I was going to create with a colleague before that project fell through, so it was related to my games business initially.

Either way, my first month as a full-time indie game developer was spent getting used to not having a day job to worry about. I knew that it meant a month of spending my savings with nothing to show for it, but I decided at the time that it was acceptable. I was taking a break and getting my bearings (and watching soccer).

Now What?

When I finally sat down to do real work related to my business, I found it frustrating to not know what I was doing at any given moment. Not knowing when my next infusion of income was coming from made me feel a bit antsy, and yet I felt a bit overwhelmed by the number of different tasks to accomplish. I wrote about how it felt in the article Clear Goals or Trivial Pursuits, and I realized I needed to define some specific goals to tackle, or at least pave the way to learning what those goals should be.

In July, I hosted MiniLD #20 with the theme Greed and the special rule “Only One of Each”, which was meant to discourage people from reusing content and code. It was one of the more successful MiniLDs, with plenty of submissions, but my game wasn’t one of them. My project, The Old Man and the Monkey Thief, was the first game development project I started since quitting the day job, and I didn’t finish it in time.

Inventory and Treasure!

It was the first game I’ve made that involved a scrolling screen, and I remember feeling incompetent. How can I have thought that I could be a full-time indie developer when I didn’t even know how to make a game with something as basic as a scrolling background? It was a scary thought. Had I made a huge mistake? Was I not as prepared for making a go at a game development business as I thought I was?

Again, one of the reasons why I went full-time was so I could dedicate many more hours towards my games. If I felt incompetent, it is because I didn’t spend nearly as much time on it as I should have, and now is my chance to do otherwise.

Setting Monthly Goals

I decided that August would be the month that I would try to complete three small games in an attempt to learn as much as I could as quickly as I could.

My first project was my MiniLD game, which was taking me much longer than I expected, partly because of how unique everything had to be in the game. I didn’t finish it until right before Ludum Dare #18, and I didn’t feel it was worth releasing.

My second project was my LD #18 project, Stop That Hero!, which involved the most complex AI I’ve ever implemented. That is, I’ve never implemented pathfinding algorithms more complex than “go directly from point A to point B”, and in The Old Man and the Monkey Thief, I learned that there was a lot of problems with a character that couldn’t avoid obstacles well. Stop That Hero! took me three days to finish, but I was fairly pleased with how it turned out and wanted to flesh it out later.

Stop That Hero! is finished

I never did make a third project.

Still, two finished games in a month taught me a lot, and I was getting feedback from friends and colleagues. Even though I failed my August goal of making three games, I made good progress towards it and learned plenty.

Unfortunately, September started without goals set for it. In order to figure out what my goals should be, I spent a good chunk of the first week or so figuring out my options as an indie game developer. I thought it would take me a night to write down the options, but then I thought I could write up an article or two for ASPects, the Association of Software Professionals newsletter. It ended up being four full length articles, and it took me almost the entire month before I submitted all of them. If you’d like to read the articles, for now the only place they’re available is in the ASP members-only archives.

I also caught up on some reading. Business articles, audiobooks, and other literature were consumed. I would highly encourage anyone starting a business to read The E-Myth Revisited. For a long time I ignored it because I thought the E- part of the name meant it was a book about how Internet-based companies aren’t get-rich-quick schemes. I didn’t know it was a book about why most small businesses fail and what you can do to succeed.

Anyway, I spent the latter half of September analyzing the heck out of Stop That Hero! and trying to figure out what design directions to take it in. This time coincided with the creation of an organized daily schedule. It gave me some much needed structure, and I felt much more productive and focused, and I didn’t feel like I was letting anything fall through the cracks. I had time for writing, reading, organizing, and most importantly, game developing.

The October Challenge

While I wanted to flesh out and sell Stop That Hero!, I was having difficulty figuring out out how long to allow the project to run. I didn’t want to put together a skimpy game in a matter of weeks. Who would pay for it? And I didn’t want to spend six months working on it since that would be half of my burn rate. I don’t want to spend all of my savings on one game, and I don’t want to put together disposable games. I learned that Flashbang Studios used 8-week projects, but they had entire teams working on their games. Did I need longer? Could I afford to take longer?

Then Mike Kasprzak announced the Ludum Dare October Challenge, and I had my deadline. Make a game and sell it by the end of the month? I could do that! It took me only three days to make the prototype, so a full month should be plenty of time to make Stop That Hero! with multiple campaigns and different game modes. Right?

I wrote an October Challenge post-mortem, but suffice it to say that I didn’t get the game finished in time. Read the post-mortem for more details about what went right and what went wrong, but one of the biggest problems was not realizing how much technology I didn’t have to leverage.

Hacking a dinky game together virtually from scratch in a weekend is one thing, but making a full-scale game requires a lot of infrastructure and technology that I didn’t have. Rather than go without, I did research and development, which took up a lot of time. Tracking entities and game objects in a way that didn’t require a ton of dependencies was surprisingly difficult, and I wrote about my difficulties in implementing a component-based system in State of the Art Game Objects.

Of course, developing infrastructure is not developing the game. It’s just laying down the groundwork for a game. Kasprzak took time off to work on a framework after PuffBOMB HD, but it sounds like a lot of it was already in a game and he was cleaning it up and improving on it. While I had some prototype code, a lot of it needed to be reimplemented. Stop That Hero!‘s pathfinding algorithm was fairly hacked together, leaked memory like crazy, and required a few other algorithms to compensate for when it wouldn’t work well on its own. The new version is less dependent on knowledge of the entities moving through it and works very well, but it took me way longer to write than I would have liked.

Besides creating the necessary technology for the game, I’ve never worked on such a large scale before. Programming is not software engineering and hacking is not project management. I didn’t have much experience leading or creating a serious project before this one, and I found myself struggling with choices. What do I call this class? Should this be its own class in the first place? Is this overengineering or good practice? And that’s just the software architecture. There was also the question of project scope. I was behind schedule, and it wasn’t due to feature creep. What was I doing wrong?

Continuing the March Towards Completion

But if I could get the game done by Christmas, I think I’d still be doing well. The October Challenge was just a fun deadline and wasn’t a must-hit, urgent business deadline. According to the work I have identified and my actual rate of work, I thought I had a more accurate project estimate, and Christmas seemed to be a doable deadline. From what I’ve been told, there is a trend of increased sales around Christmas, so it might work out better for me. I pushed forward.

I was making decent progress at first, but the end of the month involved Thanksgiving and moving out of my apartment. To make matters worse, individual game systems weren’t working quite right, so I spent part of the last week finding and fixing bugs for work I thought was finished. I was finally hitting my weekly estimates, but there were also setbacks. Progress was still slower than I would have liked overall.

Unfortunately, near the end of November, I saw my schedule slip even more when I identified a ton more work. When hacking a prototype together, there can be missing menus, level selectors, data permanence, or any number of other aspects of a game. A full game missing these features isn’t a full game, by and large. When I initially planned out the project, I glossed over a lot of these kinds of details. I wanted multiple game modes, but I didn’t plan for them, nor did I figure out how I wanted the player to access them. Suddenly my project ballooned to almost twice its size, with a likely deadline in February or March, which made Stop That Hero! the six month project I wouldn’t have started if I knew.

Burn down towards February

The Future!

It was demoralizing to miss the October Challenge deadline, but this new estimated deadline was frustrating. I initially hoped to make my first sale at the end of October, and now I might not do so until after winter? And that’s assuming anyone is interested in buying it in the first place!

All this time, my savings account has been slowly reducing in size, and it will continue to do so. I’m well aware that I don’t make money producing a game. I can only make money selling a game. I could shelve Stop That Hero! temporarily while I work on something smaller, but I fear I’ll simply end up in the same situation writ small. That is, a smaller game still requires a lot of technology and infrastructure that I don’t currently have. Plus, I don’t like the idea of dropping a project midway and starting a new one. I’m tired of unfinished projects on my résumé.

I read a lot of things that get me second-guessing my choices. Is Stop That Hero! too complex and hard to make? Should I focus on “evergreen” mechanics, as suggested at Lost Garden? Is TDD inappropriate for getting games finished quickly, or is it necessary for getting games finished quickly? Am I expecting too much from my first project, or should I take the problems I’ve encountered as a sign? Am I running into the same kind of problems everyone runs into, or do I need to scale down my ambition until I have more experience? Do I need to work on smaller projects to build up my technology and code base, or can I continue building what I need when I need it for this project? And before you ask, yes, I have made a Pong clone, among other simple games, so it isn’t like I was jumping into a very large project without any experience at all. Or, maybe the problem actually is that I don’t have enough of these simple games under my belt.

There’s a lot of uncertainty, and it would be easy to panic or freak out (and I have at certain points!), but it is good to have some perspective. In six months, I’ve done more and learned more than I have in the last five years prior. While I expected to learn a lot during this time, my existing knowledge wasn’t as helpful as I thought it was. I’m taking on roles that I never had experience with before. Before I went full-time indie, I didn’t make decisions that would have a major impact on my business, and it’s an enormous responsibility.

And yet it isn’t a crippling responsibility. It’s exhilarating!

While I have the added burden of figuring out what specifically is important, I get to focus on it as much or as little as I want. While it’s a little scary to think that my decisions can make or break my business, they’re my decisions, and part of the fun of running your own business is in learning how to make better ones. The stakes are high, but at least I’m not settling for less out of a need for security.

Six months ago, I had very little idea that I’d make the progress I have and face the challenges I did. I knew it wouldn’t be a cake walk, but I also knew it wasn’t impossible. If I could change anything, I’d have tried harder to produce results while working part-time. I wish I had more direct experience working closely with other people making games so I didn’t have to figure out nearly as much on my own.

Still, I’m only six months out, and I’m in it for the long haul. In 2015, I hope I’m writing my own five year retrospective with plenty of good news to report.

If you are a veteran game developer, do you have any specific wisdom to share or regrets to warn against? If you are an aspiring game developer, do you have any questions about what the future might hold? Please post them below!

9 replies on “Six Months As a Full-Time Indie”

I still subscribe to your blog, and as I was reading this post thinking that I would write to you. Your invitation for feedback at the end of the article was all the invitation I needed.

You need a Producer, or make yourself into a producer, and kick yourself in the butt. As I have been reading your posts, my thought is that you have been all over the map. You are writing too many articles, and they are loooong. How much time are you taking writing articles? My sense is that you are using articles as a form of procrastination and to help you find your way. It feels as though you are not confident in your decisions, so you are getting into “analysis paralysis.” Do you really think that participating in another Ludum Dare is going to move your indie career forward? Sure practice make perfect, but shipping a game is what you need.

I would also question your business model. Pay upfront, downloadable games are quickly becoming outdated as a viable way to make money. I see you are reading Lost Garden. Those guys are right on top of things. Free to play Flash games are guaranteed money with immediate distribution. Make games like that. You are aiming, aiming, aiming. Instead, you need to fire, fire, fire, get user feedback, and find out what will work in the market.

Once you have a proven concept, which will make you money, then you can figure out how to bring it over to mobile. If you have a proven Flash game, there will be bidding wars over the rights to take it to mobile.

Anyway, I am not trying to be condescending here. I have just been following your blog for a long, long time, and I want to be able to keep reading it because you are able to stay in business.

-Jeff Tunnell

Thanks, Jeff! I’m glad you are still reading this blog. B-)

And no, I don’t think it’s condescending. I welcome this kind of honest feedback!

Writing time is relegated to at most an hour a day. In the past I didn’t keep track of the time I spent doing any given activity, and I didn’t realize how much time it takes to write an article. Writing those ASP articles required more time, but it wasn’t as if I was taking that time away from game development. I just took more 1-hour days of writing to finish them!

I’m currently pursuing downloadable for Linux (what I use) and Windows (easy to port to for me). While you say I am aiming instead of firing, I think I am firing. The gun is always aimed at the same target. It’s just very slow going getting that bullet out of the muzzle!

But reading contradictory advice everywhere does result in me questioning my decisions. As for confidence, at times I do lose it. For instance, I’ve been told that Flash games are the way to go over Java games due to ubiquity of the platform (even though Java was on just as many relevant platforms anyway), but I didn’t want to work with a proprietary technology. Then suddenly everyone is in love with Unity, which has no distribution anywhere near Flash. Downloadable is either dead or it is still alive and well depending on who you talk to. And free web games are everywhere which means a lot of competition, but you say they are guaranteed money. And then there are emerging markets like iPhone/Android/tablet/Kindle/etc.

I think I’ve done well to stick with my decision to pursue downloadable in the face of all this. Maybe it is the wrong decision, but as you say, I can’t keep jumping to this trend or that without firing at least once.

In the past when I was part-time, I might do only an hour of real work a week. It was pathetic and I needed that kick in the butt. These days, I believe I am putting in good time. When I’m working on my game, I’m not browsing the web, checking email, etc. So if I need to kick myself in the butt today, it’s not for trying to push me to do real work as opposed to time-wasting trivialities.

I think you’re fine doing what you’ve been doing. So far, you seem to have made necessary and appropriate course corrections along the way. The fact that you’re even cognisant of the need to do so is indicative of your desire to succeed with this venture.

While I’m currently only part-time Indie, I have a lot of time (a decade+) spent on the professional side of the fence. That experience has proven to be invaluable. On that side of the fence things usually feel rushed and there is rarely enough time to truly see a feature or system through to what most coders would consider “100% completion”. Along the same vein, the sooner something could be up and running (regardless of initial performance or code cleanliness), the better. It was always better to have something to iterate on than nothing at all.

I guess what I’m trying to say, is don’t over analyze and cause paralysis by analysis. Make an succinct honest first pass on the design of a feature and then code it up. From there, improve it if it needs it.

Lastly, I say stick with the project you’ve started. You started it for a reason — because you believed in the idea behind it. Anything you do in this industry is going to be a gamble. Yeah sure, maybe it won’t sell. And regardless of whether it does or not, the true value in the completion of a first product is the (mostly) production ready code that is now available for immediate re-use. The significance of that simply cannot be overstated. You’re currently incurring (somewhat painful and possibly frustrating) one-time start up costs in the form infrastructure development. Once this foundation has been laid, it’s highly unlikely you will have to tread much if any of this path again.

Hang tough, stay focused, and good luck!

Keep at it, man! It’s a long hard road, and I wish I had the stones to go for it full time.

I tend to agree about downloads being dead, but since you’re using Java, can’t you do both? like have a downloadable offline version and an online demo or IAP version? That’s how PopCap started out I think… And then there’s minecraft…

ship, ship, ship! remember, players don’t care what the underlying code looks like.

Thanks, Brian! Going along with my lack of confidence, it is sometimes hard to know if I have made a poor decision or if I made the right decision that happens to involve an one-time start up costs, as you say. I think if I had more contact with other game developers, it would be easier to know if I am approaching things correctly, differently, or just plain wrong.

jovoc, I’m using C++, not Java. I mentioned the language in the Flash vs Java arguments online, and I never understood why people argued that Flash had more ubiquity over Java, then argue that Unity is great.

Downloads are not dead, I’ve been in business years. Sure, you won’t get rich without a hit, but you can make enough to get by with luck. The market is shifting now though, Steam is taking over and you need to get on there to see decent money, but that probably won’t happen until a few games down the line. Your own direct sales will be small, but they are dependable and critical. Making money with a browser game is super hard unless it’s an MMO/facebook, Steambirds is exciting but will it make money, that’s what everyone is wondering. There are very few single player flash games that make a good return directly (most get a tiny amount from sponsorship). With Linux and PC versions think about a Mac port, there is ~35% of your money in Mac, you could even get someone else to convert it for 50% royalty split. Hitting all the platforms, knowing when to go for portals (steam,impulse,D2D), running sales, not selling too cheap, updates and add ons – all important to get by in the downloadable scene, its definitely not easy. I’d stick with what you are doing, everyone has same issues you are writing about. Get that game playable, get a forum and get some player feedback from an alpha (but don’t let the players dictate to you, just get a feel for what is right and what is wrong). That’s my two penneth 😉

I always enjoy reading your articles. Keep up the fantastic work! You are on the right track.

My one piece of humble advice would be to consider the “second system effect” which to simplify talks of how every excited and inspired programmer’s second major effort is always overly complex and dies of featurecreep. I think that perhaps you have gotten trapped by over engineering and over analysis, aiming too high.

You are making a mistake in requiring your code to be “perfectly designed” and should allow the use of hacks, ugly code, copy-n-paste and other heinous code patterns: the number one feature requirement for any piece of software is for it be to completed. All others can and SHOULD be less important. I sense that your source code is “too clean”, “too OOP”, and too flawlessly and academically perfect.

Give yourself some slack and embrace your inner hacker. Stop optimizing too early. Allow a few memory leaks. Accept a few pieces of inefficient code. Whip something up and throw it out there and move on to the next title. Assume it will be your tenth game that makes you tons of money. Don’t aim for perfection, which by definition is impossible to achieve. My gut instinct is that your source code is too perfect.

Reading this comment makes me realize I’m accusing you of what I myself am guilty of. =D I have found myself missing self-imposed deadlines all my life, and every project I start, I seem to get too enthusiastic and aim for something too complex, too feature-rich, too big for one person to finish in a reasonable amount of time.

Please take all of the above with a grain of salt as merely my two cents worth as I am definitely as guilty of these “crimes of pride” as anyone.

Congratz on the 6 months!

Some tips that have helped:
– Finishing a game teaches essential lessons. Finishing is an entirely different aspect of game development that puts the rest of your development in perspective. It is harder than expected and needs an immense amount of practice to get right so the sooner you start learning to finish the better. A lot of lessons mentioned above (plus about 300 more) end up burned into your skull when you start personally experiencing finishing.
– The key to finishing repeatedly is reducing scope. This also takes practice. Questions worth asking: Can you reduce the scope of your design? Of your art? Of your code? Of your levels?
– Doing jobs that put you in contact with other game developer or producers isn’t as bad as it is made out to be. Long term, it sucks out your soul, but it also forces you to finish and prioritize. Ever notice that many of the successful indies have had some history working for or in game shops? Until modern art destroyed the concept of competently created visuals, almost all ‘artists’ went through a period of intense training and apprenticeship that gave them critical tools they later used to innovate. We haven’t had our post modern period yet so even art games require an immense amount of craft. There is zero shame in learning from people who have been doing this crazy dream for years.

Persistence + Learning + Short cycle times. Dear Mr. McFunkypants has the right idea with the 10 games. After about 10th finished game, the process starts to gel.

As a note, there’s a strong emphasis on technology and process on this blog. All good things in moderation. The ultimate goal is a playable game released to a customer…anything that delays that is an opportunity to cut scope.

Happy day,
Danc.

Thanks for the comments, everyone! I really appreciate you taking the time to give me your feedback. And I have quite a bit to mull over!

Comments are closed.