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.