Neskiairti wrote:this may be completely naive.. but for maintaining.. wouldnt it be better to have a general 'bithandler' code.. and then use user/programmer friendly programing everywhere else... then feed that to the optimizer function? in the save file you wouldnt need readability.. only in the code and the user readable unit.csv (then use the same optimizer function for a unit.csv conversion) that way you can edit it plain text.. with a bit of extra syntax.. like.. keyword styled values
$(weapondata(some plaintext value, the next one, the next one, and so forth))
then it gets converted to the bitmask.. say 2 bits for what type of data it is.. then followed by the bit data.
this allows both maintainability and optimization.
You've hit the nail on the head. In fact, that's what I was really talking about. The essence of it is that optimizations don't really need to show at the interface. There's already bit array classes or something along the lines in the STL, which I haven't used, but I know it's there.
klauss wrote:@chuck: maintainance includes modifications. Ease of maintainance is also ease of extension, because at some point in the lifetime of any software, there are new requirements being introduced. What you have to ask yourself, is if having a bitfield pattern stored in an int (32 bits max) is more or less maintainable (ie: extensible too) than having a bitfield pattern stored in a struct (no size limit, some functional limits) (ie: extensible too), or than having an enumerated value (different limits, different functionality).
I don't have an answer. But it's the question you have to ask yourself and others.
Gottcha. So, let's look at it:
The problem of maintenance can be summarized with a question: What happens when we run out of bits? (That's assuming we use a DWORD for bit storage, as opposed to a bit array, which would grow automatically as we add bits.)
Well, let's begin with the class itself:
More bits means we've expanded the number of size categories, added more special equipment compatibilities, etceteras.
And that means new set and get functions, at the very least.
Thus, the interface of the class will have to change, no matter what we use as the underlying representation.
A function to test for compatibility of a weapons system with a given mount would also have to change; however, notice here that while a bit-wise test is easy to extend, and only necessary to extend when the number of bits used crosses an underlying storage unit threshold, fully coded tests as gargantuously long chains of bool tests &&'d together would have to change even when a single bit is added.
Outside of the class itself, the question is how does the type of class storage affect other pieces of code around the engine.
Here it should be obvious that the problems of code dealing with the class through its standard interface would be the same, regardless of the form the storage takes, as presumably the interface would be no different.
However, OO programming's interface abstractions apply to functions. Data is always a subversion of OO principles. Assignment, copy constructor, equality comparison, and other data-centric functions, have a funny tendency to expose internal representation.
Case in point, the big question is really about representation in units.csv, I strongly suspect, and gladly address: If we have to enter these weapon and mount compatibility fields in units.csv, what's the more maintainable way to do so? Units.csv is a funny thing, because each field usually contains either numbers or strings, and strings have their own representations. Each, in a way, can have multiple "columns" of info.
Now, if we follow the units.csv traditions, I guarantee you we'll end up with,
"0,1,0,0,0,0,1,0,0,0,0,0,1,0,0,0,1,1,0,1,0,0,0,0,1,0,1,1,0,1,0,0"
where each 1 or 0 has a special meaning, depending on its position, which can only be determined by counting bloody 1's and 0's.
But some will suggest that's more user-friendly than its hex representation "0x4208d0b4".
I disagree: I think a string generator app will be needed either way, and that, for some reason that elludes me completely, yet claims status as Fate, I happen to KNOW that if the "0,1,0,0,..." solution is adopted, such a generator app will NOT be forthcoming; but that if the "0x4208d0b4" solution is adopted, this will make such an app materialize almost immediately. And, no; I'm not joking. Besides, I find it easier to memorize a hex number than its equivalent strings of 1's and 0's, just as I remember phone numbers easier in decimal than in binary representation, if this fact matters at all.
Either way, there is no need for units.csv storage and run-time memory storage to agree; but for maintainability... It would be mind-boggling for the two representations to be different, which would put us in a difficult choice if their conveniences of representation were different. In this case they agree, IMNSHO: they both cry out for bit-fields at the top of their lungs.
This is not to say there may not be more serious issues in the representation: I'm not at all sure about the mixing of size-bits and feature-bits in the same bit array (perhaps having separate Size and Features DWORD's would be safer, more maintainable, as well as give us more room to grow), as I'm not
completely sure that generalizing weapon size slots across a galaxy is best idea, though I strongly suspect it is. Lastly but not leastly, different mods would put the bits to different uses, and this is the real big joke... Do you get it? Hint: Even in the same mod, the meanings of some bits could vary, such as bit N could mean one feature for race X, but a different one for race Y; just as we discussed the strong possibility that size 4 in our bit field might mean size 3 in military classifications but size 5 in civilian; thus our size slots are internal to the mod, and could be "interpreted" variously at the player's interface.
Well, the big joke is that all our class
IS is a storage representation of it knows not what, anyhow.