Working on OctoberProject, I noticed an odd bug where it is possible to pass through solid objects if you are moving quickly enough. It turns out that this is due to the ugly hack that is my movement logic. At the time, I didn't want to figure out a good general collision system so I just hacked up something based on a bunch of special-cases in order to give me the right behaviour in the early cases.
Now, more recently I needed to implement a proper DDA ray-cast algorithm for block selection in OctoberPeaks so I think the path forward is to adapt that into the basis of movement collision logic in the core logic engine. This should work, and not be too ugly (just ray-cast the 8 points around the prism and take the smallest ray length), but I do wonder if there is a better way.
Much of this thinking comes from the realization that, once OctoberSkies gets going (probably in 4-6 months), arbitrary cuboid collision starts to become a bigger requirement. In that version, the world won't just be a single space where blocks are fixed and entities move, but where everything is considered a collection of blocks moving relative to each other (part of why vehicles and projectiles aren't a thing in the current version - I am anticipating generalizing this idea to support them). This is also much of the reason why the system is based on cuboid octrees extending in all 3 dimensions, without limit: The octree structure may be useful in recursive collision evaluation.
So, I am unsure if I should just do this adaptation, now, or spend more time looking into ways to reconsider the collision logic in a more future-proofed way. I will probably peruse some possibilities, to make sure I am thinking about the problem space correctly, but will most likely use this simple adaptation since over-design or preemptive design usually don't work out.
We will see but this does mean that the next release of OctoberPeaks will be largely about bug fixes and under-the-hood improvements (aside from having some things like damage feedback, etc),
Jeff.