Sunday, January 15, 2012

Project Aeon, and How I spent my Holiday Break

It's been a month since my last blog post, so today I'm going to write about what I've been doing since then. Even though I've been on break from classes for the past month, I've been incredibly busy working on a Flash game called Aeon. I first introduced this project in my History of the Interguild series, and given that this is a blog about game development, it's odd that I haven't written more about the game that I'm currently developing.

Most of this game's production has been incredibly slow, inefficient, and just plain horrible. But recently, I managed to turn this project around while making more progress in just one month than I would have made in a full year otherwise. In this post, I'll explain the major challenges that have held this game back for so long and how I drastically improved my time management and productivity skills.

A Brief History of Aeon's Development

The idea for this game was first conceived on the Interguild forums in the beginning of 2008, and while there were a lot of people who wanted to see this game get made, I was the only one who made the commitment to actually make it. The plan was for me to program the game, while other Interguild members contributed through art, music, and eventually, levels.

I didn't begin learning how to develop in Flash until the summer of 2008. The game's progress was severely limited by my lack of experience with both Flash and programming in general. Furthermore, I spent most of my extra time during 2008 working on the Interguild's big move to

In 2009, development went a little smoother, but I didn't make much progress until the summer as I spent the first quarter of the year adding features to the new Interguild website. I released the first Aeon demo on October 23rd, 2009. It was very primitive, but players could make their own levels (using only terrain and a movable character) while editing some basic properties of how these objects behaved.

The second Aeon demo was released on April 1st, 2010. While this demo featured the addition of a few extra objects, including treasure, spikes, platforms, and doors, it also contained an April Fools Day prank. It was the first demo to include an entirely XML-based interfaced for customizing levels. Unlike the nice GUI from the previous demo, this allowed players to attach their customization settings to their level codes.

Debug Menu from Aeon Demo 1
Debug Menu from Aeon Demo 2
The third Aeon demo was released on July 30th, 2010, just in time for the final round of the Interguild Olympics. This demo didn't add much, aside from a few more customization options and a throwaway level editor prototype. After this demo, the game's remarkably slow development pace seemed to have come to a full stop.

DDAeon by canadianstickdeath
But a few days ago, on January 11th, 2012, I released the fourth Aeon demo. The game had been almost completely rewritten, featuring fast loading times, polished menus, accurate collision detection, and an ambitious and versatile customization system called the Styles system. Even though it's been over a year since the previous demo, most of these changes had been implemented within the previous four weeks.

Getting Serious

This game had a lot of problems holding it back, but the biggest problem was that I simply wasn't taking this project seriously enough. This was a humbling realization to have, because the fact that I held on to this project during all these years, long past the point where most people would've lost interest, led me to believe that I was already taking this game very seriously. But the incredibly slow pace with which this game was being developed suggests that I was approaching this difficult project with the naive mentality that if I just kept working on the game long enough, it would eventually get finished.

The breaking point came during last summer. I had just finished my first year of college studying computer science, and I was very excited to apply my new programming skills to Aeon. But by the end of the summer, all I had gotten done was a new menu system. So what happened? I tend to procrastinate by finding other things to work on, so while I did get a lot of work done that summer, little of it was actually on Aeon.

When the summer ended I felt ashamed and incompetent, and that's when I decided to stop messing around and finish this game already. Making a game is incredibly hard, especially if you're a student, and there are a million obstacles preventing you from finishing your game. But once I became serious about getting it done, I started seeing these obstacles as problems that needed to be solved.

Problem #1: Time Management

My main motivation with pursuing this skill was because I wanted to find time during the semester to work on Aeon, as opposed to having to wait until the breaks between semesters. I've been trying to learn this skill ever since I got into college, but I must admit that those early efforts were a little lazy.

The first step to managing your time is to start tracking how you spend your time. You can't change your habits in the right direction if you don't even have enough data to make a clear diagnosis. In October, I started maintaining a "time log", which at first, only tracked the start and end times of specific tasks. Even though I would often forget to jot down the end time of the current task, maintaining the log was a huge eye-opener. Small distractions such as what felt like a 20-minute break on the Interguild ended up lasting up to two hours.

A sample of my time log from those days.
Problem #2: Productivity

In mid-November I changed the way I recorded my time in order to finally start taking planned breaks as I worked. Retrospectively, the idea of not taking breaks sounds just plain stupid. I feel as though I've become at least 100% more productive simply by adding breaks to my schedule, whereas before I would try to work continuously until I finished something. I started by taking 10-minute breaks every hour, and to remind myself to take these breaks, I downloaded a free timer program called TimeLeft. Since then, I've gradually increased my work segments from 60 minutes to 90 minutes, with 15-minute breaks.

Simply having that timer silently ticking away at the corner of my screen was a huge productivity booster. This made me feel like I was in "work mode" and that I had X amount of time until "rest mode". Having a limited amount of time for work forced me to stay focused so that I could make the most of it. Furthermore, my time log became much more accurate as the timer reminded me to update the log at least every 30 minutes. This allowed me to evaluate and respond to productivity problems as they came up, rather than waiting for the end of the day when all I could do was kick myself for not getting enough done.

A more recent sample from my time log, including breaks.
My time log also served as a very useful tool for evaluating how productive each day was as a whole, which allowed me to set a benchmark for how much work to get done per day. For instance, during the holiday break, I pushed myself to work on Aeon for at least four hours per day, not counting breaks or interruptions.

Problem #3: Focus

When I was working on Aeon, it should have been a real challenge to stay focused, especially considering that I was working at home and we had guests staying over for the holidays. But I managed to defend myself pretty well from distractions by working in our dining room (which is not too secluded from everyone else) and by having the courage to tell people, "Go away. I'm working."

This is NOT what game development looks like, by the way.
The fact that I took frequent breaks gave me the certain amount of credibility needed to not come off as a jerk when I told people to leave me alone, because everyone knew that I wasn't always working. It's amazing how working hard on a tough project does not have to intrude much into spending time with family and friends.

Problem #4: Motivation

One of the biggest challenges that I had always faced when working on Aeon was the fact that I was always working alone. It's hard to stay motivated when working alone because there's no one to hold you accountable for when you slack off, not to mention the fact that working alone is just plain boring. So last September, I teamed up with my club's treasurer, Rory, and it was refreshing to have someone else on the team. I was able to use our regular project meetings as a big source of motivation for getting tons of design work done during the semester. These designs were what allowed me to write so much code so quickly during the holiday break.

When in doubt, make UML diagrams.
When the break started, I got in the habit of sending Rory daily progress reports via email, summarizing how many hours I've worked, which features I've implemented, and what I planned to get done the next day. After a long day of work, writing these reports gave me an incredible sense of progress by making me to look back at everything I had accomplished that day. This unique perspective made all of my hard work feel more fulfilling, and it really helped me get excited about all of the progress that I was going to make the next day. It's always easier to get back to work, when you can easily remember (or look up) what problems you were planning to solve next.

Unfortunately, finding reliable teammates is a challenge of its own. The biggest contributions that Rory made were putting the game up on github and writing a simple LinkedList class. He felt really bad about how unproductive he turned out to be, and he eventually pulled out of the project because he felt like he was holding me back. Even though I planned to continue working at the same usual pace, I was less motivated to write my progress reports, and I noticed my level of productivity drop to about half that of the previous week (but that's probably because both Christmas and New Years Eve landed in the same week). If I hadn't been keeping a time log, it's likely that I wouldn't have even noticed this drop in productivity, because that week felt just as hectic as all the others.

In an attempt to restore my motivation, I decided to post my daily progress reports on the Interguild forums, despite the fact that most users would have no idea what I was talking about. But thanks to the great positive feedback I was getting from some of the members, I was back working at full steam in no time.

Crunch Time: the day before the big demo release.
Problem #5: The New Semester

Even though I just released Aeon Demo 4, the real work is just beginning. Remember that the whole reason why I was interested in time management was so that I could continue working on this game throughout the semester. If the holiday break was basic training, then the semester will be the real test of whether or not I can manage my time effectively.

Rather than finishing my assignments just in time for the due date, my goal this semester is to get in the habit of finishing everything very early. I probably won't be able to write daily progress reports, but perhaps I could make my time logs detailed enough to replace them. I also intend to keep track of how many hours of homework I do everyday, and eventually I'll develop a daily quota to meet, like I did with Aeon. This way, if I do a particularly small amount of homework one day, rather than taking that as an excuse to slack off, I should be motivated enough to get to work on future assignments or get some reading and studying done.

Many of these plans were inspired by Cal Newport's blog.
For Lack of a Better Ending

By the way, did you notice that I stopped bolding random phrases in my posts? Those were mainly there to assist skimmers in finding what might be interesting about the article, but I realized that my writing style really doesn't go well with that kind of technique. It tended to give off a low-quality vibe, almost as if I'm not expecting my readers to care much about what I'm saying. Of course, there will be at least some readers (*cough*shos) who might complain about this change.

1 comment:

  1. Even if Shos complains, I like the change. <_<