For today’s Devember update, I bring you an ugly and not entirely functional title screen! Also I thought I’d show off a picture of the game over screen while I’m at it, since I never did that yesterday.

Our title screen is currently very simplistic with just some (vaguely) informative text and a semi-functional menu. This should actually allow us to select a level AND a speed AND a music, but I don’t have sound support yet and speed support is not added but would be simple to do so. Also the level changing does not yet function (it should really be a slider or something, but this is a simple prototype after all). However, the option to start the game actually works.

The prototype title screen

The prototype title screen

Selecting the start game option switches to the game scene, which is the main scene that drives the actual game play. When the game is over, it switches to the game over screen:

Our simplistic game over screen

Our simplistic game over screen. “Press enter” flashes for “panache”

This should really display a menu to start over or quit, but for now it just has an implicit retry; pressing enter switches back to the game scene again. As mentioned yesterday, the game over screen invokes the render method on the game scene before rendering its own text.

This is not a lot of outward forward progress but behind the scenes I am working towards a more generalized menu scheme that I can pull out into its own class or classes for reuse; possibly into the engine itself. Currently the code is all in the title screen method, where I’m working to implement all of the features that I think it should have before I start to make it more generic and refactor it out.

Based on the proximity to Christmas and the enjoyment of festivities therein, I’m not sure how fleshed out this is actually going to get over the next couple of days. I would like to have this and possibly also the image and sound preloading into the engine before the end of Devember, though.

Once again just a small set of simple changes; busy day with holiday errands which also included taking the car in for servicing and having the dog fluffed and folded (no starch, though). Additionally, super early morning trip across the border is planned, so early bed time as well.

In any case, Rx changes! There is now a display of the upcoming capsule, and a simple game over screen that uses some rendering tricks.

Continue reading

Today’s changes are an example of something that’s pretty simple to do, but which enhances the game experience quite a bit; scoring. This is a fleshed out version of the crude mechanism created in yesterday’s commits. Points properly accumulate per virus matched the way that they do in the original NES version of the game, with an added cascade bonus.

Viruses matched as part of a cascade have a multiplier attached to them that cause them to be worth more. Since the mechanism for scoring is simple, this means that you get the multiplier even if the cascade starts off with matches that contain no viruses. For now I like it that way because it provides a reward for setting up a cascade.

As a nice visual tweak, whenever a match happens, the traditional floating text appears to show you that you received points for doing something.

Continue reading

Let there be score! Also a couple of other changes.

Since it is the bottle that does the matching and dropping, it needs to communicate to the bottle every time a match happens, as it was only notifying when all matching was complete to signal the next capsule. I did a bunch of pondering on the complexities of this only to discover that it’s actually not complex at all.

Continue reading

Ok, Rx is now officially a playable prototype of a game! Albeit a game with no scoring mechanism or point, but still, baby steps! My logs indicate that back on Day 8 I started on this, so 10 “days” of prototyping to get this far with only a couple of hours fully spent on each of those days, That’s probably pretty slow by most standards, but assuming you were not also writing and tweaking your engine code along the way, that’s not to shabby, I don’t think.

Continue reading

Today’s update brings us really close to an actual fully playable game prototype! The only thing missing is a constantly applied drop force for the current capsule; currently the player has to move it down on their own. Apart from that, everything is more or less there.

So a capsule appears inside the neck of the bottle, which is outside of the content area of the bottle. The capsule is always horizontal and has randomly selected colors. The player can use the arrow keys to move the capsule left and right and drop it down, plus the ‘Z’ and ‘X’ keys to rotate the capsule left and right.

Rotation is only allowed while inside the bottle, and then only when there is nothing blocking the position that the capsule will ultimately take. For a horizontal to vertical rotation, this means that the space above the left end of the capsule has to be free. For a vertical to horizontal, this is a little more complicated (but only a touch).

When going in this orientation, the capsule will “wall kick” away from an obstruction on the left when rotating left or on the right when rotating right. Here “wall kick” just means that the position will shift over one to the left or right in order to facilitate the rotation. As such, the rotation code needs to check to see if such a kick is possible if the rotation won’t work the other way.

When a drop attempt fails because the capsule is blocked, it will insert its segments into the bottle, then trigger it to find matches. The bottle in turn will also call back to the game scene when, after an attempt to find matches, no matches are found. This is the scene’s notification that it needs to reset the capsule back to the top of the bottle and go again.

Simple game over detection triggers when the drop fails but the capsule is still outside the bottle. In this case we just clear the bottle and stop everything.

Normally, the capsule treats the bottom/left segment as its first color and its top/right segment as its second. This slightly complicates rotations that require the color order to swap around. Since there are three colors, we just treat the colors as a base three number; using the same trick to pull out the right and left colors, we can pull out the right color and multiply it by three to “move it to the left”, and then add it to the previous left color to end up with the new enum constant for the colors.

Lastly, the original Dr. Mario allows you to rotate the capsule from horizontal to vertical even in the top row of the bottle; when this happens, the upper segment appears  outside the bottle, but if the drop stops there, gets truncated away. Our little version here does the same. We render the upper segment with some alpha transparency in this case so that it’s more visually distinct. This also paves the way for our ability to show a “ghost capsule” on the bottom of the bottle to show you where the current capsule is going to end up.

The next steps will be to add the automated dropping and clean up the input a little bit. Right now capsule changes can only happen in the update loop, which is cleaner but makes the movement a little chunky due to the timing I put in place to stop a movement update from happening in every frame update. I have a potential solution to this, but I ran out of time to implement it.

Once these two things are done, the prototype is playable on its own, although it still has no scoring or sounds. Still, progress!

User controlled capsules are in!

User controlled capsules are in!

I didn’t make quite as much progress and I might have liked today, primarily due to having a Doctor’s appointment shuffled around to an earlier point and some problems cropping up at work that drew my attention away. This is not all bad; that particular Doctor usually tends to bump my appointment in the other direction, so having it happen sooner is a nice change of pace.

On to code!

Continue reading

For today’s foray into game development in TypeScript, we have some changes that almost make Rx a playable game; all that’s missing is, you know, the ability for the player  to actually play it. As you can read in the commit log in the repository, today was mostly about code refactoring with some new features added, including a crude level and virus count using a hand rolled font.

Continue reading

Today I pushed some engine changes to rendering and got a full final first draft done of the virus generation code. Not quite as much as I wanted to get done, but better than a kick in the pants.

The engine now sports rendering of stroked shapes instead of just filled shapes, which I have wanted to cram in there for a while but never really had any need. This is now used in concert with the debug property on Segment, which is a boolean value; when it’s set to true, the current bounding box of the Segment is rendered prior to whatever the contents are.

Continue reading

No, not the Weird Al song, in Rx. This was another one of those days where it was tricky to find some time to get some coding done on this (ironically, work days work better than days off, go figure), but I did manage to get some stuff done. In fact, this entry will be a little short since it’s late and I have to get up super early for work in the morning to do some after-maintenance testing.

Continue reading