Stop That Hero! Development Continues

With the Ludum Dare October Challenge over, I am still working on Stop That Hero!. Even though I had said that the Challenge deadline wasn’t important to me, I still had this desire to meet it, and I think I had a lot of competing thoughts in my head since I never made a firm decision to hit the date or ignore it. On the one hand, it’s mentally freeing to not have a deadline breathing down my neck. On the other hand, I don’t want to take forever working on the game.

Project Estimation

My old project schedule estimates were based on a few key pieces of data. I had a deadline I wanted to meet, which was October 31st. I had the number of estimated story points for the entire project, which came out to 75 points total. Going backwards, if I did 20 points of work each week, I’d hit the date with some time to spare. Putting together a sample iteration, I felt 20 points was reasonable at the time.

In the last month, I found that I added new stories each week, so now the project’s total story points have increased to 89 points. I’ve also found that 20 points per iteration was overly optimistic, and it seems 10 points per iteration might be more doable. With this new data, I decided to estimate the project with a different set of data, and you can see the project comparison below.

The flat lines to the right are basically projecting into the future based on no work being done, so you can ignore them. The blue line indicates the ideal. In the first case, I was expecting to hit 0 points on October 27th. In the new schedule estimates, I’m likely to be finished by December 8th.

What’s nice about these graphs is how much they can show you in an instant. So long as my actual burn rate and the actual backlog stay under or at the blue line, my project is healthy and progressing nicely. If they cross over to the top of the blue line, something has gone wrong. In the first case, you can see that the project was in trouble from the start. I thought that if I could start hitting 20-point iterations that it wouldn’t be that bad, but I couldn’t do it.

With the new estimates, those weak iterations were actually relatively strong, even though the last week was very poor. I only managed 2 points of work then, and I ended up adding 6. I hit a snag in development, but I am recovering from it. Still, you can see that over the life of the project, I’ve been adding to the backlog, and with the previous week, my backlog matches the estimated backlog at this time. It doesn’t give me much room to add more to the backlog, but it isn’t scary yet. If it is mid-November and my backlog is far on the upper-left side of the blue line, however, then I’ll have to question what’s going wrong.

My main concern is that there will be many more stories added to the backlog, especially since I was surprised to learn how much of the basic technology I needed to build in the last month. Also, I worry about not being able to dedicate all of my time to the project that I normally would. Besides the fact that Thanksgiving and Christmas are coming, I’m also moving at the end of the month. I’m more than certain that my project’s schedule will be negatively impacted, but since I am aware of it now, I can take steps to plan for it.

The Game’s Status

What’s implemented so far? I have a menu system which allows me to select what level I want to load. A level loader will populate a level instance with map data from a PNG file. The level uses that map data on initialization to know where to place towers and treasure chests, as well as what type for each, and it also knows where the hero’s initial spawn point is. The level loader also sets the hero’s starting lives to a hard-coded value.

There’s still a lot left to do, but the biggest thing missing is the concept of an entity.

Near the end of the previous month, I ran into trouble when it came to actually implementing the hero. The large number of added points were partly because I took a vague story for implementing an Entity and broke it down into multiple, specific stories related to various aspects of the creation of an Entity. Now instead of trying to create an entity and all of its behaviors at once (and not knowing when I’m finished or how to start), I will be working on rendering an entity, moving an entity according to its speed and direction, and other very specific tasks that are easy to understand and focus on.

Other major components include pathfinding and player actions. The prototype had a poor-but-workable pathfinding solution. While I was happy with it in terms of a weekend project, I knew it wasn’t as good as it could be, and I learned a bit more about A* implementations since then.

While the main activity for the player involves picking a monster type and deciding which tower to create it at, I’d like to investigate other things the player can do to impact the game. In previous posts I’ve mentioned ideas such as banners that all monsters will gravitate towards or clicking on resources at controlled towers in order to collect them. I’ll hold off until I get the fundamental activities implemented, but I think they could change the feel of the game in a positive way.

Once I have the ability to create entities and some way for them to move, fight, and die, the rest of the game will fall into place relatively easily. Victory and defeat conditions depend on the entities actually doing things, animation requires things to animate, and there are details and balance issues that can only be addressed when I have something to detail and balance in the first place.

Of course, I’ll continue to write about the game’s development. B-) Is there any aspect of the game’s development that you’d like for me to explain in the coming weeks? Let me know by leaving a comment!