Hey ** MaxTheVool ** don´t get me wrong, but since you asked the question, and I suggested some solutions (although I was wrong on some preprecessor replacement issues), I think you owe us further explanations Seriously, I am really interested in that.
First: How exactly do you expose your variables to the artists (in a debugger sense, as you implied)? With those weird macros you proposed? How does that expose variables to the artists? Why not spew out a lenghty trace of everything, with different info/warning/error levels, and maybe artist/programmer/supervisor ratings as well? That is always helpful, and from the output of a well designed tracer you can easily extract all sorts of helpful information, including performance data, with scripts or spreadsheets or other tools.
Second: I´m not convinced of your inheritance hierarchy (as outlined in the second paragraph I qouted). That seems, to me, like an abuse of inheritance. Sure, not everything is always textbook perfect. But why use inheritance, and not simply different objects, and aggregation? Using INT types to refer to different classes sounds extremly contrived to me, like inventing another type system instead of what is already in place.
Again, don´t get me wrong, but the more I think about your posts the more I get the impression that you want to work AGAINST to language, instead of taking advantage of what it offers.
Max, there is a solution to this problem as well as the static initialization order and I believe you even identified it early in this thread. Include an init() function for each file that has static variables. This init() function can initialize statics, register them with the debug database, and allocate a type-identifier. Adding new static variables to a file would only require a change to that file’s init() function. The only time you would need to change the main() file is when a new file is added to the project which is pretty rare.
True, but it doesn’t matter. There’s a single global instance of an object-manager class. It has a function that’s something like RegisterObjectType(). Inside that function it checks a static variable to see whether it itself has been initialized, and if it hasn’t, initializes itself. Then it doesn’t matter what order everything happens in.
Yes
Not by name, although I was familiar with the concept. I don’t see how it’s automatically a win.
No, although merging is always a pain. And it’s frequently more a case of touching a central .h file forcing a 250 file recompile instead of a 1 file recompile.
I’m not quite sure what you’re talking about about tracing. I’m talking here about a way to tune things on the fly, as opposed to a way to find bugs. Basically, there’s a function which registers particular variables with the debug menu so that they artists and designers can then have an interface to tune Player::fHitSpeed, or whatever variables the programmers decide to expose to them, with the variables mentioned by name, tuning parameters set, a way to automatically save the tuned variables out to a .ini file, etc.
Once again… what? We have a base entity class (EntityBaseClass), and many other entity types are derived from it. In a few cases, the tree is more complex (AIBaseClass derives from EntityBaseClass, various classes derive from it). What’s so wrong with this?
As for using INTs, that’s partly a holdover from the days when I was doing all of this in C using function tables and message functions, but it’s also quite useful at times. For instance, if the entity manager keeps lists of entities sorted by type, if the types are represented by INTs 0…n-1, it’s easy to keep an array of list, for loop over that array, etc.
Seriously, I am really interested in that.