You are here

Obligatory end-of-year blog post

Body: 

So I thought I would write a post talking about the progess I've made, and some of the things I've learned over the past few months. Everyone else seems to be doing it, and I'd hate to be accused of being the kind of person that does not follow trends.

It's probably best to start off with a recap of the story so far. So, here's who I am and what I'm doing: My name is Jay, I am a solo indie game developer. My company, Mind Relay, is a Community Interest Company, a special kind of not-for-profit organisation meaning that all the profits the company makes are donated to charitable causes. I am developing a game called Tiny Robot Justice Squad, a 2D side-scrolling arena shooter for Windows, OSX and Linux. It started off as a hobby project, but quickly snowballed into something I am taking more seriously. I've done game development as a hobby/weekend thing for several years, but this is my first real, big serious project. In a couple of weeks, it will be on Steam Greenlight.

Over the past few months I've learned a lot -- mainly about the business and marketting side of game development, which I really had no experience in before. I've learned that keeping up with Twitter/Subreddits/etc. takes up a lot more time than expected, but is really rewarding, especially when people give you feedback (it's also where I learned about the art technique of Greebling which I now use everywhere!). Since I work solo, that feedback is like gold dust to me. I posted a one-minute long draft trailer to Marketting Monday on /r/gamedev about a month ago, and received some really helpful, detailed feedback, not only on the trailer but the game itself. I then used Behaviour Driven Development to motivate development of the actual game to satisfy what people said the trailer should contain. I'm still working on it!

Art has really been my main struggle. I am by no means an artist, but I can fumble my way around Photoshop to make things that I think look half decent sometimes. I've made great use of resources like OpenGameArt.org to find references to act as a jumping off point for my own work. I feel confident that I could code up any game mechanic/behaviour I come up with, but art remains my biggest bottleneck -- I can design and code it, but can I draw it? Usually the answer is no, and so I have to work within my own limitatons.

This isn't always a bad thing though, and you can use your limitatons to your advantage, and result in a distinct style. For instance, I can't really draw freehand, so the majority of my art is done by deforming primitive shapes. One thing I discovered early on was that it was really important to have a set of re-usable visual tropes. I approached this by having a set of technical rules about how the stuff in my world worked. I asked questions like: How do things that can fly work? How do the laser guns work? How is the environment constructed? This then let me define components like anti-gravity engines, ammo containers, power supplies etc. that mean that when I needed to build a new enemy or boss, I could look at that list and know what components the thing should have. This means I'm not starting from scratch, and I can base what I draw in the rules of the world.

The art is definitely improving though. This past week I've had to go and touch up a lot of the old art from when I started development, since it looked out of place next to the newer stuff. I think this is a very nice problem to have, but it's also quite time consuming. I never throw anything out -- code, art, etc -- it's all kept. You never know when you might need it in the future. Case in point: One of the playable characters in Tiny Robot Justice Squad uses art assets I created over four years ago for an unrelated game.

An example of the art improving is how the art for the signal pod has improved over time. Signal pods are a type of enemy that form the game's primary mechanic. Signal pods drop into the levels and control the intensity of the waves of enemies you will be battling. You must destroy them to progress, and so you have to balance thinning out the enemy hoard with taking out signal pods. I never really had a clear idea in my head what a Signal Pod looked like. I've just sort of bumbled through it. This GFY shows how the art for them has changed over time:

I've made the decision that I'm going to launch Tiny Robot Justice Squad on Steam Greenlight on or around the 14th of January. I'm nervous, naturally, but I'm pretty confident in the quality of my work. A few weeks after this I'll be releasing the one-level demo. I'm planning to use that as a shot in the arm once the initial greenlight spike dies down. One big issue I'm going to have to deal with is promoting the game to websites, bloggers etc. this is really daunting, but there are some wonderful guided on Pixel Prospector that discuss how to go about that. As an aside, Pixel Prospector is a goldmine and easily the most useful website for everything gamedev related. I would be lost without it.

In terms of overall development the game is coming along nicely. I have one level totally complete, one at 80%, two that are skeletons, and one part-designed and yet to be implemented. I'm aiming for 7 levels, each of which taking about 15-20 minutes. Really, as always, content creation is the bottleneck. Making the enemies, backdrops, tiles etc. for these levels takes up the most amount of time, and there's no way to shortcut that. My development style is very anarchic -- when I sit down to work, I don't really have a set plan of what specific things I need to be working on. I know what needs to be done, so I sit down and do it, sometimes flicking between half a dozen different things at once. This kind of thing would never fly when working in a team!

Well that's about it for now I think. In the new year I hope to start posting some more technical devblogs, specifically covering my workflow. The number one thing that caused this project to take off was that I figured out a solid workflow of designing stuff, drawing it and deploying it in a game engine. For me this is absolutely key, because this needs to be a lightning fast and painless process. In the past I've had very laborious workflows, and it's just killed my interest in those projects. I think I've cracked it now, but I'm always looking for improvements!

Thanks,
Jay