Picking a Project

Allow me to introduce Gateway.

Set in a future where the destruction of Earth and the colonization of space are fading images of the past, humanity has spread throughout a galaxy for which they are not prepared. Although their scientific understanding of the universe is not what it once was, humanity has constructed a massive gate network that allows fighters and cruisers to be deployed anywhere in the regions they control. An ongoing civil war only adds to humanity’s stress and amidst the turmoil, nearby regions of space begin showing signs of activity.

Don’t let the story bore you — here are a few screenshots coming from Gateway’s nearly-complete game engine:

Two massive cruisers face off.

Four massive cruisers face off.

An enemy fighter takes laser fire damage.

An enemy fighter takes laser fire damage.

A massive space battle takes place in high orbit over New Röntgen.

A massive space battle takes place in high orbit over New Röntgen.

Friendly reinforcements arrive through the gate system.

Friendly reinforcements arrive through the gate system.

An alien cruiser returns deadly fire.

An alien cruiser returns deadly fire.

This is not a technical blog. Yes, I might mention things such as depth sorting, matrix multiplication, and stack-based menu systems, but I reserve that right at all times. What we will be talking about here is the nature of game dev for the lone developer, with some personal project management tips and the occasional technical detail thrown in for additional flavour. In my opinion, finishing a game is a lot harder than any of its technical implementations.

Ideally, I’d have started this blog at the beginning of Gateway, not somewhere between the middle and the end. I’ve never been this close to finishing such a large project before, but even a few thoughts at this point in my game’s development might be valuable to someone (maybe even myself).

If you know a fair bit of C++ and have a good OpenGL background, it’s tempting to think: “I know how to implement every single one of my game’s subsystems. I can easily write this game.” Perhaps this kind of optimism is the reason why we can be so motivated — if we really knew how much effort or work something meaningful was going to be, we might find it hard to even get started.

Unfortunately, writing a game (yes, even a small one) is much harder than implementing just the sum of its parts. Significant overhead and time must be committed to putting all of these parts together, and it’s laughably easy to underestimate this effort.

This is not meant to discourage anyone, but to provide a note of caution: you don’t have to write the game of a lifetime. Your project doesn’t need to be the single, greatest goal you’ve ever had in mind. Some of the best, most fun projects (not all of them games, either) I’ve ever worked on in my free time have been ones much smaller than I was capable of producing. Don’t worry: the big, unstoppable projects will come, and you’ll be ready for them.

How do you pick a project to work on? Maybe you can make a pros-and-cons list, or write down what you think it would be like to work on it. My own approach, especially when I’m trying to decide between multiple ideas, is to not work on anything. Eventually, perhaps after about a week or two, one of those ideas surfaces higher in my brain than the others, and begins to keep me up at night and distract me while I’m driving. At that point, I know I’ve made up my mind and am ready to begin.

GN

Advertisements

One response to “Picking a Project

  1. Pingback: Finish or Fail | Single-Handed Game Dev

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s