In the feedback I got on the first part of this series, a few people asked me to do a blog on how I pick, plan and schedule my games. There obviously isn’t any one way that works for everyone, I believe a lot of this grows from the experience of developing and completing multiple games. If you have other ways and idea’s on how to handle schedules and work load, I’d love to read about it in the comments!

Full time is a job

These blogs are written from my point of view as running a business. Sure I’m an (indie) game developer, but I didn’t set out to be a game developer when I started Orangepixel. My plan was to be self-employed and developing games was something I saw an opportunity in – mobile games just started back in 2004 a few year before the iPod touch or the current smart-phones appeared, but I felt it had potential to grow.

Anyway, my point being: decisions on which games I make and how to plan or schedule the work all comes from the perspective of running a business and needing to make money. If that sounds dirty to you, don’t worry about doing this full-time and just keep it as a hobby!

Stick it to the wall

The starting idea for my games can be a variation of things. It might be a fun movie, a great game I played, a funny cartoon image, or just a general musing of “what if..”. As with most creative jobs, anything can spark something new.

It always starts with prototyping: this is a combination of drawing some art to get a sense of the vision in my head; I’m a very visual guy, so I usually have rough idea’s of how it should look and just try to put that into pixels/graphics. I always compare this process to browsing through badly compressed screenshots, the images in my head, that are a bit blurry and not 100% clear. I then try to get that feeling and sense in the graphics I create on the PC.

My luck is that I can do both graphics and code, so I never really work with “programmers art” (blocks, blobs, circles, lines, dots, etc.)  I often dive in and either create some new graphics or use any of the graphics I have floating around on my HD from other projects or cancelled prototypes.  This is the main reason I often have something playable and looking decent within just a day or two of prototyping.

Prototyping really is just trying to get the core mechanic of the idea I have up and running. My idea is that if I can play it, it becomes clearer on what works and what doesn’t. I’m not someone who likes to write-down documentation and plans on what the game should be, at least not in this prototyping stage.  Just try stuff, get a feel of the mechanics, and see what sticks to the wall!

The trick here is of course identifying what the core-mechanics are of your game, and also limiting these in scope! That’s something you learn over time, and you get better at it over time so the scope can increase in size on future prototypes.

Turning it into something more

Many of my prototypes fail within a week or so. They are just boring, not working gameplay wise, or I often stumble into a better idea!  The trick with prototyping is to get those core mechanics up and running as soon as possible and play it a lot so you can iterate it and also identify where the fun is.

Sometimes, however, I skip the prototyping phase completely. For example, after releasing Space Grunts, I wasn’t really sure how the market would react to this game: It’s a turn-based game that plays with instant-turns, very much like a fast arcade shooter. I never released anything like it, and there was a big risk that my normal arcade-loving fans would think the turn-based stuff was stupid, and an even bigger risk that turn-based lovers would ignore the game due to it’s Arcade-like qualities.

So my business decision at that time was to quickly create something more safe just in case there wouldn’t be enough revenue coming in from Space Grunts. A sequel to Heroes of Loot was an obvious choice: the first one did huge numbers, and I also just created a cool new top-down level-generator for Space Grunts that I could base this on for a quick start!

So skipping the prototyping phase and “just” creating a new part in a proven series is somewhat of a short-cut, but very common and normal if you do this as a business thing (look at all the AAA games getting sequels). However, I only create a sequel if I can really improve on the original one in some interesting ways. Not just new settings and graphics, but enhance the gameplay.

Once you are confident in the prototype being fun enough, the real work starts!

Sizing it all up

In general I put my games in two different categories: small and big. Simple right? So a small game, for my workflow, is a game that can be created in about 3-4 months time. And a big game is one that can take 8-10 months. The type of game I make is mostly based on how business is going: revenue still coming in from the last released game? then it’s very possible to experiment and create something bigger.

I know, for some, it’s dirty to talk about game development in terms of making money, but that’s really the thing about doing this full-time. Sure it’s romantic to say you are in it for the art and for the creation aspects of the games, but if that’s the main thing, I’d urge you to keep it as a hobby and stick to a normal day job.  For me creating games is for a large part about running a business while doing the thing I love.

So planning and scope are based on the simple reality: how much time can I put into this before it needs to make some money for me.  Now that doesn’t mean a smaller game is a lesser game. Simple example: Space Grunts was a “big” game, it took about 9 months to create. Where Heroes of Loot 2, which I created after that, was a “small” game because time-wise it only took 4 months. However the end-products are fairly equal in size and scope if you look at it from a player’s perspective.

The main difference between those two is that Space Grunts was something new, my first ever turn-based game and most of the development time was experimenting what worked for me (since I don’t like turn-based games). Where Heroes of Loot 2 was a clear game from the moment I started: a dungeon crawler like the first one, but better world layouts (copied from Space Grunts code). So it had a much more polished and clear start allowing me to put in a lot more extra’s because I didn’t have to invent new wheels.   So simple lesson here: experimenting costs time and thus money! (see many AAA games as example).

We don’t need no stinking deadlines

Once I know a game (or rather the development-cycle) can be big or small I start thinking about the base requirements that I want in the game. Those requirements are the first that need to be made, and I add them to my Trello list. Then as I work on the game I keep adding possible-ideas to the trello list. Those are simply added to the game if they are very basic/easy, or added at a later date when I know I’m on “schedule”.

I don’t set strict deadlines or milestones. There’s no point in having all that if there’s no boss/publisher/investor hovering over you. Usually I do have a month in mind that I would love to release the game in, that’s simply based on business: money must be made to keep Orangepixel going.

I often become slightly nervous if my game isn’t done yet and the target month is closing in, and I think that’s just an automatic trigger by being self-employed: nobody else is gonna complete the work, and eventually money stops coming in!

The end is never near

The biggest problem for many seems to be staying focussed and actually complete a game. My first instinct here is to tell you: it’s easier if your livelihood depends on it! but it’s hard in any case.

My best solution is to mix up your work a bit. Don’t create all the fun stuff first and then add the boring stuff like menu’s and interfaces. When adding a cool new enemy, and you’re code isn’t fully working, stop staring at it and just put some time into a boring task like adding menu buttons, or cleaning up the interface and user-instructions. Then you also have a clearer head when returning to the difficult code and most likely it will be fixed faster.

Oh, and libraries! Make some re-usable code for things like input handling, interface rendering, etc. Your start menu doesn’t have to be the most unique thing ever, it can be a copy of your last game with maybe some images changes to make it look different.  Pressing a button is the same in all games, so don’t re-invent stuff like that, just copy+paste from previous games!

That doesn’t mean you should design code to be flexible for future use, that’s just a waste of time because most likely you’ll have to change the code in your future games anyway, or you found a better way to do it. Your game code should be an evolution. It changes with every game you do, or get’s replaced by something completely new.

The hard moments

As with all creative jobs: sometimes creativity just isn’t there. This can be caused by the gameplay not working as you like, you being in a less than productive mood, or everything you touch just isn’t working.

It happens to all of us, and try to power through it for a day, but if it’s not going away: stop working! Relax, do other stuff, try to literally clear your thoughts from the game for a few hours or a day. I often play other games, watch some movies, or just go out for walks or bike rides. Clear that head.

It’s a job and a business, but that doesn’t mean it should be a 24/7 life controlling monster. As most self-employed people will agree, we actually become self-employed to control our own time and have more free time when we want.