in reply to Re: RFC: RPG ;-)
in thread RFC: RPG ;-)

1. Is this a rules description or a rules engine? What I mean by this is are you intending on using this to just build and maintain characters or run games with? I would say to start with just a character sheet maintainer. You can always expand later.

The scope of this is rules description with (eventually) some level of logical build support (i.e. It will do some of your math for you). If you have Windows or Wine, check out Grapevine, a Whitewolf LARP administration utility. It's not going to be a clone, but my intent is to eventually provide that sort of support system for GMs, possibly with a restricted-subset mode for players (one of the problems with grapevine is that, if you want everyone to have access to their own character sheet and such, you basically end up passing around the whole gamefile, and run into synchronization issues between users. Definitely a "version number" sort of thing, at least.

2. Figure out which systems you intend on supporting at first. White Wolf? AD&D (if so, which edition? 2? 3? 3.5? 4?)? You can always add systems later, but trying to solve ALL systems is going to doom you to failure. I would suggest just supporting what you play right now. You will need to refactor later anyways, so embrace it.

My plan right now is to try and generalize the data structure so that it can cover White Wolf, D&D3.5, and Paranoia (which will be simple enough if you can cover White Wolf). As far as which ones I'm actually going to try and handle making a valid configuration file to handle in the first release... definitely one, either White Wolf or Paranoia. Paranoia is simpler, White Wolf is an itch I'm more likely to scratch, and would be closer to a complete test of this.

3. How amenable do you intend on being to supporting house rules? Initially, I would say no.

I definitely intend on there being support for player-created traits and such. One advantage of loading the description of the system from a description document is that it seems like it would make it fairly easy to support multiple cascading documents. So that, for instance, loading White_Wolf.xyajsonml would get you the standard traits, and then you would load "White_Wolf_User.xyajsonml" and superimpose trait redefinitions and new traits.

I think this provides for a fairly graceful path for building the system. At first, you can only edit the main file to add house-rules and user-created traits. Then you can load a second file to do so. Then, finally, you can do so in-GUI.

That seems like a very sensible release schedule, with the caveat that I might want to be able to load and display a system's rules for characters before having a character to display. Maybe not, though... I still have a lot of planning and thinking to do before I start coding ;-)

I've found this really helpful, and I may very well take you up on your offer of help. I do have to say that I'm a little worried about being overwhelmed... this is my first non-school/trivial programming project, and I do definitely want to collaborate with people on this... but I also feel like I need to have SOMETHING that I made that's remotely functional before I bring people in. Maybe it's just insecurity, but I feel like, if I don't have some of the skeleton first, I risk being a useless appendix on my own project.

That being said, I'll definitely take a look at DBM::Deep, and I'll let you know when/if I'm ready to open it up. Thanks VERY much for the detailed analysis... the suggested roadmap especially is really useful.

for(split(" ","tsuJ rehtonA lreP rekcaH")){print reverse . " "}print "\b.\n";

Replies are listed 'Best First'.
Re^3: RFC: RPG ;-)
by dragonchild (Archbishop) on Nov 06, 2008 at 22:39 UTC
    Take your time and don't feel the pressure. It's a lot easier to edit than create.

    I do definitely want to collaborate with people on this... but I also feel like I need to have SOMETHING that I made that's remotely functional before I bring people in.

    That's like cleaning the house before the maid comes to clean the house. Think about it.

    Now, if you're worried about losing control or creative direction, then the best solution is to get a Git repository (from github) or SVN (from svn.ali.as, for example) and just allow people to check into their branches. You are the only person to merge into the trunk. That way, at least at first, everything has to be reviewed by you. This also has the neat benefit of you reading everyone else's code and having the ability to ask them questions. You'll learn a lot. :-)

    Don't worry about system rules - remember, those are going to be mutable. And, what you write first isn't what the user is going to see first. In fact, it's very likely that what you write for 0.01 won't make it into 1.00. Well, those specific lines of code won't, but what's built from them will.

    Lastly, and I cannot stress this enough, you have to work in small chunks. Otherwise, how on earth are you going to be able to test them? In just those tiny pieces of functionality I mentioned, there's at least a 3-1 test LOC to code LOC (Lines Of Code). It's only going to get bigger from there. Think about it.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

      Very good points.

      It is a bit silly, isn't it?

      I think you're right... I'll set up a git repository and get this out there as soon as I get design and requirements stuff better thought through. And if I end up controlling the trunk for merging purposes, that pretty much means I have to get to where I can understand anything that gets merged in, which can only help with learning.

      for(split(" ","tsuJ rehtonA lreP rekcaH")){print reverse . " "}print "\b.\n";
[reply]
[d/l]
        . . . as soon as I get design and requirements stuff better thought through.

        *smiles* You know you need to be able to create and manage characters. All characters have, at the least, a name. Just get that up and running. Managing to adequately test a Tk application is going to be tough enough to set up without worrying about a bunch of features. Don't over-design. You have a well-defined, if very minimal, deliverable, so deliver it already! :-)

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Meditations