http://qs321.pair.com?node_id=83925


in reply to Daft text adventure project

I am well aware that the advice of many here will be simply 'don't'. I am not deterred.

Brother, praise your determination! Many's the new disciple to the wisdom, magesty & magic of PERL, but few are so eager! This is a Good Thing. Don't let it go. It seems that you've been wresting with this for some time now & are not deterred, blessed be!

Here's some advice & maybe a little bit of a simplified explanation of what has been said before:

Since you are new to PERL and OOP, you are right to stick with functional programming for the time being to get out your first revision. However, anyone who has written a game that has to keep track of 'critters' in the backround, moving about & doing dirty deeds in deep dark places or whatever, will learn that OOP was invented for just this sort of problem! What you are creating in essence is, a simulation. Each monster would become an object. Each room would become an object. The relationship between them would be "contains". In this way, you don't need to hard code a monster's movement (unless you need to for some storyline of course) all you would do is to create a method called "move" in the monster class. It would find the room that contained it, see how many exits there are & say pick one at random to go through. Then you could call all of the monsters every turn or so & call to the move method on all of them. This is much simpler than how you're dealing with it. BUT, you've got to start your whole design from scratch to make it OOP friendly. If you're already drowning in code (which it sounds like) then this would probably be another Good Thing. But again, don't change cars in the middle of a race. Aim for that in version 2.0

As for the question of the use of my.. Yes, you should always use it. It helps! Especially when you have a lot of code to deal with. And yes, it is normal to have a lot of declarations at the top of your code. But, as pointed out earlier, this can illustrate a problem in your design also. Rather than using a gaggle of global variables to deal with your data, look at it from a 50,000' aerial view... See the patterns in the data usage & build yourself Data Structures that more appropriately deal with the problem. Limit their existence to only where they are needed so they can't step on each other. You're going to want to deal with array & hashes & yes - references. I will tell you this right up front: PERL makes references Easy. So take your enthusiasm & use it as fuel to get through the textbook time & learn about them. You'll be glad you did.

I will point out that T$R, though they are going towards an open platform of sorts is still very much the owner and junk yard dog of the intellectual property rights involved in their gaming system. (i.e. AD&D) So I would be very careful about saying that "I'm making a game that's D&D" or whatever. Especially if this is going to be a MUD/MOO. Or especially if you ever plan to bring the product to market. Besides, their system is overwrought with problems & overcomplexities. Use GURPS. (Steve Jackson Games) It gives you more freedom through simplicity; and remember, Laziness is a virtue!

HTH!



Wait! This isn't a Parachute, this is a Backpack!

Replies are listed 'Best First'.
Re: Re: Daft text adventure project
by Tiefling (Monk) on May 29, 2001 at 18:06 UTC
    On copyright points: There was a degree of sarcasm inherent in my earlier allusion to the Open Gaming Licence. For reference, this is not going to be a MUD/MOO in the normal sense, nor is it going to be distributed. (Although, of course, if it were made suitably modular, rewriting certain elements could produce an engine that was OGL-friendly, so that I could distribute. But all that is far in the future. For the time being, this project may be considered a utility for personal use only. I can't be investing in GURPS. I'm out of bookshelf space, and as I write for the RPGA, I am somewhat tied to D&D. 3e is much, much more modular and coder-friendly than earlier versions - that's what inspired my dream of automating the system. (Although combat will be a kludge, since I'm _not_ providing floorplans of every room.)

    Again, I understand the principles of OO that you describe, in the same way that I understand, say, heavier-than-air flight. I understand that it's possible, and could explain it to someone else, but I couldn't do it personally. Not yet. To continue the analogy, the present implentation is a hot air balloon (QBasic was diving off a church tower with feathers glued to my arms), and the OO version will be my aeroplane (or helicopter).

    Perl may make references easy, but I have to confess I'm floored, even by merlyn's lovely books.

    And obviously, if the PCs and the monsters were both subtypes of the same class, they could presumably possess the same movement routine, called in different ways. I think.

    Tiefling
      And obviously, if the PCs and the monsters were both subtypes of the same class, they could presumably possess the same movement routine, called in different ways. I think

      Actually the way it would work would be that they would both inherit from a common class (prototype critter?) and therefore would be called the same way, via say the hypothetical "move" method. But, you would override the move method to make it function differently depending on the type of NPC or to add an interface for the PC's. But you would still call it by the same method name. i.e. move



      Wait! This isn't a Parachute, this is a Backpack!

        ...called the same way...

        Doh. I didn't express myself clearly, because I wasn't thinking clearly. I meant more or less what you just said. What I was thinking was that monsters (and generic NPCs, but not most other NPCs) would have a 'move me' feature which gave them a certain chance of making a random move, while the PCs would have their moves specified by input, and the special NPCs by hard-coded behaviours, although all these would end up being the arguments of a single move action. (The effect of which would be to put the moving object into the exit, and keep it there until the travel time had elapsed.)

        By the way, I currently have an idea of timestamping actions, so that multiple players can sit at a single terminal (and indeed, I don't have the resources or skill to do it any other way) and take their characters actions when the time comes around. This requires trust, but I anticipate that anyone making unauthorised moves for a fellow player will immediately have his ale taken away, or something. At least, it's for use at my own home, where such a result is inevitable. :-)

        More thanks,

        Tiefling