Category: Game Development

I posted the date of the next Chicago Indie Game Developer Meeting on the Indiegamer forums:

Where: The Starbucks at
Streets of Woodfield
601 North Martingale Road
Schaumburg IL, 60173

When: Tuesday, January 17th, at 7PM.

This post is just to provide a little over a week’s notice to those who can make it to the meeting. We’ll alternate between Chicago and the western suburbs each month, so February’s meeting will be in Chicago.

I was also experimenting with an About Us item:

The Chicago Indie Game Developer Club is an informal group of indie game developers who meet every month to talk shop with likeminded people. It’s generally good to keep in touch with your industry; no one wants to become obsolete. This club is just one way to make and keep contacts, learn about developments in the industry, and provide personal feedback to other developers.

It’s one way to help improve the CIGDC. I think a dedicated domain and website would be another. These are some of the things I would like to discuss at the meeting.

Oracle’s Eye is really shaping up as a game. I’m awfully close to the project, of course, so there could be lots of things wrong with it, but it’s definitely much more playable than when I called it “technically completed” a few weeks ago.

The links from December 9th still reflect the game’s current state, which means I haven’t done too much to update it. I made the Player’s sprite smaller and haven’t been able to walk through walls so far. Some of the small tweaks I’ve made with the code have made drastic changes in the resulting gameplay. For example, I combined two sections of code knowing that it wasn’t exactly what I wanted. I just wanted to get closer to whatever it was I was doing. The result: now instead of just pushing the Ball, you can push against the Walls, and depending on the direction you are facing, the Ball moves. Psychic powers?! Maybe I could make some Walls into switches that create a gravitational pull on the Ball? It might be an interesting gameplay development.

Of course, I haven’t exactly created or updated a detailed design, so how can I know when something is progress or the introduction of a bug? This project is starting to become a bit more concrete, so I think it is appropriate to list specific implementation goals. Since I’ve gotten this far, I really think it would be appropriate to turn it into a commercial quality game. Besides having a game to sell, it would also allow me to have the experience of finishing a game that doesn’t look and feel like a newbie’s first project.

It’s clear that Oracle’s Eye is becoming more like a puzzle game than anything else. The basic premise: maneuver the Ball through the Room to get to the Exit. Maybe that’s all a player needs to know, but what about me? I’m still making it!

• The Player should not be able to occupy the same space as a Ball. If the Ball hits a Wall, the Player should find that he/she needs to push at the Ball from a direction that isn’t towards the Wall in question. The point is to force the Player to use the level layout to find the best way to move the Ball. Allowing the Player to move the Ball through him/her would break the game since the Player would not need to worry about where certain Walls are.
• Graphics: the Ball should rotate when it is moving and in a way that implies rolling. As it stands,the Ball rotates in only one direction, and while it might not be too noticeable, it is incorrect. Similarly, the Player should have images from multiple angles and various key frames. The static Player image is fine for placeholder art, but it will need to be replaced by someone that looks alive and breathing. The Ball and the Wall and Floor tiles should also be updated with higher quality art. The graphic style should be cartoonish but not exaggerated.
• Sound: the game is silent currently. I should work on getting at least one piece of music for the background. The music should be upbeat and fun. There should also be sound effects for the Player when he/she kicks the Ball or hits a Wall. There should also be sound effects for the Ball hitting a Wall or getting to the Exit.
• Levels: each level will consist of a Room with Floor and Wall tiles, an Exit, and a starting location for the Ball and Player. Rooms should be able to have different dimensions. One Room might be 10×10, another might be 5×15, and another might have varying widths. The purpose is to allow vastly different level designs as well as varying visuals. The maximum limit is related to the screen dimensions and the Tile lengths. The Player should be able to choose levels from a menu, and finishing one level should allow him/her to continue to the next one. I imagine that the game would require the ability to restart a level if the Ball gets stuck in a corner or gets in some other situation that prevents Player progress.

I was about to add that I wanted extra items, like angled banks for the Ball to bounce in new directions, but I already decided to cut out such features. It’s a nice-to-have, and maybe I’ll find that it will be easy to add, but the above listing is what I want to concentrate on. I think that focusing on these things will greatly improve the game, and I can always write down the gameplay elements I come across that don’t fit this design but might be useful elsewhere. I will keep an offline version of what I have here. It should be easy to update as I gain more insight into the project and its needs. I already know that this isn’t nearly detailed enough, but it should be good enough to show you (and me!) what I’ll be working on.

Working off of the list of improvements for Oracle’s Eye, I managed to improve the hit detection somewhat.

I was originally thinking about changing the movement code completely. Instead of freely moving about, the Player and Ball would move in a tile-based manner. I spent a bit of time thinking and writing about how I would go about implementing a tile-based game, and I still believe that it might make some things easier. I could also start adding different objects easily.

But when I sat down to code, I decided to continue to do what seems to work for me: mold the existing project until it works.

A major problem with the movement is that the Ball can get stuck in Walls. It can bounce back out normally, but if the Player is too close, it will get stuck in the Wall. Unfortunately, one of the ways I tried to avoid problems with movement causes a very annoying bug. If the Ball moves into the Wall, it is supposed to move back out at twice the distance. It looks like it bounces back out. But if the Player is touching the Ball, it stops moving. Well, if it stops moving, it won’t bounce back because the reverse of stationary doesn’t exist! The next update through, if the Player moves, the Ball wants to move with the Player; however, because it is stuck in the Wall, it “bounces back”. The result is that the Ball looks like it is going the exact opposite way that the Player would expect, which makes the game feel buggy. And not the good, on-purpose buggy, either.

I’m not a fan of guessing with my code. If X = X + 1 doesn’t seem to work, I don’t just automatically turn it into X = X – 1. I prefer to analyze my code and try to determine what exactly is going wrong. In this case, I found that each update, the Player moves, then the Ball moves. Then the Kyra engine’s tree is walked, which allows me to accurately handle collision detection. The next step is to check if the Player collided with a Wall. No problem there. I just reverse the direction of the Player, move him, then change his direction to STOPPED. Then I check if the Player collided with the Ball. If it does, then the Ball will take on the direction of the Player. It makes sense in most cases. If the Player touches a stationary Ball, the Ball should act as if it had been kicked in the same direction that the Player was moving.

When the Ball is near a Wall, however, the Player can kick a Ball, and the Ball can bounce off the Wall. Now the Player and the Ball overlap. Again, it is not a big problem. If the Player moves, the Ball follows the Player. The problem occurs when the two overlap AND the Ball is overlapping the Wall. The Player moves, makes the Ball move, but then the Ball wants to reverse itself.

I found that most of the Ball/Wall overlap can be avoided by changing the order of the collision checking code. The Ball will check for collisions first, then the Player will do the same. The Ball might still get stuck in the Wall, but I’ve found that it is a quite a bit more rare and not as dire a situation. It is a lot harder to reproduce the issue, but of course, right when I was about to say that the problem was completely solved, it occurred.

In any case, it was a quick fix and didn’t require any new code. I’ll probably continue to work on this same issue, but for now it has been vastly improved. I think I will also want to change the size of the Ball. The diameter of the Ball is the width of a Tile, which makes it very difficult to maneuver. If there is a single Tile opening between two Walls, a player might find it incredibly frustrating to try to get the Ball in between. It is part of the reason why I was thinking about using Tile based movement. I should eliminate this problem entirely. Of course, Duke Nukem Forever has had its engine gutted and replaced a number of times, and I would actually like to complete this game soon. B-)

Download files: EDIT: I decided to take down this set of downloads. For both tar.gz and .zip files, it comes to about 16.5MB, and I’m running out of space on my server apparently. This update doesn’t exactly merit its own release, so I will remove it and allow space for better uploads.

Already I’ve improved the movement of the Player and the Ball.

Essentially, what I am supposed to do is make any moves, then walk through the Kyra Tree, then check for collisions and respond accordingly; however, my hardcoded movement code moved the Player, then walked the Tree, then moved the Ball and checked for collisions. The Player worked out just fine, but the Ball would get stuck in the Wall.

Then I changed it so that the actual movements wouldn’t happen until the update code ran. When you push the arrow keys, the Player’s Direction changes accordingly. It will only change positions during the update, and it does so at the same time as the Ball. Then I walk the Tree, and so collision detection is a bit more accurate.

Also, the Player only moves in four directions now, so it isn’t possible to move twice as fast on a diagonal. For this game, not being able to move diagonally shouldn’t be a problem, but an adventure or action game might require such movement in the future.

The Ball currently changes Direction when it hits a Wall. It’s actually kind of cool to watch the Ball bounce back and forth between the Walls. If I start adding more Walls throughout the middle of the level, it could actually be fun.

It’s amazing what can be done when you don’t have to worry about ruining the code base. I’ve been using Subversion all this time, but psychologically I’ve been concerned about doing the wrong thing. I basically convinced myself that I’m going to be writing code that needs debugging anyway, so the “wrong thing” will most likely be a bug that needs to be fixed to make the right thing. So far, I haven’t had to rewrite whole sections of code, or if I had, I haven’t noticed it as hard work.

Thanksgiving is here, and I’ll be out of town for the rest of the week/weekend. I’ll probably have a bunch of spam comments to delete, and I won’t likely have time this weekend to approve any. Still, keep the comments coming. I love the feedback. B-)

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