• Super Search is your friend !
  'rpg' or 'adventure game' would provide useful links like
  RPG rolls or Rule Based Game Engines for example
• Use strict shouldn't be avoid !
  Just understand that it will HELP you avoid mistake, and find somes quite tricky !
• use strict and lexically scoped variables (my) don't prevent you to use large quantity of data
  (I'd suggest to store your data in (separated) files and load them in your lexically scoped hash, for example, at execution.)

Thanks for your fast response!

In order:

1: SuperSearching for 'text adventure' yielded the useful fact that I'm very far from the first person to try this flavour of thing for a first project. Thanks for the further links.

2: I appreciate the benefit of use strict - I was just wondering if the twenty or so lines of multiple-argument my commands it will require were normal.

3: What, exactly, does 'lexically scoped' mean? As a mathematician, it suggests something like 'having a alphanumeric string value' to me - is that correct? I'm already storing my data in files and loading multiple hashes with common keys at execution.

To explain that last bit in a little more detail, so as to help those who would help me:

In an inheritance from the QBasic implementation, everything has an identification code, such as R001234 (for rooms) or Z054321 (for spells - S was taken by another feature, so I used my scrappy knowledge of German to implement a poor mathmo in-joke), which is used to key all the hashes for the given type. Some hashes are keyed to more than one family of codes. For example, the PC races and the general species classes ('Humanoid', 'dragon', etc) both call the same hash for their names and superspecies references, so that the routine which classifies creatures can be fed a race or a species and won't quibble.

Thanks again,

Tiefling

• 2. several my ($var1,$var2,%hash1); lines is ok.
  Learn to use hash/array to reduce the number of variables and group them in useful structure.
• 3. Super Search my frien, Super Search is your friend.
  Almost all is said in my and local??.
  In brief lexically scoped variables are a kind of local variables.

As Jepri said you'll probably have to play with Objects,
as he already suggested perlboot, I will only add perltoot and Object Oriented Perl
(I haven't read it yet but I've only heard good comment about it...)

"Only Bad Coders Code Badly In Perl" (OBC2BIP)

In the meantime you can build yourself a function library by reading through perlmod. As always I recommend using the example there to start your module building experiments.

Modules are just like adding functions to Perl, but you can also add variables full of data. You just set them up in the module, export them and then any program that calls a use module; will be able to use those functions and variables. The declarations happen in the module, so you can declare hundreds of variables (but you shouldn't) inside the module and then use them in the program.

Doing that will give you a firm basis for moving into object orientated programming, since packages are the basis for objects. ( I think they are actually classes, but I'm just learning this stuff too ).

____________________
Jeremy
I didn't believe in evil until I dated it.

This all sounds very positive! I am aware of OO principles, but (for a variety of reasons) I'm sticking to pure function Perl initially. Hopefully, if I do a sufficiently good job first time through, then an OO re-write will be either easy or unneeded. I presently lack a home 'net connection, so building a function library will require care, time and floppies. I wasn't overtly aware that modules could be used to generate data, although I guess I'd have known if I'd thought about it for half a nano. However, as I will almost certainly want to use a 'god mode' for at least some of the game-world development, I'd need to be certain that such a usage was open-ended, rather than binding in a fixed quantity of data at the export time of the module.

Thanks!

Tiefling }:-)

For the 'back' feature: You need a whole new interface for that, whether you implement it in object-oriented perl or just in function-perl.

You'll have to rewrite every instance of changing a variable to use code that remembers that chance. So instead of saying $foo++ you would say something like increment( $foo, $undo_stack). Because of inheritance, this is somewhat easier to mix in some OOP code than into non-OOP code, but your that really depends on how you have written/will write the code.

Anyhow, you have to put into an extra layer between your normal code and the change of variables.

I would use a undo-stack of a certain size (depending on the amount of resources you want to use). You can only undo the action that has been pushed onto the stack the last. When the stack exceeds its predefined size, you 'freeze' the first action of that stack into the vars.

Many GUI-OO libs have a predefined undo-class. However, you need to write your own methods/ childs to define undo-actions for your own code...

Hope this helps,

Jeroen
"We are not alone"(FZ)

Actually, since (as is typical in this family of software) I'm writing a different kind of data at each step, it's not as difficult as you might think.

Here's a little pseudo-code to illustrate:



initialise_stuff;
set_abilities;
set_race;
set_class;
set_skills;
[download]


That's the way (roughly) that it looks now. In my bad old BASIC days, I'd simply have had a GOTO triggered on the return value of each procedure to send the program back a chunk if the user asked to go back. Since you're given the chance to review any decision you make at the time you make it, this should allow procedures called to offer up the previously made choice for revision (and if it doesn't, I'll re-write the procedure so that it does) - I just need a clean way to drop back a stage on the appropriate return value.

Tiefling

My mind is not in general compatibility mode, apparently.

Does this mean that you only allow the user to correct his input? Otherwise, the state of your program has changed since that step, because variables/objects have been altered. So you need to revoke these alterations.

Checking for return values is really simple in perl:

#This example is wearn out to the bone due to it's general use
open FILE, 'data.txt' or die "Could not open data.txt: $!";

#in general, if function() returns either false or some true info:
MAIN: {
    initialise_stuff;
    ask_user();
    function( @_ ) or redo MAIN;  
    ....
}
[download]

Jeroen

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!

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!

The one I'd recomend looking at is Circlemud. As far as text processing, you're not going to find useful information being that you're writing this is perl and circlemud is written in C; but as far as the structure and implemenataion of races, skills, spells, etc.. it would be an excelent refrence. IMO, things like their magic system could be improved.. and it might have being that I haven't looked at this code in over 2 years. But there's probably a lot there that you can draw from since this has been an evergreen type of project for many years.

As far as having a bunch of constant data declared, It's pretty common. In perl, I'm not exactly sure of the socially acceptable way of doing this, but if you look at the header files for any (well written) C program, you have declaration upon declaration of constant data. Wether you put that at the top of your script or put it in another file that you include or require is a matter of style and what's socially acceptable. Personally, with something as large as this, I'd farm out all the constant declarations to a seperate file. It helps to keep things as simple as possible. I'd also try to keep all systems in a seperate file. For instance.. all combat related subs would be in one file.. magic in another.. communication in yet another.. etc..

Hope this helps..
Rich

Last things first: the idea of storing separate routines in different files sounds nice - especially as the creator and adventure software will be distinct, but share certain functions. How is this achieved?

As for the use of CircleMUD or the like: I don't know any C, despite other hacker friends singing the 'Code in C' filk irritatingly, and I don't want to overburden myself, as I'm already dealing with a new job and learning Swedish. Moreover, lots of MUD software I've seen has ignored the 'zero-one-infinity' rule, and allowed for, for example, at most six exits from a location, each with a fixed name. I want _very_ flexible exits - preferably allowing more than one with the same name, and a descriptive menu to allow you to choose between them. (This is partly because I want the spell fly to have some real application, and I'm somewhat unwilling to code separate locales for the airspace over every street-level area. Consequently, the option to have ten or so exits called 'down' would be a plus.) And the magic system is going to be as close a port of D&D 3e's system as I can manage (probably by having the spell file call routines via eval, and keeping the spell effect routines in a distinct file, as suggested.

Thanks!

Tiefling

Undersatandable if you don't know C. Just thought I'd throw it out there in case you did. Ad far as using different files, you're going to want to look at use and require.

There's some significat differences between the two and you're going to want to read up on them first. A basic example of require would be..

#!/usr/bin/perl -w 
#
# This is the main script
#

use strict;
require "test.pl";

somefunc("test");
[download]

And the required file...

#!/usr/bin/perl -w
# 
# This is test.pl
#

use strict;

sub somefunc {
  
  print shift, "\n";
}

1; #file needs to return true on require or use.
[download]

Now this probably isn't a good example, but it shows you the basic usage. You're probably going to be better off creating modules and useing them instead. I'm still relativly new to perl so I can't give you all the reasons, but the 2 bigest benifits of modules and use will be 1) you're not going to (or you can avoid) polluting your namespace. Which means you can do something like DaftMagic::Cast($source, $target, $spell); where "Cast" doesn't exist in your namespace. Keeps things a little cleaner. 2) Things are loaded at compile time instaed of run time.

I'm sure others could give you the pros and cons of requiring files vs. using them.. and the usage of modules. There's also some other reading - perlmod, perlmodlib, perltoot, and perlobj.

HTH..
Rich

1. How to store routines in separate files:

#file shared1.pm:
use strict;
sub xxx1 ($\%\@@) # define xxx1 with prototype
{ blah blah;
  return ...;
} # end sub xxx1

use Exporter(); @ISA=qw(Exporter);
@EXPORT = qw(xxx1);   # exports name xxx1
[download]

-----------------
Now, in your main.pl program file, you may call subroutine defined in shared1.pm above:

use strict;
use shared1;  # 'include' shared code

...
# call sub defined in shared1.pm
my $result = xxx1($arg1, %arg2, @arg3, $optarg1, $optarg2);
...
[download]

---------------------
2. In project this huge, I advise to use not only 'use strict' everywhere, you may want to learn how to do 'prototypes' as well. It will help you to detect (some) errors when wrong numbers or types of parameters are passed to subroutine. While on that, you can also learn to pass hashes as references. Good luck on your long jourmey! PMAS

---
A fair fight is a sign of poor planning.

Tell me about the data dumper, please, brother. The aforementioned hacker friend said that there was a capacity for hash-dumping, and if the first draft of the program is to retain the current way of handling the data, such a facility would be ideal. I've tried to find out about this before, and failed. (Don't say 'use Super Search', because I'm wasting office time on this thread already, and I don't have a home connection ... yet. I'll do a proper search for all these things later - I greatly appreciate the input of my fellow monks right now. Bless you all.)

1) Ok, I believe you all about use strict. :-)
2) This is clearly what I have to learn next.

3) Absolutely. It struck me that I'm going to have to recode the room data by hand, because I'm going to want the olfactory, visual, auditory and tactile/environmental data of each room to be accessible in bits, to allow for the spells blindness and deafness, not to mention darkness and other environmental effects. Clearly, using a format that will enable me to add other such elements later without another re-write is essential.

Thanks!

Tiefling

this is a real simple breakdown of the code ...

its quite simple to do, and not very difficult to figure out :)

to read a file:
$filename = "$player_dir/$temp";
do($filename);

to save a file:
print FILE Dumper \%myhash;

Mbond.

 my $sword = Sword->new("Excalibur");
 my $damage = $sword->damage($someOtherPlayer);
[download]

Best of luck with this project!

updated: clarified use of prototype

• It's a bit late, since you've obviously already put a lot of work into it, but I'd suggest you look at what other MUD and text-adventure authors are doing now. Text adventures have come a long way since Infocom. Check out the rec.arts.int-fiction newsgroup http://www.faqs.org/faqs/games/interactive-fiction/authoring/part1/ , and look at the engines at http://directory.google.com/Top/Games/Video_Games/Genres/Adventure/Text_Adventures/Design_and_Development/Authoring_Systems/ (Inform and TADS are arguably the two most used systems. Inform is probably the most powerful, with TADS having an easier interface while still being flexible) (the main IF archive can be reached at http://www.ifarchive.org/
• You mention that references confuse you. No problem. Here's my attempt to explain them, which differs from the typical "It's a pointer" explanation.

Thanks!

I have looked at the existing state of play, and the conclusion I draw is that if I were only ever going to be interested in writing an RPG or IF I would certainly get, learn and use Inform. However, I am doing this with the two equally strong interests of writing an RPG and getting really good at Perl, OOP, etc. So I'm determined to do it the hard way, so that at the end (if there is an end), I can say 'thus did Tiefling', and understand every bit of my code. Also, I'm not sure how receptive Inform (for example) would be to an attempt to build all the core D&D character classes and several prestige classes.

As a note, I will be producing (in the end) a modern-setting version of the game which will lack the specific copyrighted identities, and be a bit more in the whimsical line of early text adventures. This will be posted here on PM, in all likelihood.

As for your explanation of references - thanks! This looks like the way to implement the first Perl version of my project. One question: is the long string in your penultimate line a single scalar for all purposes?

Oh, and another: Could I include lists in that hash by reference? (Storing feats, spells, etc. as booleans is not efficient, IMHO. I want to be able to brew a new feat and not have to go and set the bit in all the PCs.)

And another: If, for example, $character{'Bob'}->{'Class'} holds 'Ftr', and $class{'Ftr'}->{'Base Attack'} holds 'Good' (to indicate that fighters have Good attack bonuses, which are generated by a short procedure in the combat module), what would be the code to retrieve Bob's Base Attack type? I may be being dense here, but I'd rather be clear.

Thanks again!

Tiefling

So I'm determined to do it the hard way, so that at the end (if there is an end),

Doing it the hard way is a time-honored tradition :) I just suggested you check out how the others work so that you can steal good ideas & interfaces.

is the long string in your penultimate line a single scalar for all purposes?

You mean $character{'Bob the Fighter'}->{'Attributes'}->{'Str'}? Yes, because in the end it is just a value stored in a hash, and only scalars can be thus stored. By dereferencing part of that mess, you can get a hash. For example, %{ $character{'Bob the Fighter'}->{'Attributes'} } is the Attributes hash. (The scalar value $characters{'Bob the Fighter'}->{'Attributes'} is a reference to a hash. the %{ } dereferences the reference.

Could I include lists in that hash by reference?

Absolutely. A reference to anything is a scalar, and a hash can store a scalar. An anonymous list can be created by [], or you can use the backslash reference. So:

$characters{'Bob the Fighter'}->{'Feats'}= [ 'Strong Spit', 'Perl Guru
+'];
# or
@feats = ('Strong Spit', 'Perl Guru');
$characters{'Bob the Fighter'}->{'Feats'} = \@feats;
[download]

both work just fine. You can then access them like:

$characters{'Bob the Fighter'}->{'Feats'}->[1];
#is equal to 'Perl Guru'
[download]

Remember that although we're using a hash as our "base" variable here, we could use any other data type that is appropriate. A list could work:

$characters[3]->{'Attributes'}->{'Str'};
[download]

as could a scalar:

$characters->{'Bob the Fighter'}->{'Attributes'}->{'Str'};
[download]

(Assuming you had stored the data in that fashion.)

If, for example, $character{'Bob'}->{'Class'} holds 'Ftr', and $class{'Ftr'}->{'Base Attack'} holds 'Good' (to indicate that fighters have Good attack bonuses, which are generated by a short procedure in the combat module), what would be the code to retrieve Bob's Base Attack type?

Well, $class{$character{'Bob'}->{'class'}}->{'Base Attack'} would be equal to $class{'Ftr'->{'Base Attack'} (actually, it would _BE_ the same, since all that happens is $character{'Bob'}->{'Class'} resolves to 'Ftr') However, this assumes that Bob's class will ALWAYS have an entry in %class.

Storing feats, spells, etc. as booleans is not efficient, IMHO. I want to be able to brew a new feat and not have to go and set the bit in all the PCs.)

Just so you know, Perl handles non-existant hash keys quite nicely, and it's quite common to see code that would be like:

if($char{Bob}->{Feats}->{'Good With Pointy Objects'}){
    Kill_Bad_Guy();
} else {
    Die_Hideous_Death();
}
[download]

If Bob doesn't have that feat, you don't have to set it to 0, you simply don't set it to a true value, and it will evaluate False. (Well, undefined, which in turn is false)

-- Randal L. Schwartz, Perl hacker

Odd... after 30-ish posts in this thread, I still haven't seen anyone mention PerlMud from the brlliant Tom Boutell. I guess it's up to me! {grin}

Thanks! I remembered having heard of such a project, but couldn't recall where or exactly what. Thanks very much for filling me in. Duly downloaded, and I'll install it tonight.

Of course, as one of the intents of my project is to provide sequential play for multiple users at one terminal, PerlMUD won't *exactly* fit the bill, but by heck, it's going to be worth a look.

Tiefling (Alex Roberts, not a Perl hacker)

Not only should you use strict;, you should embrace Object Oriented Programming concepts. As such, the undo is trivial—copy the object first and throw it away rather than copying it back with changes made. Learning how to architect a large project uses totally different skills than learning how to write in Perl (or whatever language).

—John

Edit 2001-05-30 by mirod: fixed typos

Update: I can imagine how much of you, fellow monks, frowned when I proposed to use MS Access as database of choice. No so fast. I assumed Tiefling does not have experience with databases (otherwise he will used DB right away when run out of data space). MS Access is excellent for prototyping in Windows environment and has excellent 'wizards' to help with building SQL queries graphically and to visualize tables and their relationships.

pmas

I'm afraid this is the first helpful suggestion that I'm going to have to turn down wholesale, for a variety of reasons:

1: I don't want to have to learn how to make Perl read a database created with some external package.

2: My work involves two databases, one MS Abcess, the other SQL. I've just spent a hellish afternoon trying and failing to produce a list of items from a given list once each exactly in the SQL database. I know I could have written Perl to do the same thing, given an appropriate data structure, in about 5 minutes. I'm trying to learn, yes, but I'm doing this for fun.

3: I have the version of Perl I got with Redhat Linux. I don't see Access for Linux anywhere, and I'm not about to start going to the mountings of the Windoze directories to fetch data. The adventure is intended to be self-contained.

4: Judging by my experience today, transitive exits would be quite a challenge in SQL, etc. I'd rather produce my own editing features, integral to the program, so that I can tinker as I go.

The game is intended to be multiplayer, in the sense of sitting around a single machine. AI is an option. But I'm not quite clear how drowning in SQL helps me write AI later.

Sorry to discard your advice - I'm just not a databasey person! :-(

Tiefling

So...In trying to support the "Daft text adventure project" I was totally harshed.

Perhaps I should have done something like: <sincerity>Heh, heh, heh...What an ambitious project! Good luck!</sincerity>

That might have made everyone feel a bit better about it, eh? If one were to peruse my write-ups, a comment made regarding community might have staved off some of the negativity regarding my post. Perhaps not.

I really, really do wish Tiefling the best of luck in the project; I know that the project will be supported in any way possible through the Monastery. It is a huge undertaking, but everyone loves a challenge, yes?