Working things out

Working things out before coding is important if you have a complex project that needs to be done, and needs to be done right the first time. It's also important in a general sense, but I don't do it that often.

Right now, I'm working out exactly how to handle units without classes. (It's significantly more efficient to do things this way in GM)

Basically, I can separate the unit functionality into four components:
* Data - this is inert, nonactive stuff stored in arrays that describes the unit in question. It is referred to, and acted upon, but never acts itself.
* Loops - this is where the simulation and the unit interact. This includes the movement loop (which is designed only to act on units that are actually moving) and various AI counter loops (which only act when needed).
* Grid presence - units will show up on a variety of maps and grids that help expedite AI speed. I figure I've got memory to spare (Especially on modern PCs - 8 gigabytes is middle-of-the-road nowadays!) and so I can use as much of it as I want, in order to increase optimization.
* Visual presence - Oddly enough, this is almost completely separate from the rest of the unit's "existence." When the player camera moves within range of a unit, a model is loaded and "synched" with that unit's data. It will follow the unit and act as a UI tool (if you click it, you select that unit), but is not otherwise linked with said unit.

The end result of all this complexity is this: A unit at rest, and out of range of the camera, is free. A moving unit, out of range of the camera, is worth two lines of code per frame, plus short AI scripts every 8-12 frames. A unit at rest, in camera range, is worth the polygons it takes to render it. A moving unit in camera range is worth that code and the polygons.
This does not take into account other forms of AI. Battle awareness and long-range pathfinding are both "heavier" scripts that I hope to offset by various methods.

Anyway, I believe that this is as well-optimized as I can make the unit system. I'm not quite so worried about buildings. And once the base code is in place, well... all that remains is to make a game out of it!


...Which reminds me, I'd do practically anything for the chance to separate the Ogre process into its own task, to run on its own CPU core. I wouldn't have to worry so much about optimization if this were the case. (Not to mention it'd be wicked fast!)


Finally, screenie time! This one shows off the forests ingame, as well as some nice reflections and a pretty sky in the background.