Category: Game Development

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-)

My last documented development session was mid December. It’s now about a month later, and I haven’t worked on Oracle’s Eye.

I could list a bunch of reasons why I haven’t been able to work on it. Christmas took up a lot of my time. I was out of town for a week at the end of December, and I don’t have a laptop I could have used to work on the project. I moved during the first week of January, and only now do I feel that my computer area is mostly distraction free.

But those are just excuses. Clearly I didn’t give my project the priority it deserves. Still, I think there was something more to it.

I would decline invitations to events and say, “No, I really need to get some work done.” Then, during the time I should have been working on game development, I would get too easily distracted. Email would get checked way more often than it should have. I’d shuffle through papers on my desk. I would handle other tasks in my list of things to do. Then it would be incredibly late, and I would have to go to sleep to go to my day job in the morning.

It would be another evening wasted. I could argue that I at least got to cross some things off of my list. “The day wasn’t a total loss!” Of course, that’s not a useful justification when I haven’t done what I should have been doing for a month. If I keep this up, December 2006 will show up and I still won’t have a game to show for it.

So why haven’t I been able to even look at my project for so long? I finally identified it as fear. I’ve gotten the project to a point where I don’t have clear specifications and so it is hard to know exactly what to do next. I had the same problem when I started the project. I didn’t know what to do, and so I didn’t do anything. I didn’t want to do anything wrong! I’ve since learned that it is better that I do something rather than nothing. By hacking at my code until I have something useful, I now have a base to work with. Now, when I have to decide on my next task, I can more easily see if it will make the project better or worse.

So I sat down and wrote down all the things that would need to be accomplished in order for Oracle’s Eye to be considered really finished. For each of those accomplishments, I can then write down a plan of action. Afterwards, it should be a simple matter of just following the plan. Once the plan is completed, I can repeat the process with another accomplishment. It won’t always be easy to list out exact actions, of course. After all, I’m still learning about the problem domain. Still, it should get me out of this slump.

While I was writing this post, I realized I was referring to my lack of progress as a slump, which reminded me of Steve Pavlina’s article From Slump to Supercharged. Rereading it, I see that I was able to diagnose the problem correctly.

So let’s dive right into the heart of the problem. Why are you in a slump? You’re in a slump because you’re afraid. And you’re expending a lot of energy avoiding what you fear. It may not even be the subject of your work. It could be something totally unrelated, but it’s something that’s very important to you.

Near the end of the article, he talks about how fear and love are opposites. When you get rid of the fear of a challenge, you replace it with the love of the challenge. I noticed that when I was able to get past the fear of doing the wrong thing and could jump into development on Oracle’s Eye, I was loving it.

This week, I’m tracking my development time very closely. I’ve joined The Thousander Club at the beginning of January, but I haven’t done anything to show for it yet. Essentially that means that I am almost 85 hours behind for 1,000 hours of development time this year. I intend to catch up, which means that I’ll need to work on a plan to do so.

In the meantime, I just want to get out of my slump and start loving my game development again.