Except than improving the debug information rendering performance by tweaking how the formatted strings are actually converted, I’ve added unicode support to the engine. Since the game is going to some Korean and probably some Japanese developers, I thought it’s a good idea to implement the unicode support now. My plan is to translate the demo to Korean and Japanese and unicode was the only way to go. Now I can format then render any kind of unicode strings.
Then I’ve coded some low-level scene graph components, this time in a much more efficient and safe way than the previous versions of the engine. Before the scenegraph tree seemed to work fine but that was because I’ve only had one level of depth. Now it supports many levels of depth and moving nodes around works like a charm not just functionality-wise but also memory, safety and performance-wise.
Next it’s the drawing interfaces. The idea generally is to create a series of customizable drawers attachable to the object nodes. This way the actual object node will be independent to its drawing functionality. This is not really about making the hero look like a monster on-the-fly although that will be possible. Supporting all kinds of different drawing in a separate module than the object allows for easily creating high-level drawers without having to mess with the low-level components. If for example I want my hero look like a square box, I can create a drawer doing exactly that and then attach it to my hero. Then maybe later I will decide that I want a 3D mesh instead. No problem, I’ll just write a mesh drawer and attach it to the hero object. This will become extremely handy later since I’m not planning to create meshes for all my game objects. Especially in the prototype most objects will be rendered as squares and trust me this is so much cleaner than what I’ve had before.
Then a resource management will be coded so all kind of resources are controlled by a single manager and automatically deleted when not needed anymore. If for example a drawer asks for a texture to be loaded, the resource manager is responsible for giving a pointer back to the drawer whether this was a new texture or one already created. When the node that uses the drawer is deleted, the texture reference count will be decreased. If the reference count reaches to zero then the texture is unloaded from the memory.
Another important thing is AI and input. Why do I mention these two things together? Because they are exactly the same thing. It doesn’t really matter how’s controlling; the same series of commands will be executed anyway. AI be will implemented in a similar fashion to the drawer. There will be a control module attached to an object on runtime. That control module can actually be anything including user’s input and all kinds of AI like a state machine or a neural network. This way the hero can play on his own or the monsters can be controlled by the player. Might sound like useless but this allows for a range of nice tricks including support for the player to easily play along with AI controlled heroes. And of course allows for easily testing and tweaking the AI. This nice control module approach (that most serious game engines use anyway) is nicely described in AI Game Engine Programming by Brian Schwab.
That said, before any AI or input implementation, there are still the cameras that needed to be implemented. I could paste in my old camera code right now and it will work fine but as I said yesterday I would rather doing it using DXUT camera functionality this time. Hopefully it shouldn’t take more than one day.
