Creature/object definition files

[svenskmand]

Under these circimstances I'D say: use CEGUI's xerces if that's possible without any problems

I agree with this. If we already have xerces then lets use it.

[StefanP.MUC]

As far as I can see the proposed file layout only covers creatures. The logical questions that come up:
Should we have a general format that covers any kind of object (only one schema that covers all types)?
Should we have a separate format for each kind of object (one schema per object type)?

With regard to this, I collected some current problems of the code structure and the Level file that should be taken into consideration while finding an answer to the question:

I just noticed that currently every type of object is treated differently, which I think is very unflexible:

• Creature: read from level file, have their definitions, can rather easily be made an xml
• Weapon: read from Level file, but very unflexible: meshName = name + ".mesh" (identifier = filename = unflexible), also the wepon properties are stored for each individual creature again and again (unneeded waste of memory, numbers can't be adjusted easily).
• Room: Meshname and numbers are hardcoded (worst case, completly unflexible)

Independent of the question from the beginning (I have no preference for this yet), I think these points must be fullfilled for every object type:

• Everything that defines an object type must be read from file and only read once
• Identifiers and file names must be separate
• Definitions must not be coupled to other definitions (e.g. a Weapon must be able to "exist" without being bound to a Creature)

I think this will lead to having new "definition classes", like CreatureDefinition: WeaponDefinition and RoomDefinition. This will give us full flexibility, also with regard to scripting.

[oln]

XML schemas can import other schemas, so we can use "inheritance" for the formats. (I.e object schema, and creature schema that uses the object schema in addition to creature specific parts.)

I think weapon can be treated similarly to Creature, we should definitely have WeaponDefinition as well.
Rooms are more tricky, as a large part of the room behaviour is defined outside the room objects themselves (and I don't think there is an easy way around it and not something we should focus much on on this stage.) We could allow overriding the cost/mesh names though. (Same with tiles and traps.)

Otherwise I agree with your points.

[StefanP.MUC]

Yeah, rooms will be hard to generalize and should be the last objects to be touched, after everything else is in a good and final state (I'm absolutely not sure what's the best way there, too).

[svenskmand]

I agree on making separate definition files for creatures and weapons. Although I think it should not be a problem to make a definition file for rooms also, what problems do you see in that?

[StefanP.MUC]

Several things:

- Rooms have a dynamical size (or not?), so the meshes and their position must be dynamically anyways (the file name can come from a file, of course)

- Most rooms work fundamentally different, so changes to a specific room most likely will require code changes anyways

I agree that rooms should have their values (file name, hp, defense, whatever) read from file. But unlike Weapons and Creatures, rooms can not be dynamically added just by adding a XML file. Weapons, for example, always have the same properties (name, file name, damage), but a room can have a lot of different numbers depending on its function/purpose.

So basically the specific room types need to be hardcoded (or ideally scripted, if we manage to get this working) and cannot be added by simply adding a XML file.

or in other words: every room type needs its own schema.

[svenskmand]

I am not sure exactly what you want to store in the xml file from your comment above. But the way I see the info that the xml file should store it is this:

• hp
• the set of different meshes for the tiles
• rules for which tiles are allowed to be next to which tiles
• list of objects that can/is be placed in the room
• number of allowed creatures per tile

The exact configuration of each room can of course not be stored in the xml-file as that is user-dependent. But the xml-file can store the stuff I mentioned above.

The xml schema should define the allowed stuff in each room. This of the xml file as a class instead of as an object/instance of the room.

[StefanP.MUC]

Yes, this will probably be done this way.

But what I wanted to say originally (and oln, too, if I understood him correctly):
Designing and adding new Creatures and Weapons with just an XML file only will be possible (no coding needed, only a text editor).
However, we are not able to design new rooms with just an XML file only (we will have to hardcode the room behavior and recompile the game).

That's why rooms (and traps) have to be handled differently (code-wise and XML-wise). But the values will be loaded from a file, of course.

[svenskmand]

Yes yes. But in that relation we could also be doing this using only xml and scripting. I depends on how flexible we want the game to be in terms of modding/adding new stuff.

[Smilex]

I don't mean to be that guy who pisses on all your idea's, but they are wrong if I'm nice about it or not.
The way this should be done is very simple, you start of knowing that you'll have a parent element called Creature, then you just think of what data each creature should have, and you just add elements for it.
So here's my first draft (Which I plan to start implementing immediately)

{l Code}: {l Select All Code}

<Creature>
<name> TestCreature </name>
<mesh> MeshName </mesh>
<material> Material </material>
<texture> Texture </texture>
<script> Script </script>
<stats>
<health>10</health>
<!-- ect -->
</stats>
</Creature>

So now this creature is associated with a mesh, a material script and a texture ( also an AI script, but those aren't available yet. ). Along with those essentials for visuals, the creature also has 10 health points. Working like this allows you to easily just add tags as you please.
Also attributes are for extra data to the tag, so in case of the mesh tag, it could be scale or something. But this can also be added over time.

[Smilex]

Ok, I've decided to document the new XML classes here, because I don't have a better place in mind at the moment that makes the information public, so that you guys and anyone else who's interested can read initial idea behind the design. Please do tell me if this was a bad idea, and suggestions for how to better do it in the future (I'm personally thinking that adding to the wiki is more appropriate, but I also think that the wiki entry should have more effort put into it).

First of there'll be a class that reads any .xml file and parses it. This file other classes that specialize at certain tags, registered to it and it will send the contents of those tags to the registered classes.

{l Code}: {l Select All Code}

class XMLReader {
- m_fileReader : std::fstream;
+ ReadFile(file);
+ RegisterClass(IXMLTagParser, tagName)
};


Then there should be the IXMLTagParser (for lack of a better name) abstract class, which must allow deriving classes to interpret the xml tags freely. Note that when I mention xml tags, I mean the text data from the start of the tag to the end of the closing tag, with everything between.

{l Code}: {l Select All Code}

class IXMLTagParser {
- m_document : XMLDocument;
+ virtual Parse(xmlData) = 0;
};


Then a deriving class for the creatures.

{l Code}: {l Select All Code}

class CreatureTagParser {
- m_definition : CreatureDefinition;
+ virtual Parse(xmlData);
};


This is obviously just a first draft kind of thing and is subject to change. Also all feedback is appreciated.

[hc]

Ah, Smilex, while a bit of actionism isn't always a bad thing,
I think the discussion you are replying to is still on the concept level as it seems to me.


@regulars: LOL, sorry guys didn't meant to interfere.

[oln]

[quote="Smilex"]Ok, I've decided to document the new XML classes here, because I don't have a better place in mind at the moment that makes the information public, so that you guys and anyone else who's interested can read initial idea behind the design. Please do tell me if this was a bad idea, and suggestions for how to better do it in the future (I'm personally thinking that adding to the wiki is more appropriate, but I also think that the wiki entry should have more effort put into it).
/quote]

I really like your approach to the problem, and your interface suggestion.
Regarding the wiki the project has been a bit stale the last year, which is why the wiki is a bit outdated.

[paul424]

I tried and downloaded the xml xsd scheme definitions of Sven's Maskd or ( Stephan* ... ) linked from that thread and it does NOT validate with xmllint. I wanted to start extending the Smilex code, but again someone don't even cared about xsd validity.....

[paul424]

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: oXygen
Severity: warning
Description: Hint: Some components referred by your schema were not found. If this schema file is included in a schema from where those components are visible then you should validate it starting from that schema file using a validation scenario. Search for "Validation Scenario" in the oXygen Help for more information.
Start location: 1:0

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'stats' to a(n) 'element declaration' component.
Start location: 6:25
End location: 6:32
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'scale' to a(n) 'element declaration' component.
Start location: 10:31
End location: 10:38
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'material' to a(n) 'element declaration' component.
Start location: 11:31
End location: 11:41
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'sound' to a(n) 'element declaration' component.
Start location: 19:31
End location: 19:38
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'level_stats' to a(n) 'element declaration' component.
Start location: 79:23
End location: 79:36
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'attack' to a(n) 'element declaration' component.
Start location: 80:23
End location: 80:31
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'job' to a(n) 'element declaration' component.
Start location: 81:23
End location: 81:28
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'normalmap' to a(n) 'element declaration' component.
Start location: 117:23
End location: 117:34
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

System ID: /home/tom/xml/CreatureDefinitionsSchema.xsd
Main validation file: /home/tom/xml/CreatureDefinitionsSchema.xsd
Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'specularmap' to a(n) 'element declaration' component.
Start location: 118:23
End location: 118:36
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

I will try to fix that , by my motto is to show other faults

'dea culpa, dea maxima culpa '