I'm actually kind of torn between using virtual methods or passed-in functors here. One problem is that the entity Update() method doesn't have any context in the world, so it can't check itself for collision as it moves, or wrap itself around the map (because it doesn't know the width and height, so it doesn't know when or where to set its value to the other side). That's one of the reasons I'm starting to lean heavily towards a passed-in functor... I might actually do that, because it's the only solution that sounds sensible.
I'm also considering doing something with my MazeGen along the lines of splitting it into an object that actually comes up with the maze, and one that takes its output and converts it into entities. The latter might be incorporated into the World as another method... perhaps it could take a MapLoader* - MazeGen's parent abstract class - as a parameter. MapLoader's been pretty much unused, actually - just forward-thinking design - but this might be the time to use it. Hmm.
As a short footnote, my Keyboard class design - or more correctly, my keypress management algorithm - is growing on me, and I'm not even using it! I think, with tweaking, it could be used in a normal application too, though at high update-rates you kind of lose the benefits of the three-state: you're checking fast enough that with human reflexes the chances of a tap going unnoticed are slim. In Snipes, though, I've locked it at one frame every 150ms, which is ample time for a tap to be missed.
That's three topics there (plus a footnote): IDrawable, Entity update functors, and MazeGen abstraction/decoupling. Thoughts?
~Jonathan