Category: Game Development

While I have pretty much made the game “feature complete”, I feel there is still a bit of work to do. As most developers would put it, I did the first 90%. Now I have to do the remaining 90%. Except I feel like I did the first 20% and still have 160% left. B-)

What improvements and additions can I make?

• Sound. Right now, the game is completely silent. It shouldn’t be. Even simple beeps would be an improvement.
• Improved collision detection. If the Ball hits a Wall, it is possible that it can become stuck. It shouldn’t.
• Level loading. It’s very boring in its current state. It has only one level, and it is a trivial one at that. It should be able to load an arbitrary level layout from a file, which will allow multiple levels to be created. Any players should be able to load an arbitrary level from a menu.
• Graphics. Why is the Ball always rotating in the same direction? Why is the Player’s sprite just a static stick-figure? Why not spice it up and create some animated movement?
• Better quality code. My code doesn’t delete memory properly. When I create a Room, it is made up of a series of sprites that get owned by the engine, and the engine deletes the sprites just fine when the engine is deleted, but the Room itself isn’t deleted. I couldn’t delete the Room without causing a seg fault since I shouldn’t delete the Tiles in the Room. I’m sure there are other places that could be improved.

With all of these improvements, why leave Oracle’s Eye alone? I admit that I want to start working on something I can knock out relatively quickly, such as a Space Invaders clone. I’ve learned a bit while working on this game, and so I should be able to improve on what I’ve learned by working on something new. On the other hand, I feel like I would be quitting while there is still some good educational value left in developing this current project.

It’s obvious that I can’t really call Oracle’s Eye “complete” when there is so much left to do. I have decided that I will continue to work on it for the rest of the year. With holidays coming up, and the fact that I don’t work for more than a few hours a week in the first place, I don’t exactly have a lot of time to work on it, but I’ve surprised myself with how much I could accomplish so far.

At the very least, I should replace the stick figure with a living, breathing character of some kind. B-)

I was fine last night.

I was fine early this morning.

But today I got this incredibly sharp pain in my lower back. I lay on a couch with a heating pad and read a book, but I really wanted to get on development. My morning was shot, but my afternoon and evening could still be productive, right? I have to admit, I was tempted to call it off. I should lie down and relax.

Well, screw that! With Thanksgiving and Christmas coming up, I’ll have plenty of time to relax. Today is my day, and I will work on Oracle’s Eye. Maybe I’ll take more frequent breaks, but I am not giving up a great opportunity to get plenty of quality work completed on this project.

I’ll let you know how much of a folly this decision is later. B-)

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