I often struggle with the question of when to use XML docs. Does anyone have a good rule of thumb when it comes to deciding to use them or deciding not to use them.

At the moment I am working on a project that has a lot of name, attributes, textures and even maps that are randomly selected when an object is created. Should I be harnessing XML here?

Thanks for your time!

  • \$\begingroup\$ What isn't clear here is XML docs vs. what? Is it "XML vs. hard-coded values" or "XML vs. JSON" or what? I would highly recommend putting as much of your game into external data files as possible; XML is one way to do that, but not the only way. \$\endgroup\$ – jhocking Mar 25 '12 at 20:34
  • \$\begingroup\$ btw the reason I asked for that clarification is because the two answers each appear to interpret your question differently, which means the question is too vague. \$\endgroup\$ – jhocking Mar 25 '12 at 20:58
  • \$\begingroup\$ I'd say you shouldn't use XML at all; often there are more comfortable formats such as JSON or YAML. \$\endgroup\$ – ThiefMaster Mar 26 '12 at 12:08

Short answer: when the benefit outgrows the effort.

Long answer: there's no long answer. You have to decide this yourself. You'll spend some time implementing, debugging and tweaking the XML system. Is it going to save you more time than you'll expend? Then do it.

Summing up: do I really need this part of the game to be data-driven?

| improve this answer | |
  • \$\begingroup\$ Appreciate the insight kaoD. Not had much work with XML so an outside view is most valuable. \$\endgroup\$ – AndrewAchilles Mar 25 '12 at 19:12
  • \$\begingroup\$ I lean toward disagreement with this answer, although that depends on how easy it is to work with XML in XNA; I've never used XNA/C#, but just about all languages have libraries that handle parsing XML and thus there is little effort. The benefit would almost definitely outweigh the effort. \$\endgroup\$ – jhocking Mar 25 '12 at 20:50
  • \$\begingroup\$ @jhocking the effort is not implementing the XML parser (which is obviously almost zero, like any other simple library/middleware.) Unfortunately XML parsers don't magically bind to data, unless we're talking about simple serialization/deserialization (which is guess we're not.) The trouble here comes from what, when, why and how to serialize (do I REALLY need data-driven development?), not the actual parsing. I wish things were that simple :) \$\endgroup\$ – kaoD Mar 25 '12 at 20:52
  • \$\begingroup\$ That's a good question, "do I really need this part of the game to be data-driven?" I would suggest put that in your answer, rather than saying "there's no long answer". \$\endgroup\$ – jhocking Mar 25 '12 at 20:57
  • \$\begingroup\$ @jhocking done for clarity purposes! That's pretty much what I wanted to state with "benefits outgrowing the effort". As you said, the effort is not about parsing, but there's still an effort implementing the parser even if it's part of a library :) \$\endgroup\$ – kaoD Mar 25 '12 at 21:00

To be up-front and fair: I'm not a big fan of XML for most purposes in games so take my advice with a grain of salt, please.

Regardless, there are some situations where you probably wouldn't want to use XML for your data:

  • When document creation has to be carried out by humans. Stuff like attributes and balancing constants come to mind. It's a very wordy format and it takes quite a lot discipline on the part of the author to keep XML documents easily understandable and terse, if that is at all possible.
  • When data storage does not need to be platform independent or backwards compatible, a binary format makes for simpler load/save code and shorter loading/saving times.
| improve this answer | |
  • \$\begingroup\$ I think that I may share this view with you. I figured that I could use XML, but in most situations I find myself not wanting to. I was concerned that I was sacrificing quality over preference. It is good to hear that it isn't an absolute must. Thanks! \$\endgroup\$ – AndrewAchilles Mar 25 '12 at 20:22
  • \$\begingroup\$ This answer is why I asked for the clarification on your original question; depending on what you were asking I can see what this is getting at (I don't entirely agree, but that's a different matter) while a different interpretation of your question would render this answer nonsensical. \$\endgroup\$ – jhocking Mar 25 '12 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.