This question is sorta half-programming, but half design related too, because it raises a design consideration that may or may not be pointless. I was thinking about how a lot of the things in my game are user modifiable. I''d like the player to be able to design just about all aspects of the game via a built-in game editor using a script engine (I''m boning up on Python now...damn what an easy language, too bad it''s slower than Java). I thought that it''d be a good idea to store these files in XML files that configured things like units, military organization (Cluster and BattleGroup designations), and even nation design. What worries me is if it''s a good idea to allow this or not. The nice thing is that it allows easy sharing of data so that players can trade designs around. The bad thing though is cheating. I suppose I''d have to create a parser that validates the XML files (perhaps instead of seeing the XML files as a descriptive-content model, it could be a sequence of steps...a recipe to build the object through the script engine...ie, using the XML config file like a script itself run through the scripting engine), otherwise the player can bypass the Game Editor design rules that build these config files. For example, most of the Unit objects have private variables that can only be set by the public methods of the class (and the parameters passed into these accessor methods are put in through the Game Editor). So it seems like there''s a potential loophole here. I''m not very knowledgeable about XML parsers, so perhaps there''s a way around this, and this whole point is moot. But I do wonder about the cheating aspect, and if there''s a way to "validate" the XML file. I do know enough about XML to know that DTD''s only validate the structure...not the content. So you could have a perfectly valid XML file that passes validation against the DTD, but when the game runs the XML config file, it could override the private member variables. I heard Schemas can somewhat validate content, and not just structure, so maybe this is a way out. This also begs the question in general...is it good to have such "open" configuration files that directly manipulate the characteristics of things like units, Commanders, and other items which could have good "cheating" potential? I guess since my game will be open source, someone with enough programming savy could easily change the script engine "rules" to build whatever units he wants....which in turn brings up cheating concerns about open source games in general. Any thoughts?

quote: Original post by Dauntless
I heard Schemas can somewhat validate content, and not just structure, so maybe this is a way out.

That is correct. Schemas can let you dictate in a very precise way exactly which values are acceptable in a value or in an attribute. These are some of the things you can do:

* You can specify that an attribute has to be numeric and within a specific range.
* You can specify that a value has to be in a set of enumerated values
* You can specify that a value has to match a regex.

And of course, it also restricts the logical structure of an XML doc, just like a DTD does.

See W3Schools XML Schema tutorial for more details: http://www.w3schools.com/schema/default.asp


"Laughter means distance. Where laughter is absent, madness begins. The moment one takes the world with complete seriousness one is potentially insane. The whole art of learning to live means holding fast to laughter; without laughter the world is a torture chamber, a dark place where dark things will happen to us, a horror show filled with bloody deeds of violence."
-- Jens Bjørneboe

quote: Original post by Dauntless
(I''m boning up on Python now...damn what an easy language, too bad it''s slower than Java)

Don''t rule it out because it''s "slower" than programming language X. Does it do what you want? Does it do what you want well and correctly? Does it do what you want fast enough? Then you have a winner. Bleeding fast language performance isn''t necessary for the vast majority of code in most programs; good algorithm and data structure design make all the difference. And when you do do language comparisons, remember to compare equivalent services (like the fact that Python is dynamically typed yet strongly typed).

Anyway, I think the XML config is a good idea. It gives the end user a lot of flexibility in how they choose to create resources, which is often critical to creating community (mods give a game tremendous longevity; make as much as possible essentially open). Cheating isn''t an issue except in online multiplayer games, because cheating against oneself isn''t quite as satisfying (like finishing Doom using IDBEHOLD etc), and in online games you can validate user configs against an online schema.

Using XML configuration files gives a natural hierarchical organization to data, yet could potentially (if well implemented) give the user a lot of flexibility in terms of defining the organizational structure of their forces - which I know is big to you.

Go for it!

A while ago I looked up XML as a scripting language. Pretty much everything I read said that it was rather redundant (which I agree with, if you''re doing it according to the xml specifications) and that you''re file sizes would be huge if you included a lot of info. Even INI files seem rather large to me, but I suppose if you''re not including much in your file xml wouldn''t be that bad. It really all depends on what you need it for.

quote: Original post by Dauntless
What worries me is if it''s a good idea to allow this or not. The nice thing is that it allows easy sharing of data so that players can trade designs around. The bad thing though is cheating. I suppose I''d have to create a parser that validates the XML files (perhaps instead of seeing the XML files as a descriptive-content model, it could be a sequence of steps...a recipe to build the object through the script engine...ie, using the XML config file like a script itself run through the scripting engine), otherwise the player can bypass the Game Editor design rules that build these config files.

But, if you''re worried about cheaters, then you''d have to do this for any format, not just plain text ones or XML. eg. The Baldur''s Gate File Format Hacking Project shows that people will reverse engineer proprietary binary formats if they have to. So this is no reason not to use XML (or INI files, or any other ''plain'' format).

quote: But I do wonder about the cheating aspect, and if there''s a way to "validate" the XML file. I do know enough about XML to know that DTD''s only validate the structure...not the content.

Yep... just like any other data storage format. I don''t see why it would be any trouble to simply check it once you''ve loaded it in. After all, your program will contain routines for ensuring the validity of units created from within the game, so why not re-use those in the loading routines?

quote: This also begs the question in general...is it good to have such "open" configuration files that directly manipulate the characteristics of things like units, Commanders, and other items which could have good "cheating" potential?

Perhaps some players will enjoy your game even more if they are able to cheat? Maybe let them have a checkbox that allows them to decide whether they just want legal units or not.

quote: I guess since my game will be open source, someone with enough programming savy could easily change the script engine "rules" to build whatever units he wants....which in turn brings up cheating concerns about open source games in general. Any thoughts?

With a disassembler, all software is open source. Seriously though, I don''t think there''s much you can do about it. You can use certain trust mechanisms if running a multi-player game, but at home, let them do what they want; they will, anyway.

(PS. Make mine another vote for Python - you can always replace the slow modules with C++ ones later, with no changes needed to the rest of the code.)

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

I agree with most of the comments. My personal opinion:

As far as config files for a game/ level/map data - XML is as good as any other format. The question is, as Oluseyi says – does it serve your needs? Are you ready to learn how it works? Do you want to add another component to your software (an XML parser) and handle all it’s moods?

The thing is - XML was designed for a purpose of easy and standardized exchange of information between diverse systems worldwide. So what other game will need your data? Chances are - if you play the same game – no other game will use its data – so what difference, which format your level data is in?

If there would be some project to build different game which needed the same data format – that’s a different story.

As far as cheating - well you don''t HAVE to store ALL the data in XML - use another file/format for your score/resource etc data.

Good luck


... no magic ... just coding

I was just browsing through some XML stuff and came across entities, which can be binary data. So this should alleviate some of my concerns.

But all the points are well taken. If someone wants to cheat, they''re gonna cheat. It''s just that since my game is so open, it makes it incredibly easy to do so if someone wanted to.

The last point is a good one. I thought that if I put it into XML then people could browse through the file fairly easily, even with just their web browser. In other words, you could put the XML files up on a webpage, run it through XSLT to transform it to easily readable description of what the config does, and then download it. That way you can see what it is before you download it.

Actually, XML seems kind of nice in that it''s almost self-describing. Of course, you need the DTD or schema to validate it, but it is kind of interesting and lends itself to OO programming pretty well. And for laymen who are browsing the files via the transformation through XSLT, it will be very intuitive. The elements and attribues should match up fairly well to data variables and classes...though the layman need know nothing more than when he reads a description like the following:

Weapon: 125mm Binary Propellant gun
Tech Level: 8 (advanced)
Type: Chemically Propelled
Receiver: Auto Loader, 40 round internal bin
Rate of Fire: 12/minute
Max Charge: 25k Joules
Effeciency: 70% (excellent)
Max Round Weight: 20kilos
Maintenance: 6 (Average)
Mass: 130kilos
Volume:
Cost: 100,000 credits
Accuracy: 7 (good)

Ammunition: 125mm APFSDS
Type: Kinetic
Mass: 10kilos, Sabot, 15kilos total
Damage: 14 (very good)
Penetration: 800mm@1km
Accuracy Modifier: +2
Max Range: 8km

To me, this is more interesting than downloading something and not really knowing what you''re getting.

Of course this will be the transformed document into HTML. But the actually XML file will contain the actual configuration numbers needed by the game engine to dynamically create the object. The same can be done for Organizational Lists to flesh out Clusters and larger BattleGroups, and even define National resources, manufacturing capabilities, and the like.

The Xml parsers that come with .NET are extremely useful I''ve been playing about them to store data for a BloodBowl team editor I was creating. If you''re worried about people editing your games Xml files you can do various things to make them non-accessable to the average user (though if they''re really determined theres not much u can do to stop them). Possible solutions include:

Having a checksum field in the xml file so unless the user knows the method of calculating the checksum the program can detect whether a file has been modified.

If you''re using .NET as your xml parser then you can use the .NET cryptography classes to really make them secure (this may be a bit over the top).

As well as using schemas to make sure your xml documents are ''correct'' (follow correct format) you can use them to define sensible ranges for values like Arild Fines said. That way you allow the user to play with the config but not make things to outrageous, except then they can edit the schema etc.

You could create something like a quakes pak files (an archive which contains many files) this allows you access to the xml files with a decent parser. This should stop the average user from changing things.

Hope this helps

Rahven

I think Age of Mithology uses XML to store some of the configs... check it out...

There is another huge advantage to using XML as the basis for a config system in a game. Extendability.

XML is wonderfuly extendable. If you devise a new attribute to something, you can easily add it to the XML data without breaking anything. In fact, you can read OLD XML data sets that don''t have this new attribute and not have the program break or perform strangely assuming you have sane defaults for missing tags. In a game, which is a type of software that seems to evolve constantly, this type of flexibility is wonderful.

That said, I wouldn''t recommend using XML for scripting purposes. While XML can form the basis of a scripting engine, it would be like fitting a square peg in a round hole. It''s simply not a good fit, even if you can pound it into submission.