I had a remark in my notebook, wrote a few months ago, where I felt it weird that some parts of the game engine would require a SpriteSet where they actually needed information about the level map, and that the SpriteSet class was actually the only object capturing the map pointer, as well as its dimensions.
I then realised there was several places in the code where you'd load a map from a file, and it was tricky to use only one of them because one is within SpriteSet and the other (in the level editor) has no use of such a SpriteSet. It was time to introduce a new class with informations about a loaded map. Refactoring things went pretty fine and I could even repair a few things thanks to the 'unit-testing' tools (and thanks to the 'watchpoint' feature of ddd).
Well, I realise that doesn't mean a lot. That's all I could craft since I'm on holiday, I'm afraid. Happy new year.
"load level1.map save test1.map load test1.map eq"
to check the level hasn't changed after being saved-and-reloaded (e.g. on-the-fly newmeta conversion produces the same contents as PHYS chunk loading).- by just passing "show" as the constructor argument to CommandHandler, this handler will be invoked whenever we see "show" on the command line
CommandContext.maps
is the stack of level maps,CommandContext.next()
provides one token from the command line, for both commands-to-handlers lookup or for command arguments.- it could be further simplified into a
void run(cc)
since we no longer need to communicate the amount of command line tokens we consumed.
I love how both the core loop and the handlers are elegant, although I'd have loved a more in-line syntax like
case "show":
or show=>sub { ... }
as well, but they wouldn't have worked in C++, would they ?
No comments:
Post a Comment