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.

Today was the first official day of my Christmas vacation, which on the one hand should provide me with a bunch of extra time to work on Rx and Devember in general, but on the other hand due to Christmas being so close, a lot of time is spent on holiday related endeavors. I’m still going to power through and get in my minimum one hour a day, but we’ll see what sort of progress gets made.

In today’s update capsule gravity is now implemented fully; based on the current level, there is a speed at which the capsule will attempt to drop down on its own (based on clock ticks). This is not fully how Dr. Mario for the NES operates. Firstly, there should be a low/medium/high speed control, plus the number of capsules dropped should also increase the speed over time even while in the same level.

That is easy to implement from this point since it’s just tweaking the time value, but this requires a bit of trial and error testing to see what is too slow to be fun and what is too fast to be annoying. Also, since there is not (yet) a preview of the capsules that are coming up, higher speeds are really tricky.

I spent the rest of my development time today going down a dumb road as far as input is concerned.

I had been using KeyUp/KeyDown events to track the pressed state of the input keys as a boolean, and then polling that array in the update loop. This is primarily because all game updates should happen in the context of the update method, and in JavaScript events are asynchronous. In practice everything works fine, but it was bothering me nonetheless.

This leads to a problem where a light tap on the key sends the capsule to the bottle edge because it moves in such large jumps and the update is happening 30 times a second. I had been just limiting how often the input can be applied by saying, e.g. “only on every third frame”. However this leads to input drops if you happen to press the button during a “dead” interval.

Anyway, I spent some time trying to work a better way to do this before ultimately deciding that the easiest (and most obvious) solution is to have the update method reset the boolean flag whenever it consumes a key. This artificially limits what keys are pressed to the keyboard repeat rate but still lets all key pressed by the player take effect.

The controls feel much better now, but they still need a bit of tweaking. The biggest problem is that the down arrow now causes the capsule to drop directly as far as it can. Coupled with the capsule starting in the neck of the bottle when it appears (constraining movement and rotation until it drops once) this makes the slower levels more of a pain to play.

Probably the best solution to that is to have the down key just call the drop () method once instead of in a loop, but I’ll need to play around with that a bit to see what happens.

Tomorrow the plan is to start doing something score related, unless I spend too much time tightening up the controls.