Programming Q&A

[Derakon]

Yes, you should take a look at the util/record.py file. An example for how to use it would be in things/terrain/terrainLoader.py. Basically you hand it the path to the file you want to load, and a function to call for each element in the JSON list in that file. It'll load the JSON structure, iterate over the elements in it, and call the given function for each one. In this case the function being called is a class constructor (the __init__() function in terrainFactory.py).

[Nick]

In order to use grep you need to know what you are searching. My question goes one step up from that: how do you know what to search?

This page has a guide to the 3.2.0 codebase - it hasn't changed structurally too much since then. While it's not enormously detailed, it does at least give an idea where to start looking.

[Patashu]

So my question is, is it possible to read that stuff in from the file and then refer to stat[STR] in the code? Come to think of it, I wouldn't know how to do this in C either, but I'm actually interested in Python because I kind of have a hunch that Python can do this.

(Let's leave aside the question of why one would hard-code references to stats which are defined in an external file - one thing at a time!)

You could define the stats in an XML formatted file - most languages will have an XML parser library by default, so you can serialize to and from such a format without writing any special code. The in-memory representation of such XML will be a hierarchical tree structure, or maybe you'd flatten it to dictionaries for example. You can ask this representation 'Do you have an entry called STR?' and if it does it returns you all the information stored under STR.

The harder problem is how to link stats defined in a file to what they modify in-game. I see two approaches:
1) is for things that can be altered by stats to specify what flags they're looking for. Stats then have or don't have such flags (and possibly other data associated with it, like constants/factors/thresholds).
2) is for stats to specify what things they alter. Whenever an alterable roll or number is computed in game it will first check to see if any stats specify they alter it, and using what formula (python has eval() for example, or you could roll your own syntax).

You'd also need to have some dynamically binding specification of how stats are rolled, what classes/races get what stats, etc. again using the system of your choice.

[Magnate]

You could define the stats in an XML formatted file - most languages will have an XML parser library by default, so you can serialize to and from such a format without writing any special code. The in-memory representation of such XML will be a hierarchical tree structure, or maybe you'd flatten it to dictionaries for example. You can ask this representation 'Do you have an entry called STR?' and if it does it returns you all the information stored under STR.

Well Derakon's chosen JSON for the text file format, and I think that should work ok. But yes, in a more general case XML would do.

The harder problem is how to link stats defined in a file to what they modify in-game. I see two approaches:
1) is for things that can be altered by stats to specify what flags they're looking for. Stats then have or don't have such flags (and possibly other data associated with it, like constants/factors/thresholds).
2) is for stats to specify what things they alter. Whenever an alterable roll or number is computed in game it will first check to see if any stats specify they alter it, and using what formula (python has eval() for example, or you could roll your own syntax).

I had a different thought about this, based on my earlier thinking about the effects framework. In my design, effects should specify how stats affect them, for example:

Number: 1
Name: Fireball
Range: 8 + stat[INT] / 5
Damage: clev * d6 * (100 + stat[WIS] / 2) / 100
Save: stat[CON] > 10 ? half : no

I guess this is not a million miles from your #1, without the need for stats to have flags.

[Derakon]

Effects can certainly have a lot of leeway in deciding how to use stats. However, I wouldn't try to stuff all interpretation of stats into effects. Some fundamental game rules, like how combat works or how to decide the failure rate on a spell, is going to go into the core engine. So any stats that deal with those "core rules" should just be assumed to exist (and filled in with defaults for the cases where the data files don't define them, e.g. for the majority of monsters).

The bottom line is that you have to strike a balance between flexibility and getting stuff done. A maximally-flexible game engine will be impossible to debug, and will likely never be finished, because of all the added complexity that introducing that flexibility causes. On the flipside, a game engine that hardcodes everything can get basic stuff done very quickly, but becomes horribly difficult to extend to get to a "finished game".

[Patashu]

I had a different thought about this, based on my earlier thinking about the effects framework. In my design, effects should specify how stats affect them, for example:

Number: 1
Name: Fireball
Range: 8 + stat[INT] / 5
Damage: clev * d6 * (100 + stat[WIS] / 2) / 100
Save: stat[CON] > 10 ? half : no

I guess this is not a million miles from your #1, without the need for stats to have flags.

Ok, but if you're not making the implementation of stats code-side dynamic at all (e.g. I can't add a new stat WIL that effects your saving throw against magic since all places are hard-coded either check WIS or nothing) why move this stuff out of the program at all?

Addendum: I also agree with Derakon. Customization is something you tack on because you know you'll need it anyway. So don't make a fully customizable game engine when all you need is a game.

[AnonymousHero]

You could define the stats in an XML formatted file - most languages will have an XML parser library by default, so you can serialize to and from such a format without writing any special code. The in-memory representation of such XML will be a hierarchical tree structure, or maybe you'd flatten it to dictionaries for example. You can ask this representation 'Do you have an entry called STR?' and if it does it returns you all the information stored under STR.

(I don't want to derail the thread or anything, but I think this needs to be said. If nothing else then to hopefully dissuade the novices.)

XML is not good for data -- this should not be surprising given its origins. If you use it for marking up content (hardly anyone outside of office suites does it seems), it's a pretty reasonable format. If you use it for data format definition, however...

The data model is ridiculously complex, namespaces are overly complex, it's verbose, it's not actually human-readable/writable in practice... and 99%(*) of uses can be trivially replaced with s-exprs.

Also, AFAICT all current C libraries for XML suck (insanely verbose, no data binding, etc. etc.). S-exprs in C are dead simple using sexpr, and JSON is also dead simple using Jansson.

As things stand the only valid (technical) reason I can currently see for using XML would be data binding, but if you're using a language with dynamic type checking that is already of dubious value.

(*) Estimates may vary. No waranty. Void where prohibited. (etc.)

[Magnate]

Ok, but if you're not making the implementation of stats code-side dynamic at all (e.g. I can't add a new stat WIL that effects your saving throw against magic since all places are hard-coded either check WIS or nothing) why move this stuff out of the program at all?

I think you're making my point - I'd envisage you could do precisely that, by defining the effects which used WIL as a save instead of WIS.

[Magnate]

Effects can certainly have a lot of leeway in deciding how to use stats. However, I wouldn't try to stuff all interpretation of stats into effects. Some fundamental game rules, like how combat works or how to decide the failure rate on a spell, is going to go into the core engine. So any stats that deal with those "core rules" should just be assumed to exist (and filled in with defaults for the cases where the data files don't define them, e.g. for the majority of monsters).

The bottom line is that you have to strike a balance between flexibility and getting stuff done. A maximally-flexible game engine will be impossible to debug, and will likely never be finished, because of all the added complexity that introducing that flexibility causes. On the flipside, a game engine that hardcodes everything can get basic stuff done very quickly, but becomes horribly difficult to extend to get to a "finished game".

Agreed on both counts. Just because a stat is assumed to exist doesn't mean it should be hard-coded separately from other stats - IMO it shouldn't. And yes I very much see a set of core rules and default values underlying this system, I didn't intend to imply that everything would rely on effects. I'm pretty sure I can strike the right balance between development speed and future-proof flexibility, I've been thinking about it for years. All that remains is to get on and do it ;-)