This is a relatively simple platform engine that operates at like 5 frames per second. All movement is
done in chunks. Really, the only secret here is that you need to know what color player/box is querying
each cell, and what the results mean. For instance, a black player can move into a white cell, but a white
player can not.
This prototype was created entirely in a single day, and as such, was written with reckless disregard
for "the right way of doing things". I'd write a function for black to move right, then copy and paste it
for white to move right. Then copy and paste again for black and white to move left. There's a lot of
redundant functions. But the goal of Three Hundred Prototypes is to make prototypes as quick as possible
(better a finished piece of crap than an unstarted masterpiece), so don't judge my code.
The levels are saved as ASCII strings, but the levels themselves use rectangular tiles that are half an
ASCII tile. Why did I do this? Because I didn't plan ahead. It worked well initially when I was designing
the levels by hand - but once I created edit mode, I discovered that this approach does not work well with
an objects that exist at the half-step. Basically, no objects, players, or flags may begin at a half-step.
Pretty much all edit functionality was an afterthought of an afterthought, which is why it is so unpleasant
to use. It's fun to just hammer at something until it works, but the abominations it will create... Anyway,
my point is mainly that this code may be okay to learn from, but never, ever use anything even remotely
like this crap for anything you plan on releasing. Who knows how many bugs lurk beyond the edges of the