Making up for the lack of actual coding done yesterday in lieu of researching and benchmarking, on Day 4 things have moved along at a brisk pace!

All of the classes now have appropriate (or mostly appropriate; time will tell, I guess) member variable visibility. Member variables are also now marked up with leading underscores so that they can be exposed with less ugly names.

Of perhaps more importance, the Stage class is now less crufty, although more cleaning is yet to come. The class itself is kind of long, what with it housing the rendering code as well as the game loop and scene management.

This has been partially rectified by splitting the scene management code out into a new class, SceneManager. Additionally a lot of static variables have been replaced with module locals. Effectively they’re still static, but since they’re captured in the closure of the module constructor, they have names that are less unwieldy  to use.

I was a little sad to discover that TypeScript does not allow partial class definitions. For the uninitiated, this is basically a way to declare the contents of a class in more than one file and have them blended together at compile time.

OOP purists automatically hate this based on the “you’re not using enough objects and your code needs to be managed better!” argument. However, having used Java for a while, I’m of the “Jesus, why are there so many god damn classes in this hierarchy?!” mindset.

In any case, TypeScript does not currently allow this, although maybe it might in the future. For my purposes I would really have liked to split the Stage class into at least two files to make the code easier to grok, since the rendering code is in there and makes the file longer. Sadly, this is not to be. So, some more work will need to be done here.

I’m not sure yet exactly how I will accomplish this; I need to think on it a little bit. The easiest thing to do would be to create a new Renderer class of some sort (bonus: it would also allow swapping rendering back ends out). However all of the API’s currently assume that you can get at the renderer through the Stage, and so I’m not sure if the Stage should hold the renderer instance and pass it out or if the API’s should change in other ways.

I think that would lead to extra cruft; either the Renderer needs to have knowledge of the stage dimensions, or objects need to have references to the stage AND the renderer.

I’m going to try to think of that while playing a little bit of Neon Struct tonight, courtesy of the latest Humble Monthly.