|
in reply to Re: Re: Re: Modules: Building blocks for the Daft Adventure
in thread Modules: Building blocks for the Daft Adventure
However, I then said that both RPG::D&D::Character and RPG::Dice would be needed. That implies that dice() would be located in a non-D&D spot.
However, I don't want to start a flame-war. This project is obviously something dear to your heart and I apologize if you felt that I was insulting your intelligence or your design capabilities. I was merely attempting to humbly offer up some ideas of my own.
No offence intended or taken, dragonchild. I was agreeing with you! I just didn't express myself very well. I was endorsing your point about the need to separate the Dice and Character modules. Consequently, I presented my version of the arguments against your initial suggestion - which you yourself argue against further down the post. I apologise for the confusion - nothing could be further from my intentions that to start a flame war with you or anyone.
Now, onto the project!
The basic functionality you're probably going to need involves (at least) the following areas:
- Character/NPC/Monster Generation
- Skills
- Magic (both Arcane and Divine)
- Combat (both mudnane and magical)
- Items (both mundane and magical)
- Map Generation
Ok:
- Character, monster and NPC generation. In my original BASIC implementation, PCs were generated by manually writing a character into a .txt file. My present attempts at writing the character generator software are naturally designed to improve on that rather unfriendly method. Thus far, yea good. Monster generation was one of the better aspects of the BASIC version (at least first time through) - individual instances of monsters were created by reference to arrays of base statistics - a technique I would repeat in a non-OO Perl implementation. However, OO offers a more natural way to handle this - provided I can get my head around OO. NPC generation will be essentially like mosnter generation for generic NPCs - 'farmer' is much like 'orc' in most ways. Special NPCs will be hand-written, possibly with a text editor, perhaps using a 'DM mode' feature of the main engine.
- Skills are a side effect of PC generation, and have already been entered in a tabulated format. The table can be read into whatever data type takes our fancy/fits our purpose. Obviously, for RPG::Cthulhu::Character, a different, and differently-formatted list is required.
- I conceive of spells as consisting of their casting details, as data, plus specific referenced calls to procedures in RPG::DND:Magic to invoke the unique effects. Duration spells would create objects with timers, checked periodically to detect expiry.
- Combat will interrupt normal play. (As it happens so quickly, characters who are, say, shopping in the market, will have just about enough time to turn a corner while a group elsewhere fight and slay six orcs.) That will be a set fact about the game, no matter what engine is invoked, since the time-stamped actions are part of the text adventure interface, rather than the rules emulator. I had originally intended to fudge combat, but a curses-driven engine to produce roguelike floor plans does not seem impossible.
- Items should be handled by a method parallel to that used for monsters. If, as seems likely, we go OO, Perl objects' ability to inherit from more than one parent is useful: objects which are both weapons and clothes (such as gauntlets) should pose little problem.
- There is already a large map in a format friendly to the text-only BASIC implementation. An ideal Perl implementation would accept the data from this file, convert it to a 'vanilla' set for the Perl version, and leave me the ability to round the original data out to something more appropriate to the finished engine.
It makes your high level very instinctively obvious. Any new DM can, given a well-defined and documented API to your modules, create his/her own high-level programs.
It makes changing game systems very easy. You are creating RPG::D&D::* right now. However, by that very package nomenclature, RPG::Cthulhu::* is very possible. If you leave out all implementation details from the top level, switching systems is almost trivial.
It makes designing the system much easier. You don't have to remember that there is a 1% need to roll dice at the manager level. You'll know that all implementation details are hidden from the top level. You just need to have the appropriate module adjudicate itself.
But if we're employing modules that use RPG::Dice, won't we have the option, however undesirable its use may be, to access the dice rolls from the top level? I'm not saying we should - just trying to check that we could.
Now, we don't know exactly how these modules will go about doing their thing. In fact, we don't even know if they will be modules or classes. (RPG::D&D::Character may very well be a class - I find it easier to think of a PC or monster as an thing that knows how to do stuff versus a set of methods to be run on a data structure you have to maintain.) Each module will have an API (set of methods that other modules know about) and a mandate (what it takes care of for you). Once you have sketched this out, it becomes very simple to flesh out the skeleton.
Silly question: what does API stand for?
That aside, this re-emphasises to me the need to go OO. On the other hand, it leaves me scratching my head as to where to begin. Clearly the current create.pl will have to be re-written from the ground up. At the risk of picking other people's brains too much - how do people think I should start?
Suppose we have RPG::DND::Character. Would 'fighter' be best as a function or other form of data in that module, or as a separate module dependent on it? How can we produce a call to the appropriate 'new' (or whatever) function which creates the character with the statistics chosen by the player? Or should the character be created as a 'blank sheet' and then filled in?
I recognise that people will say 'It's your project: do it your way.', as well as 'TMTOWTDI'. But I'd be interested to know what (in broad terms) people think of my attempts to understand this new (to me) field of programming, and how they think I can avoid hamstringing my own project with bad implementation.
Thanks!
The grateful and apologetic Tiefling
-----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------
|
Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure
by dragonchild (Archbishop) on Jun 12, 2001 at 18:44 UTC
|
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*) | [reply] |
|
|
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------
| [reply]
[d/l] |
|
|
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] |
|
|
|
|
|
|
|
