Choosing the unit and questionable code design by exhaustion
I took what is to me an unconventional decision early in this project. The "scene" is a 1x1 board. By 1x1 I don't mean 1 tile, though, but a continuum (well, a floating-point interval) between 0.0 and 1.0. Due to the fact that I'm going to be designing mostly views to the map, it makes it easy for me to reason about how much space I want a thing to take when a 0.3 means always 30% of the length or height of the map, rather than 34, 67 or 103 tiles being the same. The oddity here, being that the player will have variable size between levels, and the player's level will indicate how big the level actually is (his speed is defined as a function of his size, so it still works)
The trade-off here is a loss in precision. I could be the case that dynamic entities' movement get visibly distorted due to floating-point operation updates, but my expectation is that the views you're going to get to the levels are going to be unclear enough that such imprecisions won't be noticeable. At the very least, I hope that they won't introduce game breaking bugs.
Today's work was establishing diagonal movement and reworking of the dynamic entity to wall collision detection and handling. I initially produced a bogus diagonal collision, so I thought of restricting player movement to 4 directions. After some sleep, I was able to think more clearly and adopted a lazy approach drafted from some ancestral memory. The code is not particularly beautiful, but it works.
I also got started with the concept of a Matcher. It's basically a filter of entities in the scene/level, allowing the view to select a subset of entities to describe. At the moment I'm suspecting that a better approach would be to assign a subset of views to each section of the screen and cycling through whole views, but the idea of cycling just through matchers might still be viable. Let's think about this again tomorrow after a good rest and an exhausting day at work.