- Do some memory management. I'm doubt all dynamically allocated objects are being cleaned up properly, especially all the GUI-related classes, which aren't really destroyed anywhere yet. Oops.
- Decouple the source files by un-inlining methods. The OO architecture is reasonably decoupled, but the source files aren't. This is because most of the implementation is contained in the header files as inline methods (it's so much easier to maintain and modify that way, like in Java), and as a result a lot of the header files depend on each other. Also, I'm betting header and source files are probably including files that they don't even need. As a result, a minor change to any file usually means recompiling a majority of the program's source.
- Enforce
const correctness. Currently a lot of methods that should be const aren't, and contrary to my disinterest in this whole const business, there are instances where it's useful (see the CComponent::get_absolute_bounding_rect() method, for instance, as well as the C++ Annoyance in Testing::add_components()). And of course, making one method return a const object usually means making lots of other methods accept a const object and defining methods on that const object as const. Phew.
- Make pointer/reference method parameters consistent. As Bruce Eckel mentions in Thinking in C++, pass-by-reference should only be used when it's a
const reference; otherwise pointers should be used. Right now it's a completely mixed bag. This also goes hand-in-hand with enforcing const correctness.
- Implement exception handling. I've heard from developers that using exceptions can severely impair a game's performance, but this could easily be an old wives' tale (it seems like a lot of what many game developers say about efficiency is actually entirely untrue and not perceived as such until someone actually makes a fast game using such "slow" techniques). At least at a higher level of abstraction (i.e., low level of granularity, assuming 'granularity' means what I think it does) I doubt exceptions would impair performance, and I'm pretty sure exceptions are used in the very-cool-looking OO framework Tim Sweeney designed for the Unreal Engine, which has always thrown me very OO-like unhandled exception stack traces whenever it crashed on me.
- Add a flyweight pool that manages resources. Currently the CGame object implements the CGame::get_font_small() and CGame::get_font_large() methods, which really don't belong to it--these belong to the resource management arena, which isn't represented at all in this framework.
- Rename CEventSystem to CInputSystem. This will require the renaming of a lot of supporting classes, but it needs to be done, because
CInputSystem is much more descriptive.
- Improve the rendering algorithm. The current dirty rectangle algorithm is extremely inefficient; it just uses the STL list's
unique() method to remove consecutive duplicated rectangles, but it doesn't check for overlap or do any merging/differencing of rectangles or anything like that.
- Implement a scriptable finite state machine framework. Originally, this is what I really wanted to do with this project, but I was too busy with the multimedia abstraction layer and the GUI foundation. I'd like to use SWIG to interface with an embedded Ruby or Python interpreter/VM to provide for a robust OO version of the kind of procedural FSM framework I developed in my Pman project. The processor-intensive tasks, such as the physics system, could be handled by the C++ code and the scripting language FSM code would only be called for events that happen infrequently, such as when an enemy AI sees a player. My basis for this would be the UnrealScript language Tim Sweeney created for his Unreal engine.
Generated on Wed Aug 27 11:59:27 2003 for GFW by
1.3.3