John Salerno wrote:
> On Jun 19, 8:52 pm, Chris Kaynor <ckay...@zindagigames.com> wrote:
>
>> Having a character class (along with possibly player character,
>> non-player character, etc), make sense; however you probably want to make
>> stuff like health, resources, damage, and any other attributes not be
>> handles by any classes or inheritance in order to allow you to make such
>> data-driven (ie, read from a file). Doing so makes the game much more
>> extendable: using classes, you are likely limited to 5 or 'combinations
>> and a few developers (plus, any designers need to know programming).
>>
>> A basic way to determine between using subclasses over a data driven
>> approach is: is there significantly different back-end behavior or merely
>> attribute differences.
>
> Can you give a basic example of how this data-driven approach would
> work? You don't have to provide any code, just a description would be
> helpful. Such as, do I create a data file per character, and then have
> each character instance read/write to that file? Is it good to have so
> many files open at once, or would they only need to be read, closed,
> then opened again at the end to write?
Battle for Wesnoth is set up this way. I don't know what the code does, but
you can go wild creating new classes of character by mixing up new
combinations of attribute settings in new configuration files, and injecting
them into the standard game config files.
AFAIK you are stuck with the attributes the game is programmed for. I've
seen no way to create a new dimension for the game -- Conversation, for
instance, with currently unknown attributes like vocabulary or tone.
Mel.
--
http://mail.python.org/mailman/listinfo/python-list
