Welcome, Guest. Please login or register.

Pages: [1]
Print
Author Topic: Meeting to discuss programming tasks with mechanics designers  (Read 6444 times)
Technomage
Admin
Community member

Posts: 80



View Profile
« 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.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

kb1pkl
Community member

Posts: 24


View Profile Email
« Reply #1 on: February 06, 2011, 12:36:59 AM »

Sounds good to me, lets do it. I'll be on IRC more often.
Logged
rowanthepreacher
Community member

Posts: 139



View Profile Email
« Reply #2 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.
Logged

Testiculos habet et bene pendentes.
zenbitz
Community member

Posts: 1164



View Profile
« Reply #3 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.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #4 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.
Logged
kb1pkl
Community member

Posts: 24


View Profile Email
« Reply #5 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.
Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #6 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.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #7 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.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

kb1pkl
Community member

Posts: 24


View Profile Email
« Reply #8 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>
Logged
aspidites
Community member

Posts: 29


View Profile Email
« Reply #9 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.
Logged
Pages: [1]
Print
Jump to: