Uses of XML?
Blitz3D Forums/Blitz3D Programming/Uses of XML?
| ||
| I've heard the term used a lot, and it is apparently extremely useful, but what for? That is, how is it useful in games programming? |
| ||
| The community project Jump Around uses XML for it's level format. |
| ||
| XML is a database format. The smart thing about XML is that its a markup language, like HTML and stuff. XML is really just a text document with a .xml exstention, and some basic set of rules. But the power is XML is large. XML can be used to save any information you would need, like config, levels and other neat stuff. Simple XML file: -------------------------------------------------------- <?xml version="1.0" encoding="utf-8" ?> <root> <gameLevel name="MyLevel1"> <timeLimit>30</timeLimit> <scoreLimit>30</scoreLimit> <objects> <add type="static" x="0" y="0" /> <add type="static" x="10" y="0" /> </objects> </gameLevel> </root> ------------------------------------------------------ This file could be a very simple level for a game. (The design of the XML File is not perfect, but sould get you the idea of what it does) |
| ||
| Wouldnt you have to write a parser to use the XML files though? |
| ||
| XML is the =very= best solution for development file formats of any kind. Level description, asset management both simple and complex, save files, config files -- the list goes on and on. It's incredibly easy to use for this purpose, and by using it you not only get a human-readable format, you get one that's easily changed during development both in code and in format. If you're not using XML for a development format then you really need to re-evaluate what you're doing and give XML a spin -- can't recommend its use highly enough. Advantages: human-readable (so it's easy to create files without a custom editor), easy to parse (so it's easy to write loaders/writers) and insanely flexible (so on the fly changes are tiny impacts to the dev cycle instead of huge headache-inducing "crap, so if I do this, I need a byte counter for how many instances at position 22, plus null-terminated strings for each instance... " sessions). There =are= two drawbacks: one, it's slow to load in, and two it's human-readable -- a drawback in distribution. Fortunately, as easy as it is to parse, it's just as easy to write a binary encoder that'll enable both faster retrieval and munge the data so it's not readable anymore. Just use it. Happy to post examples if anyone's interested. |
| ||
| you could, if your worried about distribution, as mord said: read in an xml file, writing each tag as a string or something maybe. You'll have to write a complicated parser, but its harder to read then :) |
| ||
| GUIde will move to an xml structure... It's awesome for defining gadgets, configs and projects. I can post an example if there is need |
| ||
| HTML Parser has been requested many times for Blitz3D. IMHO an XML Parser will become highly requested as well. Parsers for these markup languages are desired. I can visualize a group project emerging out of this. |
| ||
| Frank, there's an XML parser in Jumparound as an include by Blitztastic. |
| ||
| Yup, the XML parser is in the code archives. |
| ||
| The simple explaination: You put <> around each piece of data, and it's XML, it's merely a format group, than a format as you will always end up with you own specific format. It's fine if you need it to be readable by humans, otherwise you will probably do better with a more compact format. |
| ||
| The simple explaination: You put <> around each piece of data, and it's XML, No, it's not, XML has specific definitions that need to be followed or it's not really XML. If it's not really a format, why did the w3c spend all this time creating this document instead of just saying what you said? :) |
| ||
| here's a simple tutorial on hw to use XML: http://www.w3schools.com/xml/default.asp |
| ||
| Sorry, I stumbled about the "not format" myself, I think the new description is better. |
| ||
| Here is an example of a gui button defined in XML, as I intend to use it in GUIde. This will make adding and modifying gadgets very easy. The fun thing is that you can create your own keywords, as XML does not have pre-set keywords. Creating a parser for this is not too hard. <gadget ID="Button" version="1.0" description="A button you can press."> <label type="string" default="Button" description="The text shown on the gadget."/> <xpos type="int" default="0" description="The horizontal position of the top-left side of the gadget."/> <ypos type="int" default="0" description="The vertical position of the top-left side of the gadget."/> <width type="int" default="64" description="Width of the gadget."/> <height type="int" default="20" locked="true" description="Height of the gadget."/> <active type="flag" default="true" description="Determines if the gadget is active or not."/> <groupname type="string" default="" description="Name of the group this gadget belongs to."/> <image type="string" default="" description="Filename of the image shown on the gadget."/> <icon type="string" default1="res/button.png" default2="res/buttonsmall.png" description="Filenames of the icons shown in the GUIde interface."/> <left type="choice" values="Free,Locked,Float" default="Free" description="Determines how the left side of the gadget behaves when the parent is scaled."/> <right type="choice" values="Free,Locked,Float" default="Free" description="Determines how the right side of the gadget behaves when the parent is scaled."/> <top type="choice" values="Free,Locked,Float" default="Free" description="Determines how the top side of the gadget behaves when its parent is scaled."/> <bottom type="choice" values="Free,Locked,Float" default="Free" description="Determines how the bottom side of the gadget behaves when its parent is scaled."/> </gadget> |
| ||
| Thanks guys for pointing me to the Blitztastic's XMLParser |
| ||
| Thanks as well guys! Whoah, that's a lot of replies! ;) |
| ||
| Mmmmmm.... XML... maybe I'll write an XML 'compiler' for the sake of writing one. |
| ||
| what would an XML compiler do? (and please don't say compile XML). :) |
| ||
| It'd take in the information and spit out a, close to unreadable (with the exception of strings- numbers would be converted to floats or integers, probably) I guess, binary file. Then it'd get loaded back up, parsed byte-by-byte (or short-by-short if you somehow managed to go above 256 'instructions'), and send the information to the application in some form or another. Just random ideas, though ;) |
| ||
| it has potential... |
| ||
| My experience has been that a binary encoder is really best left to each specific implementation -- that way you can hand-optimize the parts that need fast reads. Indices can go to a header, while data can trail along at the end -- that sort of thing. That said, if you wanted to artificially limit your XML with attribute names that automatically signalled 'this bit needs to be in the header' to the compiler, and the compiler gave you feedback on how the header'd been created and how the data was stored it could be an interesting project. |
   |