Saturday, April 26, 2008

Mark of the 1.0

I am finally prepared to call my current build of "Circle Game" (now "Spherical Prison") version 1. For some reason, I'm a fan of giving the major numbers to the major releases. This release is the one that I will call "done".

After taking the time to fix a few hack solutions with proper solutions (i.e. using a boolean to determine if the player has entered the editor to invalidate scores instead of making the score infinity, using a list to buffer the collision callbacks instead of just using the first, etc.), and committing to a decision on what levels I should include, I'm happy with the result. As far as the level editor goes, it is not viable for community sharing. I found that even with making my scene dynamic, it would still be quite a bit more work to add methods of filtering keys from walls for deleting and rotating objects. There are member data fields inside the box2D objects that fit this need, but even with that I don't feel that the implementation would be clean in the end. The design I chose did not account for sufficient separation of actions pertaining to modification of objects in the scene.

Today I've also completed my configuration for the Xcode project, so I have a fully functional Mac version that is a duplicate of the Windows version. Aside from this, a good friend of mine (who would wish to be reffered to as "Z-Dawg") wrote up a makefile for the project for easy building in Linux. So, fortunately, I'm able to say that using cross-platform libraries has enabled me to build my first totally cross-platform windowed application.

For now, I must begin channeling my game through the library communities (at first) and then see what else I want to do when I get a web page up for it.

Sunday, April 6, 2008

Onward to level design!

Okay, maybe not quite so energetic.
This weekend let me get a number of things done. Now the menus are about 95% complete, and I have the first three levels pretty well set.

The first level gives the player a chance to get a feel for the movement. Just rolling around and letting the physics do the rest.

The second introduces the bounce and sticky walls. By changing your speed you'll hit the wall at a different angle and thus be shot off at different angles. So far everyone that's played the level has figured it out, so I'm definitely keeping the design. The only problem with this one is that hitting the walls just right takes a bit of practice. When you shoot up to the top, you can only get back down by pressing up to shoot your self off of the stage, which adds ten seconds to your score. So the strategy is to get the lower one first.

The third introduces the magnet wall. It's a pretty simple concept, but the design of the level gives a number of options for shortening your time.

Through some testing with my friends, I'm pretty happy with the designs. I'm still not entirely sure of the difficulty of the second, but I think I can overcome this with some sort of message shown to the player during gameplay. Of course, with levels I needed to finish the logic for "winning" the game. So now I have a place for credits and high scores.

The high score list shows the top ten total scores, and lists the player's initials and score per level. This is stored in a binary file (which is just a struct written out and back in) so it will persist.

Something worth mentioning is that I used DropBox to share the executable with my online friends. Doing this introduced an interesting type of concurrency to the game. As the files shared are synchronized across computers, each player was logically using the same files to play. This meant that the scores data file was shared too. Because of this, I could no longer leave a pointer to the file open while the game was running (bad design anyway). After fixing my design, however we still noticed that if enough people were playing, and finishing the levels quick enough, the files may not sync fast enough to prevent overwriting. There's not really much I can do about that, but it was still interesting to try and compete with each other.

Things still left to do are:
build an in-game level editor (extend the lifetime of the game)
finish the rest of the hardcoded levels
animations for the man, and likely the walls

Tuesday, April 1, 2008

Refactoring, and moving towards level design

Even though classes are back in session, right now all I want to do is build my game. It beckons me when away, and teases me when I play... (this is why I don't blab in these things...)

I just finished some refactoring, I had let myself put the world and player management inside the main class instead of the scene. Now they are where they belong, and I have legitimately separated collision callbacks from distance checks for the walls' interactions with the player. As it stands now, every wall type except sticky is near complete. After I take the time to create some animations, they should be good. I'll have to check my color choices to see if they work alright with common color blindness, or if I need worry with the choice of animations. I figure that this project ought to be as polished as possible, since the complexity of it gives me that option.

Shown here is my little test level. The absense of a clear cut or even sensible strategy should be a dead giveaway.