Macro scripting

[GB]

I made some changes to the lockpick macro and have broken it somehow. I tested the short version and it doesn't give the odd behavior my modified version can under some circumstances. I think that what I need to know is, in this example:

1 IF A = 2 THEN
2 IF B = 1 THEN
3 SMSG 16
4 ...execution continues

Is that the same as saying that if A is 2 AND B is 1 then play SMSG 16?

And if A is not 2 the next line executed is 3, or 4?

[Chris H]

I couldn't get it to indent the lines (I tried) but it could also be written as

IF A=2 THEN
IF B=1 THEN
SMSG 16
STOP

So you are correct -- it would only display the short message if A=2 AND B=1.

[GB]

So, I gather I could do something like:

If condition 1 then
goto 30
if condition 2 then
goto 30
if condition 3 then
goto 30
if condition 4 then
if condition 5 then
goto 30
SET SUCCESS = 0
SMSG 14
goto 31
30: MAPSET X Y
31: SET M = 0
other execution
STOP

And that would serve to test for (condition 1 OR condition 2 OR condition 3) AND (condition 4 AND condition 5) if those were satisfied it would do the deed on line 30 (for example). If those were not satisfied it would report failure with the success value of 0 AND with short message 14, and then skip over 30, to do some housekeeping and value incrementing that we want to do whether the attempt succeeds or fails.

I've been trying something like this though. (without trying to lists of OR operations yet.) And I have been getting some behavior that I really didn't expect. Blank lines really screw with the functioning of this thing. At one point I had it replacing ANY map square with a door, whether the condition that the GETADJ returned 202 or not. I thought (mistakenly) that the locked door was being stored in variable M, and so put in a line to set M to 0. After making other changes I no longer think this was happening, I think it was just that I had left blank lines and they were screwing with me.

And about the value incrementing and housekeeping:

Setting the lock-pick to work 20 percent of the time seems to work ok, but testing this made me realize that this chance is still too high, if you can just stand around trying to pick the same lock turn after turn. So I figure that I need to have the macro remember that I tried that door already, and not let me try again for a few hours.
This is tricky.
I want it to get a variable that represents that door, and store it somewhere. But hold on; which variable? Not variable M. M stands for generic locked door 202, which is stronger than average and which there are 5 of in this town, and 5 of in each of the next 6 areas, some of which are towns, and some of which are dungeons. It is unique, not in its object number, but in its map location and the description it gives when you examine it. (Most of them just give message 12, "This looks like a rather solid door.")
So, First it seems I must get some other variable in addition to X Y M, something that tells me the region and room, and store that along with X and Y, and not check anything else until the time limit between lockpick attempts has elapsed.
And I have to store these values until all of my countdown variables are 0.
Is this less tricky than it looks to me? Or is it even currently doable?
It seems to me, that what I want, might not be either the map location or the object number, but the instance number, that which tells you that this custom object plays message 12 and not message 11.
And in deciding how flexible the macro should be I ought to take into account what the maximum number of instances 10 custom objects might have.

I think this leads to an excellent question of game design philosophy. How does having support for leveling up an RPG type character stats comport with a very limited number of doors that open to unique keys?

Ultimately I would like the macro to base the chance of success not on a fixed percent, but on a skill vs the lock difficulty, such that some doors could be absolutely certain to open, and others would open various percentages of the time. I'll probably study the lock-pick skill in the Palladium system and mimic its mechanics if it seems appropriate.

It would be good if lock difficulty and door strength could be independently set, but I'm leaning towards creating another skill for forcing doors, simply because I don't think that breaking down a door is something that should always work just because you have a weapon that can do so many points of damage. I want to add some randomness to it, because I think that any time you can keep players guessing it adds to the fun of this kind of thing.

[GB]

Ok, I finally have something worthwhile to contribute.

One of the first ideas for what I would consider a sophisticated spell that I had early on has now come within my abilities. Part of it depends on Chris's implementation of the GETADJ command, at my indirect request. I asked for it in the context of an unrelated matter. My wish was for a way to allow macros to work on doors for a sophisticated mix of alternative methods for opening them, the solution to this is very close, but manipulating adjacent squares is just so useful as you'll see.

My inspiration for this spell comes from Blizzard's Diablo, a dungeon-hack style game that is really hardly advanced at all from games I consider similar to ACK. As I would like to discuss at length in a thread about game design philosophy.

Anyway this game had a spell for helping you get back to your town (The only town in the game, and with only about 6 inhabitants.) from really deep dungeon levels. It created a magic portal, you stepped through it and found yourself on a path outside of town. It remained until you went through it again back down to the deep dungeon levels, and then vanished. I thought I should be able to do something similar. The Moongates encouraged me.

Here's how I did it:
I started with a portal, a space and a spell.
I used the portal for the stationary side of the door, I intend this to be the side that opens near your town or place of refuge. It runs a macro when passed that takes coordinates from where you cast the spell and uses that to set the destination when you step into it. It disappears, like the moongate without the moonstone in the tutorial, when you haven't cast the spell to set the other end of the portal.
I use the spell to cast the space in other places.
The space runs a macro that is set to teleport you to the location of the portal. If you wanted a spell that cast both sides of the portal then this macro could use a set of variables.
The macro the spell runs was the trickiest part. It has to get the location where you set the portal, it also has to get the region and room address. It sets the value that makes the other end of the portal visible, and ideally it should check to be sure that it is being cast on an unoccupied passable space.

So that's three objects, and a macro for each object

Portal 222
Action: Execute Macro 37
triggered by: passing
Passable to: if Variable A = 1 (I'm considering changing this to having the dispell portal spell)
Disappear? When impassable (just like the Moongate)

And the macro:
1: SETPORT PORTAL TO Q R S T
2: STOP

Q R S T being variables for region room and x y (I am using x and y elsewhere so I thought I should use different ones here.)

Space 221
Action: Execute macro 36
Triggered by: passing

and the macro:
1: SET LOC[RG] = 3
2: SET LOC[RM] = 0
3: SET LOC[X] = 4
4: SET LOC[Y] = 2
5: STOP

And this is where you would plug in another set of variables if you wanted to make a spell that defined both ends of the portal

Spell 220
Action: Execute macro 35.

Macro 35: PORTAL SET SPELL
1: GETADJ X Y 0
2: MAPCHK X Y V
3: SET S = X
4: SET T = Y
5: IF A > 0 THEN 16
6: IF V = 17 THEN 8
7: GOTO 13
8: SET Q = LOC[RG]
9: SET R = LOC[RM]
10: MAPSET S T #221-PORTAL
11: SET A = 1
12: STOP
13: SMSG 16
14: SET SUCCESS = 0
15: STOP
16: IF V = 221 THEN 19
17: SMSG 17
18: STOP
19: MAPSET S T #17-BRICK
20: SET A = 0
21: STOP

And yes, it could use a lot of tuning up I'll bet. I'm juggling some variables in there that I'm not sure if I need to juggle. I have it set to work on only one kind of ground because the editor isn't letting me use a variable for the third value of MAPSET, so that I can put back down a square of sod, or whatever I dug up to place this door, and when I get that worked out its going to have to test to see if the ground chosen is one of about 21 types of ordinary passable terrain that I think one ought to be able to cast a magic door on.
I want to test for that because early in my testing I had the misfortune to have the magic door only appear over real doors, locked doors that I was testing my lock pick on, and I didn't think that should do.

You realize here that without these kinds of controls this becomes a very powerful and disruptive kind of spell, allowing players to see and pass through locked doors and walls, to instantly kill even invulnerable and benign creatures. you could rewrite this as a spell to vanish sections of stone wall, or create barricades for protection. Like the flying spell or the peer spell it risks being too powerful for a game with scripted quests.

[Chris H]

Very cool! I will check to make sure that the engine can handle this properly... my only concern is that normally portals (like custom spaces/obstacles) have an extra "data" setting attached to that map spot, which points to a table with destination info. However, it doesn't make any sense to have to set that up for this -- the portal macro sets it when you step in. So let me just make sure that "SETPORT PORTAL" doesn't go haywire when PORTAL is zero. If so, I'll fix it in the next patch.

[GB]

To set up the necessary groundwork for this spell I placed the portal location and original destination in the map editor, rather than creating it with the script. I didn't think it would be possible to create a portal with a script, which is why I use a space that runs a macro for the movable end of the portal.
You're right, if there was some risk of glitches when using a portal, or if I wanted to have the spell place both ends of the portal, then I could use two spaces that run macros.

The odd behavior I experienced while developing this was centered on the cast portal, not the stationary one.
I learned first that this macro, even before I added the test for "open ground" would not work on places where I had not put a floor. But somehow the teleport effect was still enabled, and I found myself transported whenever I walked over any of the items I had placed on the floor. Getting the item, and then standing in its place did not teleport me though.

I also learned that walking through a door in a rooms region to a room you had deleted caused absolute annihilation.

[Chris H]

haha yes -- entering a deleted room would no doubt cause some problems. :)

But there's no reason why you can't create portals from scratch with a macro, as long as they get assigned a portal number (with the last patch, if you create it out of nothing, it assigns it #255, and you can change this with MAPSETD) and, as long as the destination is set (with SETPORT, either when the portal is created or when you step into it.)

If you want to create them ahead of time in the map editor, you can cursor over it to see the portal number, and use that number for MAPSETD to make your new portal #whatever.

[GB]

Ok, I've looked over the rules and skill mechanics for lock picking in some role playing games books I have around the house and I've come up with this:

Some games make lock picking easy, like some of my testing macros, they give beginning thief characters about 20% chance to pick most locks and let them try as often as they want. I just don't see where the fun or balance is in that, as at that rate of success it just isn't a challenge.

A later edition of the same game gives beginning thieves a 45% success rate (if I'm reading it right, otherwise, and for non thief class characters its 30%) But only gives them two tries, assuming after that that the roll indicates a lock beyond their current abilities. But softens this by giving them a third chance a week later at a large penalty, but never again until the next experience level. This is a more interesting balance.

In my opinion it is hard to know how to adapt a rule of this kind to a single-player game. If the player might already use a sword and a spell then they should not also have a full first-level thief ability. I want to give them options in the game, not make them a polymath, one-man adventuring party. So I think that both restrictions should apply. Lock picking should begin at 20%, and only 3 tries per lock should be allowed in a given day. Since I want game play to depend more on player resourcefulness than leveling by monotonously slaying creatures until you build up experience points it is difficult to know how to treat the waiting periods and penalties for trying to pick a lock again. So maybe another try after a few days with only a slight penalty would be in order before allowing another try a week later at a heavy penalty. And it does open the question of how much leveling might be involved.

I don't plan to make a game where lock picking is critical. Finding keys should usually be possible if difficult, and forcing a door would often be another option. So it isn't critical to me that a player ever be able to gain the skill necessary to pick any ordinary lock. But a few skill levels, especially early in the game, to get a player into the habit of trying it will be important. Most increases in skill level can probably be scripted. For instance, the character increases skills for: the first few successful picks, the next 10 or 20 picks successful or not, and perhaps for completing certain quests and opening certain doors. (By whatever means.)

How should the skill work?
Most notes on lock picking skills in the system I'm playing are based on percentage dice. Where you succeed on a roll of your skill level or under.
Simple enough, but how do you account for doors that are harder and easier? Like a door that requires you to roll a much higher number to open it, such that you are unlikely to successfully open it until your skill has increased or one that will open for any attempt at all?

How about this:
SET A = RND(99)
SET A = A + 1 / for a range of 1-100, instead of 0-100
IF A < S THEN success

Here, A stands for the dice roll for the ATTEMPT to perform the lock-pick skill. S stands for the success ratio for that skill. It is a variable that would be set by other scripts to increase the level of the skill.

For hard doors:
Set A = A + 10
This ought to work like a penalty on the dice roll. It makes it less likely that the dice roll will come in under the 20% necessary to unlock the door.
For Mickey Mouse easy doors:
Set A = A - 78
So A should end up under the success ratio in any but the most unusual cases.
This reminds me, am I right to assume that it does nobody any harm if a variable goes negative?

Currently, I see only two ways to get information about the hardness of the current door into the lock-pick macro. One would be by listing every door I want to define as easy or hard in the macro. I assume that if I leave a door out that it will just be treated as a standard door with a 20% chance of opening.
The other way would be to set a variable by passing over the space in front of the door. This is doable. It imposes a small design constraint in that 2 or more locked doors of varying hardness could never be adjacent to the same square, but that would probably be a small restriction to endure so that I could avoid having to list every door in the macro.

The larger problem with this approach remains how I get the macro to remember which doors have been tried so that I don't allow the player to try them again.

Any suggestions or input would be appreciated.

[Garth's Equipment Shop]

There is no way to set and test a flag variable assigned to each door? You know like a "tried" flag? I still haven't tried my hand at macros yet so I am still kind of in the dark as to how they work. So if I sound totally ignorant that's why. lol. I do however have quite a bit of experience programming so I understand all the usual object oriented programming principles.

I've gotten pretty good at TADS3 coding over the years. Here is a little demo game I made a few years back using TADS3 to show the power of it's virtual machine and IF language library. It is inspired by wasteland and Bard's Tale my two favorite games of all time. though I used some graphics from KKND2 to give a bit more realistic look.

A 2D Interactive Bird's Eye View Map using an HTML table and graphic tiles.

The combat in both WL and BT are pretty much the same but you can see the influence of BT in the celtic knotwork design of the frames and the little compass I implimented for navigating the map. I made the little character and monster icons myself pixel by pixel. The inside room graphic is really primitive, its from a really really old CGA adventure game.

[Chris H]

Actually, I suppose there would be a data field on each door that you could use. Every spot on a map has two bytes: the first is the object number, the second is a data field used only if the object is a creature, an item (to track what's underneath), or a custom space/obstacle. If a door was a regular space/obstacle, then there's an unused data field sitting there. Macros can access that with MAPCHKD and MAPSETD commands.

[Garth's Equipment Shop]

Hmm, interesting. So Chris is that documented information or if not how much more of this kind of undocumented information can be discovered from probing the uncharted nether regions of your mind? I just got a flash of a funny idea to add to the WL style ACK game that has been percolating recently in the deep dark recesses of my own unfathomable mind. It has to do with Finster's electronic brain in WL.