Adventuron Halloween Jam

Hosted by Adventuron · #textadventurejam

Entries

Ratings

Overview Submissions Results

Community44

Screenshots Submission feed

Adventuron Halloween Jam community

How do you do movable enterable objects?

A topic by Garry Francis created Oct 05, 2019 Views: 110 Replies: 8

Viewing posts 1 to 2

Garry FrancisSubmitted4 years ago

Do you have an example of a movable enterable object? These are the requirements:

You have an object that can be picked up and moved around, e.g. a chair or a big basket.
You can't enter that object when you're carrying it.
You can enter that object when you're not carrying it, e.g. you can stand on the chair or get into the big basket.
When you're on the object (or in the object), you can't move anywhere until you get off the object (or out of the object).

The first three points are pretty easy to handle, but how do you handle the fourth point in an efficient manner? Perhaps a barrier that applies to every room?

Also, you need some way of indicating that you are currently on or in the object. Does Adventuron have a convention for this? You could put it in the header (if you have one); prepend it or append it to the room description; or add a sentence after the room description, exits and list of objects, but you don't see any of these until you do a redescribe. Alternatively, you could add a sentence prior to each prompt, but this is a bit extreme.

AdventuronHost4 years ago (1 edit)

Location agnostic blocks are coming, until then you can simply use:

: match "n _;s _;e _;w _;ne _;nw _;se _;sw _;enter _;exit _;u _;d _" {
    : if (is_standing_on_chair) {
        : print "You can't go anywhere right now!";
        : done;
    }
}

To instantly refresh the header without a redescribe, use:

: refresh_header;

Garry FrancisSubmitted4 years ago

Would I be right to presume that this match statement should appear before any others with direction-specific commands?

I used refresh_header in my previous game (to update the score) and it didn't seem to do anything. I'll try again.

AdventuronHost4 years ago (1 edit)

The match statement could go anywhere really because it's made specific by the inner if.

Refresh header *should* work immediately. If it doesn't then it's a bug.

A system action is overridden if one or more unmasked actions occur. A match itself is not an action, nor is an if statement, because they don't actually do anything, they are only control of flow statements.

Garry FrancisSubmitted4 years ago

You have introduced a couple of new terms here. What is a "system action" and an "unmasked action"? They're not mentioned in the doco. In fact, "action" isn't even defined. The doco uses it in a generic sense and it seems to be the command defined by the pattern in a match statement, but you said a match is not an action. Now I'm confused.

It sounds like a system action is a predefined action like the inbuilt directions, GET and DROP. It would be nice if you could provide a list of these and what they do, otherwise how do we know that they exist or whether we need to override them?

I don't think the directional match statement can go anywhere, as I might have another specific match statement like:

: match "n _" {
: if (is_at "front_porch" && is_door_closed) {
: print "You'll have to open the door first.";
: done;
}
}

In this case, I would want the generic override to be performed first, then the specific override, then the system one.

It would really help if you could explain how commands are processed. This is sorely missing from the doco. I've also noticed that this explanation is missing from barriers. In my last game, I hade two different barriers that applied to the same room. Each had different conditions and I had no idea which one would take priority. Coincidentally, whatever I did seemed to work, but I don't know why, as the conditions were competing with one another.

AdventuronHost4 years ago

I'll see what I can document better but the common sense stuff is mapped by default as system actions (or defaul handlers if you prefer that):

get

drop

wear

remove

Examine

Directions

Put xxxx in yyyy

Take xxx from yyyy

Get all

Drop all

Wear all

Remove all

Load

Save

Inventory

Quit

Ramsave

Ramload

Unknown verb

Unknown noun

Unknown examine target (you see nothing special)

Assume that all these handlers will execute if you don't execute something yourself. Matching is not executing something. It's a statement that is not a match or an if or an else if or an else.

If you execute one line of non control code (match,etc) then the system handler is not skipped.

Of course you can choose to reapply the system handler via :get; :drop; etc commands, but they won't be executed themselves.

AdventuronHost4 years ago

Location agnostic blocks are documented here:

https://adventuron.io/docs/tut/#LocationAgnosticBlock

Garry FrancisSubmitted4 years ago

It looks like the only difference between this and a normal block is that the location is missing. Is this what you mean by "location agnostic"? Is this also what makes it unable to be ported to PAW? If so, I might be better off using the match "list-of-directions" method.

AdventuronHost4 years ago

Location agnostic means that it blocks every location.

Yes, for now, it's not compatible with paw export. If you care about that.

itch.io

Adventuron Halloween Jam

How do you do movable enterable objects?