Hidden doors

[wish]

So, a follow up to this poll is this question:

Are areas too easy to "solve"? What would make areas more difficult? In previous posts, I have talked about my pet peeves. For example, there is no way to really hide a door. No matter what name you use to code the door (e.g. hatch, portal), players can find it simply by typing the direction of the door.

What are your pet peeves in this regard?

Wish, Foul Sepiod of the Black Conclave

[Ylang]

Oh, and to answer Wish's question, yes, it would be cool to be able to hide doors (and items, for that matter) better, even if doing so requires area coordinator approval. There are ways to reduce the impact of this problem, but the fact that directions are by default also door names does significantly reduce your options. All someone has to do to discover any and all doors is to open in all directions. I have an 'openall' alias for this, for example.

Fixing this would require removing the default door names from the code, and then adding them in all existing area files (which assumed that the defaults existed and usually won't have alternative door names). The latter would be a mildly complicated search-and-replace operation, I suppose. Once this is done, it would make the area writer's job more tedious, since they'd have to manually add a direction keyword to most doors, but I think the gain may be worth the pain.


Unfortunately, I can't see how to solve this problem either. Unless the code can distinguish between existing and new areas, you can't change the code, since old areas assumed that directions were valid door names. You'd have to modify all existing area files to add the default names, and then remove the defaults from the code for new areas. (I guess this isn't as hard as it sounds, come to think of it.)

[Ylang]

I was sure I'd posted this somewhere, but I can't find it now. Maybe someone else posted this idea once... if so, apologies for the duplicate.

At the moment, all doors have their direction keyword added by default.

It would be cool if area writers could add a 'nodir' flag to a door to prevent that from happening. This would make it impossible to find hidden doors just by trying to open in all directions, and avoids the need to resort to the only half-solution currently possible, which is to make secret passages (sometimes illogically) non-passable and locked with a hidden key. An added effect would be that the 'door is closed' message wouldn't show up if you move in the relevant direction, unless the door is passable and you have pass door cast. Instead, you'd get the same message as if there wasn't a door there at all.

By using a no-direction flag on doors in new areas, you avoid the problems associated with removing the default altogether. If that was done, all existing area files would need default direction keywords added to doors.

This flag should be used only on hidden doors, and not area-wide (with rare exceptions, maybe).

This (fairly) simple change would add plenty cool possibilities for area writers.

[Ylang]

I found the original reference: Wish mentioned it, and at the time I agreed but couldn't think of a solution other than removing the default directions altogether. See posts #5 and #10 in this thread (http://forums.finalchallenge.net/showthread.php?t=1114).

[Tynian]

Thanks for the research.

I copied the posts into this thread for reference.

[Gertrude]

well i am not sure about codeing but it could be like gerteks where you have to drop urns and a wall opens but its not shown as a door whene you bump into it so it unlocks a new area.

[Ylang]

well i am not sure about codeing but it could be like gerteks where you have to drop urns and a wall opens but its not shown as a door whene you bump into it so it unlocks a new area.

I think that's a custom-written function, and works just for that zone. It certainly doesn't seem to be available as a general-purpose spec-fun. It certainly would be useful (coincidentally so for one of the rooms I'm writing), but doesn't solve the general hidden-door case.

[wish]

I suspect, (but don't know for sure!), that a lot of "area specific spec-funs" could be made more widely available to area writers. They just have not been added to the mud-editor tool. If I am not mistaken, someone took updating the tool as a project. Perhaps Tamar or Tokugawa or Tynian could elaborate on that.

[Tynian]

I can't comment on who may have been adding special functions to the muditor. I wouldn't say that there are "a lot" of area specific special functions that could be made more widely available. Unfortunately, a good many of them are not generalized enough to be suitable as generic specs.

[Tokugawa]

I suspect, (but don't know for sure!), that a lot of "area specific spec-funs" could be made more widely available to area writers. They just have not been added to the mud-editor tool. If I am not mistaken, someone took updating the tool as a project. Perhaps Tamar or Tokugawa or Tynian could elaborate on that.

I updated the muditor to include new spells and such and some things that were missing. That was awhile ago though. But maybe this is what you were referring to?

But no, there was never any plans that I know of where we could add area specific spec funs to the muditor.

-Tokugawa

[Rincewind]

I always liked the entrance to dream... but the thing is... if we make this type of change it should be mandatory that there are sufficient hints for the players on how to solve or discover custom coded hidden doors

[kaern]

I'm glad Rince brings this up because it is a very important point. Secrets must be discoverable, otherwise we run an increased risk of area writers putting in pet things for only an exclusive club who happen to have access to privileged information.

I share your pet peeves, Wish. The only way I could get around this in the Mystic Wood was by pushing all puzzles to keywords. That way, the player had known unknowns (e.g., locked chests) but the keys were hidden behind containers whose names were secret.

This worked but is hardly extensible; there are limited scenarios in which you can hide things this way and have it make sense within the context of the game.

We are all really facing the same problem: a shortage of ways to make puzzles. In fact, without the mysterious-container hack, solutions to secrets (without special-case code) are doomed to be in the finite realm of 1) find what's locked, then 2) try all objects (from all mobs) in zone.

I've been mulling this and trying to conceive of a general-purpose solution that gives the most area-writing bang for the coding buck. The thought process is more or less recorded in this thread (http://forum.finalchallenge.net/showthread.php?t=1151). It would be great to hear what you think of the ideas involved and definitely if you have suggestions on how to improve them. As it stands the new capabilities proposed would probably obviate the need to add code for hiding doors, since there would be tons of ways to create puzzles even given that the player potentially knows about all doors in an area.

[wish]

I have read your posts, Kaern, and I agree with the general ideas. Unfortunately, I am more of a "writer" and I tend not to have ideas about how the code blocks could be altered to implement new ideas. I am much more of a requirements person, as in, "This is what I want to be able to do - now please go figure out how to do it!"

You are 100% correct about the state of puzzle writing as it stands now. I just reread your post about Room and Mob progs, and I think they are spot on.

Let's face one thing, however: the real problem we have is resources. We are proposing making major changes to the game, which takes resources to implement, along with the prospect of little reward. If we build it, will they come? I suspect not.

[Ylang]

Isn't it worth writing for our current small but dedicated group of players? I think it is. If every idea that takes some work gets shot down, not with 'it won't improve the game enough for the work involved', but with 'the player base isn't big enough for the work involved', we might as well not post ideas at all.

Whether we're all old farts who should get with the times, buy a WoW subscription, and tell the TFC staff who put 15 years of unpaid work into this game 'thanks for the good times, but bye now', is a different matter. Each of us is free to choose to retire, if we think it's over. Some did. Some did and changed their minds later. And yet, a lot of our players are still under 30, which is about average for gamers these days.

All this might make a good subject for maudlin nostalgia over a drink, but it's tiresome to hear it every time a good idea that involves some coding is posted on the forums. Let the coders figure out whether it's worth to 'go figure out how to do it'. If they don't want to do it, I'll respect that, but actively discouraging them at every turn doesn't strike me as very constructive.

[wish]

You are right, Ylang. I myself have critiqued for the same sort of post. Sorry about that.

[kaern]

Ylang is right, but I'd go even further. Innovative changes to the game have the greatest chance of retaining and increasing TFC's player base. There is a reason only a fraction of the online RPGs are still around nowadays: cause people still like these particular ones. For the most part, the ones that died out did so because they never deviated too much from every other stock mud, and/or didn't end up attracting a set of players that stuck with the game long-term.

It's differentiating ourselves from other MUDs out there that offers the best possibility of keeping a great thing going. This being a text game, good writing also happens to be our most promising avenue.

More bluntly: the music we need to face is not so much that MUDs now compete with a lot of other stimuli, it's that the other stimuli is often more interesting. We should be making TFC more interesting, and attracting area writers* to make better quality zones is, imho, the top thing we can do.

* In contemporary internet lingo, there is a word for this approach of getting many people to help improve one thing: crowdsourcing.