info files

[joeclark77]

Do any of you have advice for using external info files to enable quick definition of monsters, items, etc?  (And also for users to set preferences and/or mod the game.)  Are there particular data formats that are easier to parse?  I figure XML is a bad idea because it's so hard to read, but, maybe JSON?  I'm using Python for what its worth.

[Eben]

I use JSON, it's nice and easy to read and modify.

(I actually use Jackson, an extension for Java that allows for full cyclic graphs to be encoded easily)

[pat]

I am just using plain text for a current project to store map layouts and object definitions because it's about as simple as it gets to parse and edit. The only drawback as I can see it is that people can spoil themselves by opening those files but that doesn't really concern me

[Eben]

I used plain text for a while and it was mostly okay, but JSON is basically plain text with a standardized parser so you don't have to build your own.

I had the same concern about human readability and decided that letting them edit was more important than prevent potential spoilering. I think anyone who would read the files for the purpose of being spoiled is just as likely to look things up in a guide or such and still be spoiled anyway.

[kraflab]

I just use plain text and write my own parsing when it needs doing.  Somewhat an extension to this is using external scripts to carry out certain operations, opening up the mod-space a little bit.  I hear good things about Lua.

[AgingMinotaur]

I've no experience with JSON, but would say there's nothing wrong with good old plain text. Configuration I think is practical to keep as a python script. If you formalize it like this:

Code: [Select]

x_res=1024
y_res=764
fullscreen=True
… it hardly looks like code, you can comment out lines with #-es, and it's simply a question of importing the config as a module to get the different settings instantly available as variables. You might even consider keeping "data files" for stuff like monsters as python scripts. The "syntax" could certainly be made pretty human readable, if you just constrain yourself a bit. Imagine something like this:

Code: [Select]

goblin=Monster()
goblin.name="goblin"
goblin.attack=2
goblin.defense=2
An advantage to doing it this way, is that you can even "break the flow" and put in simple scripts where you need them. Eg. if a certain item needs a functionality that's not explicitly defined in the engine, you can just hack it together in the definition/info file. That might slowly turn messy if you do it too much, of course.

As always,
Minotauros

[sokol815]

I use plain text as well. For instance, this is what the file-definition of a painting furniture item looks like:

Code: [Select]

FPiece:Painting
Click:
advancestate;
EndClick
Worth:500
Materials:WOOD=4
Image:0=3,2|(846,847,848,878,879,880);1=3,2|(911,912,913,943,944,945);2=3,2|(908,909,910,940,941,942)
complexity:16

In the actual game, when you click on said painting, it cycles through the 3 paintings (as referenced by frame numbers from my sprite file)

You might also like to see some more advanced scripting that can be put into the system:

Code: [Select]

FPiece:Metal Hatch
Proximity:
#state 0 = hatch is closed
#state 1 = hatch is open
IF state(0) AND power(2) AND enterproximity(60,anyone) THEN usepower(2) state(1) passable(true) play(slamdoor) END;
IF state(1) AND leaveproximity(60,anyone) THEN state(0) passable(false) play(slamdoor) END;
IF state(1) AND !countproximity(1) THEN state(0) passable(false) END;
EndProximity
Power:
IF !power(max_power_storage) AND determinepowersource(2) THEN takepower(max) END;
EndPower
Worth:200
power_capacity:6
cur_power:6
Materials:Iron Ingot=5
craft-require:anvil
Image:0=2,1|(722,723);1=2,1|(690,691)
passable:false
state_item_draw:0
break-below:true
complexity:50

I have 9 different types of files that all contain essential data (block definitions, furniture,ini file, pieces of items (intended to be combined by the user into items), bodies (build npcs and characters out of the body-parts), plants, craft materials, craft recipies, and the world creation properties.

I did have to create my own custom parser for them, but I have also been able to make it easy for me to extend. I even can just make comments or disable items quickly by simply using a # symbol to comment the line out. They all use the same file-formats, so the general parser they all use is the same, just different cases in the switch-case. (when it comes down to it, you are going to have to do some sort of parsing anyways, even just to massage the data from a json structure into your classes you are using)

If you want to check out more of how I put it all together, you can get a hold of the Euthenia file (https://www.dropbox.com/s/4u8umxn3z02vllq/Euthenia_0.01.zip.

[tuturto]

I second the AgingMinotaur on using Python. If you want to, you could even write a simple internal domain specific language for configuring the game and maybe make it even easier to use.

I found using Python instead of config files simple enough and results were useful (at least for me). Some examples can be found at: https://github.com/tuturto/pyherc/tree/master/src/herculeum/config/levels which contains level configurations of my game.

[requerent]

Lua data files are just table definitions, which are super easy to understand and require no parser.

[pat]

by way of demonstration, here's how one of my data files looks which defines a unique NPC character:

Code: [Select]

name
Arianna
char
296
faction
neutral
x
28
y
4
strength
2
dexterity
2
intellect
5
spirit
5
agility
3
craft
6
fighting
2
knowledge
6
perception
6
persuasion
8
shooting
2
speed
2
stealth
2
toughness
2And to use that file, I iterate through each line until I identify a header which is expected by the program and then it knows what the data in the next line is supposed to correlate to. It's probably stupidly simple but that's really what I'm aiming for.

[guest509]

Wow she's got super high Charisma!

[pat]

So obviously it's not as intuitive as it could be haha.

[Ex]

I use plain text for any game data files I have, and I don't use a library for it. Also, I hard code monster and item data, so those don't rely on outside files. The only thing I use outside files for is settings, and saved games.

The hard coded stuff I do is pretty simple. I start with a function that spawns a base template, then another function calls the first and takes the output and modifies it in some way. This repeats for a certain number of times, like so:
SpawnBaseObject
SpawnBaseMonster (calls SpawnBaseObject and modifies the resulting object)
SpawnSpellCastingMonster (calls SpawnBaseMonster and modifies the resulting object)

or

SpawnBaseItem (calls spawn base object)
SpawnBaseArmor (calls spawn base item)
SpawnMagicArmor (calls spawn base armor)

Then I use these functions to create a list of templates that all the monsters and items in game are copied from. The templates are stored as vector<Object *> Templates, and are copied into the game as needed. Randomization of properties of monsters and items happens immediately after the objects are copied.

[cupcake]

I tend to use YAML; it's similar to JSON, but it's more human readable.

Plain text, or some representation of your own design is only good if you don't intend for other people to modify your files (unless they're very simple). If you do intend the files to be modifiable by other people, using something with a standard is generally a better idea.

[TheCreator]

I used to keep such data in a simple Windows INI files, but that idea was quickly dropped in favor of my own parser, which is faster, portable and offers more features, retaining INI's layout with its simplicity and readability. In general, using plain text formats is good as long as you don't need to define stuff like tile indices.