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


in reply to Re: Daft text adventure project
in thread Daft text adventure project

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

Replies are listed 'Best First'.
Re: Re: Re: Daft text adventure project
by rchiav (Deacon) on May 29, 2001 at 18:50 UTC
    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

[reply]
[d/l]
[select]
Re: Daft text adventure project - from pmas
by pmas (Hermit) on May 29, 2001 at 23:25 UTC
    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
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom