API = Application Programming Interface. It's often used to describe the way a given module is meant to be used.

Ok. Here's how I'd begin designing this from an OO perspective:

  1. Start by listing out every single thing you think you might want to have. Weapons, armor, characters, buildings, mountains, etc. Don't group things right now. What this step is doing is to give you a pool of ideas to work from. (You can't edit nothing ...)
  2. Group like things together. So, all the beings (farmers, orcs, and fighters) get grouped under the "intelligent being" category. Armor and weapons are group with rings and relics, under "thing".
  3. Start identifying how a orc, a farmer, and a fighter are similar. What do they have in common? IMPORTANT: Don't worry about how you'll use that functionality. That's not the point. You want to have an idea of what shared methods and attributes they'll have. For example, every single PC, NPC, and monster has hit points. So, a RPG::D&D::Being::Generic will have an attribute for hit points. Orcs, farmers, and fighters will all inherit from RPG::D&D::Being::Generic, thus all of them will have hit points.
  4. Then, identify how they're different. This can be both how they're different in kind (orcs and farmers have different goals) and how they're different in treatment (you'll want different info for a PC fighter vs. an NPC fighter).
Now, you've got the start of a class hierarchy. Remember to identify what can be stored as an attribute and what needs to be a separate class. The rule of thumb I use is to see if there is fundamentally different methods used by only that difference. So, if being a cleric adds significant difference, there should be a cleric class.

You'll end up re-writing a lot of this for your first time. Don't be afraid of that! Re-writing is good for the soul.

Now, you have the first type of object down - the "thing". The second type is more difficult, intuitively. This is the object-as-process. Maybe a little discussion will help.

A battle between 4 players and 4 orcs is a very defined thing. It has a start, a middle, and an end. It takes given input (combatants, time/weather, map, etc) and transforms that input into output (orcs dead, players victorious).

Based on that, it makes sense to make a Combat class. You instantiate a new Combat object every time you have a battle.

Given that, run through the steps above again, but this time for processes instead. Do every single step. It's more critical to do that here. For example, would you consider a skill or a spell to be a class? I would, because they have a beginning and an end.

Yes, this sounds like you're going to have a lot of classes, and you will. But, if you do it right, it makes maintenance really easy. For example, if you want to change how all spells work, you have to go to Spell::Generic and make the change there. Voila! All spells do this new way. Same with skills, or combat, or weather, or whatever.

What if you wanted to add a new skill? The way you do it right now, you'd have to add a line to a table, then modify another line in the character classes to say who's allowed to use it, then add a function to handle how it works. Instead, you just add a class. The skill knows who is allowed to use it or not. The skill knows how to "do its thing." Once you add the new class, everything is added and you've added a file and changed a file (to link in the new skill, wherever it has to be linked in to).

I hope this makes sense. I would be very interested in working with you on this, either on perlmonks or via email, if you'll have me. (I wouldn't want to take over the project ... it's yours! But, I'd like to be sort of a ... design consultant, so to speak. *grins*)


In reply to Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure by dragonchild
in thread Modules: Building blocks for the Daft Adventure by Tiefling

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.