Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: RFC: RPG ;-)

by dragonchild (Archbishop)
on Nov 06, 2008 at 14:55 UTC ( [id://722011]=note: print w/replies, xml ) Need Help??


in reply to RFC: RPG ;-)

Where to start? The following should be done in order.
  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.
  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.
  3. How amenable do you intend on being to supporting house rules? Initially, I would say no.

Those questions are going to define the initial scope of the project. For the first 0.01 release, you should make the scope as narrow and tight as possible. Remember, you're going to "release early, release often". It's hard to release early (like in 2 weeks) if you have more than 20-40 hours of work to do.

Now, let's take a look at tools. You're right to look at the data structure first. Programs are nothing more than data manipulation and visualization tools. So, 0.01 should be that and just enough of a UI to manipulate what you release. Then, as you refine the data structure, you will refine UI and vice versa. But, start very very small. A possible release schedule might be:

  1. Fire up the UI and create a character with a name. Additional features (each one tested):
    • Be able to save the character.
    • Be able to retrieve it later from a list of known characters.
    • Be able to delete it.
    • Be able to change the name.
  2. Define a trait. This includes (all tested):
    • Name a trait. Guarantee the name is unique.
    • Provide descriptions (long and short).
    • Be able to modify, delete.
    • Be able to find traits. (Search is very very difficult. Providing a good UI is even harder.)
  3. Connect a trait to a character. This includes (all tested):
    • Altering traits connected to a character (adding, deleting).
    • Providing a number of 'points' a character has in a trait.
    • Preventing the deletion of a trait if any character has it.
    • Adding to the UI (find all characters with a trait, etc)

Just getting to that point will take a good 2-4 weeks. I think we would start there. And, yes, I'm offering to help out, but on one condition - the initial datastore be DBM::Deep (which I support). I want to get some real-world usage of it in a database-like setting because I want to add search capabilities to it, possibly using Data::Structure::Utils, possibly even using Presto as an overlay. The datastore can change should this project exceed the capabilities of DBM::Deep - I don't care. I just want it to be the first if you want my help. :-)


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?

Replies are listed 'Best First'.
Re^2: RFC: RPG ;-)
by pobocks (Chaplain) on Nov 06, 2008 at 22:26 UTC
    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";
      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?

        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";

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://722011]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (3)
As of 2024-03-29 14:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found