Welcome, Guest. Please login or register.

  Show Posts
Pages: [1] 2
1  General Category / Meetings / Re: First Developer Meeting Agenda on: May 03, 2011, 11:09:09 PM
Just a note: I used the merge command, so character customization was in fact merged back into trunk. However, I had some issues submitting revs after my other computer crashed, so had to manually patch those (rather, barra did on my behalf).

In short, while trunk was patched, it wasn't patched with character customization content. At least, not the content that went on during the sprint.
2  Development / Programming / Re: old_man.yaml and dialogue_demo.py on: April 25, 2011, 07:27:05 AM
The reason is that old_man implements a GREETINGS section, while others do not. Thus, is is very likely that either a) GREETINGS isn't implemented in the engine or b) there is a bug in the portion of the engine that is supposed to implement GREETINGS.

A ticket should probably be filed for this so that Technomage is made aware of the issue. Thanks for stumbling upon it.
3  Development / Programming / Re: Need New Model/Game Logic Framework on: April 20, 2011, 10:10:59 PM
Maybe I read this wrong, but seems a lot of grease's functionality overlaps with fife's. Are you suggesting that we introduce pyglet and grease as a dependency and ignore the parts that fife takes care of (assuming that's possible), or are you suggesting that fife be forked or replaced all together?
4  Development / Project management / Re: Regular Developer Meetings on: April 17, 2011, 03:44:40 AM
Trying to reply for f'ing ever.

Anyways, twice-weekly scrum meeting plus a weekly developer meeting seems a bit like overkill, which is why I voted for a bi-weekly developer meeting, though i'd much prefer a weekly developer meeting with a reduction of the frequency in which we had the scrum meetings.
5  Development / Programming / Re: Need New Model/Game Logic Framework on: March 12, 2011, 05:27:33 PM
After reading through  most of the links you provided, i have reached a few conclusions:
1. As interesting a concept as FRP is,l it seems to mostly b an accademic one.After hours of research, I was only able to find one example (traits) of FRP in python. I, unlike you, think the learning curve for such an implementation would be steep.

2. The entities system seems more feasible, considering the prevelance of it in the gam industry. Im more confident that it would be easier to adapt this code to this paradigm than the former.

3. Either strategy would require a lot of facade code to wrap the existing fife api, which might cause some overhead.

I suppose we could create experimental branches for either or both. Either way, I agree that something should be done
6  Sprints / Character customization / Re: Post-Sprint Analysis and Reports on: March 07, 2011, 11:38:08 AM
1. In general, I thought the sprint went really well. Having specific areas of interest and a generous time frame in which to accomplish it seems to have worked out better than the generalized goal and liberty that previously drove the team. I especially liked the meetings. Not only was it helpful to know how everyone was progressing, it felt good to know that there was a specific time and place where I could voice my concerns about progress in general, hurdles I was facing, or to outright brag about what I finished! The biggest pane during the sprint was getting acclimated to the new work flow and submitting changes.

2. Two things blocked my progress more than anything else: Windows and SVN. As far as windows is concerned, I found myself having to cater to the platform to get things done, especially in the packaging department. Furthermore, not having a native Windows machine made it tough to test my work. As for SVN, I find myself making local branches quite often, which SVN doesn't support. As a compromise, I've had to adapt to git-svn, which generally gets the job done. However, problems arise when you try to submit changes, due to SVN's flat nature. I think I've finally got it under control, but using purely git would have helped in this respect.

3. I'd like a slightly shorter sprint with less tasks. I say shorter because there were a lot of devs on the team that finished quite early with nothing to do. I say less tasks (for now) because the current state of the code base makes it impossible to foresee some of the pitfalls that await us. In my case, It took a few days longer to merge the new settings module into the code base because I kept running into what (for lack of better phrasing) amounted to poor design decisions early on. The shorter list of tasks would allow us to adjust fire more rapidly.

4. Overall, I think it was a success. To an average user looking in it might not seem so because the only things that were added visually were the new character screen and the notebook gui. However, if you look at the number of commits to the source, the fact that there is now a (in my honest opinion) simple packaging system), the number of new members we've attracted (myself included), and roadmap
7  Sprints / Character customization / Re: Reorganizing the Directory Structure on: March 07, 2011, 04:17:24 AM
I've pretty much finished packaging PARPG for Linux and Windows, but left a few files out of the package because I wasn't sure where they should go.  I have ideas, but am waiting for input before I proceed.

Here are the unpackaged files:
AUTHORS [1]
design/ [2]
dialogue_schema.yaml [2]
dialogue_demo.py [2]
license/ [1]
parpg_editor.py [3]
pylintrc [2]
README [1]
run_tests.py [2]
tests/ [2]
tools/ [2]

* [1] I'm wondering if these should be installed in the root installation directory, or if they should reside in a docs/ subdirectory
* [2] These all seem to be development related only. As such, I'm not certain they belong in a distribution at all. Unless perhaps we had a package called "parpg-devtools" or similar.
* [3] None of the tools are mature enough for packaging I think. When tehy are , i think they should be their own package.

I almost think it makes since to move items from  [2] above to a top-level directory like "testing" or similar.

Opinions?
8  Sprints / Character customization / Re: Might not be on for a few days... on: March 07, 2011, 03:55:07 AM
That's the beauty of open source -- when life happens, you can simply commit your code and take care of business.

I hope all goes well, bro. We'll still be here when you get back.
9  Sprints / Character customization / Re: Implementing the GUI in PyChan on: February 28, 2011, 01:04:07 AM
Not registered at the fife forum which is why i'm replying here, but:

1) the python shebang line in each file should be removed from all except the launching fife script, then that one should have the python2 shebang line isntead. I'll be doing something similar for parpg when time allows

2) If you don't get any useful replies then I'd be willing to help you once I'm done with my current sprint tasks or I find some free time otherwise
10  Development / Audio / Re: a quicker track, maybe for combat... on: February 15, 2011, 05:49:38 PM
I liked the general idea of 0:00 - 0:31 and thought it just needed a bit of polish. The sound of the instrument from 0:31 - end I absolutely hate.

Its hard to say if it will fit into PARPG combat because we don't quite know the nature of the combat -- I'd say zenbitz would be in a better position to answer that.

I'd say continue with whatever energy you had with the first draft.
11  Sprints / Character customization / Re: User Story: Character Selection (as opposed to creation) - In this sprint? on: February 14, 2011, 04:42:46 PM
Actually, predefined characters wouldn't be too much work to program.  Especially if the stats are to be saved to a file of some sort.
12  Sprints / Character customization / Reorganizing the Directory Structure on: February 14, 2011, 08:52:32 AM
Summary:
What would you recommend as a directory structure for PARPG's source code and documentation?

Detail:
In trying to contribute to PARPG, I have found that the current directory structure prevents me from continuing work.

For example:
* the dialogue editor that I am working on needs to wrap a few of PARPG's objects in order to represent data correctly.
* the cleanest way to gain access to those objects without duplicating them in the file system would be to import them, which requires them being available on the system.
* in order for them to be available on the system, there has to be a standard way to install PARPG, which there isn't
* the simplest way to install PARPG on a user's system is through the use of distutils and friends (py2exe, py2app), which requires a sensible directory structure.

For the purpose of resolving (or at least regaining the ability to work toward resolving) the above issues, dramatic restructure is not necessary. Instead, only minor renaming needs to be done. However, at some point, I think we should evaluate the structure itself in an effort to ease the task of packaging and make it easier for people to find relevant information.

As it stands now, the package that has all of the importable modules is called scripts, which means that a typical import line looks as follows:
Code:
from scripts.dialogue import *
# or
import scripts

I think it would be much more desirable if we followed FIFE's lead and rename the package 'parpg':
Code:
from parpg.dialogue import *
# or
import parpg

While not strictly a name class, the pre-existence of a module named parpg might make it a bit awkward for some developers:
Code:
from parpg.parpg import *

I haven't an ideal name for this module unfortunately, but I was thinking perhaps 'core':
Code:
from parpg.core import *

The only other name that would be bizarre for packagers is the run.py script itself. We could either add it to the scripts directory and create a bash/batch file to invoke it, or simply rename it something else, like just parpg (without the extension). Not doing so would mean you would end up (on unix systems) having an exicutable called run (/usr/bin/run) which is odd.

What are your thoughts for the short term and the long term? That is, as a means to allowing the above tickets to be resolved, what changes would you propose, and for the future, what kind of directory structure would you propose?
13  Sprints / Character customization / Re: Ticket 306 (Stats Prototype) on: February 14, 2011, 08:21:03 AM
While I understand that the function of the PrimaryStatisticValue class, I'm not certain I understand the purpose of PrimaryCharacterStatistic. Is this class's primary function purely aesthetic? Asked differently, is the point of the properties assigned to such a class only useful for the user interface, or is there some programmatic purpose for them?

Additionally, is there any particular reason that this is one class instead of two? In my mind, I'm trying to find out why the following wouldn't suffice:
Code:
character.statistics['strength'] = PrimaryStatistic(long_name='strength',
                                                    short_name='ST',
                                                    description='You know, muscle. Boom! Boom! Fiah Powah.',
                                                    value=50)

If the concern is boiler plate, then perhaps the following:
Code:
# in foo.py
class PrimaryStatistic(object):
    pass

strength = PrimaryStatistic(...)

# in bar.py
from foo import strength
character.statistics['strength'] = strength

Or if determined to adhere to inheritance:
Code:
# in foo.py
class PrimaryStatistic(object):
     # some abstract base class
     pass

class Strength(PrimaryStatistic):
    pass

# in bar.py
from foo import Strength
character.statistics['strength'] = Strength()

Now I could of course be missing the point of the PrimaryCharacterStatistic class all together. In either case, feedback to help me understand how these objects are to work in theory would be greatly appreciated. Thanks
14  Sprints / Character customization / Re: Meeting to discuss programming tasks with mechanics designers 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.
15  Sprints / Character customization / Re: Twice-weekly Scrum meetings every Tuesday and Friday? on: February 11, 2011, 04:25:50 PM
Will be there tonight, should be there Tues
Pages: [1] 2