Post-Apocalyptic RPG forums

Sprints => Character customization => Topic started by: Technomage on February 06, 2011, 12:22:38 AM



Title: Meeting to discuss programming tasks with mechanics designers
Post by: Technomage on February 06, 2011, 12:22:38 AM
After organizing and reviewing the dependencies on the sprint tasks we agreed to yesterday (see http://parpg-trac.cvsdude.com/parpg/depgraph/264 in particular) I appears that many tasks are blocked by mechanics-related tasks. In particular, some of the programming tasks can't be finished until the relationships between skills, stats and attributes are finalized. I therefore propose that zenbitz, rowanas, KB1PKL, Taldor and I get together to discuss how to start working on these programming tasks while the mechanics are worked out.

Please let me know what you think.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: kb1pkl on February 06, 2011, 12:36:59 AM
Sounds good to me, lets do it. I'll be on IRC more often.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: rowanthepreacher on February 06, 2011, 12:59:30 PM
Yep, sounds good to me. Unfortunately it'll have to be at a similar time to the sprint prioritisation meeting, which was, for me at least, quite late in the day.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: zenbitz on February 06, 2011, 06:39:58 PM
I agree that discussions need to be ongoing.  I think we are going to struggle to work around meeting times,  and we should just get stuff done anyway.

Right now what I need very soon is a some agreed upon format (XML?) to load relationships between stats/skills/etc.

I think it would be "ok" (possibly not ideal) if we hard wire the 8 primary stats in.  We could load them from a metadata file... but because the other data is 100% dependent on them, they are going to have to be fixed pretty soon.

Essentially we need three files:
One that defines "traits" (stat modifiers) and their effects on primary stats.
One that defines secondary stats and how they are derived from primary stats
One that defines skills (tree structure), and what stats they are "based" on.

I actually am not sure if further discussion should go in this forum / thread or elsewhere.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: mvBarracuda on February 06, 2011, 06:41:09 PM
I actually am not sure if further discussion should go in this forum / thread or elsewhere.
It's fine to make a new thread for the topic. It should reside in the sprint board as it's a sprint related question.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: kb1pkl on February 08, 2011, 05:40:05 AM
(XML?)

Please no. A raw python file or a JSON file would be nice. I'd rather not XML.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: zenbitz on February 08, 2011, 07:14:56 AM
I just want to reiterate I am CRAZY busy this week, then gone for 8 days with essentially no internet.
If you need something from me you need to pester.  I have some spare cycles and I will get stuff done if I need to.

Being flexible and creative would be a good thing.

JSON?  Really?  So PAPRG will have XML, YAML, pure python, AND JSON configs.  That's totally bonkers.
We are kinda stuck with XML for FIFE (I think), and we will probably move from YAML->python for  quests/scripting/dialog.   

I guess I can put the skill dependencies in a python "config" if you tell me what datastructure you want.  Or maybe you just convert my excel file?   I have no problem editing python.  I think it would be smart to keep any methods out of such a config file, though.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: Technomage on February 08, 2011, 08:10:55 AM
Quite frankly I support using XML in this case. We need some kind of scripting that is implementation-independent so that we can easily change our implementation later on if needed. YAML is out, simply because its a pain to write parsers for and we're moving away from it in general. As Zenbitz points out, Python isn't terribly useful unless we have the data structures designed, which sort of defeats the purpose of scripting. JSON would work as it is simply a subset of Python, but for consistency XML is probably our best option.

Keep in mind that it is fairly trivial to write parsers for XML and JSON, so we can change it later if needed. But for the time being my suggestion is to just go with XML and deal with the details later.


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: kb1pkl on February 09, 2011, 02:00:29 AM
Quite frankly I support using XML in this case. We need some kind of scripting that is implementation-independent so that we can easily change our implementation later on if needed. YAML is out, simply because its a pain to write parsers for and we're moving away from it in general. As Zenbitz points out, Python isn't terribly useful unless we have the data structures designed, which sort of defeats the purpose of scripting. JSON would work as it is simply a subset of Python, but for consistency XML is probably our best option.

Keep in mind that it is fairly trivial to write parsers for XML and JSON, so we can change it later if needed. But for the time being my suggestion is to just go with XML and deal with the details later.

I'll swing with that. I just really, really hate editing XML. I don't really see much of an implementation difference between pure-python and XML in terms of knowing the data structures, because you can have something like:
Code:
fitness = {'name': "Fitness", 'type': 'Stat' 'level': 'Primary', secondary_affected: [('Long-Distance Running', 1), ('Lifting Capacity', 0.3), ('Carrying Capacity', 0.3), ('Sprint Speed', 0.7)], 'skills': [('Something here', 0.5)]}

or you could have...
Code:
<stat level='Primary' name='Fitness'>
    <affect type='Secondary'>
        <stat level='Secondary' name='Long-Distance Running' weight='1' />
        <stat level='Secondary' name='Lifting Capacity' weight='0.3' />
        <stat level='Secondary' name='Carrying Capacity' weight='0.3' />
        <stat level='Secondary' name='Sprint Speed' weight='0.7' />
    </affect>
    <affect type='Skills'>
        <skill name='Something here' weight='0.5' />
    </affect>
</stat>


Title: Re: Meeting to discuss programming tasks with mechanics designers
Post by: aspidites on February 11, 2011, 06:23:35 PM
I'll swing with that. I just really, really hate editing XML. I don't really see much of an implementation difference between pure-python and XML in terms of knowing the data structures, because you can have something like:
Code:
fitness = {'name': "Fitness", 'type': 'Stat' 'level': 'Primary', secondary_affected: [('Long-Distance Running', 1), ('Lifting Capacity', 0.3), ('Carrying Capacity', 0.3), ('Sprint Speed', 0.7)], 'skills': [('Something here', 0.5)]}

or you could have...
Code:
<stat level='Primary' name='Fitness'>
    <affect type='Secondary'>
        <stat level='Secondary' name='Long-Distance Running' weight='1' />
        <stat level='Secondary' name='Lifting Capacity' weight='0.3' />
        <stat level='Secondary' name='Carrying Capacity' weight='0.3' />
        <stat level='Secondary' name='Sprint Speed' weight='0.7' />
    </affect>
    <affect type='Skills'>
        <skill name='Something here' weight='0.5' />
    </affect>
</stat>

Agreed. I'd even argue that determining the data structures for XML would be equally, if not more taxing on developers because not only does the structure (read: schema) have to be agreed upon, but the parser must be created as well.

With pure python, the amount of work that needs to go in a parser relies solely on the amount of encapsulation that developers agree to implement. That is, raw python data structures (dictionaries, lists, etc) could be used initially, then a layer could be built upon that to make it easier for non-programmers. Further, I seem to remember the argument being made that these kinds of files wouldn't be edited by hand in most cases (eg. editor tools) so the technology used is irelevant.

A final argument would be that the XML parser would simply be converting tags to python objects, so in theory wouldn't it be much simpler to just cut out the middle man?

At any rate, I'll follow suit with whatever we decide upon but would much rather not have to play with XML for this particular purpose.