I was originally going to make this a short post on /r/gamedev, but as my thoughts of what I wanted to share began to solidify, I realized the length of the content would necessitate something a little more formal. Thus, this blog post began to take shape.

First, let me say that I am releasing the source code to my first indie game, Irritum. Also, since I do not want to spend a lot of time cleaning the Git repository, I am including all of the game assets as well. As a natural consequence of this, I’m making the game free to download.

If you’re just here for the source code and assets, they can be found here. If you’re looking to download the game for free, it’s available on my personal site here. If you’re interested in a post-mortem and critical breakdown of my history with the game, read on (if you’re into making your own games, I highly suggest this).

I also want to state that I’m not actually going to cover a lot of the game mechanics in this blog. The game is free, so you can go download and experience the mechanics if you want. I personally think discussing the inspiration and ideas for mechanics is not very interesting; Everyone has ideas, but the implementation is where the rubber hits the road. Furthermore, adding mechanics to the conversation can make new developers think the content of this blog doesn’t apply, since the mechanics specifically relate to my personal game, which is a huge disservice. As such, I’ll try to keep the blog content separate and abstract from the game implementation.

There is a lot I want to cover, and I expect this post to be very long and probably a little disorganized, but first we need some background information.

First Things First

I want to get some things out of the way early on:

The game was not successful, I only made about $100 at my best guess. It also received many negative reviews (though a few positive ones).

The game was released in 2013, and it was the last game I released. I’ve played around with some prototypes since, but have not spent any real development time making a game.

The game was released over four years ago, and as such it’s difficult to recall a lot of details, but I’m going to do my best.

Regardless of any of the mistakes or shortcomings I mention here, it was a great experience and something I am happy I decided to do.

With that out of the way, let’s get started!

Background

In the Spring of 2013, I was wrapping up my second year at a local university for a four year Computer Science degree. I was aiming for an internship over the Summer, but after a few phone screenings, I realized I was clearly unprepared. At that point I had a wider realization about my education and how to make the most of my career, but that’s a conversation for a different time. The point is – I was now left with a summer where I needed to spend time developing my skills as a software developer.

I jumped at the opportunity to develop a video game, which is something I had been dreaming of since my early teens, and I immediately began preparing. I acquired my tools (more on that in a moment), and began playing around with some game concepts. I considered my education to be more important than the game (a decision I still stand behind, which I can go into more depth in another blog post), which meant I needed to finish the game before the next school semester began in mid-August. This left me with about 3 to 4 months of runway to develop the game. Considering most games take 2 to 4 years to develop, time was obviously not in my favor.

Additionally, I was operating on a budget of exactly $0 (USD, if you were curious). I would work the weekends to keep my bank account from sinking (a retail job making just over minimum wage), and thankfully I was still living with my parents so this strategy was feasible. With such a small budget (literally nonexistent) I also could not hire or outsource any assets (not entirely accurate, as I will discuss later), meaning I would have to work on the game 100% alone (I couldn’t wait to find another team member either, and I also wanted to avoid the legal paperwork).

The above facts brought me to a development process with a nonexistent budget and a short timeframe. I was fortunate enough to not have to worry about supporting a family, paying a mortgage, etc. Without the support from my family, this would never have worked…

I eventually settled on a 3D platformer game, with a minimalist art style and an experimental setting. I thought this would be a nice balance between interesting gameplay, an interesting hook for an audience, and a simple to implement set of assets. And with that, I started development.

Development Process

I had been trying to develop games using the Unity game engine several years prior. However, all the projects were small, riddled with bugs, and hacked together. Now, I had actual programming knowledge and could develop something more substantial. I decided to continue to use Unity, since I had experience using it, and since I learned both Java and C# in school (Unity supports C#), it was an obvious choice. I was actually more familiar with Java, but since C# and Java are extremely similar in syntax, in the context of Unity I could reuse a lot of my Java knowledge. Programming is what I know best, and as such I was confident I could get something working relatively cleanly. What I really needed help with was assets.

For the art assets, I used Gimp and Blender. Gimp is a free application which is very similar to Photoshop. I used it mostly for developing 2D textures. Blender is also free, and is a 3D modeling tool (or at least that’s how I used it). For music, I used Garage Band (included on OS X at the time). These applications let me create nearly all of the required assets easily, even if they were not of professional quality.

I now had everything I needed to make the game. And with that, we arrive at the game idea.

As I said before, I wanted to make an experimental game. If I didn’t choose an experimental genre, I feared my game would be eclipsed by the myriad of other indie games with larger budgets and more talented teams. The most obvious experimental topic for me was suicide. I won’t go into detail about this here, but it’s a topic I am passionate about.

Before we move on to specific experiences, I want to show you what a typical day looked like:

Wake up around 10 or 11 AM. Get ready for the day, which took less than one hour.

Look at my white board for what needed to get done. If I estimated any task to take less than an hour to complete, I would try to prioritize it.

Basically follow this process until I get to a “blocker” task, which I would then prioritize. These tasks were ones that needed to be resolved before I continued, as they would slow down other related tasks.

Repeat this process until 1 or 2 AM.

The above schedule, working Monday through Friday, leads to a roughly 70 hour work week, excluding the few hours I could put in over the weekend. Oh, and then my part time job was typically 16 hours over the weekend. It took a lot of discipline to follow this schedule, and was often extremely stressful. It’s also not only physically draining, but mentally. More on these effects later.

Now let’s see what specifically I was working on.

Assets

I don’t think I did too bad with textures, as I had an artistic background. I was really fortunate with this, as I had been drawing and painting since I was a child, and was actually considering pursuing Art as my major before I chose Computer Science. Without my previous interests in art, the game would never have gone as far as it did (which wasn’t very far anyways). Looking back, I’m still very proud of the textures I made for the game.

As far as game assets I am proud of, that’s where it ends.

If you are considering making a game by yourself, I would strongly suggest a similar history or experience for the developing assets as a requirement. Otherwise, it will come off as ugly and amateurish, which is certainly not the kind of chatter or perception you want surrounding your game.

The music was all boilerplate and minimalistic. I considered it to be creative at the time, but it was really just an excuse for a lack of interest and time. I was actually graciously donated a piece of music by Matthew Norris (youtube), but everything else was content I created, and it really shows (in a negative way).

I was in a similar situation with 3D models and animations. I spent a lot of time developing these assets, and the results were unsatisfactory. On top of the amateurish quality of the assets, it is simply not worth the time to develop these assets. In fact, we can use some simple math to demonstrate how much of a waste it is to create these artifacts.

I spent nearly two weeks creating the player model, textures, and animations, and they were all ugly. I previously estimated I spent around 70 hours a week on the game, which means I spent 140 hours working on the character. We can add monetary value to these hours by considering my time as an opportunity cost, which can be understood as time I could have been spending doing something else, and making more progress. At the time, I was making around $10/hr at my retail position. This means the player models value can be estimated at $1400.

To put it another way, I basically spent $1400 building the player character. This is not an efficient way to spend time. Not only did I pay an exorbitant amount of money for this singular model, but it was, quite frankly, shit! If I paid someone else $1400 to create a fully animated character model for a game, and it was a piece of shit, I would be irate. Yet, this is basically what I did, and what’s worse, I thought it was a good idea beforehand even though I generally knew the costs and generally knew the outcome. I essentially decided to spend a lot of money to buy something I knew I would not be happy with (for the value).

The Unity asset store contains hundreds, if not thousands, of player characters, many of which are under $50. Turbosquid offers comparable rates. Don’t forget, these value of the model was determined using the pay of a retail employee! Could you imagine what the cost would be now, with my current salary in an actual software engineer position? The costs would be ludicrous!

Sure, maybe the assets don’t fit your game 100%, but what is the value for such an asset? If you can’t afford to hire a team member to develop the assets, then you can’t afford to pay yourself to develop the asset. At least to me, it really is that black and white.

This leads me to one of the biggest mistakes I made. I interpreted budget as the amount of money I had to spend, but I failed to consider opportunity cost as part of the budget. It’s counter-intuitive, but it would have been cheaper for me to purchase a model for $50, than to build one for what i thought was free (the cost being two weeks of my time, valued at $1400). If you or someone on your team has the skills and talent to create beautiful assets, then go for it. Otherwise, I wouldn’t even consider trying to create homemade assets.

All of the assets I created, when placed together in the game world, resulted in an ugly game. I pulled off some tricks here and there to make the game look better, and at some points it really does look good. But there is nothing more damning than a game that does not look good, or even professional. Don’t confuse unprofessional with minimalistic.

As a final comparison, would you ask someone who can do 3D modeling to write game code? It seems completely unreasonable, and it may well be, but at the time I was basically convincing myself that I could do the reverse.

With the assets out of the way, this brings us to what I know best, programming.

Code

Now this is where I knew what I was doing (or so I thought). This was my area of expertise, and as a result where I wanted to spend as much as my time working (and it is certainly where I spent most of my time).

I was comfortable with writing code at this point, but had no experience with software architecture or managing large codebases. This eventually lead to unmanageable code, which is quite honestly embarrassing when looking back on it. (Please, be gentle when reading the source code. We were all noobs at one point).

But, I was making a working game, and it felt great. I think the code was as good as it was going to get, for the amount of experience I had at the time. I was also on a really tight schedule, so there wasn’t a lot of time I could dedicate to refactoring, unless something was just plain broken. I’m not necessarily proud of the code I wrote, but I understand and remember the circumstances, so with that in mind I am happy with how it all turned out.

What I’m not happy about, is the importance I gave the the code over virtually every other facet of the game. Primarily, I was happy with working code for features, rather than ensuring the features were actually fun.

I think I can attribute this to my original intention; Getting more experience with software development. I focused so much on practicing writing code, I unintentionally put the actual game itself on the back burner. Whoops.

So this went on for about 3 months, until it became August. Over the summer I spent time trying to send out Alpha and Beta copies of the game, get youtubers free copies, and send the game out to reviewers. None of these tactics really led to a big difference in attention, but they did offer some good feedback, which I did my best to incorporate into the final version of the game.

This brings us to the launch of the game.

Launching

The first thing that comes to mind when I think about launching is the marketing campaign. I was contacted late in development by an indie game marketing organization who offered their services for an expensive fee. I negotiated an initial fee of $300 (around 10% of the original asking price) alongside royalties for game sales over the course of the first year after launch.

This was a mistake, and I stress to any other indie developer to have the same point of view.

I don’t think the company had any malicious intent when offering their services, but I was virtually promised success by virtue of their proven track record, which included games like Thomas Was Alone. Being the hopeful young game developer, I was all too eager to hope for success.

The problem was that their provided services were responsibilities I was already handling. One of their offerings was getting interviews, of which they provided me two (if I recall correctly), where I found three others myself. This is all I can recall them doing, with the rest of their time spent “talking to their connections”. They may have indeed been doing more work behind the scenes, and they may have been doing more work that I simply have forgotten, but if I can’t recall exactly what I paid for, then I probably shouldn’t have paid for it.

I saw very little return for their services, and I’m only grateful that they worked with me on agreeable pricing terms, where the original offer was a few thousand dollars.

A counter point to my perspective could be my aforementioned opportunity costs, where it would be more cost effective to purchase this service from someone else, however I don’t think that’s a fair comparison. If I respond to an interview request, I still need to actually write responses to the interview questions, regardless of the avenue the interview came to me. This time is required to be allocated either way. So I’m not really paying them to do much in my stead.

The impact of this company’s involvement is difficult to determine, mostly because the final sales of my game were abysmally low. I couldn’t imagine their involvement impacted sales much, if at all. On the topic of sales…

My payment processor for the game does not appear to have a complete history, only going back two years (which there have been 0 sales of my game,) but digging through my email history, it looks like sales of my game may have reached just over $100… Like I said, abysmal. Desura has also changed hands since my game launched and has yet, to my understanding, migrated the previous content to the new platform, so that sales data is currently unavailable. There was another platform I published the game on, however I forget the name of it. I don’t think it brought in any sales at all.

What about Steam Greenlight?! At the time, Greenlight was relatively new. They were charging $100 to submit a game to the actual approval process, and I felt I would instead launch on Steam after my general launch. I made a free Greenlight page, which attracted very few views. Recognizing the low amount of views, regardless of the amount of “marketing” being done, I determined Steam was something I did not want to dedicate my time to yet. Being available on Steam may have changed the success of the game, but at the time only a few handfuls of indie games were actually being accepted to the Greenlight program. For me, it was a virtual certainty it would not make it through the initial screenings. I wasn’t going to waste my time on it, and I figured if my game ended up being successful that I could swing into Steam easily. This was, of course, something I never came back to.

Why were sales so bad? Well, it seems like the marketing company didn’t really do a whole lot. I would imagine if they had, sales may have been a little better. That may not be an entirely fair assessment though, as I’m sure the game quality had something to do with it too… Like I said before, whoops…

Initial reviews were divided. Some reporters appeared to enjoy it quite a bit, while others bashed virtually every aspect of it. As time went on, bad reviews became more common. I wouldn’t say the game collectively received a “negative” reception, but “mixed to negative” reception may be more accurate.

The most common complaint would be incoherence. The story was confusing, the game mechanics were sloppy, controls missed the mark, there were several bugs, etc. All fair assessments and critiques. At the time I was pretty unreceptive to the reviews, but now I see they were mostly accurate. As I said before, I attribute this to my prioritization of the code over the design of the game.

Mistakes

Now we get to where, in my opinion, the most beneficial content is found. What were some of the mistakes I made developing the game? There were many, some of which I touched on in the previous sections, but I consider the ones listed below to be the most important ones.

Marketing Company

The marketing company I worked with was a waste of my time and my money. I hear this kind of sentiment echoed by many other indie developers, which leads me to believe these kind of services prey on inexperienced developers or small teams. These services won’t make a bad game appear good, and it won’t make a good game appear any better. I advise indie developers to stay away from these services, especially if you are operating on a nonexistent budget.

Let me be clear though, this is not a suggestion to avoid marketing. Marketing is paramount to the success of a game, and your team needs to figure out the best way to market your game. In my opinion, the best way is word of mouth. Additionally, if you add features to your game such as “invite friends”, “post to Facebook”, “integrate with Twitch”, etc, this can be low hanging fruit for word of mouth marketing. Probably a topic for a different blog post.

In-house Assets

If the team does not have a member with experience developing some type of asset, it’s cheaper to purchase this content instead of learning how to make it while you build it. The asset will also likely be of higher quality.

An example: You can buy a set of a thousand generic web icons for about $20 from a ton of different services. How long will it take someone to manually make these icons? In many situations, the provided assets in such marketplaces are well worth the money. Do not get trapped in the thought process of “our stuff is too custom”. It may be, but if it is, it’s still, mathematically, better to hire someone or outsource to someone else.

Focusing on Implementation

Making games is difficult. Very difficult. So much so, that you may get caught up in actually making something that works, much like I did. But this is not the sole aspect of what makes a good game (even though it is important in making a working game). Good games are made by fun experiences, and these experiences are inherently separate from implementation details.

Some contemporary examples (as controversial as they may be): The Order 1886 and No Man’s Sky. These games are technically impressive, but are they fun games? Most gamers, and reviewers, don’t tend to think so. Just to clear the air, I like both of these games.

Bad Name

I named the game Irritum, which was a terrible decision. Yeah, it has meaning behind it, which is hard enough to find in game titles, but otherwise it sucks. It’s difficult to pronounce, difficult to spell, and is always auto-corrected into something else. It’s also not memorable. Really, a bad decision overall.

Benefits

This blog may sound overwhelmingly negative, but there are some good parts, I promise! My perspective may be skewed for many reasons, but the below benefits are likely the most prominent.

Releasing a Personal Project

Releasing a personal project is a huge feat, and even more-so for inexperienced developers. This looks really good to hiring managers, and my game was specifically called out as an impressive demonstration of skill during several internship interviews (the following year). If anything, the game helped me move out of retail and into a software development industry faster than I would have normally.

It’s also personally satisfying. How many people can say they released a video game? Not a lot of people. Even when talking to other technical people, they are impressed. Of course the game wasn’t very good, but they’re impressed nonetheless. Not to mention, the younger generations in the family always think it’s super cool!

Personal Discovery

I enjoyed making a game, and I hope to do it again someday. But I learned making a game is genuinely not fun for me. I enjoy writing code, and it’s part of my current job. I enjoy solving difficult problems and developing elegant solutions for such problems.

What I don’t enjoy, is changing a jump height variable 17 times until it feels just right. I don’t enjoy spending time building something, such as a character model, only to realize it all sucks and should be entirely redone, concept and all. I don’t enjoy wasting time on inefficiencies, which is what developing the assets felt like to me. Unfortunately, these were my experiences when developing Irritum.

I still dream of making games. I have ideas I think would make fantastic games. But then I come to the instant conclusion that I need a team, I need a budget, and I need a generous amount of runway time, none of which I have major access to at this moment.

I’m glad I figured this out through a personal project, rather than, for example, spending $130k going to Full-Sail University (this topic is a powder keg… yet another future blog post).

Discipline

I like to think that I have always had a good work ethic and was disciplined enough to work long hours with tough duties, but working on this game really helped me practice this skill. These “soft” skills are often overlooked, but are incredibly important when it comes to a professional career in any field.

Things like time management, troubleshooting, finding documentation, etc. are skills all software developers require, and this project helped me develop these skills earlier in my career. There is, in my opinion, absolutely nothing wrong with learning things sooner rather than later, even when you fail at that particular project. As I’ve come to discover, failure is the best way to learn.

Conclusion

Spending my Summer vacation developing a game was an amazing learning experience, and something I would do again under similar circumstances. Even though I made many mistakes, and didn’t make much money, I grew a lot and I learned a lot.

Would I make a game again?

Eventually, absolutely. I’ve been working on a few prototypes over the past several years, but none of which I find interesting or fun enough to continue pursuing. One of the bigger projects I have been playing with recently is a multiplayer game server (server-client architecture), but that’s almost entirely programming, and not much actual game development.

I think that, for now, I would rather focus on what I know best. Writing good software for the full stack. I will return to games one day, but I don’t know when that will be.