Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure

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:

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 ...)
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".
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.
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*)

Comment on Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure by Tiefling (Monk) on Jun 12, 2001 at 19:02 UTC
Wow...such a lot of advice. Thank you. I would certainly welcome having you, or anyone else, as a collaborator, providing that we don't breach copyright on the system we're emulating. (The initial idea was for my home group to use the system to familiarise themselves with the game and the world - the original 1800-room map being a slice of Waterdeep and Undermountain.) We can probably achieve this by considering ourselves a PbeM group, and communicating game-specific details by private email. Also desirable would be some system of our own devising which we can use to show the other Monks how we're progressing - a simple RPG of some kind which exemplifies our techniques. As for the skill table: Having the skill as a class would, obviously, be optimal. However, the existing table has the permitted classes listed in it, and is assumed to have a standard functionality, so the current version is not in fact as cumbersome as it might be. This is good, since it shows I'm thinking in broadly the right way. You mention mountains as objects. I'd been wondering about sightlines on the map, and this suggests a way of proceeding, although I'm not exactly sure how it would be done. That aside, I'd not really considered objects larger than 'rooms' to be feasible. Tiefling (making progress) `tieflet\|at\|hotmail\|dot\|com -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--) !O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y +? ------END GEEK CODE BLOCK------` [download]	[reply] [d/l]
Re: Re: Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure by dragonchild (Archbishop) on Jun 12, 2001 at 19:23 UTC
If you're worried about sightlines in a 3-D world (which is what it is), then I'd consider visualizing the world as a huge 3-D cube. Each point on the cube has different properties, and would thus be a node in this 3-D grid. One of these properties would be opacity - does light pass through? It then becomes very simple to write a procedure (if it hasn't already been done) to determine the points the sight vector would pass through, and determine where it stops. Weather would also be implemented as a modification of these values. You can get wind (for people flying on griffons), etc. This also allows for a very easy way to handle underground activities, and how those activities would interact with the rest of the world. Now, you would have a world grid, then a grid within each of the major locales, like Waterdeep or Undermountain. This would be a sub-grid, sorta. At (40,23,0), there is another grid for that place. You enter the sub-grid at a defined point, depending on where you came from. Another point that has to be made is that D&D is owned by Wizards of the Coast. I know for a fact that they tend to frown very heavily on people writing stuff for public consumption based on their intellectual property, even if you're distributing it as free-ware. So, if you wanted to do something serious, you would have to make it for private distribution only. Sorry, but you don't want their legal department hitting you with a cease-and-desist. (For examples of this, check out www.mtgnews.com and look in the news archives.)	[reply]
Re{8}: Modules: Building blocks for the Daft Adventure by Tiefling (Monk) on Jun 12, 2001 at 19:35 UTC
Another point that has to be made is that D&D is owned by Wizards of the Coast. I know for a fact that they tend to frown very heavily on people writing stuff for public consumption based on their intellectual property, even if you're distributing it as free-ware. So, if you wanted to do something serious, you would have to make it for private distribution only. Sorry, but you don't want their legal department hitting you with a cease-and-desist. Understood. Hence the suggestion that any putative development group would be like a PbeM group. We'd have access to the data, etc, for our own consumption - and it would be a help if the majority of developers ownerd the books the data is drawn from - and we'd not distribute the distinctive D&D features to another living soul. I think that sticks to the ideas of closure and fair use that WotC prefer. And hence also the idea of a low-cal implementation for the general consumption of the monks, based on some simple RPG architecture of our own choosing - perhaps even PerlMonks: the RPG? (Monk: the Coding, for any White Wolf people out there.) I'd enjoy trying to adapt my existing location system, or any other we devised, to a map of London, for example. Your description of the grid makes me tremble, I'm afraid. This was the kind of approach I'd been considering for the weather in the last BASIC incarnation, and I'd rejected it as too complex. The present map is an abstract graph, and that's an approach I'd be keen to retain. A grid probably is needed for combat purposes, but I'd prefer (unless it were actually _more_ unworkable) to define each locale as a finite union of cuboids for the purposes of the combat map, and to retain the abstract form of the general map. But then I haven't deciphered (or even played) spork yet. Perhaps that will inspire me further. If we do go for an ASCII-graphics combat system, curses is a must. Tiefling (getting keen) `-----BEGIN GEEK CODE BLOCK----- Version: 3.1 GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--) !O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y +? ------END GEEK CODE BLOCK------` [download]	[reply] [d/l]
Re{9}: Modules: Building blocks for the Daft Adventure by dragonchild (Archbishop) on Jun 12, 2001 at 19:54 UTC
Re: Re{10}: Modules: Building blocks for the Daft Adventure by Tiefling (Monk) on Jun 12, 2001 at 20:12 UTC
Some notes below your chosen depth have not been shown here


XP is just a number
	PerlMonks