Xml-driven 2d Game Engine. Opinions?

[CyruzDraxs]

I'm working on making a 2D game engine that will be heavily XML-driven. It's intended use will be for a super mario style platformer, but I want it to be very flexible as I will likely make an RPG next and would like to later make it open source so anyone can use it.

All assets will be loaded via references in an XML file and set up based on coordinates listed in the XML file. Actual programming will be as minimal as possible and I'm hoping to get rid of it altogether. I decided this because I would like to eventually make a Graphical Editor for the engine sort of like RPG Maker...but totally different. :huh:

The game will be split into scenes, each scene has it's own XML file, containing references to all it's assets, keypress actions, AI behaviour, map data, menus and presentation mode data. All this data will be split into local and global sections--local is the data for that particular scene and is unloaded on scene change, while global remains in memory until overwritten or the engine is exited.

I plan on making this open source once I've completed enough of it to be stable, so I want to know what the community would want from such an engine and what they think of what I have so far.

Here's the Scene XML for the intro menu;

http://pastebin.com/f1f4b4d1b

If you have any questions about what different parts of the XML file will do feel free to let me know. I want to document it as well as possible as I construct it to make an easy sample game for users of the engine to build off of.

 

[ledow]

It's a good idea (in fact, I'm pretty sure it's been done before) but it would seem to make simple levels quite tedious to make.

However, I'm all for anything that breaks down the logical structure of a game. I once had something similar for a remake I was doing of Castle Of The Winds (a graphical nethack-y sort of game). I had everything described in INI files (XML didn't exist back then), and each object, map, character, monster, etc. had its own file that contained all the information that was required, even down to filenames of the bitmap that represented that object.

Once things start getting large, you need some sort of organisation and plain-text descriptive files and class systems to make it work properly. Having the entire game's particulars specified in seperate text files, while the actual workings of a generic "world" sat behind it in the code saved me a lot of work.

My comments would include:

Don't hardcore game keys into the files - You seem to have done this in the example file and it doesn't seem to be a good idea. Instead, you should use key "names" (like Up, Down, Jump, etc.) and then allow those names to be assigned to individual keys in another file (probably the main game configuration file for a particular user, not a particular level, etc.). For example, in an intro menu, I'd only require one "key", which would be a special case "any" key. In game, I would provide definitions for what happens when Pause, Resume, Up, Down, Left, Right, Jump, etc. are pressed. Then if the user wants to change all their keys, use a foreign keyboard, etc. it's simply a matter of changing the file that links, say, the P key with Pause.

 

[skeezix]

I built my 2d engine so everythign was done using my own script language and a config file crazy grammar; it worked out well in a lot of ways (easy to hack with any old editor you have handy etc), and was a pretty simple (though confusing..) language. Even at that, people wanted an editor before really using it. XML is much worse that way.. verbose (lot of work to get not much done) and complex-enough to write and validate.. you'll need an editor earlier rather than later.

But yeah, certainly doable .. its just a config file, so not impacting performance.

jeff

Allow for a lot of re-usability; not sure abou t macros and so on, but in mine.. I made heavy use of the concept of 'tiles' (where a tile could be one square, or many squares), so coudl just drop into a level description very small or large parts of maps or over-lay artwork or physics references etc.. that was really really handy.

 

[hessiess]

Irrlicht could be used as a bace, while it isn't strictly a '2D' engine, it can be driven by XML and I have used it for a 2D game. although in the case of my game, level data is stored as a binary file.

 

[CyruzDraxs]

Don't hardcore game keys into the files - You seem to have done this in the example file and it doesn't seem to be a good idea. Instead, you should use key "names" (like Up, Down, Jump, etc.) and then allow those names to be assigned to individual keys in another file (probably the main game configuration file for a particular user, not a particular level, etc.). For example, in an intro menu, I'd only require one "key", which would be a special case "any" key. In game, I would provide definitions for what happens when Pause, Resume, Up, Down, Left, Right, Jump, etc. are pressed. Then if the user wants to change all their keys, use a foreign keyboard, etc. it's simply a matter of changing the file that links, say, the P key with Pause.

That can be done. It's incomplete presently, but there is per-scene assets folders and then there is a common assets folder. One of the types of assets that can be loaded is external XML files, so you can actually place any of the code from the Main XML file's body inside of the external file, including global key references. I'd show you my level1.xml file to show you what I mean, but it's missing quite a bit right now and is in improperly encapsulated pieces right now. You can actually use that same feature to split on large scene XML in several smaller and more specific ones, such as level1_keys, level1_map, level1_global, etc.

For the time being, each scene XML will load a corresponding py script that actually overrides the entire game loop, rendering and all. I plan to abstract that all when I have the XML spec somewhat more completed, but for now I have it like this for simplicity.

I built my 2d engine so everythign was done using my own script language and a config file crazy grammar; it worked out well in a lot of ways (easy to hack with any old editor you have handy etc), and was a pretty simple (though confusing..) language. Even at that, people wanted an editor before really using it. XML is much worse that way.. verbose (lot of work to get not much done) and complex-enough to write and validate.. you'll need an editor earlier rather than later.

I agree that it can be a bit overwhelming for someone new to the program, but I will be programming a proper editor for it before it goes open source. For now I just needed a way to seperate the logic. There will be a fair bit of simplified actions available to the scene XML. for example; I could move the character from his current position to the position of an NPC by simply stating global.character.main.pos.moveto("npc1", 10), where npc1 is the ID of the NPC to move to and 10 is the speed. I'll probably also make a handful of common namespaces to achieve the same thing with less encapsulation (that's all just based on the XML structure), I could use MoveMainCharacterTo("NPC1", 10) aswell.

 

[torpor]

Just use SVG, and use it well, and use it properly. SVG is an XML file-format - no sweat there. In fact, SVG was designed for *just* this purpose, if you grok it right.

So, how do you 'use it well'? All SVG items have an 'id' and this 'id' is the key to using it well. Base the functionality of your engine around the -dictionary- of these keys. For example, if you have:

CODE

<g id="player"><&etc.</g>
<g id="enemy"><&etc.</g>
<g id="bonus"><&etc.</g>



.. then it becomes very easy to create the engine such that the "player" g is animated along with the "enemy" g, etc. Then for extendability purposes, its also easy to just use Inkscape, with "XML Node View" open (for easy naming of objects by the level creator) to create levels and so on .. this dictionary could be all you really need to define, and then just use the nouns and verbs of this dictionary to relate to your engine functionality. That is, "id='shot'" gets animated by engine_shot_animate(), etc.

BTW, I've already done this, commercially, non open-source, for a company that didn't end up using it for anything (they threw it away in lieu of their proprietary bitmap production-line). I'd love to participate in an open-source SVG-based 2D game engine project for Pandora..

 

[atomicthumbs]

Doing it in YAML might make it easier to write content without a special editor.

 

[sindbad]

Only use XML if you don't have any other choice. YAML or it's subset JSON are a much more pleasant experience.

 

[Dutch_Cap]

Only use XML if you don't have any other choice. YAML or it's subset JSON are a much more pleasant experience.

I found the article All markup ends up looking like XML by David Megginson quite enlightening. He argues that given some complexity, the difference between different kinds of markup, be it XML, JSON or S-expressions, becomes rather small. I'll admit XML is my least favorite, though.

On a related note, a binary format would be much faster to read and parse by the computer. If your levels are large and/or complex the difference in loading speed might be noticeable. A binary standard like Protocol Buffers should provide many of the advantages of XML. Personally I'd only use XML (or another markup language) if human readability was of critical importance.

 

[Tramboi]

Hi!
Sorry to go against the flow but I did register on this forum just to reply
The world doesn't need more game engines that verbose!
Even on PS3 and XBox, we game developers use binary files because the loading bandwidth we get is far superior. I wouldn't have dreamt of loading XML data when I was doing PS2 an XBox projects.
So I wouldn't want to spoil power and memory on a device like Pandora for this kind of stuff, XML can be cool for incremental development but you definitely need something slicker if you want to release a cool engine.

(Ok the Pandora has the same system memory than a PS3 ^^ )

My 2 cents (working in the industry since nearly 10 years),

Cheers,
Tramb

 

[CyruzDraxs]

Well, I do intend to move it to UBML after it is all stable and properly functional. As a one-man-team that would be a little illogical this early on though. It would make it difficult for me to extend, test and refactor if the data was all stored in binary format. I'd have to create a fully functional editor before I could do anything at all with the data.

I had considered starting with YAML, but I couldn't find anything like lxml.objectify that supported it.

 

[Tramboi]

You're right I was considering it from a larger team POV, XML is indeed a good solution to feed data to your engine with a small development time!
Good luck with your project