XNet Definition File format
Posted 29 August 2003 - 05:16 PM
Good to be working with you guys! Mamutas' suggestions sounds good to
me. I'll start with the X-Net loader. Once I get that done, I'll start the Options
Management Class. Better go buy some more coffee.
Posted 30 August 2003 - 01:30 PM
Please take a look at interface submission made for PAQ and FontRenderer in Sourceforge.net mailing list. This will show you an example of what would you need to do first.
I will write up a requirements list for XNet Definition Loader shortly.
Posted 30 August 2003 - 08:45 PM
Here are requirements for XNet definition loader:
- XNet Definition Loader (XNDL) will be an object, which read XNet Definition File from file system (eventually definition file will be stored in PAQ).
- XNDL will store read information in the memory and expose set of 'get' methods to retrieve the information. Note, the information is read-only.
- XNDL will have methods to provide additional information about data definition, for example: what is the number of categories? what is the number of entries in each category? etc.
- XNDL will not have methods to retrieve entry data from file system. This functionality will be implemented in other classes.
- XNet Definition File (XNDF) will be a file in XML format, which describes existing data categories, entries for each category and information location for each entry.
- Entry's information will be located on the file system in data type specific directories (eventually those directories will be stored in PAQ).
This thread will be "the number one" documentation.
If someone sees anything missing, please comment promptly.
Posted 30 August 2003 - 09:07 PM
You almost nailed it! I bet you have not read the thread I point to in my previous post, but still there are very few things that need to be changed:
Here is what I've started for the XML data..
Sorry for some reason I can't upload anything. You'll have to get it at:
Just a start.
- some entries will have a 3D model in addition to image;
- there must not be any text which we will display on the screen in this XML file. Reasons: a) eventually game will be translated to other languages. All language specific files will be kept in separate directory. Ideally there will be only plain text files; it is job of Creative Text Department members to name things and to provide descriptions to them; c) some descriptions are very long. they would clutter XML too much. So, please use a references to some external files which contains, names of categories, entries and descriptions;
- there could be special descriptions, like stats, which might require special display format.
Posted 31 August 2003 - 12:33 AM
Wow.. two weeks.. didn't quite make that.
I figured I was a little off, that's why I posted an early example.
It makes since to not include the text.. I should have thought of that. :/
The descriptions are very long, and that is one thing that I personally
am not very fond of, but that's not my department so I won't throw a
fit. I know I very rarely read the text when there's that much, and I'm
the kind of guy who will keep playing a game just to uncover those last
few secrets.. There's no harm in it though.
It sounds like we're on the same page on how the XNDL is stored in
realtime. From what you wrote it sounds like we are to load the
class into memory and simply keep it there. So there are no trees
or lists to search, just a series of get methods. This is what I had in
mind because it shouldn't take up that much memory and will eliminate
search time. I figured we would load it whenever the geoscape starts up
and keep it in memory as long as the game is in geoscape mode. I've
done similar classes before so this should be pretty straightforward.
Posted 31 August 2003 - 12:37 PM
As far as loading go, I think it is fine to load it on geoscape initialization, since it will not take lots of memory anyway. However, to make things more clean, I suggest to load info and to create XNDL only when XNet view will be called. That is if player will never open an XNet view, XNDL will never be created. Minor memory usage improvement as well.
Posted 05 December 2003 - 08:28 AM
Has additional work on this XML file occurred? I've been wondering what format and naming conventions would be needed for the individual entries, I'd be happy to pick up this task and finish for you. I'm not a programmer, but can read up on XML, it appears fairly straight forward so far. It seems there are 2 parts needed: this definition file which calls the individual data files; and the data files themselves.
Regarding the data files, yes they are pretty long for the most part, but my intent is to have the in-game stats be the very first thing, followed by a short paragraph at the beginning with a summary for those who don't want to bother with all the details, then the remaining text.
To clarify what you need, should the stats for items include the price/build times as well, and should all the stats be pulled from a file seperate from the descriptive text? Could these stats be part of the definition file, or should they make up a third file? For the definition file, reading previous posts, it should include:
xnetentry (generic name)
category (like craft or weapon)
imagefile (png filename)
modelfile (3D filename)
stats (actual damage/range type stuff)
description (text entry)
Should there also be some type of counter Mamutas, for determining how many entries as you said before? Could it be built into the naming system, or does it need to be numeric variable so the code knows how many button/entries to make for the UI?
Posted 05 December 2003 - 09:13 AM
Here to answer your questions.
-Should the stats for items include the price/build times as well?
Not necessarily, that kind of info belongs to strategy guides, but we might show it here too.
-Should all the stats be pulled from a file seperate from the descriptive text?
It will be better to have them in separate file as far as I see. Cause they are really independent on descritpion and could be changed often during balancing.
- Could these stats be part of the definition file, or should they make up a third file?
Definition file does not have any context text in it, but just refers to files which has it. For example, for rifle it will have something like:
- Should there also be some type of counter Mamutas, for determining how many entries as you said before? Could it be built into the naming system, or does it need to be numeric variable so the code knows how many button/entries to make for the UI?
I am not sure what counter were you talking about, but there should be an category description like:
entries=rifle, pistol, cannon
The definition loader will load that data and will be able to provide the counter to UI.
Check SF mailing list, ChrisP has posted his initial version there.