Let the fanfare begin! All enemy types now have their basic actions completed. Unfortunately, most of the actions don't have animations to accompany them, but this is something I will have to live with for the time being. Regardless of that fact, it is very cool to see every enemy type actually doing something now instead of only being able to execute their "special" move.

Each enemy has their own unique type of attacks and actions, which is something I'm very proud of. All of these attacks will have to be tweaked in order to get a good balance. Of course, there are generic actions shared across all enemies such as walking around, as well.

This is an item that has been on my todo list for such a long time. It feels good to have completed it!

Using the wonders of parametric functions yet another enemy attack has been implemented. One of the flying enemies will have a "swooping" attack where they dive out of the sky and attempt to intercept the player before rising back up. This attack was the perfect candidate for using a parabolic type of movement. A symmetric arc with the tip being the intersection point between the enemy and the player was just right. I came up with a thrown together parametric method for positioning the enemy along this curve.

The calculations for the x coordinate were quite simple. Take the distance between the beginning and ending x coordinates and multiply by the parameter. When done, add on any offset required to reposition the curve. The y coordinate was a little bit more complicated. In order to achieve that perfect curving shape I decided to use the properties of the sine wave. Using the sin of the parameter where the parameter is scaled to be between 0 and PI, everything worked out fine. Multiplying this result by the "height" that you want for the arc achieves the effect of creating a parabola that starts and ends at specific points. An additional parameter is used to offset the curve to some location on the y axis. In mathematical notation it all looks like this:

x position at "time" t: ((endX - startX) * t) + offset
y position at "time" t: (sin(t * PI) * height) + offset
where 0.0 < t < 1.0

The only restriction on using this method is that the starting x position is always less than the ending x position. So, when using this method and the enemy is to the right of the player, the coordinates have to be reversed and I use (1.0 - t) as the t value to force the coordinates to be generated in a right-to-left fashion.

I am beginning to love using parametric function models for pathing purposes.

The enemies are coming to life more and more. The ground enemy with attack timing and probability rate issues mentioned yesterday is now fixed up. I'll still be doing a bit of tweaking to make sure he attacks at a good enough rate to be a nuisance to the player, though. An interesting issue I had to deal with regarding enemy types that use projectile attacks crept up while doing testing today: killing the enemy of a projectile while the projectile is still "alive."

In my current setup, each enemy instance is responsible for their own projectiles (technically, since these projectiles are an attack, there can only be one executing at a time -- this is how it is designed). These projectiles don't get tossed off to a projectile handler or anything like that. Because of this, I ran into some issues. Killing the enemy would remove that instance of the enemy, and along with all of their internal goodness, the projectile would disappear from the screen as well. This was something very bad! It looked very weird and was definitely a gameplay issue. That said, it was a very trivial fix; simply having a flag to determine when an enemy needs to be deleted, rather than is just "dead." This allows me to prevent the enemy logic from taking place, but still allowing their projectile logic to do its thing. Now enemy instances aren't removed until their projectiles are done processing (that is, hurting the player!)

Some additions were made to one of our fellow enemies in the sky, as well. These additions were also in the form of a projectile attack, but the problems that I faced were a bit more complicated. The attack for the ground based enemy only depended on knowing what side the player was on relation to the enemy. The projectile essentially moved in a straight, non sloping, line. For this particular flying enemy, though, the projectile would be moving in a straight line--any arbitrary straight line. This had me stumped for a little while. I originally thought of calculating the slope of the line and doing some number magic to move the projectile using a modified version of the slope. This was, however, messy and unintuitive. There had to be something better out there. Then it hit me: the parametric line equation. I was surprised I didn't think of this initially, but regardless, the solution works like a charm. I'm able to have the projectile placed perfectly (well, as perfect as rounding from the float x/y values given from the equation to the nearest integer value is). The best part of it is that it is extremely easy to change the rate at which the projectile moves.

After coming to this solution for the linear projectile, I realized that I can probably implement another enemy attack I have been having trouble with using the parametric equation for a parabola.

A lot of updates to stuff that should have been done a long time ago. I still have a long way to go, as well. Something that has been lacking for a long time is basic AI for all of the enemies. Incidentally, every time I thought about doing it, I ended up working on something else. Obviously, it was one of those tasks that kept on getting pushed further and further back. While it's nothing overly complicated to do, it is time consuming. Needless to say, I did a huge chunk of work in that area today.

I beefed up one of the flying enemy's AI and made it a bit more natural looking. As opposed to simply moving from side to side, she now will move around in all directions, which is nice. I applied this same type of movement to the second flying character, although in a different region on the screen. One attempts to hone in on the player, while the other always tries to get as far away as possible. The full attacks for both of these characters still need to be implemented.

Moving down onto the solid ground, one of the "walker" enemy types has been given a new projectile style attack. Initially I wasn't paying attention and inadvertently gave the attack to the wrong enemy type. After a bit of frustration, I was able to move all that code over to the correct enemy. There's still a bit to be desired. I need to take some of the concepts I used for one of the flying enemy's attacks and apply it to this new attack I added to the ground enemy. Currently, if the enemy "decides" that he wants to attack, he will, always--100% of the time. I'll be adding a probability rate and a "cooldown" timer to prevent too many successive attacks in a row from happening.

Once the flying enemy attacks and all projectile style attacks are completed I will be adding in the melee style attacks that don't involve simply dashing or flying into the player. These are a bit of a problem, mostly because they will be largely dictated by how the animation for executing these melee attacks will look. I'm considering putting in a basic structure for handling melee attacks and simply leaving it at that until I get proper attacking sprites for the enemies that need them.

I added another new combo effect today. It is quite basic, but has a few different features from the ones I've done previously. I won't delve into the details because they aren't all too exciting. Some settings parameters were also set which will help in linking the combo effects to the dictionary aspect of the game. Aside from that, not a lot of new stuff was put into the game.

I found an issue in my file i/o where values were being written out in a smaller form than they should have. Needless to say, that is all fixed now. It should work fine in the Windows world, but another test port shouldn't hurt.

I have to honestly say that as things are coming together, it's very exciting. Unfortunately, though, I feel as if there's a good chance there's just something missing in terms of gameplay. The main core aspect of the game is very simple and basic. I just hope that it doesn't get too overly repetitive and/or frustrating. The dictionary / combo systems should help balance that out, but I still think players might yearn for more. I have yet to learn what players of a score driven game will truly want. Perhaps the time is coming to show off what I have done so far to a small set of fresh eyes and hands.

I know I've been mentioning a small test release a lot these days. I'm also sure I'll push it further back down the road by a few weeks or so. While things are more complete and solid-feeling than ever, I can't help but feel there are still some large holes that need to be filled in. I think I will start rounding up some people who are interested in testing this early stage of the game. Hopefully that will help push things along their natural path.

Now there are four combo intro sequences (two of them are copies of the other two). While I believe it's a cool feature, I can't help but wonder whether others will find it interesting or annoying. Speaking of annoying, it is a bit of tedious work separating the slides and then calculating where each one should position itself when it slides into view.

Another alternative to intro slides is having a unique player animation play each time a specific combo is executed. I have yet to see what this might look like in action. In either case, I feel that it can hinder the fluidity of the gameplay. This is something I'll have to ask those people who get to test an early version of the game. Another thing to consider is there will be a large amount of artwork that has to be done for each unique combo effect that gets put into the game.

Because of those factors I have started to think about some different ways to show something interesting on the screen when a combo is executed other than the combo effect itself. One idea that comes to mind is showing the combo sequence used on the screen, zooming into and then out of view. I'm sure there are other ideas I will think of. For the time being I will be playing it safe and not be adding too much content regarding combo effect intros; at least until I can get some feedback from actual players.

It is at times like these it doesn't hurt to have a lot of siblings!

I implemented combo effect intro sequences. In actuality, at this stage it's simply a rudimentary version of something that might need a little more beefing up as time goes on. As I have stated before, I envisioned three comic-book like slides zipping in from the side, and then disappearing. Currently this works fine, but my implementation is extremely wasteful. Each "slide" is a screen sized bitmap, with almost 2/3 wasted in transparent pixels. This was simply the easiest way to test out whether the scheme worked, as I didn't want to calculate explicit locations where each slide would have to lock into.

The next step to take is to trim down each image slide and create an easy to work with scheme for how each slide will lock into place after it scrolls into the screen. This is easier said than done, since each individual slide per combo can have vastly different dimensions under the scheme that I have envisioned. I think in any case it's going to require some hard-coded values to determine where each slide should stop scrolling. There is no other efficient or easy way to calculate it on the fly. That said, it might not necessarily be required that it is extremely efficient since technically it runs through its own logic and drawing loop. These are all things to consider as I move forward.

With the addition of the combo execution introduction sequences also comes the ability to change whether or not they actually display. The option screen now gives the user the ability to turn intro sequences to always on, always off, or show once. The purpose of the show once feature is to allow intro sequences to be viewed on the first time they are executed, but never again. I think those options should be robust enough for a large majority of players.

Animations are now officially added to the remaining two combo effects that I finished up yesterday. While not so beautiful, things are looking slicker than ever.

While these basic core combo effects are done, I think it's going to be some time before I'm happy with the actual effects they have on the game. I know there will be lots of tweaking and balancing to be done in the future. I've already gone through my first iteration of balancing things out so they're not absolutely ridiculous tonight. Next up, as I stated yesterday, it's time to try out some combo effect introduction stuff.

Done and done! Well, with the six base combo effects, that is. Like the previous one, I was having some trouble thinking of something unique for this last combo effect. When I did come up with an idea, it seemed so natural that I'm surprised I hadn't thought about it earlier. The combo effects aren't completely done, however. I still need to implement some sort of visual cue for two of them. These won't take much time as I will make a quick, rough sprite for each.

I revamped a bit of the code regarding combo effects in general. For some strange reason I was having a class member declared with a default value passed to the constructor of most of the combo types and then assigning that value to an internal parameter. It finally dawned on me that this was quite ridiculous to do. What was the point of it all? I could simply just use the class variable directly within the class' own code. At this point, there was no reason to make it public any longer, so now everything is neatly packed into the classes themselves and there's no unnecessary throwing around of values.

Next on the plate after the two combo sprites are created is a trial of the combo effect intro screens. If they don't hold up my next move is to have some kind of generic custom animation for executing a combo effect.

I was able to implement one (Two if you want to be technical, but they borrow a lot from each other. At this point, they're basically identical save a single variable: duration) of the two combos I have left for this current "set" of combos that needs to be done. It took a bit of thinking, but with a little prodding from some other minds I was able to come up with a unique idea for it.

This leaves me with one more combo left over. After that one is done, I have a bit more freedom in picking what the effects of the rest of the combos are. They aren't directly tied to the enemy types that generate the player's ability to execute a combo.

With a lot of the combos in place, and working, I think it's safe to say that it adds a whole new level of depth to the game. Things are definitely a lot more exciting now even though they are rather ugly looking (I've been using very quickly whipped up sprites as placeholders for much of the combo animation graphics). It's nice to see that every little bit of work I do adds a lot in terms of playability or fun-factor in the game.

As for combo splash screens on execution, I created a simple mockup of one of them, but have yet to implement it in order to check out its viability during gameplay.

Today was a bit uneventful. I hit a roadblock in what the next two (well, four if you want to get technical) combo effects will be. I thought I might have them nailed down by today, but I just can't come up with something interesting. There are a few that I had though up, but they are more useful for different types of combo effects. It's hard to explain without giving it all away, but they're more fitting of another combo style than the ones I'm currently working on. I'd like to come up with something asap, obviously, but I'd rather not rush it into being something silly that I'd have to change anyway.

Hopefully I can formulate some good prospective ideas over the course of tomorrow morning and afternoon.

Two new combo effects have been added to the game system. They are actually the more interesting looking effects of the others I've done so far, but their purpose is very basic. Regardless, it's very fun to see all of these combos come together and be useable during gameplay. I have yet to do a serious test run of the game with the current set of combos in place. I think I will wait until I add the remaining four that I have my mind currently wrapped around.

While playing with all of this combo stuff it dawned on me that there is no neat transition between not doing a combo to actually doing a combo. I think I'd like to do one of two things: either add an animation to the player for starting up a combo, or, display some stylized image pattern onto the screen. The former is pretty basic. I had some neat ideas for the latter.

If I were to splash some image goodness onto the screen on using a combo, I would first add an option where this feature can be turned off after the first time you see it. No user should be forced to have stuff pop up and interrupt gameplay if it's unnecessary to the gameplay. What I envisioned, though, is a splicing of three separate images that slide into place, and then slide out of place. Consider, for instance, a combo effect that might make the player more powerful. An image sequence of the player not looking powerful, then the player releasing a combo, and then the player looking all powerful would slide into the screen from left to right very quickly. Each image would take up a third of the screen. After hovering on the screen for the matter of about a second, they would slide out just as fast as they slid in, and the combo effect would then take place.

Currently it sounds like a neat idea. I might whip up a prototype of this and see if it's workable without being absolutely annoying each time you do a combo, especially in the case where the user doesn't want to watch the combo effects. If that option is turned on, I still want to display the combo intro images at least once, so the goodness isn't missed. If even that could have the potential of becoming absolutely annoying, I will either rethink this method of displaying combo introductions, or allow an option to turn off the "show me once" feature in addition to the "only show me once" feature.