Category: Game Development

Fighting Procrastination: The Local Maxima Problem describes how procrastination might be a symptom of a project that has hit a standstill and can’t easily move forward without taking a few steps back. The Local Maxima is best illustrated by the example of the robot that wanted to go to the moon:

The Moon is way up there. That tree is higher than the ground. I must climb to the top of the tree to get to the Moon.

So the robot climbs up the tree and sits. Yes, it may be closer to the moon than it was when it was standing on the ground, but it won’t actually reach the moon. To actually reach the moon, it would need to climb down the tree and get inside a space shuttle or rocket ship; however, the robot might not want to go down the tree. After all, if the moon is higher, why would going back down the tree, going lower, help?

Jay Barnson experienced this same problem with his own project. He had created a working prototype, but to make progress he would need to tear out functionality and replace it with something else. I’ve experienced this same problem myself, and the fear he refers to is real. Who wants to work productively only to have to say, “Ok, those results were nice, but now they don’t matter, and I’ll need to do it over”? So procrastination becomes a real problem.

I use Subversion for my projects, and I think that it has helped alleviate this problem quite a bit. I could experiment with code, go in different directions, delete and change functionality, and if I fall into despair with no hope of returning with a better product, I can essentially hit the reset button. My last working build is returned to me in pristine condition, and I can start again, only now I know what not to do. The worst case is that I am back where I started with more knowledge of the problem domain. The best case is that I now have an improved code base.

It is probably easy to think that a project’s progress is simply a linear series of accomplishments. Maybe people who have tons of experience can do it based off of a perfect design document, but I can’t. For instance, I had hardcoded variables to get certain functionality up and running in Oracle’s Eye. Originally those variables helped move the project forward. Otherwise, I would be writing abstractions before I know what abstractions are needed. Trying to write code that works in more than just your specific case is great and all, but it is also a great way to stall what you are specifically trying to do. And in my case, I didn’t even know what I was specifically trying to do, so how could I hope to write code that will work for all cases as well as mine?

Later, as I gained an understanding of what I was doing, I had to tear out the old hardcoded variables and analogous functions to replace them with something better. Essentially, I would need to break my project to make a better project. It isn’t so bad when you can change a small function or change a variable, but if your change impacts three classes and fifteen functions, you might be a bit wary. I was. There was the temptation to think, “But why should I go lower when I need to go higher?” Even with the safety net that Subversion provides, it was scary to dive into my code and change it so fundamentally. Even scarier was not being able to compile it for hours.

I did go through it, however, and came out the other side with great progress on Oracle’s Eye. When I hit the next local maximum, I hope I can remember Barnson’s post.

Yesterday I finished by saying that I was working on adding a configuration loader . I added some stub code so that I would be ready to start working right away.

I realized that while I have coded a text parser before, I never had to worry about getting configuration data out of a file. What would I actually need? Before agonizing too much over it, I thought that it was more than likely that a ready-made, well-tested solution already exists. I spent some time looking through books, notes, and Gamedev.net before finding someone asking the same question I was: isn’t there a an easy to use tool so I don’t have to reinvent this obviously already solved problem?

One suggestion was boost::program_options. I looked into it for a little bit, but another suggestion was to use TinyXML. At first, I thought that using XML was a bit overkill for configuration files. At the same time, it would be ideal for holding the levels, and if I could kill two birds with one stone, all the better. The best part? TinyXML is already in my project! It comes with the Kyra Sprite Engine.

I spent the day reading the tutorial and trying out some test code. It took me only a few moments to get an XML configuration file to load successfully, and a bit more code allowed me to view a few of the elements. I spent the evening learning how the library works, and it seems easy so far. I wish there was some better documentation out for it, though.

My configuration file used to look like:

TimerInterval 80
SpriteSize 64
LeftEdge 64
UpperEdge 64
Ball velocity 5
Player velocity 5

and I wrote it before I wrote more than a single function to help parse it.

Now:

<?xml version=”1.0″ ?>
<!– Configuration for codename: Oracle’s Eye –>
<Config>
<Timerinterval interval = “80”/>
<Spritesize dimension = “64”/>
<Border leftEdge = “64” upperEdge= “64”/>
<Entity>
<Ball velocity = “5” />
<Player velocity = “5” />
</Entity>
</Config>

Unfortunately, I haven’t been able to do more than grab the root element, but I’m still learning how this library works. I’ll hope to be able to finish the configuration loader within the week. Afterwards, it shouldn’t be too much more work to write a level loader with TinyXML as well.

This past Saturday I worked on Oracle’s Eye for the first time in over a month. When I last worked on it in late December, I was trying to update the Frame Rate Independent Movement code I created. It was good enough when I implemented it, but I had a nagging suspicion that I didn’t do it right. I never did check in the changes I had made, and since it has been so long, I had to figure out what I was doing and then do it.

Originally, my code required that the Ball and the Player had movement functions that took an argument. This argument was the delta. For example, the Player could move 5 pixels each frame. 30 frames per second would mean that the Player should move 150 pixels per second. Of course, each frame might not be exactly 1/30th of a second, so I would have to calculate how far to move each frame so that the movement seems smooth. If, for example, a frame takes 1/30th of a second, then the delta multiplier should be 1. If it takes 1/10th of a second, then the multiplier should be 3. A frame that took 1/60th of a second would result in a multiplier of 0.5.

The sad thing is that it wasn’t all that clear how it should work when I originally implemented it. Also, I didn’t understand how to repeat the exact results in case I wanted to script it, nor did I know how it would work if I ever wanted to run a networked game on multiple platforms. After reading through a few more tutorials, I decided to fix it. I based my new code off of Sol’s Tutorials. Running the example game, I noticed that it isn’t terribly smooth itself. It periodically seems that the player’s ship takes small jumps. Perhaps it isn’t the best example to use? I’m open to better implementations if they exist.

This implementation works by setting game updates to specific time intervals. If the Player should move at 5 pixels per frame, then each update will result in a movement of 5 pixels. Multiple updates can take place during each rendered frame, but it is really easy to track the movement for each frame and use the data to accurately reenact it. For instance, I could eventually code replay functionality, which would be a great way to show solutions to the puzzles. I had to change a lot of the code to allow for this change, which shows how fundamental FRIM code is to a game engine. It wasn’t terribly difficult, and it didn’t take me too long.

The best part is that I’m familiar with the project again, which means that I won’t feel apprehension whenever I think to work on it. There were a number of days last month when I felt guilty for not working on the project. I just felt uneasy about the project, and while originally it was probably because I needed to focus on the direction to take it, it eventually was due to the fact that I hadn’t worked on it and had vague thoughts about not understanding it. Rationally, working on it would necessarily bring back familiarity, but it can be tough to pinpoint the fear sometimes.

I decided to focus on coding a configuration loader next. Basically, if I wanted to change the speed at which the Player, the Ball, or the game engine ran, I would have to recompile. Being able to load the configuration dynamically without recompiling or even rerunning the game would do wonders for productivity. I wrote some stub code on Saturday, and I will work on it this week.

Thanks to a comment from a previous post, I decided to follow the advice on GameProducer.net specified in the article 1 hour solution to any problem.

… decide that you won’t check email before you have done that one daily hour. Don’t watch tv, don’t visit those nice discussion forums you usually do, don’t allow yourself to do any nice thing you usually do – until you have took action for at least one hour.

So I did it. I set an alarm for an hour and started planning my next steps with Oracle’s Eye. Before I get to the results of that hour, let me just say that I couldn’t believe how easily distracted I could get. I’d want to check my email to see if someone responded to a message I sent the day before. I wanted to see if a question I asked on the Indie Gamer forums was answered. I even wanted to start a blog post! There were a number of smaller things that I refused to do during that hour as well. Still, I didn’t think that hour would be so difficult. Perhaps with practice it will get easier.

So how did I productively spend that hour? I started by trying to picture what I wanted Oracle’s Eye to be like when it was completed. I then worked backwards by trying to list each “accomplishment” I would need to complete the entire project. Among the subprojects: defining a level structure, creating a level editor, selecting a level, loading a level, playing background music, and playing sound effects. I also wanted to add animation to a number of objects, fix the collision detection, improve the frame-rate independent movement, and create a menu system. I want to be able to build the project for Gnu/Linux and Win32 from a single codebase.

Having all of these specific subprojects is a bit less unwieldy than simply wanting to “complete the game project”.

I then needed to manage what actions will be involved in actually trying to finish a subproject. I picked frame-rate independent movement first. Here is a portion of my next actions list:

Frame-Rate Independent Movement:
    - To get game time to run at regular intervals
        - find/read FRIM references
        - define # of milliseconds in interval
        - verify that the code already in place will run updates at interval
        - change/update code so that it does, if needed

That doesn’t seem so hard, right? Perhaps I’m leaving out some details, but the very next action is good enough to get me going when I do sit down to work on this part of the code. It might be all I need to keep myself going, filling in the gaps as I go. Otherwise, I’ll just run this exercise again to get a better next actions list.

I’m still surprised at how easily distracted I was. I’ll need to work on that issue. I have a sign on top of my monitor that says, “What is the best use of my time right now?” that I apparently ignore now. I do so many things from one moment to the next without consciously thinking about whether it is the best thing I could be doing at that moment. In the future, I think during the hour it should be ok for me to at least write down those things I think to do. I can remember to do them later when it is more appropriate. It won’t really serve as a distraction in that case since I can get it down on paper and get it out of my head. We’ll see.

In any case, forcing myself to work within the hour actually made me more efficient with the time I utilized. When I needed to look up something for my list, I noticed that I was much quicker about searching than I would have been if the hour deadline wasn’t approaching. It would take me less than a minute to get the information I would need. Normally I might take five minutes or more because I would check if there are any comments on my blog or check for interesting new posts on the forums. I had a feeling that each second counted, and for the most part I treated them that way.

The next time you have a project that is sticking around on your list for too long, try to take at least some of it out in one hour. Even if you get somewhat distracted as I did, you might find that the time you do focus on the project will be incredibly productive. For another example, I dedicated an hour to catching up on magazines and got through a few of them before stopping to make dinner. I might catch up on the last few Escapist issues if I dedicate another hour tonight. B-)