Jolt Country

One central concept of a puzzle dungeon that I want to be sure I fully understand to create an effective game with ACK is the design of a locked door.

The door concept is ordinarily pretty simple; a door is a space that is opaque but has no special conditions required to pass.

A locked door that you are not meant to open could be a space that is set to be impassable, or an obstacle. It should probably give a message, like, "This door is securely locked."

Very well.


The basic unlockable door would be a space that is passable only if holding a key. Problems can arise here quickly.

First, apparently you need many unique keys and many unique doors, otherwise you run the risk of a ridiculous situation where any key can open any door.

Second, how do you know it was the key that allowed you to pass that door?

(It seems to be assumed that the player would just keep anything they acquired perpetually in inventory, but a key could conceivably be dropped, be destroyed, (perhaps accidentally,) be stolen, be sold, (would it really not occur to a player to sell a gold or silver key? And if they found it to be worthless, might they not feel a little bad about carrying it around?))

This can be dealt with in a few easy ways:

a. a message. The door that opens with the iron key in Brigands is a good example. Though seeing a message and being required to press a key to go on each time you pass a door could easily become tedious.

b. the key changes the locked door to an unlocked door. The door in Brigands can be easily modified to this behavior by setting it to be destroyed if passed, and replacing it with a regular door if destroyed. Note that this means you still have the key, yet are unable to lock the door again. Though the key could be redeemed by passing the door, and many games have used this concept.

c. you don't need to get back out that way (the adventure may require that you don't)

Let me know of any others you can think of.

Third issue with these kinds of locked doors, is that they do not seem to allow for alternative ways of unlocking the door, like lock-picking skills, a skeleton key, D&D had a "knock" spell for this, the first Harry Potter story had a spell for opening locks as well. However, unlike keys, lock-picking and spells should probably have a chance of not working.

Door objects already allow for being destroyed. If destroyed they can be replaced by things that are passable or impassable. The door that opens with the iron key in Brigands has interesting implications. Its structural points are such that it is only likely to be destroyed by one weapon, though the flames never die down.

The typical situation I think of for a door being destroyed, is a locked or stuck door being kicked open, rammed open, or hacked through with an axe. This should leave a broken door, or a pile of wood and splinters. It could conceivably leave a normal door, as if only the lock was broken, or it came unstuck, but Should the door leave the same remains if attacked by a fireball spell or an axe?

I make this point only because a door as a space object apparently has a setting that enables it to disappear in only one way, either if destroyed or if passed (probably while holding key.)

In conclusion:
Locked door behavior that works fairly well and is familiar from many games can be easily implemented using the settings of a space object, messages and conditions. But any behavior that involves changing from locked to unlocked and back, or which allows for alternative methods of unlocking, methods of unlocking with a chance of failure or alternative forms of destruction will probably require a macro. Any ideas for ways to enable these behaviors would interest me greatly.

The ordinary, least complex method would be to do everything on the door's object property page. For example if you wanted a door that you could break down, replaced by door debris, perhaps) OR that you could walk through with a key (in which case the door remains as "locked door" but you can just pass through it -- with or without message, that isn't required)

In addition to the above, you could have a macro perform an "unlock spell" or a "lock pick" action -- have the macro look at the spaces immediately adjacent to the player, and if they're the "locked door" object, turn it into an "unlocked door" object instead. This could be tedious if you have a large number of key or door objects, of course, as it would make for a long macro, but it's certainly feasible.

Yet another (weird, but possible) option would be to have the door check a variable: door passable "if A=1" for example. Then have the space in front of the door run a macro (action run macro, triggered by passing) that checks the player for the right key(s) and sets the value of A accordingly. The macro for your unlock spell or lock pick could likewise set the value of A. This method might be the most versatile, as you could implement things like lockpicking skill, where some doors are more difficult to pick than others (this was talked about briefly in another thread)

And finally, of course, you can have doors open by mechanisms that have nothing to do with keys at all. For example, the door in the tutorial that you open with the lever: the door is passable "if D=1" and the lever has the action "set D to 1", triggered by bumping. Likewise you could use this method to make more complex puzzles. For example, four crystals that you have to find, and four sockets that you have to drop them into; each socket is a space with action "increase A by 1", triggered by "dropping crystal here", and the door is passable "if A > 3".

I'm thinking about what would be the best kind of object to use for locked doors: a space, an obstacle, a custom space, a custom obstacle. I've decided that the kind of door behavior I want will probably require me to learn macros.

Focusing limitations:
I need doors with varying structural strength:
Super easy, easy, medium, hard, very hard, ultra hard and impossible.
We're talking about maybe 7 levels of door strength.
If the door detects conditions and changes its state I'd expect to create 7 doors as custom obstacles, each running a macro to be set later when bumped. 7 because I want 7 levels of structural integrity, and custom objects because I'll want to open them with more than 7 keys as well is in other ways besides passage with key or destruction. However, it seems a waste to have the action run a macro rather than give a unique description of the door when examined close.

This can't be handled by any action besides a macro because I want the door to be replaced by different objects depending on how a player contrives to get by it. It should be replaced by an unlocked door in the case of a successful use of a key, lock-pick or spell, by door debris if hacked through, maybe my cinders if a fireball spell or flaming oil was used.

The locked door needs to be an obstacle, not a space. I don't want anyone dropping a key that isn't working for them on the locked door and discovering that 1 they can see what's on the other side and 2, they cannot get their key back, as I discovered after I fought the camel bandits in Caravan.

Since I'm going to be relying on Macros anyway, I ought not to use up the A-D values that objects can use.
I probably won't want to trigger any actions for if passed, or if passed holding or redeeming or bumping for standard doors, because I want the player to consciously try various keys on various doors. This probably means that unlocking a door means USE-ing a key. So maybe the key instead of the door should be an object that runs a macro.

I don't want using a key to set a value that can be increased by using it again, or combined with other objects influence on that value, for instance, say a key sets a value of 3 for B, but the door requires a value of four. One idea for a lock picking skill was to set a random value and compare it against the value needed to pass the door. So I'm worried that a key that does not set quite the right value combined with a failed attempt of lock-picking could raise the variable enough to allow passage, so the key's macro should probably re-set the value after a step. This would force the player to use the key for a given door in the space adjacent to the door.

The macro that unlocks the door could depend on bumping the door or by using the key on the space in front of the door. A key macro that tested for this map location could replace locked door obstacle, with unlocked door space and give a message. It might also give alternative messages for using the key on the wrong door:
"Your key does not quite fit."
"The key will not fit this keyhole at all/the principle of the mechanism is entirely different"
"The key slides in very roughly and turns with great difficulty, but the door remains locked."
"The key is too big to fit"
"The key is entirely too small"
etc.

The special case here would be a floor tile with 2 or more doors adjacent. The best possible solution might be one which, when the player tried to use a key were prompted for which door? (direction) and they could choose an arrow key to indicate the door they tried their key on.

This is not critical. I could simply avoid setting up situations like this, but I like the idea of trying a key being like melee attacking.

I also want most doors to be susceptible to lock picking, with a chance of failure, and spells, with a chance of failure. Different chances depending on different doors as well as different levels of skill.

A cool thing would be the ability to re-lock doors, however that's probably not necessary for a game like this that one person can play, and where NPC's are extremely limited and have no intelligence at all. To get any use out of locking a door you would have to script it so that locking the door was the solution to a puzzle or the fulfillment of an instruction, and make up some rationale. Otherwise the player would only be thinking something like: Gee, I'd better lock this door so that it won't be disturbed by other adventurers that come by, or pillaged by wandering thieves. (This is a clue to why most computer RPGs are not nearly as satisfying as playing with a serious game group.)

The early game should have several doors which are hard to open in any but one of these ways: a breakaway door made of balsa wood, a stainless steel bank vault door with a lock Mickey Mouse could pick, a door that opens when any spell is cast at all, a set of similar doors that open for their own keys, a skeleton key and sometimes for each other's keys. etc. This trains the player to try many ways of getting through doors, so that thereafter you can have more doors that open for just one condition, and the players will stay busy trying lots and lots of ways, and hopefully receiving an entertaining response each time they try something new on a door. It beats combat hollow as a way of keeping players busy.

I'd skip the re-locking of doors -- it doesn't add much, with the limited NPC AI and the lack of any other PCs, but adds a huge amount of complexity.

The rest of that is certainly doable with the existing tools, but it would make for one heck of an ugly macro -- and such a basic thing should be, in my opinion, easier to implement than that, as it could be universally useful. Let me first digest this problem for a little bit and see if there's a way to better support this through new macro commands or new object properties.

Well, Chris, I expect it would be longer than some of the very basic macro examples you give for many functions, but I don't think it would be an unreasonable short to medium program to write as a macro. I can almost put all the steps down now in pencil, and lack only familiarity with macros to begin constructing demonstration pieces.

On the other hand, I'm glad you agree with me about the usefulness of such an element for puzzle or exploration driven games.

I've just been re-reading the manual about moongates and wondering about the value of conditions that leave doors replaced by other objects.

Okay, I gave it some thought, and decided that it was definitely overly cumbersome to do with the existing macro resources -- it would have been a snarled mess of displaying a prompt, using GETKEY and trying to figure out if it was an arrow key, and if so figuring out what map location to look at, then a tangled mess of IF's and GOTOs as it puzzles over whether the object at that map location was relevant.

That hurts me just describing it, much less trying to code it. :) And for what should be a fairly basic thing to do -- prompting for and manipulating an adjacent map square -- that just wouldn't do.

In other words, there's a new PATCH.DAT. :) Read the UPDATES.TXT for the full list of changes, but here's the example it mentions:

...you could have the "use" of a lockpick item prompt the player for a direction, and then if there was either a #18 LOCKED DOOR or a #26 LOCKED DOOR at that spot on the map (let's say you have two different types of locked door, because they take two different keys) it would replace it with #31 DOOR. The macro might look like this:

1 GETADJ X Y 0
2 MAPCHK X Y M
3 IF M = 18 THEN
4 MAPSET X Y 31
5 IF M = 26 THEN
6 MAPSET X Y 31
7 STOP

Add or remove IF/MAPSET pairs (likes lines 5 and 6) as needed if you want it to check for more (or fewer) types of doors.

If you want to implement random chance of success and varying difficulty of doors, of course that adds to the complexity, but at least the foundation now is reasonable. If any of you use this, let me know if it works as expected; I've tested the basic functioning of the new stuff, but of course haven't tested it in all possible situations.

Cool, I got the email last night, and I see that some people have already tried it out and have posted in the bug thread. I'm glad to know that other people are looking on.

I am definitely going to try to use these door tools.

I'm also very impressed with another added feature you mention in the update thread, the ability for actions to initiate a dialog. I have been making notes of the existing possibilities and things I would like to be able to do, and having NPCs initiate dialogs instead of just waiting to be talked to was high on that list. It just makes too much sense; dialogs are where this program shines. Anything you can do to smoothly supplement gameplay with text or pictures will tremendously improve the ability of a game to evoke the right mood.

As I begin experimenting with locks, doors and game dynamics, I want to move to a general game scripting thread. It has also occurred to me that something like a Wiki might be a lot better for working on the manual and a set of tutorials.

PS Apropos of nothing, I fixed the problem with the door to the granary in Caravan that you get the key for when you kill the camel thieves. It was set to be passable if holding goblet of wine. I got 3 goblets of wine when I was in Rome and drank them one after another with no ill effects. When I dropped my key on the door space and was unable to retrieve it, I went back to the woman and she gave me the same schpiel and handed me another key. I tried talking to her a third time and she gave me the same schpiel and, I bet, would have given me another key if the line had said something like add a key to his inventory rather than make sure that his inventory contains exactly 1 key.

I'll have to go back and check that out, that's obviously a bug. I think there are several flaws with that bandit encounter, in fact. Also -- you shouldn't be able to drop an object on an impassable space (unless the space has an action triggered by that, in which case it will make an exception) ... I'll check that out too.

Caravan (and Brigands) are kind of odd beasts because they were created with the v1 version of ACK, when there weren't nearly as many ways to do things; macros and dialogues were much more primitive. They've had little touch-ups, but I'm anxious to replace them with newer adventures that serve as better examples of how to do things.

Being able to drop the key on the locked door was what I was alluding to earlier in my ramblings about what kind of object would be best for a locked door. I wouldn't see the need to make in an obstacle type object if that sort of thing didn't happen.

Ah-hah! I did some testing, and it clearly doesn't work the way I thought it did, thank you for pointing that out. I'll make it so that you can't drop onto opaque spaces.

I also found some other bugs with dropping in regions where you have disabled the "drop" command (it was letting you drop anyway)... I'll fix those as well.