Thursday, January 10, 2013

How to Not Suck at Finishing Game Projects - Part 1

But wait Chris!  Didn't you say that you never finished a game project?  Ok so yes, thats true, but I'm 99.9999% confident that I'm going to finish my current project because of the following tips that I figured I'd jump the gun a bit.  If I don't finish, well I promise I'll go back and rename this post!

First off, I'd like to mention a great source of tips on Getting Things Done is from Lifehacker, I've learned a ton of tricks from there to use on my projects and personal stuff.  Also, Vince on the Tiebreaker blog made a great post recently on staying motivated on a part-time project and his list closely mirrors my own.  Just more proof that these tips work!

Here are my personal tips to finishing a project:

Work on something you can finish

This should probably go without saying but seeing as it was one of the number one reasons I failed to finishing I guess it does require mentioning.  So how can you tell your great idea is one that you can finish?  Estimate how long you think it will take to finish.  Make sure you put some good thought into this estimate.  My mistake when first did estimating was that I tried to estimate how long the entire project would take.  As many of us in development know, estimating something that big is like taking a wild guess.  So break up your project into major milestones and estimate each of those separately.  Its especially important that if you're learning a new technology, engine or framework that you factor that in the estimate too.  Also, its difficult to estimate how long things will take doing it part-time, when most of us are used to estimating full-time work.  So estimate as if you were doing it full-time, then break up those hours into how much hours you think you'll be able to do in a week (aim on the low side, for those times when need to get caught up on a season of Game of Thrones and you don't get any work done)

Find a partner (or two)

This is a common tip but it really does work.  My own personal spin is to make sure your partner's are as dedicated or preferably more dedicated than you are, because if you're both too lazy no one does any work!

Celebrate the milestones

This is important, because hey, celebrating is awesome!  But is also gives you a sense of accomplishment and that feeling that you are getting closer to the end.  And that's important when you still have a long way to go.


Celebrate! Yahoo!

Don't stop working

The number two reason I kept failing at my projects is that I'd go for long periods without working, which resulted in a loss of interest or a loss of momentum which was hard to gain back.  To remedy this, I commit myself to completing some tasks every two weeks (more on this below).  The key word is commit, not aim.  It's easier to start small to ensure you meet your commitment, then gradually you can commit to more.  But don't ever stop the work cycle.

Have a process

Not a must have, but I find having a process that works helps things get done easier because when things are repeatable and predictable, you settle in to a nice work rhythm that just keeps going and going.  I use a agile-like process with my team of two week iterations.  At the beginning of each iteration, we plan the work items we are going to commit to, and at the end of the iteration we go over what we completed.  Lather rinse and repeat!


I'll go over our process in Part Two.






Wednesday, November 14, 2012

Why I Suck at Finishing Game Projects

There's a great moment for me in Indie Game: The Movie when Jonathan Blow talks about all the unfinished games he tried to make and how demoralizing it was to never be able to finish making games and how he finally decided to set out to and finish one.  I laughed and thought to myself, "hey, that's just like me!"  I'm sure many others out there who watched it had the same reaction.  Let's face it, making a game from start to finish is not an easy thing, and many of us don't see the process all the way through.

Now I've been trying to make a game for a long time now.  I tried making my first back in 2002 and 10 years later, I've still yet to finish a game.  Trying to finish a game has been on my New Year's resolution lists for as long as I can remember.  Just to show you that I'm not kidding, here are a couple of excerpts from those lists:

2005: "finish writing a game (for real this time!)"
2006: "make one of the games from Wario Ware (so that I can write a game I can actually finish)"
2007: "write a game. I've been saying this for years so if I finally end up finishing one, bonus points for me"
2009: "I'm not just trying to write any game, but _the_ game. I started working on this last year and while development stalled for a bit, my goal this year is to finish it."

Needless to say, my track record for keeping this particular resolution isn't that great.

I read a great post recently by Tristan Clark of Launching Pad Games where he described his failures and mistakes in making games which was a great learning experience for me.  So I thought I'd do the same and examine all my past attempts to make games and share my failures so that perhaps you could learn something as well.

In 2002, I and two friends had finished making a small flash game and we were feeling ambitious so we set out to make a strategy game that was part real time, part not.  Think of it as Warcraft with battles that were like Advance Wars.  I had next to no experience with C++ and zero experience with DirectX so I bought Teach Yourself DirectX 7 in 24hours and set to it.  I had a 2d tile engine worked out and some simple pathing and we had quite a few art assets done but it proved it was going to be way more than my poor little coding skills at the time could handle at the time.  I got discouraged and work slowed down and eventually it just faded away.

A unit from the game.  Kind of like a beetle, with guns.  Lots of guns.
A year or two later, I decided to scale down my ambitions and make something really simple and easy so that I could finish it.  So I tried to make a game where you control a snowball cannon mounted on an igloo and the goal was to shoot down advancing snow men.  This was my first 3d game, and I actually got quite far, the cannon worked and you could shoot down snow men (though I didn't know how to do model animation, so I coded what was probably the worst looking falling down "animation" possible).  But as time progressed, I got busy with other things, and I began to neglect working on it.   I neglected the project for so long that it too just faded away.

Fast forward to 2008.  After years of doing nothing, I was motivated once again to make something, this time armed with a several years of programming experience and with XNA which made game development so much easier.  So I decide to make twin stick type shooter.  I had some really great innovative ideas and I had got the ship moving around and shooting.  But then it dawned on me that to do all the levels and enemy movements and all was going to take a lot longer than I had originally estimated so the thought of how long it was going to be scared me into stopping.

So then in 2009, I decided to take the shooter idea and simplify it immensely into a bullet trainer type game, so that I could all the code I had written could still be used.  I had all the levels configurable in xml so that it was easy to add levels, I had enemies and bullet patterns, I even had a main menu this time and a splash screen.  This would be the furthest I would ever get in a game.  But once again, life gets in the way (this usually happens when summer rolls around and I'd rather be out hitting the beach than sitting indoors and coding) and I began to neglect working on it and so it too faded away.

Lots of bullets!


So what can we learn from my failures?  Seems for me there are two recurring themes:

1.  Working on something too ambitious
2.  Neglecting the project

The good news is that the game I am working on now has suffered neither of those two problems so there's hope for me yet.

In the next few posts, I'll go over the strategies I've been using to help me overcome those problems and finally finish making a game.

Wednesday, November 7, 2012

Leave it Better


Hello!  I'm Chris, a software architect by day, indie dev by night.  For my first post, I'd thought I'd share why I do indie dev.

I was inspired to write this post after reading Robert Belluso's blog post for his game Little Bird Game where he lists out reasons to be an indie dev.  I read through his list and found myself sharing many of his reasons (who doesn't want to be their own boss?), but one of the primary reasons that I do indie dev was missing from that list, not surprising as it is a highly personal thing.   This reason is, as corny as it may sound, is that I'd like to do some good in this world.

Now I'm not trying to save the world through gaming like the way Bill and Ted saved the world through music (although that would be awesome, imagine the world united in Sonic and Mario in harmony), but I'd like to make a positive impact, no matter how small that may be.  If a kid plays my game and it makes their day, great.  If another kids plays my game and it makes their day, and goes on to cure cancer, even better.  A the very least I'd like to give back some of what I make and put that money for some good.  I'm lucky enough that in this day, a code monkey like me can accomplish something as an indie dev and so that's what I'd like to do.

So why the need to do some good in this world?  I don't really know the answer to that.  But it goes a little back to something my mom used to tell me as a kid when I would make a mess of things: to leave it better than I found it.  The world is a little bit of a mess sometimes, and I'm going to try to leave the world a little better than I found it, one game at a time. :)