This is the state of the project prior to any development being done for Devember.

This is the project code as of the end of the first day of Devember.

Some initial porting has been completed, with some internal code notes of areas
to focus on more once the initial porting effort is complete.

These should be turned into issues to track them better, possibly added to the
milestone.

This is the project code as of the end of the Tenth day of Devember.

This includes some object refactoring and engine changes. In particular the
engine now supports polygon rendering by way of an array of array of numbers.
The Point class can now return such an array instance of itself.

This is the project code as of the end of the eleventh day of Devember.

Here some small engine tweaks were made, and the Rx protoype now allows for pieces to drop
and horizontal and vertical matches to be made, including cascades.

More work is probably in order to tune this up a bit and make it less ugly.

This is the project code as of the end of the twelfth day of Devember

This is just a simple change which more closely mimics how the game would
actually operate in play; instead of a constant drop happening, instead a drop
would only be triggered after a match was found, and a match would be found only
after the player placed a capsule in the bottle.

The current drop mechanic in the bottle is for the cascade action, because it
always runs at a set speed. This is not the code that would be used to control
the drop of the player capsule in the bottle.

This is the project code as of the end of the thirteenth day of Devember.

The level editing code is tweaked a little bit to allow segment selection via
the mouse, and the start of virus population at the start of a level is in. It
is currently crude and incorrect, but it generates the correct number of viruses
in more or less the correct colors.

This is the project code as of the end of the fourteenth day of Devember.

We now populate the virus bottle with a set of viruses that does not immediately
cause matches to appear.

This does not fully match how this was done on the NES, but probably good enough
for now?  I'll have to see how I feel about it.

This is the project code as of the end of the fifteenth day of Devember.

The virus generation process is now pushed out to the game scene, so that the
viruses can be generated incrementally and displayed as they're building up. In
addition, the bottle counts the number of viruses left, and tells the game scene
when it reaches 0 so that the next level can start, which increases the level
and goes again.

Also the debugging logic has been fortified so that modifying the level also
modifies the virus count, which seems an important consideration now.

Except for scoring and user capsule movement, we're pretty much there now.

This is the project code as of the end of the sixteenth day of Devember.

There is now a Capsule entity which wraps two Segment entities and can modify
their colors and types based on its own type and orientation. The Capsule class
maintains its position in the bottle as its map position, and will update the
stage position when this is changed; changing the stage position leaves the map
position alone.

The bottle now provides an API to translate a point in bottle content space to
stage spage, which the capsule uses to set its stage position based on a bottle
position.

We're now poised to add user interactivity.

Oh yeah, and a slight engine change; since I had so many things counting update
ticks on their own, I went ahead and put that into the engine, so it just
happens now.

This is the project code as of the seventeenth day of Devember.

We're now ab out 90% of the way to a playable game. There is a capsule that
appears in the neck of the bottle. You can drop it down and rotate it. When it
can no longer drop, matches happen (if any) followed by cascades (if any),
followed by a new capsule appearing at the top.

Game over is detected by the inability of the capsule to drop into the bottle at
all because the neck is blocked.

This still needs some work; the input is all wonky and there is no constant drop
of the capsule; the only drops that happen are when the user specifically
requests it.

Still, progress!

This is the project code as of the eighteenth day of Devember.

Input is cleaner, and the capsules drop on their own now. Some more debugging
code is needed to slow or stop the speed of drops entirely, so that we can set
up and test for scoring and combos and stuff.

Also, the current code for the down key drops the capsule right to the bottom,
but it would be nice if this just sped up the drop speed, so that you can
advance forward without going all the way to the bottom in one hit. Perhaps by
temporarily forcing the drop speed to be a particular (small) value while the
key is pressed?

This is the project code as of the end of the nineteenth day of Devember.

We now communicate match information from the bottle back to the scene, which
can use that information to calculate and generate a score.

Currently the scoring mechanism needs more fleshing out; it just gives a flat
200 points per virus per match.

This is the project code as of the end of the second day of Devember.

The initial porting efforts of all classes is now complete, but more work needs
to be done before I consider this completely done. Some of the code is a little
dodgy in how it is written and can be cleaned up a bit.

In particular, there is a real hodgepodge of private vs public going on. The
initial code was all public and I implemented the new code as all private except
where absolutely neccesary. However the classes should be gone over and given
appropriate read or read/write access using property accessor methods.

I want to do some investigations to see if there are any performance
ramifications. Also I am rather unhappy with how the property accessor and the
actual property can't have the same name because I hate "warty" members.

This is the project code as of the twentieth day of Devember.

Today we add in a proper scoring mechanism, a toggleable debug mode, and a
mechanism to show a brief floating text to show you when points are achieved.

This is the project code as of the end of the twentyfirst day of Devember.

We now display the upcoming capsule to allow for better planning, and include a
simple game over screen when things go wrong.

This is the project code as of the end of the twenty second day of devember.

We now have a simplistic title screen which needs a bit more work. This code
needs to be made more generic for use elsehwere and possibly in other projects.

This is the project code as of the end of the twenty third day of devember.

This is the same code as yesterday, but refactored to have the menu code
split into its own entity class for reuse.

Additionally, thanks to engine changes all of the scenes are capable of
creating screen shots, not just the game screen.

This is the project code as of the end of the twenty fourth day of devember.

We now have a proper title screen menu for selecting the level to start the
game at, and a menu on the game over screen that allows you to replay or quit.

This is the project code as of the end of the twenty fifth day of Devember

Partial image preloading support is in, but there are some issues that I haven't
tracked down, so this is not yet merged with anything; images load, but the dot
sprites in the sample application don't move like they're supposed to.

Since it's Christmas night and it's been a long day, I'm leaving this for not.

This is the project cocde as of the end of the twenty sixth day of Devember.

The bug in yesterday's image preloading was traced to a bug in rendering that
would translate the canvas and then not restore it, which makes all rendering
seem to happen at the same location and has been resolved.

The Image preloading was enhanced so that when several requests for the same
image are made, they all return the same img tag instance, which saves a tiny
bit of memory for object references (I think) since the browser should hopefully
be smart enough to use the same underlying data for both anyway.

We now all support audio preloading, although currently sound is a little crude
in that you need to use the normal HTMLAudioElement interface.

The audio preloading also uses the same mechanism for returning the same tag as
the previous attempt if it reuses a URL, although this may not be the best since
any one audio tag can only play its sound once, so sharing it leads to sound
drops.

That will be fixed next.