Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: Modules: Building blocks for the Daft Adventure

by dragonchild (Archbishop)
on Jun 12, 2001 at 16:33 UTC ( #87785=note: print w/replies, xml ) Need Help??


in reply to Modules: Building blocks for the Daft Adventure

While everyone else has answered your question quite well, in terms of the technical Perl aspect, I would like to comment on the design of your application. (This is in no way meant to imply that I know everything that you're intending on doing, nor is it meant to imply that I have The Right Way. I merely wish to offer ideas, given my package experiences.)

You are looking to write a series of modules that will help you develop a comprehensive D&D application. The key word there is "application". I don't know what your background is in Perl or programming, but the first instinct I've seen in a lot of decent programmers has been to treat Perl with less respect than they would C, Java, or any other compiled language. If you're looking to write a stable app, you need to realize that's what you're doing and design this a bit. If you intend on using this over and over, and/or extending it, this week or two in the beginning where you define where stuff lives will be absolutely critical.

"Why?", you might ask. Well, you talk about a dice-rolling function called dice(). Then, you talk about a modifer() function. As someone who plays D&D, these, to me, instinctively seem as if they belong in the same place. This is because they both deal with ability scores.

Now, the immediate response would be that dice() also deals with combat. Ok. So, dice() may need to live elsewhere, and that's fine. The question would be "Where?"

modifier() seems to imply a character module. This would have things help you generate stats, choose skills, choose spells, and moderate when someone can cast a spell or not. Sounds like a lot? Well, it is ... and it isn't. Who says every bit of code has to be in RPG::D&D::Character?

A case could be made that the top level should not know how to roll dice. All the top level should know about is characters, spells, and combat. Why? Because it doesn't care how combat is resolved. All it cares about is that combat is resolved. All the details should be taken care of by RPG::D&D::Combat. No-one else wants to know, cares to know, or should know. Same goes with character generation, skill/spell adjudication, etc.

Creating a RPG::Randomize module is definitely appropriate. Within this module could be dice(), as well as other methods of randomization. coin_flip() could be here. (1d2 is different than flipping a coin, and you should code it that way, even if it would seem that, from the theory, it is the same.)

However, the high-level manager doesn't know about RPG::Randomize. It doesn't care about the mechanics of it. (If only I could draw a picture here!)

I hope this helps you understand a little of the deeper thinking behind sane package construction. Also, please use strict in everything you do. It will make your code much cleaner and clearer.

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

Replies are listed 'Best First'.
Re: Re: Modules: Building blocks for the Daft Adventure
by Tiefling (Monk) on Jun 12, 2001 at 17:08 UTC
    While everyone else has answered your question quite well, in terms of the technical Perl aspect, I would like to comment on the design of your application. (This is in no way meant to imply that I know everything that you're intending on doing, nor is it meant to imply that I have The Right Way. I merely wish to offer ideas, given my package experiences.)

    Have you read the Daft text adventure project thread? That contains the original brief and a lot of the suggestions and responses initially produced. It also describes the origin of the program I was intending to create, and my own background in BASIC.

    The first instinct I've seen in a lot of decent programmers has been to treat Perl with less respect than they would C, Java, or any other compiled language.

    What does this mean, specifically? I was under the impression that Perl was the proverbial Swiss Army Chainsaw, capable of bringing more than enough power to bear on a wide range of tasks. How do I risk making an unstable app? (On re-reading, that question sounds silly, but I can't express it better right now.)

    "Why?", you might ask. Well, you talk about a dice-rolling function called dice(). Then, you talk about a modifer() function. As someone who plays D&D, these, to me, instinctively seem as if they belong in the same place. This is because they both deal with ability scores.

    I humbly disagree. dice() has nothing to do with ability scores specifically, or with D&D. dice() should be relevant to Call of Cthulhu or even In Nomine, as well as to D&D. modifier(), on the other hand, deals exclusively and explicitly with a property of D&D's ability scores. Perhaps an RPG::DND::Character module is mandated, perhaps not. I would incline toward thinking 'yes' here, especially given the modular nature of 3e's rules. (The dwarven defender and the barbarian have very different special abilities utilising 90% of the same 'code'.) modifier() clearly belongs in such a module, since it is absolutely specific to D&D characters.

    I'm inclined to think that the top level should know how to roll dice, since it might need to use them for explicitly defined game features (as opposed to emulation of a given rules set). However, 99% of the calls to dice() and its cousins (the functions of RPG::Dice) will indeed be made by RPG::DND::Character, Combat, etc.

    I'm opposed to the idea of coin_flip as a separate function. However, if it were required, the following line could go into Dice.pm:
    sub coin_flip{ ("Heads", "Tails")[dice(2)-1] }

    (Something tells me I can't take an element from a constant list, in which case that would have to change.)

    Apart from the difference covered by the above line, how is a coin flip different from 1d2?

    Certainly your answer has got me thinking about sane package construction. However, I'm not sure where you stand on the topic - or where I stand. This is, of course, the kind of discussion I have hoped to promote by discussing my project here at PerlMonks.

    Thanks again,

    Tiefling the Lazy

    -----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------
      (I will be responding initially to your response, Tiefling. Please read the whole post before responding. I explain myself a little better after babbling for a few minutes. :-)

      I have read the Daft Adventure thread, and I've also written similar programs myself (back in Apple BASIC). This was actually my first program over 100 lines, back in the day.

      However, given your responses, I wonder if you'd read everything I wrote. Yes, I originally said:

      "Why?", you might ask. Well, you talk about a dice-rolling function called dice(). Then, you talk about a modifer() function. As someone who plays D&D, these, to me, instinctively seem as if they belong in the same place. This is because they both deal with ability scores.

      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.

      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

      Note that this is from an extremely high level. There is no mention of how things are adjudicated. From a DM/player perspective, this is what the game is all about - making a character, choose skills/magic, and then running around a world. Occasionally, you might have to fight stuff.

      Every single action you take from this high a level should call some method contained in another module. There are several reasons for this:

      • 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.

      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.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (2)
As of 2022-05-26 02:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (92 votes). Check out past polls.

    Notices?