The code change for today is rather short due largely in part to the time of year; It was time to start doing some holiday chores like getting Christmas cards ready, as well as putting up some more Christmas lights to be more festive.

Nevertheless, code was still written, although not what I had intended.

I had plans to either work on the virus insertion algorithm that starts off the game or work on the “scoring” mechanism in the game, which requires knowing how many viruses were clobbered with each match as well as knowing how many successive matches happened in a cascade before everything was complete.

This latter task requires the ability to not only build a board layout, but save and reapply it, since I don’t trust my ability to get everything set up all at once. To this end I spent a fair portion of my time checking into the sorts of methods that one would use to serialize/deserialize objects in JavaScript, without using JSON.

I have in my head the idea that the Segment class would have a method that returns something like “LB” for a Left Blue segment, “RR” for a Red Right, and so on, and another method that would take such a string and create a new instance automatically. More importantly, the bottle would have a method for saving and loading the contents of the bottle using a string of such specifiers, but using an RLE approach, so you might see “3xSB,14xE,1xV1B” to indicate 3 blue single segments, 14 empty segments, and a blue virus  (variant 1).

This does not jive with how everyone else would do serialization, which would be to use JSON. My idea is that a simple URL parameter would be used to set and load the bottle contents, which is more of a pain with JSON.

In any case, I left that aside after realizing that there is no immediately nice way to implement a generic method for this directly in the Actor class, where it would be inherited using a mechanism and signature I was happy with. This is probably for the best since more though needs to be put into this anyway; this seems like it would also form the basis of being able to save and load games in the general sense, so more work should go into the planning for this.

Instead, I modified the existing logic to not always try to drop. The drop code in the bottle right now is supposed to be for finding matches, dropping segments, and finding more matches, which is why it drops things at a fairly fast and constant speed. It’s not meant to be used to drop the capsule that the player is currently controlling.

As such, constantly checking for a drop is stupid. What would actually happen is that when the capsule the player is controlling comes to rest, we would check for matches, and then if any were found, see if anything can move, then find matches again.

So, this is now how the operation works. The new debug key ‘M’ checks for matches, and the space bar starts a drop operation. Together these will come in handy for setting up board layouts for debugging combo scoring and such.