In my engine’s design, an entity by default, when inserted to the scene will be processed normally but nothing will come out on the screen. The renderers (called drawers in my engine) are individual modules that can be attached on any entity and are responsible for visually expressing the entity’s data. How that data will be represented on the screen is up to its drawer. For example a customized “Hero Drawer”, when attached to the Hero entity, could alter the rendering procedures to any extent (from changing colour to complete geometry deforming) depending on any of the Hero’s variables, like his hit-points. Then you can take that drawer and attach it to any other entity and you’ll have the same output on the screen.
The completion of the implementation of the above design in my engine today was one of my biggest achievements in programming. Not only because I’ve spent the whole night yesterday thinking and drawing down the design and then successfully implementing it today but also because of the cleanness and safeness of my code so far.
The other thing I’ve done was the resource manager. It can be called from anywhere, load any kind of resources and deallocate them when they are not needed anymore.
For all of the above, Boost library’s smart pointers came extremely handy. When I was stuck with the technical aspect of my drawers design, they came in and saved my life. Memory leaks can be extremely annoying at times and every time I’m running my program I carefully check at the end if there was any memory that wasn’t deallocated normally. Smart pointers are WIN.
I’ve also created part of the camera manager and the camera classes. It was much easier than I thought to use the DXUT camera classes. In fact the implementation in the DXUT camera is almost similar to the one I was using in the previous versions of my engine so everything is quite easy and makes perfect sense. After all there are not many ways to code a camera.
I keep growing up the entity manager (scenegraph) and in the next few days I’ll probably start working on its fourth layer, which is the physics. This will probably take a few days at least since there is the collision detection and response involved, one of the hardest topics in games programming.
Then of course it’s the fifth layer which is the entity control and AI. This step will get really hard later when pathfinding and decision algorithms come into play. Blizzard has been fine-tuning this very layer for Starcraft2 and Diablo3 for many years already. It’s actually what it takes the most time for creating games today as all game’s mechanics are represented within this layer. I hope mine will take no more than one month because I’ve got a LOT of networking code to write too!
