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!