Tutorial creation is progressing quite well. Items I can check off now include: basic movement, dashing, attacking, jumping, double jumping, and teleporting. These are the basic core controls the player will need to be able to play the game. With those items done, I would guess I'm about half done writing the tutorial.

Up next is the actual gameplay. This encompasses explaining score combos, power combos, enemy types, player life, "world" life, and the main enemy. I'm sure there are more items I can't think of this very moment, but what is listed is the larger portion of what needs to be added. While the tutorial won't go into detail about every single enemy type, it will be informative enough to give the player a good sense of what's going on. Besides, the dictionary is where one will get all the good dirt on any of the game related elements anyway.

I've begun to script and code in parts of the tutorial mode. Currently it instructs the player on how to move and dash (dashing is not fully complete yet). For any of you who've gone through the ZD tutorial: No, the portion of the tutorial dedicated to movement isn't as thorough as it is in ZD.

There was a bit of code retooling for the player and main enemy in order to get the desired effect I wanted during tutorials. Obviously I can't have enemies flying around all over the place while the player is trying to learn stuff. For that reason, enemy generation can be toggled on an off, etc. Additionally, during certain parts of the tutorial I wanted to restrict the player from jumping and/or attacking.

The stuff that's left to "tutorialize" includes: attacking techniques, jumping techniques (I think jumping is going to be the biggest stickler in the game for some people), the main enemy, enemy types, score combos, and effect combos.

Currently everything is hard-coded, including the messages that are displayed for the user. This is the same route I went for Zep's Dreamland. I'm contemplating changing this scheme to, at least, read the messages from an external file. This will reduce the amount of annoyance in having to recompile due to spelling and grammar. It will be staying hard-coded for the time being, though.

Regardless of the method used to get the tutorials working, it's going to be great to have people test out the game without having to explain how to play it every time. Of course, one could always argue that a manual would server the same purpose. But, realistically, I think we all know how often users read the manual for a completed and finalized game project, much less a test demo. That said, don't be fooled, I will be writing some good documentation to go along with the first "more-public" test.

The basic framework for the tutorial mode is now in place. I'm still unsure as to how it will be accessed, so for now it runs automatically and never turns off. Technically, the tutorial mode sits on top of the main gameplay, so, while the tutorial mode is running I can have all of the game elements working in the background. It's pretty neat. For now a simple flag set before the main game loops start determines whether the tutorial mode will run or not.

The tutorial system will interleave informational text bubbles along with having the player operate the game in a limited gameplay mode. Essentially there will be informational text bubbles displayed to the player, and then after absorbing all the wonderful information they will be let loose to play with that specific aspect of the game. Once they've completed a specific task, the tutorial will continue on.

By doing things in this fashion I can slowly introduce all of the key concepts of the game to the player, allowing them to experiment without too much stuff happening on the screen at once.

I have distributed the game to a few people. There are mixed feelings about the game, but generally it seems that it is fun! This is, obviously, very nice to hear. It seems that I might grab some more people and be less picky about who I let play an early version of the game. Before I make it seem like there's nothing wrong with the game, let me address what kind of issues people have been having.

The main problem I'm noticing is that, for some people, the main object of the game is just plain hard to do! There is a bit of a "twitch" element to the game, requiring the player to keep track of a lot of data all at once. There is also a bit of a requirement for well tuned eye hand coordination. For those of you expecting something along the lines of ZD where you have all the time in the world to execute any action, this game is on the complete opposite of that spectrum.

Another thing I noticed is that without knowing what to do, the game can make absolutely no sense and isn't very forthcoming in making it obvious as to what to do. It's also difficult to explain what people have to do without being able to show them. Usually they simply get confused. Other than these main points, there are other issues with the game that will require minor tweaks that people have found. More opinions will help craft it into something great.

With those given issues, I realized it's about time to start working on a tutorial mode for the game. The tutorial mode will be an "in-game" style tutorial along the likes of the tutorial mode for Zep's Dreamland. I'm going to wait until this is complete before I send the game out to the next batch of testers.

It's only obvious that I will be using the wonderful text bubble class in order to display all of the informative tutorial information to the player. I wanted the border of the text bubble to be unique, so I quickly whipped something up and slapped it into the game to see how it looked. That approach didn't work so well; and for a good reason! The borders I created had differing sizes--something which the text bubble class was not already equipped to handle (it would only play nice with square border pieces, all the same size).

In case "border pieces" doesn't make sense, let me elaborate. A text bubble with borders contains 9 border pieces, one piece for each of the following sections: Top left, middle, and right. Middle left, middle, and right. Bottom left, middle, and right. Each of these sections is allowed to be a unique image. It looks something like this:

Top Left    | Top        | Top Right
Left        | Background |  Right
Bottom Left | Bottom     | Bottom Right 

Each of the corners are static, while the "top", "left", "right", "bottom", and "background" are stretched if the bubble is larger or smaller than their actual size. The background can optionally be tiled.

Looking at the larger picture, the text bubble class really should support borders with components that have different dimensions. Long story short: I added it in. The code required wasn't very much. Many places assumed that the border size would be constant and equal (width/height) for all border pieces; and very rightly so--it was documented!

There are still restrictions on some of the sizes of the border components, but much less than before. Now only certain groups need to share the same dimensions as follows: the top and bottom row components must all have the same height and the left and right column components must all have the same width. That's it! So much nicer.

With the enemy action milestone hit, I decided it was time to build the game for all three major operating systems: Mac OS X, Windows, and Linux. It was pretty hectic doing builds of the game on three different systems at the same time, but the task is now complete!

During the process, I was able to find one small bug that has thus far been undetected through OS X and Windows. Linux found one tough to spot bug. Before we get into that, let's just say that there was a lot of work to be done to get the code working in Linux. Not only did I have to upgrade Allegro, I had to get DUMB installed as well. After all of that library goodness, the code had some issues with a few of the standard C libraries, mostly complaining about capitalized headers that both OS X and Windows don't complain about. After all of that work, the game finally compiled -- but got stuck in a very weird state. It didn't crash, but it didn't run either. It just sat there doing nothing at all!

The cause of this problem was setting an out of bound index in an array. Thankfully, Linux caught this. If not, the problem (while not causing the game to crash or run incorrectly) would still exist. Needless to say, that problem has been fixed and now I have three versions of the game. What does that mean?

For most of the world, it doesn't mean anything fun. I will be using these versions to go through my first set of "funability" testing. I'll be sending them out to a select few of my close friends for general purpose testing to determine whether the game actually "feels" fun in its current state.

I'm still rounding up those who will be doing this initial testing. I have, however, currently confirmed that the OS X and Windows builds work fine on non-development systems. This is great news. Tomorrow I will be able to determine whether the Linux build holds up, as well.