There are less than three weeks left before the Ludum Dare October Challenge ends, and I’m worried.
I’ve been doing weekly iterations on the assumption that I would accomplish about 20 points worth of work each iteration. After the first week, I only did 7 points of work. Not only that, but I added a few points of unforeseen work. Ok, no need to panic yet. I lost some time that first week. I can see how the next week goes. Maybe I’ll do things faster than expected.
Now that Iteration 2 is coming to a close, it looks like the first one: less than half of the work was accomplished, and extra work was found.
Ok, time to panic!
Wait, don’t panic! Part of the benefit of managing the project in an Agile way is to gain some insight into the health of the project. I’m not happy about how slow I’m going, but I am pleased that I can tell that I am going slow so early in the project. Let’s figure out why progress is slower than I’d like it to be.
In three days, I made Stop That Hero! for the Ludum Dare Jam. In two weeks, I’m barely able to draw arbitrary sprites and process input.
Why the difference?
With the Jam version of the game, I hacked it together during the time I didn’t spend eating or sleeping. My current work schedule is less intense. I spend between 4-5 hours a day on game development. Why not more?
Since I work for myself, I have no fixed hours given to me by someone else. In an attempt to give my days some semblance of structure, I’ve decided that certain hours of the day are dedicated to exercise, game development, writing, reading, and organization. I don’t have enough hours in a day to do more game development without taking time from other aspects that I deemed important. Maybe it’s too lax for a newly full-time indie game developer, but I don’t need to force myself into crunch time yet. Besides, any time outside of the scheduled time is mine to do with as I please. If it means that I occasionally have days where I work more hours, all the better. All that said, I don’t believe my work schedule is the culprit here.
As I mentioned in the post on development challenges and concerns, I’m using Test-Driven Development on this new version of the game to ensure that bug fixes and game updates are as easy as possible. If a paying customer finds a bug or if I release a new feature, I want to make sure that new code works and that old code doesn’t break.
Unfortunately, I’m paying up front for it. I’m reasonably confident that the code I’ve written works correctly. I just wish I had more working features!
What I am finding, however, is that the code is easy to use in small pieces. There’s more cohesion and less coupling. Even without explicitly trying, my code is organizing itself in a way that would let me script it more easily. It’s more data-driven, in other words.
But is TDD slowing me down? I have a deadline to sell a game by October 31st. If I can’t get a playable demo of the game completed by next week, this project is in danger of not shipping on time.
On the other hand, October 31st isn’t a hard date for my business. It’s a good target date for a fun challenge and some motivation, but I don’t have sales projections and quarterly revenues depending on it. If I take a few weeks longer to make the game good versus shoveling something out the door, I think I’ll be better for it. As an indie, I have that freedom.
So what’s the solution to my project planning?
The latest issue of Game Developer has a post-mortem about Final Fantasy XIII, and one of the things that went wrong is the development of a “universal engine”. Basically, since Square Enix wanted to create an engine that worked across all the new console hardware for all games in development, they spent a lot of time trying to make sure they accommodated every team’s needs. It wasn’t until they decided to give priority to Final Fantasy XIII over the other games in development that they were able to make good progress.
Similarly, I need to be extra wary of overengineering. With TDD and Agile, I should be implementing only what I need when I need it. You Ain’t Gonna Need It (YAGNI) is the principle I need to follow more closely. I think a big reason for my slowdown is that the things I have coded are a bit more general purpose than I need them to be right now. It will be great to reuse a lot of these features and pieces of code in different games, but it’s not helping THIS game get finished faster.
For instance, I created a basic data-driven menu system as opposed to the relatively hard-coded system I had before with code strewn about here and there in my game. I based the design off of what I read in Game Programming Gems 5
But couldn’t this game have been served by menus that aren’t general purpose? Maybe it wouldn’t be as nice, but it would have been workable and I could have spent more time on the game entities and their interactions. I clearly didn’t learn the lesson from my last post-mortem:
As in previous Ludum Dare compos, I’ve found my biggest problem is deciding where to spend my time and for how long.
I think I should continue to use TDD. It’s helping me design almost naturally-scriptable code, and there are many other benefits. What I need to focus on is finishing the game with the smallest amount of basic features implemented as opposed to spending an inordinate amount of time on any one feature. Otherwise, I’m just creating a game engine for unknown future projects and their unknown requirements.
7 replies on “Agile Alert: Slow Project Progress”
I’m hitting similar sounding walls in my Facebook project for the Oct. 31 challenge.
While I’m all for the TDD / Agile approach, I think you hit upon the fact that it’s much easier to accomplish a focused endpoint with strict constraints vs. ensuring too large of an open compatibility list.
Keep plugging away at it man! Don’t give up!
Thanks, Erik! I think that TDD would be so much easier if a lot of the base technology was more easily testable. Creating wrappers for libSDL is a pain, for instance. B-)
I have a feeling that as I get more and more basic functionality under test, the bigger stuff will come together much more easily and quickly. I now have over 100 unit tests for this project, and the later ones are able to leverage the work that went before them. At the very least, it makes me think more about the design of the code.
One thing that often helps me in those cases is “hard coding the general solution”, and rapid (as in, hourly) refactoring as I write.
For instance, I’ll start off writing a particular routine I know is going to be reused, but I don’t know how yet. Then I’ll separate out the logic into a function/class and feed hard coded data into it. Then I’ll write the second instance of it, hard coding the data but passing into that same routine. Then look at the two sets of hard coded data, find the parallels, and generalize that to an array of records and a loop. Then generalize that to an extensible system where I can arbitrarily feed that data in, possibly from a declarative syntax. Then the 3rd, 4th, and 5th instances are dead simple.
The nice thing about it is that there’s about 5 places where I can potentially stop and say “wait, I’m over-engineering this, never mind” and the code still works and is perfectly functional. If I’ve got good flow going, I can iterate through that process in an hour or two.
Of course, that rapid process doesn’t always fit with strict TDD. Sometimes it’s easier and faster to skunk something together that way, then build tests around it. Othertimes not. It depends on what you’re doing.
It also helps, as you note, to have a solid framework underneath you. Any time you spend wrapping SDL is time you’re not spending doing something useful… but time you spend wrapping SDL is time you WON’T spend wrapping SDL on your next project, if you do it right.
That’s one of the reasons I’m so big on frameworks and open source. A good framework will save you so much time it’s scary, especially if you can structure your workflow to the framework’s strengths. (Eg, I work with Drupal so my natural inclination is to go for nested associative arrays and “hooks”, as that’s what Drupal does really really well.)
I tried writing a game from scratch using TDD in the last year, so I actually had SDL partially wrapped and was able to leverage that work, thankfully. Games From Within had talked about how to deal with a 3rd party library or engine, and I based part of my SDL wrapping work on the Twitter discussion I had with Brett Schuchert, so there’s some precedent for what I’m doing. I just wish I was already doing the interesting part of making my game.
I’ve found it useful to teach myself how to carve out “one hour” stories – things that can go from conception to ready-to-deploy in a single hour. This is similar to the Pomodoro technique, but working in very small iterations (7-10 minutes) to meet very specific objectives, such as “Add the Triple-Shot Power Up.”
If you don’t deliver in one hour, do a quick root cause analysis to figure out why. Add this to a list of qualities that your stories must have in order to be deliverable in a single hour.
This has really helped me ship features. Certainly not the most polished features – I might need to polish the basic feature several times over several hours.
But at least the features get delivered! 🙂
[…] Agile Alert: Slow Project Progress […]
Thanks for the tip, bonder! Right now, I don’t do anything with an eye on how long it takes me, so focusing on the granularity of an hour for a story can’t hurt. When you talk about a list of qualities for stories, do you have any specifics?