timmy gerlach - 9/29

No major coding challenges this time around, save for (A) trying to figure out UI stuff (currently on hold because it wasn't needed for the core gameplay improvements), (B) trying to work with a broken laptop screen (my standard mode of working for a couple days: pushing the screen up against a wall), and (C) motivating myself to actually do the work that was in front of me like god seriously timmy just focus on the code it's not as hard as you're making it out to be

Work for Tuesday mostly consisted of rewriting the Judge class - the first iteration only worked after the level was completed, scanning the user-generated bars and comparing them to the image below. The Tuesday build, in addition, made a comparison every frame that the player held the spacebar. It worked decently, but it had some absolutely weird problems - I still can't figure out how it judged "perfect hits".

notice i was talking about the stupid tuesday judge in the past tense

That would be because the Thursday judge actually works and is pretty neat. Instead of trying to get a "perfect hit" by looking at how close the player was to a change in color, it uses collision triggers, which are quickly generated from the initial barcode image with a little script.

The arrows are debug images for the collision boxes; they don't appear in-game.

The width represents the "grace period" for a Perfect.

Perfect hit feedback hasn't been implemented yet, but now we can actually make it, so there.

Oddly enough, none of the other guys mentioned the changes that got the biggest response - the new braking mechanic and music. But while they were good design decisions, I won't say much about it either because it wasn't much in the way of code so :P