more useful options | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
The biggest item I'd like to point out is that your flow control is flawed. You're using subroutines to call themselves and each other without ever returning, causing the stack to get deeper and deeper. I'd suggest instead that you have a control loop like this:
Then, in the cases where you're calling xxxxxxxCommand(), you'd instead just use:
Obviously, you can skip the assignment if you're already *in* the hallway. It looks like your game will be fun when you get it ironed out! But you're working too hard right now: there's duplicated code in various places. Whenever you see code that's duplicated, or is *similar* to code in other places, you should think about methods to turn it into a subroutine. For example:
In many (?all?) room, you have similar code. The problem as I see it is that you're individually managing each item by name (i.e., with a separate variable), which is pretty much *forcing* you to write all those duplicated lines of code. I'd suggest making a hash hold all your objects, so you can write a subroutine to display what you see, kinda like this:
Then in your various rooms, you can display the items with a single subroutine call:
And when you want to pick something up, you just reference the object in the hash:
Notice that you may want to change the description as you do things with it, so your inventory doesn't look like it has a desk in it! Also, it can simplify your inventory, since HAVE is just another location. There are other things you'll eventually want to tune up, but other monks have caught many of them, so I'll leave them out for now. Note: I find that when working to improve on a task, like writing, I try to learn how to fix a couple of things at a time. It's too difficult to learn 10 things at once. So when I was learning to be a writer, I had my editors give me a "top five" list of faults in my writing after they review each article. I'd review my next article with those points in mind, and eventually, I'd learn one well enough that it would fall off the list to be replaced with something else. That's when I learned another thing: You'll never be perfect at it, as someone can always come up with a "top five" list of things for you to improve on. Though, when you get really good, they may have to review a *lot* of material to find all five! One more point about the "top five" list: Sometimes people will add an item to the list that isn't really a fact but an opinion. If you ever question an item on the list, double-check it with others to check. For example: code indentation and braces are a hotly contended topic. But for most languages, there isn't a "best" way to do it, usually it's just style and opinion. A few languages have relatively firm conventions that you may want to adhere to, such as those primarily used in a single IDE that insists on reformatting to it's convention. While opinions differ on where your braces go, I believe that *consistency* is quite important. Luckily, you're doing quite well on that. It makes the code easier to read and maintain. Every once in a while, I get a bit long winded, and that obviously happened today. So to wrap it up, I'd task you with a "top two items":
Keep it up, it looks like you're doing well and having fun. I'm looking forward to updates and future questions. ...roboticus When your only tool is a hammer, all problems look like your thumb. In reply to Re: Text Based Perl Game
by roboticus
|
|