Category: Game Development

It’s the start of the fourth month of my one month project. B-) On the one hand, I’m getting impatient. On the other hand, I am learning quite a bit, both about game development in general and about scheduling specifically.

I had a few items I wanted to tackle for the next few sessions. When I last left off on Oracle’s Eye, I had a Ball spinning around in a Room, and the Player could walk around. I had also updated the Kyra Sprite Engine. The new version doesn’t use a certain class anymore when it comes to hit detection, but it mimicked the std::vector class and my code didn’t do too much with it. It was easy to just change the type of the object. I had collision detection with a change on one line of code. Pretty sweet.

Now on to the new stuff! I eventually want the Player to be able to kick the Ball around the Room. Of course, if the Ball can’t move in the first place, I’m stuck. I already have the code available to move the Player, and I already used the same code in the Ball class. All that was left to do was provide a way for the game to tell the Ball to move.

I cheated. I just wanted it to move around, and so I used the same function that moves the Player. In GameWorld, I have moveX() and moveY() functions which normally move the Player if he isn’t hitting a WallTile. I simply did a similar test. Now, the Ball isn’t in the same subtree as the Player and WallTiles. With the Player, I can do the test with the following function:

bool CheckSiblingCollision (KrImNode *checkThis, std::vector < KrImage * > *outputArray, int window=0)

The Player and the WallTiles are siblings, and so if this function returns true, then I shouldn’t move the Player. It works for what I need so far, although I can foresee some difficulties if I keep them on the same subtree. The Ball is on a different subtree, and so it needs to use this function:

bool CheckChildCollision (KrImNode *checkThis, KrImNode *parent, std::vector< KrImage * > *outputArray, int window=0)

I basically pass the pointer of the Ball’s KrSprite and the root node of the subtree that the Walls are in. I actually uncovered a bug in my program here. Since I didn’t want to keep pointers everywhere, I named the parent KrImNode when I originally created it. I can then search for it by the constant string I supplied it. In this case, I used “foreground”. What was weird was that the Ball wasn’t able to detect the Walls and would pass right through them. It turned out that the code that creates the node was being run twice, meaning that the node was being added to the Kyra Tree twice, and so when I named it a second time, the first one was basically lost. Unfortunately it already had the information for the WallTiles and the Player, and so the Ball was looking at the wrong node whenever I searched by the name. It actually didn’t take me too long to find the source of the problem, and the fix was even easier. In the end, I had a Ball that not only moved but also obeyed the Wall boundaries.

Even cooler was that it would not run through the Player, but the Player can still go through it. I’ll eventually have to write code that makes the Player and the Ball respect each other’s positions. For now, I will need to address a different problem.

The Ball starts out in the center of the Room, near the top Wall. My animation images aren’t that high quality, and the Ball seems to jump slightly at certain frames. Apparently it is hitting the Wall as it moves, which means that every so many frames, it will actually stop moving to the side. It gives the impression that the Ball is grinding along the Wall. I think I would like to make my Player and Ball images smaller anyway. Right now they fill up the entire Floor tile, and I think they should be able to maneuver better if they had a bit more leeway when walking around.

It’s not bad for a few hours of work. Still, I think I’ll schedule an entire Saturday this month to working on this project. Having a day dedicated to development with (hopefully!) no distractions should provide a big boost in productivity.

I spent the evening working on the project, and I was going to try to get the Ball to move in four directions. I thought that I should probably start by laying the groundwork and having Player and Ball inherit from a class called Entity.

My thinking was that Entity would control the movement of the object in question. It would set the position, move in a certain direction, and also control the KrSprite pointer. Then Player and Ball could inherit from Entity and have all of the functionality available, and I would be able to handle the code in one place instead of two or three.

My gosh, what a mess!

When I finally decided to give up and revert the changes, I realized that I might not want to inherit Entity. Perhaps it would be better if the Player and the Ball each own an Entity object. After all, each owns the KrSprite pointer currently, and essentially Entity acts as a wrapper. It will still require some reworking, but it might be easier than what I was trying to do.

Entity had pure virtual functions, and after Player inherited it and defined the functions, I was getting linking errors that I couldn’t figure out. The messages insisted that there were undefined references to the Kyra Sprite Engine’s functions, and that made no sense to me because they were defined nicely before I did anything to the code. I kept at it for some time, and by the time I gave up I have to admit that I still don’t understand what was wrong. Of course, I don’t exactly have the greatest grasp of the C++ language, and so I more than likely wasn’t using pure virtual functions correctly. I decided that I should think about it.

Reverting it was fairly easy with Subversion, so I am very thankful that I’m using this tool. I feel bad that I haven’t made any progress on the code, but I’m chalking it up to experience.

Never write code when you have no idea what you’re doing with it. I started to hack away and tried to do something without knowing how I was going to handle it beforehand. Now I’m backing away from the code and trying to write down some design ideas before progressing. If I take the functionality from Ball and Player and put it into its own class, I already know that aggregation is probably going to be better than inheritance. Of course, I should really try to write it down and figure out if that is the case before making the same mistake the other way. I don’t want to assume that if I was wrong with one choice that another choice is automatically correct. After all, Ball and Player are both going to be classes that provide the functionality to move the objects around. Why shouldn’t they inherit the implementation to do so?

I’ve already found one resource that suggests composition is the way to go: Game Object Structure: Inheritance vs. Aggregation.

In any case, I didn’t fail. I just found a way that doesn’t work. Or at the very least I found that there is a limit to the “just get something, anything, working” method of game development. B-\

While I didn’t work on Oracle’s Eye as much as I would have liked these past two weeks, I did make some progress. I created a Ball class, drew up a Ball sprite with eight frames of animation, and got it into the game.

I had to change some of the design and the code. I found that the Player couldn’t walk around the small Room with the Ball in the way, and it is partly because of the way I did collision detection.

To make the Player respect the Wall boundaries, I coded a simple test: if the Player’s movement would cause it to collide with something on the same level as it, then don’t move. It worked great when I only had Floor tiles on a lower level and Wall tiles at the same level as the Player. Now that there is a new object to interact with the Player, I needed to change the code. I don’t feel discouraged at all since the purpose of my original code was to have something and anything working. I’m supposed to change it as the project evolves. Months ago, my much more novice self would probably have been discouraged to think about the need to change code that I already wrote. That’s experience for you. B-)

For the time being, I simply put the Ball on a different, third level. It simply spins in place, but the Player can walk past it now. Well, actually, it walks over it. It’s not an ideal “solution” but it will do for now.

But the point of this last session was to get a Ball into the game. I’ve accomplished it, although it isn’t too functional. What it did do is bring a number of issues to light:

• The Ball spins nicely, but only in one direction. I’ll need it to move in four directions when I finally get it to move around. I can step backwards through the animation to account for rolling right and left, but I just realized that I’ll also have to make it move up and down. I’ll need more sprite images.
• I’ll need to think about how I am going to let the game know that the Player has touched the Ball or that the Ball hit a Wall. I am thinking that I will need to add a significant chunk of code to handle Game Events. Not trivial at all.
• I need to also think about how to load levels. I now have three of the four significant objects ready. The last one is the Goal Tile. I will need to be able to load levels that specify not only the Floor and Wall tile layouts but also the locations of the Ball and Player objects.

On another note entirely, I also need to start thinking about sound. I might not have any significant music, but I should probably have some sound effects. Besides using the PC speaker back in the QBasic days, I haven’t done much with audio programming. What an ideal project to learn about it. B-)

Last night’s Oracle’s Eye programming session was still productive, although not as much as I would have liked. I last had a Room that would get created, and the Player would be able to walk over it.

I wanted the Player and the Walls to be on the same hiearchical level, and the Floors should be underneath. That way, Floors can be added to Kyra‘s KrImageTree as much as I want without the Player getting covered.

I already knew that I could setup the Tree by creating KrImNodes to act as the root of subtrees. Normally if you just add nodes to the tree, the later nodes will cover the earlier ones. I could instead add nodes to the child nodes instead to control the hiearchy. For instance, I could create a background and a foreground by adding background and foreground KrImNodes:

KrImNode* background = new KrImNode;
KrImNode* foreground = new KrImNode;
engine_->Tree()->AddNode( 0, background );
engine_->Tree()->AddNode( 0, foreground );

AddNode() takes as arguments the parent node and the node you want to add. In the above example, I am adding two new nodes to the root node. Now I can put as many items in the background as I want, and I won’t have to worry about covering up anything in the foreground tree. I already used this technique before with my Game in a Day in June.

What I learned was that I could also name a node. Kyra doesn’t care about the name, but I found that I could name a node and than search for a node with that name.

KrImNode* background = new KrImNode;
KrImNode* foreground = new KrImNode;
background->SetNodeName( "background" );
foreground->SetNodeName( "foreground" );
engine_->Tree()->AddNode( 0, background );
engine_->Tree()->AddNode( 0, foreground );

Now if another section of my code doesn’t know the specific pointers to the nodes in question, I can still do a search and get the information I need. For instance, in my GameWorldFactory’s createRoom() function:

engine_->Tree()->AddNode(
engine_->Tree()->FindNodeByName( "background" ),
floor->getSprite()
);

The result is that the Player can walk over the FloorTiles and gets covered by the WallTiles if the Player sprite was added to the foreground before the Room’s Tiles were.

The cool thing is that the separation of the Tiles into the hierarchy also makes it a lot easier to do collision detection. My previous code to move the player:

void GameWorld::moveY( const double distance )
{
player_->moveY( distance );
}

My current code to move the player:

void GameWorld::moveY( const double distance )
{
engine_->Tree()->Walk();
//! Check if moving Player sprite would intersect a wall.
//! If so, do not move the Player.
player_->moveY( distance );
if ( engine_->Tree()->CheckSiblingCollision (
player_->getSprite(),
&spritesHit,
0
) )
{
//! Reverse direction to restore position.
player_->moveY( -distance );
}
}


Since the Player’s sprite and the WallTiles’ sprites are siblings, and the FloorTiles’ sprites aren’t, I can simply check for collision with the siblings. CheckSiblingCollision() returns true if there was a collision, and so what I do is move the Player back the same distance, which should place it where it was before the move.

Unfortunately, it doesn’t quite seem to work. The Player does obey the WallTiles, but it then gets stuck. I think the problem is the double precision used for the distance. The sprite makes use of integers to move, and so I am probably losing precision. When I move the player back, it might be just short of where it should be.

Before this week, I was looking at a single Tile and a Player that moved around it. Now I have an actual Room and simple, although flawed, collision detection to keep the Player in the Room.

I’m also wondering if PlayState should still own the Kyra engine. I think that maybe GameWorld should own it instead since it makes use of it more, but for now I at least know that the project is working. I can always optimize later, and in the meantime I am making steady progress.