Category: Game Development

Oracle’s Eye development has been fairly slow since I started it in August. I’m trying to get working on it earlier in the evenings I have dedicated to development, but I find that I usually don’t get started until late at night. When I finally get into a groove or otherwise in The Zone, I learn that it is 12:30AM or 1AM and I need to go to sleep.

In any case, I finally accomplished another milestone. The Player can now kick the Ball around!

I won’t go into too much detail, but I found that I didn’t have to make too many changes or additions. I was originally going to create a somewhat robust Event handling system, but someone reminded me that this is supposed to be a VERY simple game. I am allowed to hardcode it for now. I can always add the Events if I find I actually need them in the future.

I am also trying to remember not to over engineer. I found that hacking things out didn’t cause as many problems as I thought it would. I added an enumeration for Direction: UP, DOWN, LEFT, RIGHT, and STOPPED. Doing so allowed me to keep the code I already had to move the Ball around. I just had to check which Direction it was moving and apply negative signs to the moveX() or moveY() functions as needed.

I then added a check to the GameWorld’s move* functions that control the Player. Now instead of just checking if it hits a Wall, it checks if it hit the Ball as well. The Ball then moves accordingly. It’s a simple check; the collision detection isn’t very robust, but it gets the job basically done. The Ball gets stuck if it hits the Wall for some reason, and the Player can move through the Ball if it is moving faster, but it works. I’ll fix it later.

My next chance to work on it will be Sunday, which is when I scheduled all-day development on Oracle’s Eye. Ideally that means eight hours to work on the project, but if past performance is any indication, I will probably get two, maybe three hours out of it. B-\ With a Ball being kicked around, I would think that it shouldn’t be too hard to create an Exit and apply a new check to see if the Ball hit the Exit. After that milestone is hit, I technically have a playable game. It’s great to know that my one month project is almost “completed” after almost four months. B-)

This week’s Oracle’s Eye development wasn’t too fruitful, but I did spend a bit more time trying to figure out what I needed in the first place. The lack of actual code doesn’t bother me so much now that I have some ideas of the problem domain.

The problem domain of the moment is the Event system. I don’t want to hardcode the movement of the Ball and the Player since I might want to tweak the way things are handled. I’ve had a general idea of how the Ball and Player should interact, but I haven’t explicitly defined it.

So while in the middle of a presentation last week, I started to write down some ideas. What is it that I am trying to accomplish?

Well, I want to finish the game. How do I do that? Well, I’ll basically need to allow the Player to end a Level by kicking the Ball into a Goal. That line basically sums up what would make this game into a game, regardless of the amount of fun possible. The idea is that if I can do that, I can then design as many levels as I want, but the basic game is complete.

Well, how do I get to that point from here? Currently I can move the Player, and the Ball can also be moved, but I don’t have a clean way of keeping the Ball stationary until the Player touches it. I also don’t have a way to tell the Ball when to stop moving when it hits a Wall or the Player.

What I need is an Event handler and some Events. I need some indepdendent system to handle things such as telling the Ball when to move and when to stop moving. I need something to decide that the Level has been completed or needs to be reloaded. How about the creation and destruction of objects during a game? Maybe there are four Balls, and when one gets into the Goal, it disappears.

Now, when the Player collides with another object, the GameWorld can create a CollisionEvent, or maybe it knows that the Player hit an object of type Ball and so creates a KickBallEvent.

I’ve read a few tutorials and the book Game Coding Complete, and so I should be able to come up with something workable fairly easily. Well, maybe not too easily. Still, once I get an Event system working, it should be much easier to make the Player kick the Ball, to get the Ball to enter the Goal, and to let the game know that the Level has ended.

Or at least that’s the theory.

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.