June: Task Management

May was pretty awesome. I managed to stay committed to working on projects. I’ve noticed that the best days are when I get up early (around 7 preferably), and manage to be at my desk working by the time I’m fully awake =). When I can pull that, I’m able to keep focused and finish the day early, leaving free time to spend on other things.

Even if it worked well, it didn’t go perfectly. I kept up the habit of working continuously, but I didn’t keep a great sense of direction. Last semester at school, I started the habit of keeping a todo list, and mapping out when I would do what at the beginning of each week. I had so many different things to work on that I needed to do this to reduce pressure and get everything done.

This summer, though, I’m usually focusing on one project at a time, so I unconsciously dropped the habit. As a result, even though I’m productive a day at a time, I often don’t have a good sense of where I’ll be at the end of the week, and small tasks that aren’t part of my main project (like cleaning up -_-) often get put off too long.

In June I’m going to continue what I was doing in May, working 6 hours a day five times a week, but I’ll also work on longer-term task management. One way I’ll do this is to keep a scheduled todo list which I map out at the beginning of each week. The other way is something I’ve been experimenting with recently.

For whatever project I’m working on, I’ll put each task on a single index card, along with any notes I decide to write about it. I can lay these out on my desk, easily sort them by priority, and keep whichever one I’m working on in front of me so that I can’t forget what I’m supposed to be doing =). If I find myself working on something with no card, then it’s probably not important, and if it is then I can make a card for it on the spot. I found this to be a really satisfying way to manage tasks, especially when you can take a card and write DONE in big letters, while putting it into your success pile ^_^. It also helps to maintain focus since you know exactly what you should be doing at all times.

Posted on 2009-06-08 at 20:52. Leave a comment -->

May: Working without a Job

For the last four years I took full-time summer jobs, giving me four summers of servitude. Servitude that was somewhat enjoyable, and taught me a lot, but always servitude. This summer I’m going to do things differently. Instead of finding a job, I’m going to spend the time working on what I really want to.

Specifically, I’ll be doing indie game development. Why? Because it’s what I’m passionate about. I’m going to start out with short prototyping projects, probably about one week each, to try out different ideas. This summer I should have fun, come up with good ideas, and learn lots, improving my technical and creative skills.

The downsides to not working as an employee are that there’s no structured work environment, no outside pressure to excel, and no salary. Nevertheless I think it’s going to be a net win, since 100% of the effort I put in goes to stuff of my choice, the effort I put in directly benefits myself instead of some big corporation, and I can make the work fun!

The biggest worry I have is that since there’s no outside pressure, motivation will fade to laziness. To avoid this it’s very important to keep the work fun and cultivate my motivation.

My monthly goal for May will be to put a substantial effort into the projects I’m working on. Specifically, I’ll put in six hours of work, five times a week. This is similar to January’s goal of timeboxing 3 hours of time every day, but this time I’m going to aim to devote the entire 6 hours in a given day to a single project, which should let me focus and really get in the zone. I’ll have the option of changing what I’m working on from day to day, so I’ll still have the freedom to mix things up if I get worn out on something. This six hours is a minimum, not a fixed amount, so some days I’ll likely put in more. It’s a bit less than a full-time job, but I plan to use that extra space to allow my schedule some flexibility, not to slack off.

Posted on 2009-05-03 at 12:55. 1 comment -->

April Plans

April was Fail. Actually, scratch that, as much as it sucked I got a hell of a lot done. The bummer is that with a sanity-crushing load of school projects followed immediately by competing in Ludum Dare, I haven’t had any time to think about April’s monthly goal.

I have big ideas for May and the rest of the summer, so I need to start building momentum right now. To start off, I’m going to spend the rest of April getting back to waking up early. The near-sleepless CS Games and end-of-semester rush knocked me out of any regular schedule I’d managed to build up, so my first goal is to straighten it out.

Posted on 2009-04-24 at 18:38. Leave a comment -->

Extinguish, a 48-hour game

Last weekend I wrote a small game called “Extinguish” for the Ludum Dare 48-hour game development competition. You play on the side of advancing Evil, which is trying to engulf everything. The invadees aren’t so happy though, they’ve set up barriers which Evil can’t cross! Your job is to destroy these defences so that the conquest can continue.

Download it for:

The game was written for Ludum Dare, a game development competition. The idea is to write a complete (but small) game, mostly from scratch, over a 48-hour period. It’s free to participate, there are no prizes (except for your game!), and all of the post-competition judging is done by the competitors. Our theme was “advancing wall of doom,” which I think I kept to pretty well. I’m happier with Extinguish than I was with either of my previous two Ludum Dare games, but there’s still definitely room for improvement.

With my previous Ludum Dare games, the main problem was that I was driving my game design with technical ideas. This was especially true with Mininode, where I had awesome (or so I thought) ideas about how I could hook different components together into graphs and have them interact in strange ways. The problem was that once I’d implemented the technical side, I ended up having no good ideas for interesting gameplay. Needless to say, it didn’t turn out very fun.

This time, I started thinking about the actual gameplay from the beginning. With a lot of work I was eventually able to turn it into a game. This time, I had a different weakness: direction. Although I had a general idea of where I was going with the development, I didn’t take the time to break the task into milestones. The most important part of being productive is knowing what you’re doing at any moment, and what you’ll be doing next. You need to have concrete goals, or mini-deadlines. I didn’t know where I was aiming to be by the end of Saturday, so I ended up not doing as much as I could have. This made Sunday all the more frantic, and although I finished the game, I would have liked to have time to add more features, such as sound and better graphics.

I learnt a lot this weekend, and it will help me to do a better job during the next competition. If you can code and want to compete in either the next mini-competition (in May) or the next main one (in August), check out the Ludum Dare website or check out the IRC channel.

Finally, a timelapse of the development of Extinguish!

Posted on 2009-04-21 at 23:34. Leave a comment -->

Cel Damage: Breaking Survival

Cel Damage is a crazy cartoon car-combat game, and one of my favourite GameCube games, but it got terrible reviews and generally didn’t do very well. In my opinion there are two reasons for this. The first is the difficulty; it’s a pretty hard game, where even on the easiest mode it’s tricky to win. The other thing, though, is that you die a lot. Like, dozens of times in a few minutes.

A typical deathmatch game has you living for at least maybe 30 seconds on average (longer in many, like Counter-Strike). In Cel Damage, you’re lucky to live longer than 10, and it’s not uncommon to die while spawning! Dying can be especially frustrating for a few reasons:

  • many of the weapons in the game are one-hit-kills
  • some of the weapons can kill you from halfway across the map
  • whether or not someone succeeds in killing you is dependent on how good the other player is, not on how good you are at defending

Basically, you can die through no fault of your own, often with no warning!

The trick to enjoying Cel Damage is realizing that it’s normal to die! What matters is who else you’re able to take out before it happens. In Cel Damage, death is not something you can reliably avoid, and that doesn’t matter.

The issue is that most games are based on survival, where dying either gives a substantial penalty or means game over. Neither of these are the case in Cel Damage, but the attitude of dying is bad is carried over when you start to play it. The game’s failure is not in how liberally it deals out death, but in not communicating to the player that dying is normal. When you’re breaking an established game design rule, you have to make it clear, otherwise the player will assume that either the game is broken or they’re doing something wrong.

Posted on 2009-03-11 at 00:32. 3 comments -->