Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re: Daft text adventure project

by rchiav (Deacon)
on May 29, 2001 at 17:07 UTC ( #83914=note: print w/replies, xml ) Need Help??

in reply to Daft text adventure project

Now this isn't very perlish, but if you're at all familiar with C you might want to look at some MUD code to flesh out your implementation ideas.

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

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


      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 ""; somefunc("test");
      And the required file...
      #!/usr/bin/perl -w # # This is # use strict; sub somefunc { print shift, "\n"; } 1; #file needs to return true on require or use.
      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.


      1. How to store routines in separate files:
      #file 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
      Now, in your program file, you may call subroutine defined in above:
      use strict; use shared1; # 'include' shared code ... # call sub defined in my $result = xxx1($arg1, %arg2, @arg3, $optarg1, $optarg2); ...
      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

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (7)
As of 2023-02-01 22:23 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (14 votes). Check out past polls.