Category: Game Development

As I noted in my last post on Oracle’s Eye development, I wanted to transfer functionality from PlayState to the GameWorld class.

Short story: I did it. Next step is to try to make the Player object obey the WallTile boundaries.

Long story: There were multiple times when I felt like I was spinning my wheels. Maybe it was just that I haven’t been exercising my brain by designing as much as I should, but I was starting to despair that I wouldn’t be able to figure out what to do. After all, I already had a huge chunk of temporary code to see how the program would work, and here I was trying to completely change the design of it. Where do I begin? Will I ruin what I have and waste time before I figure it out?

After some persistence, I created a number of new classes, modified a few existing ones, and I molded the GameWorld class into exactly what I needed. It just all came together. For hours I was struggling with thinking about how to handle the changes I needed. At one point I even considered reducing the scope of the project so that the stick figure just had to reach an exit in a maze since it seemed simpler.

When I started this last development session, I found it difficult to imagine that I would be able to implement the complete game. Even after a few hours of “work” (in which I might have spent a big portion of it not actually concentrating on the task at hand since it was easier), I still had doubts.

Then everything just worked out, and now I can see that my original plans should be possible. Next time, even if I feel overwhelmed with my project, I’ll just have to remember that going the extra mile and being persistent will do more for me than worrying or massive redesigns would do.

I don’t have anything really newsworthy to share since last time, but I thought I should update the blog on my Oracle’s Eye progress.

I had a stick figure that would glide around, and three others that would move at different speeds and in different directions relative to the one you control. The Player objects were hardcoded into the PlayState as global variables, and I named the variables gTemp_player to remind myself that these are meant to be temporary.

I decided that I needed to create a GameWorld class to handle all of the entities and their interactions. I set out to design the class, and I found that it would have to own the Room and the Player. It makes it very easy to have a GameWorld class that determines how they interact because otherwise the PlayState would know too much and it would add way too much complexity. The cool thing is that keypresses can be handled by delegating to the GameWorld object. For instance, if I press the left arrow key, PlayState will simply tell the GameWorld to moveLeft(). The GameWorld can decide what it means for it to move to the left, but it will likely just move the Player object in that direction.

Great. Now I just need a Room class…and a Room class needs a Tile class. I already know that I want different types of tiles, so I created FloorTile and WallTile classes that derive from a base Tile class.

In the end, I created all of these classes, but there wasn’t enough time in the development session to actually get them all to work together. I’m still hardcoding PlayState, which is fine for now. Since I can’t just create a Room with Tiles easily and I want to see the tile sprites, I just used a Player object that won’t move and used the tile sprites as the sprite for the image.

It actually didn’t look too bad:

Technically all of the extra code didn’t actually do much to change what someone would see when you run the program, but I think the foundation is ready for me to make significant progress. Tonight is another scheduled night to work on it, so it will still be fresh in my mind.

My next step will be to transfer functionality from PlayState to the GameWorld class. I will then attempt to force the Player to walk only within the boundaries of a Room, probably by just having GameWorld check if Player’s position would intersect with WallTiles. FloorTiles will be in the background, and Kyra makes it easy to check only the sprites I need.

In response to my post on Creative Writing Prompts and my search for a similar tool for programmers, scott posted a link to Code Kata at Dave Thomas’ (The Pragmatic Programmer) blog, PragDave.

There are a few posts describing Code Kata, but one of them mentions the Dreyfus model for skills acquisition.

The Dreyfus model suggests that there are five stages in the acquisition of mastery. We start at novice: unsure and with no experience. We don’t particularly want to know the “why,” we just want to be shown what to do. We need to know the rules, because we just want to achieve some goal.

While Code Kata is for learning how to program in general, I think the skills acquisition description was very insightful and can apply to learning game development. I think I had posted previously about how beginners should start by making simple games because doing so will teach them a lot about what it takes to make more complex games later. Of course, I was mainly talking about myself as the beginner game developer.

I already knew that I needed more game development experience, but I need to realize that it is not just OK to make a clone for my first game or four. It might be necessary. As PragDave mentions, it is like learning karate. If you’re a beginner game developer, you should be able to emulate existing game developers before you start trying to work on your own plans. You can’t start by being the Master. You have to start as a beginner by emulating the Master.

People on GameDev.net periodically find that they need to inform idealistic newbies that they won’t be able to make the best MMO game ever. “Try something simpler, like a Tetris clone” or “You need to learn how to program” or “/me slaps you with a trout” might be common responses. The newbie is a student of game development who thinks he/she can skip the beginner and intermediate phases and start making games like a master. The newbie needs to learn how development works first. He/she needs to learn the rules. It’s learning the “How” before the “Why”.

I have a number of ideas that I think are somewhat unique, and I would love to make games out of those ideas. At the same time, I know that if I try to make those games today they won’t turn out nearly as good as I would want. I can, however, make simple clones, and I’ve already made a Pac-man clone in QBasic years before, complete with bouncing cherries and multiple levels, so I know I can do it. Perhaps a Space Invaders or Asteroids clone wouldn’t be such a bad idea after all. For a long time I thought that making clones of existing classics would be wrong in some way. I could do better and make something unique for my first few projects, right? I mean, does the world need another Pong clone?

Well, perhaps it does.

I’ll still try to finish Oracle’s Eye first since I think that finishing a game project is a good habit to gain. My next projects will likely be some simple clones which will be easier to complete in a month.

Paul Taylor wrote about working on an indie game called Determinance, and he is exactly the kind of musician I would want to have working on any of my own games:

Each track, even the menu music and closing theme, is based around a core melody or chorus. This is something I believe in passionately – if you can’t whistle the tune of a song then it’s 99.9% likely to be worthless.

Wouldn’t you want a person who is passionate about what he does making your games?

Last time I mentioned that I had made a stick figure to move around. I implemented four degrees of movement for it, but I still don’t have a timer to make it move at a sane rate. Since this project is late anyway, I figured I might as well learn about implementing frame rate independent movement.

I actually looked at my GiD entry and found that it was handling the timer code badly. Basically, the game would update every time an SDL Event occurred. Normally the event would just be the timer callback and would run fairly regularly. But if you pressed a key or released a key, an extra update and draw would occur. Now, I programmed it to allow you to hold the key down to move so it only speeds up when changing directions and may not be as noticeable; however, if you press keys multiple times, it becomes very obvious. For my first GiD, I suppose it isn’t that big of a deal.

For Oracle’s Eye, I decided to create frame rate independence. It basically means that the rendering happens independent of the game world updates. The game can go from 30 frames per second to 100 frames per second to 15 frames per second, but the game world will still update once every 10 milliseconds or whatever I want to set it to. It should result in smoother animation and movement.

When I started this project I didn’t think that I would be working on such an “advanced” topic. It sounded a bit complex and beyond my abilities. Well, screw that thinking. It can’t be THAT far beyond what I can currently do. In fact, when I think about it, making games in general is still a challenge I haven’t decisively overcome yet, so I’m charging forth. Screw you, Pessimism!

Luckily someone just posted about this topic on the SDL mailing list and so now I have a link: Game Physics: Fix Your Timestep!. Reading it gave me some idea about what needs to be done, but variable names like t and dt and functons that come out of nowhere make it hard to follow. I was able to find another article on gamedev.net called Achieiving Frame Rate Independent Game Movement. It is a bit shorter, more to the point, and easier to follow.

Problem # 1: It is a good thing that I haven’t gotten too far with my game project because implementing this feature is going to require a redesign. I originally envisioned moving my characters about by telling them to move so many pixels directly. For example,

player->moveX( moveSpeed );

should move the player sprite to the right by moveSpeed distance. If moveSpeed is 5, then the sprite will move to the right five pixels.

It would have been fine, but with FRI movement, I would need to do something different. As I understand it, I would have to know where the sprite started and where it will end up. Then I have to calculate at any given moment where it is along that path. Whereas before I would have moved the player sprite an arbitrary number of pixels, now I will need to determine how many pixels it moves each second then calculate how far to move it per frame. If a player should move 60 pixels per second, then the total movement of the sprite in all frames in that second should add up to 60 pixels. The trick is figuring out the movement each frame.

Problem #2: FRI movement works much better in 3D than in 2D. In 3D, the actual 3D model is just math. You can interpolate the animation of the model, and it will look smooth no matter how slow or fast you run it. I’m using sprites, and sprites have only as many frames of animation as I created. Let’s say I have three frames of animation for a walking sprite. Normally, I would just update every so often and make the animation step forward each time, but with FRI movement, how do I handle the partial movements AND animate at a normal pace? I can’t update each movement because then it looks like the player sprite is running way too fast. Do I have to figure out how far it should move before each frame gets updated? Does it even make sense to have FRI movement in a 2D game?

Starting this, I felt a bit overwhelmed. That’s a lot of things to take in, and all I wanted to do with Oracle’s Eye is make a simple game. Still, I forged ahead. I figured it is better to learn about it sooner rather than later.

I found a few more articles: Main Loop with Fixed Time Steps on Flipcode and Frame Rate Independent Movement on Gamedev.net. I also found a few threads on gamedev.net that discuss “time based movement”.

It actually doesn’t seem so bad now, at least for Problem #1. In fact, I don’t have to change my existing code all that much. I changed the moveX() and moveY() functions to take floats as arguments instead of ints. I added some timer variables: one for the delta, one for the current time, and one for the last time.

In my PlayState::update() function:

gTemp_currentTime = SDL_GetTicks();
gTemp_deltaTime = (gTemp_currentTime - gTemp_lastTime) / 50.0f;
gTemp_lastTime = gTemp_currentTime;

Then for each of the directions, I just change the code from:

gTemp_player->moveX( -gTemp_speed );

to

gTemp_player->moveX( -gTemp_speed * gTemp_deltaTime );

The 50.0f is fairly arbitrary. The code I got it from used 1000.0f to convert from milliseconds to seconds, but I found that the delta almost never became anything greater than 0, which meant that nothing moved. Using 50.0f seems to be fairly fast and smooth on my system. Of course, it depended on gTemp_speed which is in pixels per second. If I set it to 50, it ran quickly. Setting it to 25 slowed it down quite a bit, but it was also jerky, and setting it to 100 made it too fast.

It also didn’t take me too long to implement it, so I got suspicious that I did something wrong. After all, it shouldn’t matter how fast the sprite is moving. I will likely have sprites moving at different speeds, so what gives?

I found yet another tutorial, and this one actually made use of SDL. It turns out that I don’t do much differently. I ended up having to add SDL_Delay( 10) to the draw() function to get it to slow down enough, but I think that is a bad kludge. I believe that the reason it won’t move the sprites between each frame is because there isn’t enough to do between frames. The time between frames looks like 0.0 and so nothing happens. The delay allows changes to happen, but there is still the ugly jerkiness every once in awhile.

The next day, I tried again. I changed it so that it will constantly loop until deltaTime is something other than 0. It worked and looked great, but I found out that I forgot to remove the SDL_Delay() line. When I removed it, it ran incredibly slowly again.

So I changed the loop. I basically checked to see if the start and end times were 1/30th of a second apart since I wanted the game to update game logic at 30 frames a second. If the difference was less than that time, I delayed. It seems to work out well. 1/60th of a second looks even nicer, but I’ll have to do more testing to verify.

Unfortunately the use of floats/doubles means that when movement gets converted to ints for Kyra’s sprite movement the precision gets lopped off. I think this loss of precision is the reason why some of the movement might look a bit jerky. Of course, Problem #2 might be a tougher issue, but I’ll have to tackle both of them another time.

I am fairly pleased with what I have done in a few hours over the course of a couple of days. To think that I originally believed that I wasn’t up to the task and would have skipped it. I win.