The page templates now include a link to the source code repository
for people that are interested in that kind of thing.

I'm setting up my own page for these projects that I will be doing, and
as a result I modified the template project that I'll be using.

This commit brings in those changes. Esssentially this is filename
changes, a new thumbnail image to use in links, and a change to the
"brand" portion of the navbar so that there is a link back to the parent
site.

I didn't notice until now that these got merged over; too many open
windows, I guess. They're not needed here.

Just as a quick change, when preloading if you provide the preloader
with a stage, as the progress of the update changes, it wll display
that to the stage to let you know that something is happening.

This is currently just a simple bit of text that says how many files
are left.

The code in the preload that handles the file being loaded or an
error removes the event handlers added to the image/audio tag at load
time.

This code was erroneously always removing the event listener for
"load" even though for the audio tag we actually were using a
different event, "canplaythrough".

This doesn't hurt anything, but if you're going to do something, you
might as well do it right, right?

We now catch errors in the preload using appropriate event handlers.
In the case that an image or sound cannot be loaded, a version from a
data URL embedded in the code is used instead, so that things
continue to work.

The replacement image is a red X in a box while the audio is just
short silence.

This was to check that everything that needs to be reset when a game
restarts is set. This was already taken care of due to the cleverness
of the code and a whole lot of luck.

One thing that was not being reset but should have been (but
everything works anyway) is the next capsule. This is fixed by having
the code that kicks off level generation select a new random next
capsule.

When level generation is complete, the generator calls dropComplete()
to kick off the game, which makes sure the next and current capsule
is visible, resets the drop counter, and then copies the next capsule
to the current one  and generates a new next.

This means that every time level generation completes, whatever the
next capsule is set to at the time becomes the starting capsule for
the next level, and so whatever was next would carry over.

This is not really that big a deal but this "fixes" it anyway.

Just as a little bit of extra "aural pop", a sound also plays when a
match happens that includes viruses that has a cascade length greater
than 1 (i.e. bonus points kick in).

After a bit of play testing it occurred to me that something missing
is the sound you hear as the contents of the bottle drop after a match.

In order to get proper code completion and documentation, we need to
specify that engine.d.ts is a library definition, so that the IDE
parses it into its internal indexes and uses it for code completion.

Surprisingly, this seems to just properly work.

This finishes up the merge of the new engine code in the Rx codebase,
which mostly just involves shifting the source code location from an
rx directory to a game directory.

Conflicts:
	js/engine.js
	ts/game/main.ts
	ts/tsconfig.json

This is something I meant to push into a previous version of the
engine but forgot; in the default game that demonstrates how things
work, when the stop button is pressed on the page, music and sound is
muted, and then un-muted when things are restarted.

Phase one of this is now complete; there are two tsconfig.json files
to compile each part to its own output file and both are included
in the HTML file.

I'm currently not doing anything with external build systems of any
kind (maybe next?) so the .d.ts file falls out inside the JS output
directory because the TypeScript compiler puts both in the same place
no matter what.

As a result, this means that the tsconfig file for the game has to
reference the file in that location, which is a little bit of a drag,
but oh well.

In theory if one was to have the engine be its own project, this
would be taken care of by not having the compiler generate those
files anyway.

Today's plan is to separate the code from the engine from the "game"
project and have them generate to separate files, with an eye towards
possibly just using the compiled JS output and a type definition file
in a project without requiring the engine source.

For this exploration I'm shifting the main code into its own folder,
which should maybe be done anyway.

Even if I decide that I don't want to work with this having no
typescript source for the engine in a prototype project (for example
I don't know if documentation comments will work in this case) I *do*
want to have the source build into two different source files to make
merges nicer.

There are now some sounds in the game scene: WHen the capsule slides
left or right, rotates or locks into place in the bottle, and when a
match is made (both with and without a vius).

We now have menu selection sounds in the title screen and game over
screen. Every time the menu selection changes or the selected level
changes (title screen), a sound is played.

This includes some tracks from imcompetech.com for music, showing how
there is a different song to play for the title screen, game screen
and game over screen. Each scene starts its music when it becomes
active and turns it off when it is inactive.

We also globally support muting via the M key. This uses the new
Stage API, which will toggle the mute state of all music everywhere,
so we just need to tell it the opposite of the current mute state of
our scene's music (regardless of scene) and have it do the Right
Thing (tm).

Lastly, the game page also mutes the music when you click the stop
button and unmutes it when you click the start button, because that
seems clever.

This merges the latest engine changes into the Rx Codebase and at the
same time removes the sample sound and music files that the engine
demo has.

The engine merge is really only needed because somehow even though I
rebuilt everything after yesterday's merge, the final commit still
managed to not have all of the changes. Le sigh.

Conflicts:
	game.html
	js/nurdzGameEngine.js
	ts/main.ts
	ts/tsconfig.json

So like, instead of using the loop state to determine if something is
a music, why not just add a boolean property? That way recurring
background sound effects (like a machine hum for example) can loop
but still be considered a sound.

Duh.

The demo now uses the new stage API's. It uses the stage to preload
its audio files, and then uses the new API's to toggle the mute state
of either music or sounds as appropriate.

The Stage class now allows you to preload sounds, music (and images
for orthagonality) and also register sounds preloaded or created
elsewhere.

We include a new API that allows you to change the mute state and
volume of all known sounds all in one shot, with the code treating
sounds that are looping as music and other sounds as regular sound
effects.

The mute property of the sound element is now exposed as a property
so that sounds can be muted if desired.

With the previous commit it seems important that unlike images,
preloaded sounds don't short circuit and return back to you the
previous tag that was returned when the same sound is loaded more
than once.

In doing this changing the volume on one would affect all (for
example), which is not desirable.

The Sound class is shifted away from the Preload.ts file and into its
own class file, and also has a bit of an enhanced API as opposed to
previously.

Now you can specifically request that a sound restart when you play
it or restart it, and the volume and loop can be adjusted.

The Music class has been removed in favor of just creating a Sound
instance that loops by default. It's a bit of a generalization, but
for game prototyping it works just fine.

Conflicts:
	js/nurdzGameEngine.js
	ts/main.ts

Let there be the ability to stop music from playing in the background so
that it doesn't drive you bananas while you're busy tweaking code.

This (kind of crudely) also mutes the sounds that play by adding a
property to the dot objects that indicates if they should play their
sound effect when they bounce or not, which is turned on by default
but tweaked to track the playing state of the music.

A better way to do this would be to have the Sound (and thus also
Music) class have a static method that makes the play method do
nothing when a flag is set (global mute), but this would require the
class to track all of its own instances, or at least music instances,
or toggling the state would not fully work.

That's outside scope for right now.

(Note: I guess it could also just exist and it's up to you to make
sure that you pause any playing music and sounds would take care of
themselves).

Now that the code supports it properly, the music for the test scene
is started when the scene activates instead of via a check in the
update loop.

First, the code in the stage that schedules a scene change no longer
immediately does the change if the game loop is not currently running.

Secondly, the property for telling you what the current scene is has
been modifed so that when the game loop is not running and you ask
for the current scene, if there is a pending scene change, you get
told that scene instead of what the "real" current scene is.

This allows code that wants to check for the current scene during
initialization to do so in a logically correct way while at the same
time making sure that the activating() method on a scene will not get
invoked before the preload (if any) is finished.

This allows us to ask the SceneManager class (used by Stage) what the
next scene will be. This is always null unless there is a pending
scene change scheduled; scenes don't change until we are told to
check for one, so that the controller doesn't change in the midst of
a frame update.

These accidentally snuck in while I was busy trying to figure out
what the problem was with my update yesterday to preload music.

This just fixes up the compiled output to be appropriate afte the
merge was done because there were enough conflicts that I was not
even slightly interested in merging them when I could just recompile.

Conflicts:
	game.html
	js/nurdzGameEngine.js
	ts/main.ts

We load the included music in the demo game and then start it playing
when everything starts.

There is currently an issue with this in that you can switch scenes
while the game is not currently running, but doing so triggers the
appropriate callbacks, which happen before the preload begins, so
anything in those methods that rely on pre-loaded content will fail.

This needs some looking into.

The previous code for preloading sounds has been extended to also
allow for loading music, which is just the same thing but in a
different folder.

There is now a Sound and Music class, which are just really simple
wrappers around the audio tag in preparation for later API
enhancements.

The Music class just extends the Sound class to turn on looping but
otherwise does nothing (currently).

I implemented the Scene.activating() and Scene.deactivating() methods
to assume a null parameter if none is specified. Realistically this
never actually happens but it was useful for some testing.

In any case, as a result of this, every time you override one of
those methods in WebStorm it generates invalid code that needs to be
fixed up by hand, which is annoying as all get out.

At some point I fixed the deactivating call but not the activating
call; this is now fixed.

The attribution text shows up in the about part of the page.