Free MMORPG Forums

Eriond

You! Get on msn sometime!

__________________

Eriond

===================== Entry 9 =====================

Well a lot has happened since I updated this journal a couple months ago.

I have stolen even more stuff from unreal (read: ideas, not code), and now I have a lot of code which is in the process of generating itself, instead of me doing it, though I'm doing in a different way than unreal (no separate definition files; everything goes in the header)

For example, take a look at an interesting sample class; in this case, a module.

Now, see what's different from a regular C++ class? It's all in the addition of two things; extra keywords that aren't present in the regular language (noedit, transient), and this line: REGISTER_SINGLETON_CLASS(Belt, Caelus::WorldModule);.

Essentially, these keywords are tie ins to the game's auxiliary code-generating system, that automatically generates code on the fly for each class that's hooked into it. Take a look at the file generated for this class, by the perl script that runs at compile-time:

This code is run as the game starts; essentially it allows all sorts of cool tricks that wouldn't be possible in vanilla C++. For example, each variable that's in the auxiliary system can be automatically saved by the system; no extra effort needed on my part; it'll go through all these variables and save the ones that aren't marked transient. Likewise, when we load up a game, it'll restore everything properly, including the pointers to objects that were deallocated on game exit, through an intricate serialization system (though one that does not have to be expanded regardless of how many classes are added!).

In the end, this means big time savings for any future developments, as everything is saved back in automatically to the class when it comes time for serialization.

Also, it gives us a way to create an editor system in game, by specifying which variables we want to let the user edit using the game's editor (using noedit); allowing us to keep variables that we want protected away from the user's grasp, while letting the vast majority of other variables be tweaked with various widgets that are appropriate to the type of variable (also generated by the system ,so we know).

Because there's only one instance of the information per-class (and not per instance), the actual RAM used to maintain the system is very minimal, even with a lot of classes and the vast majority of operations are usually one-off, with no time-constraint (saving, loading, editing), so performance isn't key; even then, things are still pretty good; and it's very very easy to hook things into the system, all they need to do is inherit from the class Base, or inherit from something that does inherit from Base, and use the macro REGISTER_CLASS, or one of its variants. That's it; super-simple, and throws in a whole ton of functionality at minimal cost.

Unfortunately the system grossly breaks when used with C++'s virtual inheritance (because the compiler has to juggle around class memory layouts), so you have to be careful about when you want to do multiple inheritance, but if you structure things properly, and make a few trade-offs, things stay simple and managed.

And of course, when you need speed and absolutely bare-bones minimal size (no vtable and the uint that the base class requires), you don't need to hook into the system at all; you can just use regular old C/C++ code that's not hooked in for areas of necessary high-performance.

Well, that's all for now, just thought I'd drop in an update.

__________________