Creature/object definition files

[oln]

Why should it not be possible to make a buildscript/project file for MSVC also if we use xerces? Or was that just a random though that we should have a MSVC project file also?

It was a random thought that we should make a scripts that downloads dependencies and runs cmake, similar to what you have made for the installers. (Nothing to do with xerces.)
I agree that having an XML schema would be useful, we just have to decide on the structure, and/or you can come up with a suggestion.

[svenskmand]

Ok I will think about a suggestion.

[svenskmand]

Ok here is the first draft, I have not checked if it "compiles" (is valid) yet.

[oln]

The graphics section is not quite right.
For now it should contain a material element (or allow more if meshes can have more than one material.), which specifies a material filename and whether normal mapping is used.
Under that there should be one or more textures (which would mostly just be the normal map, as the base texture is defined in the .material file.
The generated material stuff, where you specify everything in the xml file will be for later when that is implemented, and if desired.

For the sound part, shouldn't "frame" be of the type "xs:integer" rather than "xs:string"?
Also some creature stats are missing, such as mana and health per level. You can look at how this is currently specified in the map file. (http://forum.freegamedev.net/viewtopic.php?f=38&t=1702#p17803)
Though, we're not using the faction stuff yet so we might want to leave that out for now.

[svenskmand]

Ok done, it is also valid XML Schema now What is bedDim1 and bedDim2 for?

[svenskmand]

The new version after our discussion on GTalk.

Edit: forgot some stuff

[oln]

With sorted material section.

[svenskmand]

I updated the file a bit, now the attacks of a creature can also change according to its level.

XSD extension not allowed for upload here :S

[svenskmand]

Changed the level information

[oln]

Since I am working on the level loading anyway, what should hold the reference to the map object? (Rather than it being global as it is currently.)

[StefanP.MUC]

I'd say one of these:
- GameState (the game state tells us if we are in game or not, if we are in game it could also hold the map)
- ODApplication (because it's probably the most central object)
- RenderManager (because the Map needs to be rendered accoridng to the tiles array)
- if it's possible to make it a singleton it can be destroyed an recrated on loading a map (I had problems doing this because of conflicts with ProtectedObject)

Not sure which is the best here, I think I'd prefer the last one, but that's probably the hardest to change.

[svenskmand]

If it is the model of the map, i.e. not the ogre tiiles representation, then it should be in the gamestate, and if you could make it a singleton that would be best

[oln]

The gameMap objects contain all the creature, tile, trap and room objects. (Though not the actual graphical representations, that's handled by the ogre scene manager.) It also contains some thread handles.
As it is an object that is to be deleted when not in a game, I think it should not be a singleton.

[svenskmand]

Ok, I agree.

[oln]

I've started moving GameMap out of global scope, put it in the frame listener for now (though moving it elsewhere would be trivial if that is preferred).

[StefanP.MUC]

Is this supposed to be pushed to git already? This currently stops me from doing further work on the consolle script conversion.

But no need to hurry if there's more work to do before the push.

[oln]

It's not pushed yet, but I am almost finished moving the gameMap out of global scope. Will probably be pushed today.

[StefanP.MUC]

Since 3 month there's work on TinyXML-2: http://www.grinninglizard.com/tinyxml2/index.html
It is much more C++ and has a much smaller footprint.

I'm not sure about xerces. It's just to big and heavy, imho. We shouldn't spam our dependencies with the heaviest available libraries if we don't really need them. Just for camparison:
- TinyXML-2 consits of two files, together less than 100kb
- The xerces binary package download for Windows is zip compressed already over 20 MB (!), compiling and maintaining the lib will be a lot more difficult, and there's no MingW binary for Windows

I think OD does not need to do the Schema verification itself on each run. It's enough if we check it once manually before using a file (with the W3C validator or some other tool).

[oln]

The actual library is about 2 mb uncompressed, there is a bunch of example programs taking up space in the download. (2mb is still a lot though.)

[svenskmand]

If the game is not able to validate the XML input, then how would the user know that he did something wrong?

[StefanP.MUC]

What the game should check is if every needed field is in the defintion file. This is small C++ code (read the file with a small XML reader and look if all variables got their value - if they have not then something went wrong, but this doesn't need detailed XML standard validating).
The thing with xerces is that it supportsa all the complete and whole xml standards. But we don't need XSLT, detailed DTD checking, namespaces, .... Why have all this features shipped with our game if never needed?

OD is no tool for XML devs, it's a game.

xerces is for hardcore XML develeopers. TinyXML however (and other small parsers) are for using XML in real live.

[svenskmand]

So you do not want to give the user of the XML files, some feedback when they mess up the Creature Object Definition (COD) files? I mean the purpose of using the COD files in the first place is to make it easy for non-coders (artists) to easily get their stuff in the game and tweak stats of the creatures, so having an effective tool-chain that helps them is important in my opinion. So I am simply asking what should those guys (non-coders/artists) do then if OD does not give any feedback for errors?

I am not saying we need to validate the XML files every time the game runs. But you could start the game in developer mode and then it validates the XML files and gives the user error messages, which should decrease the turn-around time for non-coders that wants to change the COD files. I mean OD already has a map-editor, so creating content is part of the scope of the games binaries.

[StefanP.MUC]

If we provide creature defintion creating/editing through the game then this is also an argument for TinyXML and against xerces actually. Then we only need to hardcode the XML structure in C++ and let TinyXML write it. Then the user won't ever see the schema or xml contents:
If writing and reading of the XML files only happens from within the game (-> C++ API from TinyXML) we don't need any extra validation because we ensure that everything is correct in the first place.

All this extra stuff that xerces provides is only for "meta" stuff, not for using defined XML structures in applications.

And people who write their XML files by hand can also validate them "by hand" with our Schema file (by loading them into some validator tool). This is nothing that OD does need to do itself.

[oln]

Speed is also a concern here (xerces is slow), so I am not sure what the ideal option is. Though, the game can still check if there are values not set after loading, or invalid values even if the file is not validated.

CEGUI also seems to use xerces to parse xml by default, so it will be present anyway. (It's possible to use a class from CEGUI as well if one wants to hook into whatever cegui is set to use.)

If we want a small parser, there is also pugixml and rapidxml which are probably a bit more stable than Timyxml-2.

[StefanP.MUC]

Ah, ok. If we have xerces already we can use it, of course. Didn't know it was already there.

I also stumbled over Pugixml and Rapidxml before, but it seems they are not maintained for several years already.

Under these circimstances I'D say: use CEGUI's xerces if that's possible without any problems, if not then take TinyXML-2.