It’s been a few months since I’ve posted, but I’ve had over a hundred code check-ins since then. A quick round-up is in order:
For the first week after my last post I was debugging, performance tweaking and refactoring a lot, trying to cleanup some code and get the system to behave more like I’d expect as a user. One of the major “new” accomplishments from that week was getting the spider to climb on the ceiling, and before two weeks were out, climbing around corners and fixing some client window issues.
Early June had some fixes to the workshop (and support functions in the core) for room editing and light propagation through room links. The bulk of June into early July was working on movement-related things such as multi-step movement targeting which involves picking a cell in the distance (using target selection) and moving towards it with a single UI command; as both an alternative to single-stepping, but as a requirement for overrun and tumble through (as well as jump). I basically had to rework the single-step movements to be a “degenerate” case of multi-step to get the whole system to be relatively streamlined.
June also saw the beginnings of my refactoring for VS 2015 (using the Community Edition Release Candidate).
By about July 26th I was experiencing a small amount of movement burnout (since I still hadn’t completely worked through overrun, tumble and bull-rush like I intended, let alone jump, run or charge). And moved on to some other things.
D = 500 (in Roman Numerals)
A change to ITrackTime interface (and implementations and usages) so that a distinction can be made between the “beginning” of a time-tick and the “end: of a time-tick. Basically I want some things to happen as the time is changing to something else as opposed to when it is changing from something else. Ah, prepositions!
Been a while since I’ve just worked on some coding. Kickstarter preparation has been absorbing my time.
Anyway, I want to build a model construction utility, and I want to be able to save the model setup state (not necessarily the final models, but them too) in a package file. However, I don’t want to (be required to) include the whole Uzi.Ikosa assembly where the packaging code currently resides.
Thusly, I begin a refactor process into a new assembly. Untangling the dependencies will be “fun”, since I’ve got a helper class to load related parts as their strongly typed object instance.
Problem is all those classes are defined in the assembly I’m abstracting the code away from. Hence, a factory pattern and a registration mechanism (complete with [static, for now] factory registry).