The path to v1.6

Sometime last month (or was it September? I’ve lost track of time…), I undertook a large engine refactoring task. After a few weeks of intermittent work, I had a 73-file changelist that didn’t compile and would have taken a good deal more work to finish. I made a local copy of the changes and then reverted them.

A couple days ago, I began this refactoring process a second time, but with a couple of clear goals to avoid another disaster. I would keep my changelists to a minimum, changing one thing at a time, and resolving any issues it created, and insofar as I were able, I would not make changes that would require me to rewrite large amounts of game code, unless the rewrites were to simplify the implementation.

So far, this is going well. I’ve implemented the concept of instanced renderables without requiring each renderable to be instanced, so existing code can remain intact. The next step will be to implement a system by which things which set shader parameters can defer to other things which set shader parameters. In this way, I’ll be able to decouple the renderable from its physical state. This will in turn allow me to move the renderable and the physical state each into its own component. The collision code I wrote for Antikythera and later brought over to The Understory is already built in a way that should be conducive to an entity/component model, so I don’t anticipate much work there.

Once I have the visual and physical elements split out into components, I should be able to deprecate my old “world object” class. This class was derived from the renderable, but it also contained physical information, as it was necessary to have these elements localized to the same object in the past. I don’t intend to delete this class, as many of my existing projects depend on it, but it will no longer be the correct supported path for game objects in the future.

I’ll need to revisit some changes I was making to the component-based entity system in my local copy. The version that’s checked in is mostly a stub; I had done some work to improve the interface for creating and accessing components. One of the issues I’m still looking into is whether I want to allow entities to have more than one component of a given type, as this could cause ambiguities if I try to get components by type.

I’ve been working on most of these changes in Drome, since that gives me a decent amount of test cases so I can make sure I’m not breaking stuff, but once I get into the new tech that won’t affect old projects, I’ll probably switch over to something else. I’m kind of liking the idea of a simple platformer…

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>