At the moment I'm using readable XML files for profiles and levels and whatnot in my game; I'm thinking that this is the easiest way for me to test things, and I can always add some form of encryption afterwards. Basically, I have all these little files with info like this: Code: <profile name="Karja" tokens="1"> <dog range="3" speed="3"/> <level id="1" score="2484" rank="5"/> </profile> and Code: <level id="13" name="Who's Afraid" info="...of the big bad wolf? The sheep are!||Bark at the wolf five times to make him go away."> <character id="65" x="290" y="278" w="16" h="16"/> <character id="100" x="562" y="324"/> <lose id="2" type="100" number="2"/> <win id="2" type="200" number="1"/> <rank score_high="4500" score_low="2000"/> </level> (These are just some examples; not actual files.) All along I've assumed that I'll be encrypting them once the game gets finished, along with packing them into a bigger data file. But then I was reminded of my mom when she played Zuma: the later levels were too fast for her, so my stepdad edited the level files to lower the speed. If he couldn't have done that, my mom would've stopped playing the game a looong time before she did. The ability to edit the levels gave her more pleasure from the game. So I'm considering leaving at least the level files open and readable; if someone is interested enough in figuring out what the different win/lose trigger variables mean, or wants to play around with how the characters and scenery is placed, why not allow it? And if I leave the file loading XML open as well, people can toy with changing the graphics and sound if they want to. (If I don't pack all the files into a big data file, that is.) (In fact, doing this means that the game would be almost completely moddable; it's just AI behaviour and such that's hard-coded.) In a similar manner, I'm even considering leaving the profile file readable. This in combination with the "rank" element in levels allows for cheating...but why should I deny a player the right to cheat if he wants to? Does anyone have any suggestions or comments on the matter?
Well, just a reduced number of player know xml programming, a few would want to mess with the files, this means its not for all the players, just a few would be able to change those setings, having that in mind you can ask yourself if you want a few players to be able to change the setup of your game, so if you want to give ALL your players the hability to cheat, you should think in another way of allowing this, i would say leave it as it is, it may add some fun for those people who like to mess with files...
I'd suggest leaving it all readable, but put a disclaimer somewhere that if they balls it up, you won't spend an hour on the phone helping them fix it. Some people like to poke around in this stuff and if they want to cheat, let em - it's their game. If they want to customise it, let them do that to - I'd even offer to put better alts into a sequel, or host them on a board or something - can't hurt to give players something positive to talk about.
Ooh, that's good to think about.. A little disclaimer is definitely something to include; maybe with a suggestion that they simply reinstall the game if they screw up. A readme file in the appropriate directory ought to do - it's just for the nosy people anyway! And yeah, I assume that there won't be many interested in messing with these things; it's just for the potentially few. But since there doesn't seem to be any reason not to, I'll just do like you suggest. Less work is always nice.. Thanks!
I agree with Applewood, they paid for the game, let them "cheat" if they want to. I myself (with the help of many others) have spent a lot of time tweaking the data files in EA Sports' NFL Head Coach, turning a mediocre game into a great one. Editing XML files isn't really programming, anybody who can edit a file in notepad can change the data. My game makes extensive use of XML files as well, and they are a godsend during dev/testing in addition to end user mods, but it's MUCH slower than reading binary data. My game converts XML to binary at run-time if the XML has been changed (it compares the timestamps of both files), giving me the best of both worlds. I also embed the original XML files into my executable as an application resource so users can easily get back to the shipped XML if they break something.
By the way, what would be a GOOD and SMALL XML viewer and editor? Doing it via a text editor doesn't seem the best possible option of all, intuitively.
All of my XML is used in conjunction with .Net XML Serialization (meaning my objects are converted to/from XML by the framework), and I don't actually write XML from scratch. I just edit the values, and the Visual Studio XML editor is more than adequate for that. I used XMLSpy back when I was doing XML in unmanaged C++. It might be "good", but I don't think it fits the "small" requirement.
Thanks Paul, I'll look into XMLSpy and the VS one (I use VC2005 but in command line form, not IDE, so I haven't peeked at it yet).