Implementation notes

I just wanted to say Ikaruga is a great game.

----------------------------------------------------------------------
0. Concept

Ikaruga really is a great game, and it's still a great game 20 years
later.  I wasn't any good at playing Ikaruga, although I do enjoy
watching people play it, and Ikaruga just happens to be on my mind
when TRICK 2022 was announced.  What I was playing at the time was
this snake game, which I wasn't very good at either (I just wasn't
very good at games in general), but the two dots connected, and I
decided to make an Ikaruga clone with snakes.

----------------------------------------------------------------------
1. Threaded input

The snake portion of the program was fairly straightforward, the part
that was giving me the most trouble was the asynchronous input.  I
have been working with a proper game engine at the time where I could
process key down/up events exactly at frame boundaries, but the
default libraries distributed with Ruby didn't seem to have anything
like that.  In the end, I had a separate input thread writing to a
ring buffer while the main game thread pulls direction changes from
that buffer at whatever frame rate the operating system wants to give
me.  And I had to make sure that input thread eats the last keystroke
before exit.  It was a mess but it works.

All other attempts in trying to capture at most one input per frame
did not work as well as the ring buffer, but in the process of trying
to make those work, I built a suicide protection scheme that made the
game more lenient, so that turned out to be a fine feature.

----------------------------------------------------------------------
2. Optimized output

Initially, I had the game redraw the entire screen on every frame,
which enabled a glittering effect on the items that were kind of neat.
I thought it was a great idea despite the program writing gigabytes of
text to the console, until I tried testing the program over SSH, where
the excessive network bandwidth usage was definitely felt.

I could have just documented this and said the game must be played
locally, which might seem justifiable for graphical programs but not
so much for a console program.  In the end, I removed the glittering
items and made the program draw only the few dirty pixels on player
movement, which greatly reduced bandwidth usage.

I did spend some extra effort to keep the glittering chain statuses
though, I thought we needed at least that bit of flair.

----------------------------------------------------------------------
3. Golf

After ~2 weeks, I now have a reasonable game with ~24K of code plus
comments, the final step was to golf it down to ~2K of code.  This
final bit took only ~4 days (during a long weekend), but it took the
most effort.  The bulk of the 24K was obviously comments and spaces,
but there were also some features that I could part with.  After all
the trimmings and renaming variables, I ended up with ~2.6K.

That last ~600 bytes was exceptionally difficult, I tried to compress
this via plain dictionary substitutions, because I know I can write a
relatively small decoder for that.  But after ~2 days of it, I just
couldn't get it below ~2.1K.  In the end, I resorted to zlib again.
The deflated and uuencoded code came in at 1999 bytes.

----------------------------------------------------------------------
4. Finally...

I didn't want to just submit a blob of code, so I drew a spline and
called that a snake, and fitted the code to it.  It seemed alright.

I am glad the program worked just fine on all the computers I tested
it on.