Lord Zorinthrox

Join Date 12/2007

Can we make better XML Schemas?

Discussion regarding the XML Schemas of GalCivII

For those who aren't familiar with XML terminology, an XML Schema is basically an XML format; the specific tags and their structure in TechTrees.xml, for instance, is the schema for the tech tree in GalCivII.

My question to the modding community is "would a revised XML Schema be a good thing?" To Stardock, I ask "How much of a pain would it be to change/augment the schemas?"

Things I was thinking would be good additions while sifting through the GalCivII files (pure speculation):

-Replace the Weapon component tags <class></class> and <damage></damage> with <damage class = CLASS>VALUE</damage>, thus facilitating individual weapon components with multiple damage types. A similar change to Defenses would be appropriate as well. This would bring weapon and defensive components into parallel with starbase modules, which support similar attributes, though a alittle differently.

-Changing the possible values for the ResourceTypes tag <type></type> from the five deffault types to any of the total list of abilities that, for instance, Technologies can alter. Being able to mine resources that grant, say, a Speed bonus would be pretty damn cool. Of course, this would also create a need for another tag in ResourceTypes, namely <model></model> and <color></color> (or individual tags for Red, Green, and Blue). It might also wreck havoc with the AI...though they never seem too crazy about resources anyway.

-Since Terror Stars are starbases, but they can move one parsec a week, a new value for <StarbaseAbility></StarbaseAbility> that allows starbase modules to add movement to a starbase sounds feasible, unless this ability is hardcoded (would be a shame). This might necesitate a <MaxNumber></MaxNumber> tag, just so people don't have starbases moving at 10 parsecs. Dealing with Mining starbases could be accomplished in one of two ways: adding a possible value to <Type></Type> called "Movement," which Mining Bases can't use, or create a new flag <NotType></NotType> that excludes a given category of starbases. This would also require an arbitrary number of either flag to be a legal part of the schema.

That's all I can think of right now.

modding

Locked Post

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

kryo

Join Date 05/2003

+458

It's not really something that can be done, as AFAIK the tags that the game looks for are hardcoded. And it's a bit late in GC2's lifecycle to be changing that sort of thing.

Successfully updated karma reason!

agreed

Successfully updated karma reason!

Surely that is the case, but it is still an interesting thought experiment. Besides, how many studies/discussions are there on how to make a game easily moddable or what makes it easily moddable in the first place? Few companies are going to design from the bottom up with moddability a high priority; clearly Stardock had it in mind, what with XML files and such, but schema choices such as the weapon and defenses Class tags show some lack of foresight.

Even when a design team asks the modding community what they would like to be able to do in a mod, the answers are often vague, or merely a statement of obvious fact: "I want to be able to mod units" or the like. Though that is a useful guideline, the designers are still in the position of specifically knowing what will be in the game while the modders don't. It would be better to have guidelines on what makes a given interface for modding good and how to design it, versus what it should do.

The resources file is the perfect example: the game states blatantly that there is a fixed list of attributes that define the characteristics of a given race, some thrity or so. Techs can only affect these attributes or unlock building options. Resources give you bonuses, in the default game, to five of these same attributes. BUT, the definition file for Resources uses a completely different scale. Furthermore, it doesn't define models for the resources, leaving one to wonder why there is such an XML file in the first place if it was going to be hard-coded anyway.

Please read this constructively: including an editable XML file for a game feature that provides no real modding potential is, on some level, a lie. Ignoring the principle of consistency aggrivates modders: the expectation is that those attribute codes are universal, but clearly they are not.

That is the kinda of discussion I was going for. We can't, and Stardock probably won't, change what we have to work with. But we can say what about it doesn't work, and maybe that will do something eventually.

Successfully updated karma reason!

Conceptually - I think moving things even further from hardcoded features to XML schema would be great, it has certainly made this game a lot clearer and more self documenting than a lot of games, even those that were highly modifiable.

And frankly, I just think XML and sgml are cool.

That said - having expanded the svg schema a bit just for the purpose of generating keymaps (where those PDF's I uploaded came from - side effect of my playing with SVG) there is so much Stardock would need to document to figure out *what* they wanted to port from being hard-coded to the xml, unless frogboy opensources the bloody program (Filed under 'yeah, right' - {G}), it's incredibly hard to even posit what is doable and what isn't.

I *would* love for any GC III to be even more XML based - amongst other things, the use of svg for things like Icons and layout would be, imo, superior even to the very nice system they use now, properly implemented, but while I don't think there's anything impossible (or even highly implausible) about xml for any given thing, there is always going to be stuff that's a lot easier to simply code, and unfortunately we're not well placed to spot what those parts are.

Jonnan

Successfully updated karma reason!

Well, I think , it wouldn't probably be a good thing to implement ingame, since using xsd, all modders were forced to obey the schema rules, thus the gameengine would not be that error tolerant anymore as it is now. It even reads/or ignores invalid xml tags at the moment.

But its a different matter on that concerning moddingtools.

Generally, if you are interrested, the underlying dataengine of my new GalCiv2IDEII is in fact xsd based

Successfully updated karma reason!

If you are familiar with XML technologies, then you must be familiar with XSLT. This is a very powerful XML transformation language. So if you don't like a particular XML format, just write an XSLT to convert it to a format you do like. And if a program has to use the old format (like GC2), just write an XSLT to convert the new format back to the old one.

Problem solved.

Successfully updated karma reason!

Well thats true, but I doubt it would be that useful in a gameengine, if you probably want to have a strongly typed object holding some related tables, then it would not help you very much.

Sort of dynamic tables is not nice to have, if you need to retrieve data and you don't know what the columnname is, eg xml tag name. Ok you can always convert from string, but performancewise this could be a memory killer.

Successfully updated karma reason!