Announcement: Be excellent to each other.


Caravel Forum : DROD Boards : Bugs : pushing moves & tokens
1
Page 2 of 2
New Topic New Poll Post Reply
Poster Message
Dragon Fogel
Level: Smitemaster
Rank Points: 2467
Registered: 06-21-2014
IP: Logged
icon Re: pushing moves & tokens (0)  
A problem with that is that it won't pick up unintended solutions, only rooms where the solution no longer works. As I noted, the current behavior prevents decoys from changing their weapons after they've been placed. Allowing that could break rooms and it would be hard to tell how many.

This would specifically be a problem for Entry Point development. We'd have to go through the hold and search for all the rooms that don't work or have unintended solutions introduced and then figure out what to do with them. The fact that this would be fairly work-intensive here suggests it would also be the case for published rooms.
10-14-2020 at 12:42 AM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
Nuntar
Level: Smitemaster
Avatar
Rank Points: 4775
Registered: 02-20-2007
IP: Logged
icon Re: pushing moves & tokens (0)  
My thoughts on this issue:

I've already written about bug/behaviour fixes in general, but to recap: I don't think it should be weighted too heavily whether a behaviour was originally intended or not. What matters is whether it makes sense; whether it adds unwanted complexity; and how much damage changing it would cause.

Even if unintended, it makes sense that stunned entities don't activate tokens; they are inert for one turn. Neither behaviour is more complex than the other; either way there is one rule to be learned.

The potential for damage is very high, for two main reasons. Firstly, while this behaviour is an interplay of three elements (a double, a pushing weapon and a token), all of those are general classes rather than specific elements. Doom has estimated that there are hundreds of rooms with all three.

Secondly, other bugs currently under discussion, such as the snake/invisibility bug and the brained aumtlich bug, affect individual moves. While an architect knowing of the behaviour could easily make a room where the particular move arising from the behaviour is required to solve the room, in most cases whether a single move is made or not won't affect the global state of things very much. Tokens, by contrast, usually have a large-scale effect on the state of a room. Changing the rules for when a token is activated will, in many cases, drastically affect the possibility space open to the player. That means that a much higher proportion of the rooms with potential for breaks will actually have breaks -- and our observations from EP rooms bear this out.

Dragon Fogel has pointed out a particular, very important subcase: with the current behaviour, decoys (and static scripted characters) with one weapon can never change to another. Making it possible for them to change weapon would add interesting puzzle potential, but again, it would open wide the possibility space of existing rooms. Another important case is the possibility of activating a conquer token that was meant to be blocked off.

I can't deny that my motivations here are partly selfish; we are at a late stage of development and have really strong momentum going at the moment, and the last thing we want is to have to add another very large task to the workload. But as a member of the community, I am also very concerned because of the potential for damage to published rooms.

Maybe we shouldn't have used the word "established" in the absence of official confirmation. But there has certainly been a cycle -- architects use this behaviour, other architects see that it has been used in published holds and assume it is accepted, and use it themselves -- that hasn't happened with other behaviours currently under discussion, because this one is so much more likely to turn up. It's true that there has been an open Bugs topic all this time, but after a certain amount of time passes, people tend to assume that a behaviour won't be changed.

____________________________
50th Skywatcher
10-14-2020 at 03:41 AM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5153
Registered: 02-04-2003
IP: Logged
icon Re: pushing moves & tokens (0)  
I appreciate the input. Yes, this makes sense to me, and I can't disagree with these points.

Don't want to cause a lot of grief for both architects and players over pre-existing material needlessly being broken. I've done my share of this over the years and I often regret it. One example of this was when I tweaked the set of custom images imported into the TSS hold for v5.0.1 (or was it 5.0.2?). I thought it would be a helpful and benign change, but it caused players all kinds of trouble on the world map screens as the images displayed there got all jumbled up in many cases for games already in progress. It would have been way better just to leave that aspect of the hold as-is and avoid that poor player experience.

I agree we don't *have* to change a behavior simply because we didn't design it explicitly.

I can also see how when an entity is pushed and stunned, it does make intuitive sense that they might not activate a token on that turn (or light a fuse, etc).

I don't have strong feelings about changing that current behavior, but it sounds like it might not be worth it in the grand scheme of things.

So, where does this leave us?

Is there a partial change that we have general agreement would be worthwhile to make? For instance, any objections to changing this corner case:
Dragon Fogel wrote: ...pushed NPCs that cannot be stunned don't activate tokens either, so that seems reasonable to change; I doubt that would have any impact on published rooms.
Edit: not trying to waffle on what I think we should do. I'd like to understand where we're wanting to draw the lines at and evoke any additional discussion that's worthwhile to have to help make a decision.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

[Last edited by mrimer at 10-14-2020 07:41 PM]
10-14-2020 at 05:12 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5153
Registered: 02-04-2003
IP: Logged
icon Re: pushing moves & tokens (+3)  
Apologies for double-posting.

I just became aware of this engaging conversation and want to elaborate on my brief thoughts here so one doesn't have to squint in order to perceive my position.

First off, I see that fixing game logic issues, now maybe more than ever in the past, as new holds are architected and published over time, is often non-ideal. I take ultimate responsibility for issues in DROD's rule design. I've implemented most of the core new game elements since DROD:AE. I've designed a lot of it intuitively, and not all that formally, maybe as it should have been, and I definitely haven't applied exhaustive theoretical coverage of game rules. My experience and practices have improved over time, but I am highly aware of my imperfections. I see this leaves us with odd and ambiguous situations in emergent behaviors, and it's not optimal for the community as rooms and solutions can break. The volume of breakage typically seems to be the predominant factor in our weighing of decisions on whether to change behaviors or not. Still, in order to provide the best play experience possible, I need to step out from under any potentially crushing guilt on this double-edged impact in order to move on.

In the big scheme of things, many of these issues may or may not matter all that much. Still, I do understand a lot of creative energy, and passion, and feeling has been invested in game rooms that may be impacted by these changes. As skell, I am mindful of players' and architects' feelings and want to always be receptive and respectful, while also making the game the best it can be. I perceive this is a complicated balancing act, and rather than apply a set of bureaucratic policies in making changes, we tend to consider each situation on a per-case basis, on its own merits.

Keeping track of all the game rules, and the 10^67^35 potential combinations of interactions that can occur in a room, is not easy. :) I respect everyone who attempts to do so for, first, the effort in striving to comprehend it all, and second, for designing excellent puzzles with all of it in mind. What an amazing community!

I understand that there may come a time when executive calls need to be made. I am often going to side with skell and his judgment in advancing the game (if such sides need to be taken), because he does such excellent work in so many areas, and I can see he is so passionate, as we all are, about DROD and pours much of his heart and soul into it. A man after my own heart. I so enjoy working together and deeply appreciate his instrumental contribution.

I share skell's stance of accepting some demo breakage (judged according to perceived need) in order to correct what we conclude to be real issues. I wince at having rooms break, mostly because there's an involved workflow in applying and publishing fixes thereafter. However, if skell is actively working with the community to not only fix the code, but also fix any architectural issues, I consider that just so kind of him to tackle and I'm super grateful for his contributions in all these areas.

...

Given this context, I'm going to propose when we're about ready to produce a beta build, we evaluate the extent of published room breakage (specifically for this topic's PR, i.e., the delta of being both w/ and w/o this PR) and report it. At that point, we will provide a plan to address the breakage. We'll be open to receiving feedback on the expected impact and mitigation strategy at that point, and we'll move ahead from there in data-driven fashion. Objections?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
10-14-2020 at 07:40 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
navithmastero
Level: Smitemaster
Avatar
Rank Points: 625
Registered: 01-03-2012
IP: Logged
icon Re: pushing moves & tokens (+1)  
mrimer wrote:
Is there a partial change that we have general agreement would be worthwhile to make? For instance, any objections to changing this corner case:
Dragon Fogel wrote: ...pushed NPCs that cannot be stunned don't activate tokens either, so that seems reasonable to change; I doubt that would have any impact on published rooms.

That corner case seems fine. I think that on a larger scale if (and I still think the best course of action when it comes to the broader cases of pushing Beethro or doubles and having a token activate/not might be to just leave things as is) we do want to change behaviour, the best thing to change would be that Beethro activates tokens when he is pushed. This is because:

1) This, to me, feels the most intuitive. If something is pushed, it is stunned and so can't activate tokens makes sense.

2) More importantly, in terms of minimising 'damage', it would be infinitely better to change the Beethro case than change the doubles case. This is because in 99/100 cases, any token that Beethro can be pushed onto, Beethro can just as easily walk onto, so this change has the potential to break far fewer rooms and demos. With a decoy, as has been pointed out, if we change this behaviour we are creating a new interaction that previously was impossible - namely the ability of an already placed decoy to activate a token. The best compromise would be to change the Beethro case and to keep the doubles case as is.

Thoughts?

____________________________
Member of the Snake Appreciation Society

One of your local HAs.

My stuff:
Click here to view the secret text


[Last edited by navithmastero at 10-14-2020 07:54 PM]
10-14-2020 at 07:53 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Dragon Fogel
Level: Smitemaster
Rank Points: 2467
Registered: 06-21-2014
IP: Logged
icon Re: pushing moves & tokens (+1)  
For whatever reason (probably game flow), a pushed player isn't "stunned", in the sense that they can move again immediately. This doesn't usually have secondary consequences, but personally I think it's not that big of a deal in a case like this.

That said, it could break some enforcement mechanisms if it were changed; tokens are often used to create spaces Beethro can't move onto but monsters can.

This can also happen with doubles, but the only example I can think of where there are pushing weapons, doubles, and tokens used as enforcement in this way is the Room of Humility. However, I could not find an actual break by pushing the mimic over the token - the room has other constraining mechanisms and setting things up to do the push interfered with getting past some of those.

So I think it's best to just go with "stunned entities do not activate tokens", and the player is never stunned when pushed. (Maybe they technically are - I noticed timeclones are only stunned on the turn they're pushed, but will move on the next one unless pushed again. But it's not actually observable.)
10-14-2020 at 08:29 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
skell
Level: Legendary Smitemaster
Avatar
Rank Points: 3771
Registered: 12-28-2004
IP: Logged
icon Re: pushing moves & tokens (0)  
Wanted to add that there was another tiny thread for the same issue: http://forum.caravelgames.com/viewtopic.php?TopicID=41419

Not sure if it was linked anywhere or not.

____________________________
My website
10-15-2020 at 07:26 PM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts High Scores This architect's holds Quote Reply
Nuntar
Level: Smitemaster
Avatar
Rank Points: 4775
Registered: 02-20-2007
IP: Logged
icon Re: pushing moves & tokens (+1)  
I'm bumping this because it seems to have drifted off the radar, and it would be very helpful to have a final decision so that we can have confidence that rooms we are building now won't be broken in the future.

Summarising the last few posts, it seems we were heading towards consensus that (1) the behaviour with decoys and stunnable doubles should not be changed, because it would probably have too large an effect on existing rooms; (2) it might be desirable to change the behaviour with regard to non-stunnable NPCs, allowing them to activate tokens. Does that seem fair?

Since the behaviour of Beethro was brought up, I should mention that pushing Beethro onto a token does activate it, and it looks like we have agreement that this should not be changed. (From navithmastero's post just above, I think maybe he was under the impression that it currently doesn't activate the token.)

____________________________
50th Skywatcher

[Last edited by Nuntar at 07-19-2021 11:30 AM]
07-19-2021 at 11:27 AM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged
icon Re: pushing moves & tokens (+2)  
Had not seen this thread before (kind of a side-effect of only poking head in now and again and seeing what's going on in "Recent posts"). Interesting reading.

First off, I'm going to quote myself with regards to how Beethro reacts to being stunned:
TFMurphy wrote:
Beethro isn't immune to being Stunned. What he's immune to is being stunned for more than 1 turn (a decision made because it's not that fun to be forced to wait a turn if something else pushes you around). Since Beethro moves first in a turn, he can always take a move. Other entities that are stunned for 1 turn can similarly make their move providing they do so before the stun takes place during the turn.
This is important, because it played into a discussion we were having on how Temporal Clones should react to being stunned. The result of this discussion was that Temporal Clones were changed to only receive 1-turn Stuns, to preserve playback while still allowing intuitive use of pushing.

And now, this is important again, because this was an interaction we didn't consider when implementing pushing. If Beethro activates tokens on being pushed, then Temporal Clones should too. And if stunned Clones activate tokens, then it becomes increasingly difficult to think that other doubles shouldn't activate tokens, when they already do on placement (a non-movement interaction that only occurs at the end of a turn), and when things like trapdoors drop or fuses start burning when a double is pushed on to them.

So, I'm kinda of the opinion that anything that would normally activate tokens, should still normally activate tokens if pushed onto it. I'm not particularly fond of the opposite stance (where anything pushed onto a token never activates it), especially considering things like one-use tokens on trapdoors, tokens placed where to block access to areas, and so forth.


Aside: Uh... okay, slight addition to the number of intuitive things that we missed. If Beethro is pushed on to a fuse, it lights. If Beethro pushes a double on to a fuse, it lights. But if an entity later in the turn pushes a double that has already taken its turn on to a fuse, it does not light. This impacts playback as well, so I'd call that an additional bug. Moving on....


I... can possibly suggest one thing that could maybe help solve the issues with breaking certain rooms? I've not seen any of the rooms in Entry Point so I don't know if this is the issue itself, but one of the main things mentioned was about whether Decoys could change their weapons or not. We could simply have Decoys never be allowed to trigger weapon changing tokens, whether on placement or by being pushed. Weapon changing tokens only affect the entity using them, so it a normally immobile uninteractive Decoy simply cannot switch to a new weapon. Allowing it to still activate other types of tokens would still be fine, right? (EDIT: I mean on push. Naturally, there's no way we'd ever stop Decoys from activating global tokens on placement.)

Obviously this isn't without its own consequences, since it removes the possibility of being forced to place a Decoy at a particular spot with a Weapon Token restricting what weapon it gets there. Theoretically this could be solved by forcing the player to have a particular weapon before they can use the Decoy Potion, but that has its own issues.

[Last edited by TFMurphy at 07-19-2021 09:24 PM]
07-19-2021 at 09:03 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Nuntar
Level: Smitemaster
Avatar
Rank Points: 4775
Registered: 02-20-2007
IP: Logged
icon Re: pushing moves & tokens (0)  
TFMurphy wrote: This is important, because it played into a discussion we were having on how Temporal Clones should react to being stunned. The result of this discussion was that Temporal Clones were changed to only receive 1-turn Stuns, to preserve playback while still allowing intuitive use of pushing.
I hadn't considered timeclones. It's a good point that timeclones are different from decoys and only receive single-turn stun -- but precisely because they are different from decoys, I don't see the inconsistency in saying that timeclones could be changed to activating tokens when pushed (they currently don't), but decoys should not. Have it tied to the stun, as others have suggested.

I'm not particularly fond of the opposite stance (where anything pushed onto a token never activates it), especially considering things like one-use tokens on trapdoors, tokens placed where to block access to areas, and so forth.
That's the kind of thing I was thinking of when I said, a few posts up, that because tokens are generally tied to macroscopic changes to the room, we can expect a large number of potential breaks to be actual breaks. Suppose you have a tar/mud token, and a tar blob in the room that must never become mud (not far-fetched; this is a fairly common enforcement widget). Beethro can't step on the token because he would activate it, but a decoy or mimic can be pushed onto it. That may not have been what the developers originally intended, but it is how architects have understood things to work for the last five years.

We could simply have Decoys never be allowed to trigger weapon changing tokens, whether on placement or by being pushed. Weapon changing tokens only affect the entity using them, so it a normally immobile uninteractive Decoy simply cannot switch to a new weapon. Allowing it to still activate other types of tokens would still be fine, right?
Please no. Firstly, my observation that under the current rules, decoys can never change their weapon was just an observation; most of the rooms that I know of that are in danger of being broken involve other kinds of tokens. Secondly, it would be really counterintuitive for different tokens to have different rules. Thirdly, mimics can change their weapon, so this would create an inconsistency between mimics and decoys. Finally, I certainly know of rooms where placing decoys onto weapon tokens is part of the puzzle, so the suggested change would break a ton of rooms (both in EP and published holds) that don't even involve pushing at all!

____________________________
50th Skywatcher
07-19-2021 at 11:04 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged
icon Re: pushing moves & tokens (+3)  
After some more thought on this topic, I still feel that using Stun Duration as a criteria for whether an entity can activate a token or not would be a mistake.

First off, it's a needlessly specific restriction that won't mean much unless you already happen to know which entities are immune/resistant to stuns.

Secondly, so far all stuns of any duration work the same: "strong effect" on the exact turn it's applied, followed by a lesser effect (movement only usually) for however many extra turns the stun lasts for. This suggestion would change that such that 1-turn stuns would have an altogether different effect to longer stuns.

Third, it doesn't help us at all if another method of moving entities (ice floors, conveyor belts) that does not stun the entity ends up being added however many versions down the line. I'd rather have a ruleset based on the entity itself than some effect applied to them that might not end up being universal.


Even without all of the above, I still find it strange that a Mimic can walk onto a token to activate it, but won't do so when pushed.

======

There are really only a few entities that can activate tokens, so I think it's instructive to go over them one by one.


Player
No matter what player role the player is controlling, they can activate all tokens. This also occurs when the player is pushed. My feeling on this is that it would be both unintuitive and risks breaking already used token controls to change this.


Temporal Clones
I've already mentioned that if Temporal Clones cannot activate tokens when pushed, then it leads to playback issues since the player can certainly record a clone that activates a token before rewinding. Temporal Clones should definitely follow whatever is allowed for the Player in this case.


Decoys
Currently, Decoys only activate tokens on placement. I've thought a good amount on this, and I'm now willing to have this left be. The reasoning for this is simple: no architect would've thought that a token was ever in danger of being activated by a pre-placed Decoy. For most of the other entities in this list, their mere presence would require the architect to have thought about whether they should be allowed to activate the token or not.


Mimics
These activate tokens on placement and on regular movement. This is the one entity that sticks out the most to me: I don't like the idea of pushing a Mimic onto a token and it failing to activate as a result. I could accept it if it were a 2-tile push such that the entity never ends its turn on the token... but we can't do that either, because tokens already activate immediately on an entity's movement, and we absolutely cannot change that.


Clones
Like Decoys, Clones only activate tokens on placement. In a programming sense, they have no need to activate tokens on movement, because whenever the player takes control, it's the player in that spot, not a Clone. In a meta sense however, we need to think more carefully about this. (I'll also note that Clones only get a 1-turn stun too, because it seemed silly to be able to transfer to a 2-turn stunned Clone and then start moving immediately.)

I could actually go either way on this one. I'd be prepared to buy that an inactive Clone doesn't have the presence to activate Tokens. Like Decoys, they don't move on their own, only when the player is inhabiting that body.

On the other hand, they are linked extremely with the player at all times -- their death results in the player's death. And they still trigger all the usual things that Mimics do (though only fuses will activate from standing still of course).

I will note that there is one thing that won't change even if Clones are given the ability to activate Tokens on being pushed: they will always fail to activate a Temporal Split token, since only the player can do that. So theoretically, this could be used to prevent such a token from activating if it blocks a passage that Beethro needs to take.


Human Characters
Any character with a Human-type identity (Beethro, Gunthro, Halph, Doubles, Guards, Slayers, Stalwarts, Citizens -- not Goblins though) can trigger tokens. If they can move and trigger tokens, my feeling is that they should actiavte them on being pushed too.

There is one unfortunate part to this: since the ability to activate tokens is solely tied to identity, there currently exists no sworded character that doesn't activate them. This... actually feels like a good set of imperatives to add, especially if we end up needing to fix a room that this change breaks because it involves a scripted character.

======

So, in short, I don't think Stun Duration should be used as the reasoning behind any change we make to this, and I still think this behaviour should be changed to allow at least Mimics, Temporal Clones and Characters to activate tokens when pushed. I'm fine now with leaving Decoys, with the argument being that their stationary nature restricts them from doing so except in the normal case of placing them with a potion. And I could go either way with normal Clones -- I feel it could be argued either way, and there's potential with whichever decision.

[Last edited by TFMurphy at 07-27-2021 08:16 AM]
07-26-2021 at 11:08 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5153
Registered: 02-04-2003
IP: Logged
icon Re: pushing moves & tokens (+2)  
I appreciate you both carefully sharing your thoughts on this issue and how to resolve it.

TFMurphy, thank you for the detailed walkthrough of each class of entity. This is what I need to form a better understanding for myself. I agree with your recommendations. I don't have a strong opinion either way for clones either and could also see them going either way to decoy- or to mimic-like behavior.

@Everyone: Any objections to what TFMurphy is proposing in the latest post?

Any strong opinions on what to decide for clones? I'll throw out a strawman argument for clones to jumpstart any additional conversation for them: let's default to leaving clone behavior as-is.

Edit: I think of "active" entities activating tokens, while "statue" ones like decoys and clones don't.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

[Last edited by mrimer at 07-27-2021 04:23 PM]
07-27-2021 at 02:57 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
hyperme
Level: Smitemaster
Avatar
Rank Points: 1185
Registered: 06-23-2006
IP: Logged
icon Re: pushing moves & tokens (+2)  
I think if there's going to be a divide, Clones make more sense on the "don't activate on push" side, since they don't move by themselves. That way, all "active" player doubles activate tokens when pushed, while "passive" doubles don't.

Characters are a bit of a mess, but I think by default it makes sense for them to inherit the token/push interaction of their base identity. Non-element identities probably want to activate on push, but that's more of a feel thing. 5.2 will be adding the Set Behavior command, which can be used to make this another configurable property of Characters, and to provide a way to deal with room breaks due to changes to the default to how Characters interact with tokens.

____________________________
[Insert witty comment here]
Qzvlkx?
07-27-2021 at 03:52 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
Nuntar
Level: Smitemaster
Avatar
Rank Points: 4775
Registered: 02-20-2007
IP: Logged
icon Re: pushing moves & tokens (+2)  
I'm really torn. On the one hand, I definitely see the point that because mimics can walk onto tokens, it feels more strange that they don't activate tokens when pushed than it does for decoys. But on the other hand, if we change it for mimics but not decoys, we're treating the two differently from each other, and that feels weird too.

I feel that a pushed decoy/mimic/inactive clone is a passive entity, whereas a mimic that steps is active even if mindless, so the current behaviour makes sense. Mimics are frequently used, so changing the behaviour for mimics still has high potential for breaking rooms, even if not as high as changing it across the board. (You could argue that the player is also passive when pushed, but the player at least reverts to being active immediately, so it makes sense that they still activate tokens in this case. For the same reason, I do agree that it makes sense for timeclones and the player to be treated alike.)

____________________________
50th Skywatcher
07-27-2021 at 03:52 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5153
Registered: 02-04-2003
IP: Logged
icon Re: pushing moves & tokens (+2)  
Good points.

There's another option here: we've lived with the current behavior for a good while already, and we could to defer this change till 5.2, where Set Behavior will be introduced. This way, we could synchronize any character-related puzzle breakage with hold updates that fix them at the same time.

This option gives us more time to think about what we feel would be the best overall decision without feeling rushed as we try to get 5.1.1 out the door. This would avoid further blocking the 5.1.1 release without forcing a final decision at this time. (And 5.2 could be put into beta right after 5.1.1 is released; there doesn't have to be a huge time gap between the two.)

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

[Last edited by mrimer at 07-27-2021 04:36 PM]
07-27-2021 at 04:34 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
navithmastero
Level: Smitemaster
Avatar
Rank Points: 625
Registered: 01-03-2012
IP: Logged
icon Re: pushing moves & tokens (+3)  
Just now in chat mauvebutterfly said:
The easiest answer is just "This is how DROD is and we aren't changing it"

And to be honest I pretty much agree. Unlike some other bugs which have been fixed where what you'd expect to happen clearly doesn't (e.g. this). The bug in this thread has become kind of part of the DROD player's repertoire (at least in my opinion). While this didn't show up in an official hold, it feels widely accepted by people enough that this is just one of those things that if you really think about it may seem a bit odd but overall I didn't really think it was too strange when I learned of it and others didn't either.

I definitely think that changing the behaviour for decoys should not be done as it has wide potential to break things I think. The change could be put in place for mimics (which would also break some things) but then if we have different behaviour for mimics and decoys this also feels wrong and in some ways *more* wrong than how it is now (EDIT: which is what Nuntar said above).

DROD is full of quirks and nuances which are not necessarily obvious, but are definitely intended (remember when people just didn't get snake movement?) and trying to remove all the unintended ones just seems a little pointless. This particular behaviour is simple enough that once you see it once, you're not going to forget it. This, combined with the rooms which could be broken completely or just through a US, makes me feel that this shouldn't be changed :)

____________________________
Member of the Snake Appreciation Society

One of your local HAs.

My stuff:
Click here to view the secret text

07-27-2021 at 06:34 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
bbb
Level: Master Delver
Rank Points: 215
Registered: 10-07-2013
IP: Logged
icon Re: pushing moves & tokens (0)  
I think I'll join the "don't change anything" camp. At least for now. The current behavior is well established, at least de-facto, if not de-jure. While the current behavior isn't always the "best" possible, it has (for the most part) gone through months of design and testing, and have been found to usually be reasonable. A decision to change an established behavior (as measured by the affected rooms, and the magnitude of the effect) should be done very carefully after thorough analyses, and not just by a suggestion on the forum and it seeming like a good idea.

My opinion on the current proposal:

The option for a character to be active when pushed or not should be scriptable. Then the default (at least for older holds) would be that characters are NOT active, so the current behavior would not change. Even if that is not the default, old holds could be fixed with this option when necessary.

Scripting if mimics and temporal clones are "active" can also be scriptable if necessary to fix rooms (similar to Gunthro suddenly learning how to swim) though that is not an ideal solution.

The proposal seems reasonable assuming fixing old holds is possible.

(This is a response after looking at the proposal for a few minutes. Not serious analyses.)

In another related thread I wrote:
The criteria for rooms to be checked could be any room where at least 20 or 25% of the demos break. (The exact number and ratio doesn't matter.) The result of such a check can be one of the following:

1. Some demos fail because of a technicality, such as requiring an extra wait move, or skipping unnecessary actions. This result shouldn't block a change, and shouldn't require much discussion.

2. Demos break which can't be fixed trivially, but the room can still be solved with the intended solution and doesn't obviously break. Such a change should require discussion, but should be permitted.

3. Rooms break such that they become trivial. Should not be done without serious discussion, but shouldn't be completely prohibited. See point 4 for additional considerations.

4. Rooms break and become unsolvable or unreasonably hard. Should not be done without serious discussion. A decision can be made to accept that change without further action only if the hold is considered to be a poor hold which no one will miss, e.g., Bad Evil Restaurant. Even in this case, the author should be notified if possible to fix the room. If the broken room is in a "serious" hold, official or not, the room has to be fixed before accepting the change. The fix should preferably be one which does not change the room behavior, e.g., fixing scripts, or simulating the old behavior using scripting. The next option is to modify the room so it works with the new rules. Changes should be slight, such as modifying timers and such. Another option, which would open a new can of worms, is to continue supporting the old behavior with the engine version tag in the hold. If the original room authors are still around, they should be consulted, but changes can be made even without them. However, the fact that an interaction appears in several (good) rooms is often a fair indication that the interaction should not be changed. Even if it should have been implemented differently in the first place.

Any such change would almost certainly fall into category 4, which, in my opinion, should require fixing old holds when possible. (I'd be willing to look if I had access to a spider and the demos.)

[Last edited by bbb at 07-27-2021 07:48 PM]
07-27-2021 at 07:08 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Nuntar
Level: Smitemaster
Avatar
Rank Points: 4775
Registered: 02-20-2007
IP: Logged
icon Re: pushing moves & tokens (0)  
Set Behaviour will only help when it comes to characters -- and only characters with a human base, since characters with a monster base don't active tokens by stepping anyway. I haven't done any kind of quantitative research, but my impression (from having played or seen a decent number of usermade holds since TSS came out) is that this is a relatively small aspect, and the behaviour of decoys and mimics is the real core of the issue, affecting far more rooms.

____________________________
50th Skywatcher
07-27-2021 at 08:10 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
bbb
Level: Master Delver
Rank Points: 215
Registered: 10-07-2013
IP: Logged
icon Re: pushing moves & tokens (0)  
Scripting - I know. I mentioned two options.

Impact - Definitely more rooms with mimics/decoys. The real question is how many rooms are seriously affected, and how these rooms can be fixed.

I just think we need to check the impact before going ahead with such a change.
07-27-2021 at 09:17 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Doom
Level: Smitemaster
Avatar
Rank Points: 3311
Registered: 07-05-2004
IP: Logged

File: disarms.png (91.9 KB)
Downloaded 409 times.
License: Public Domain
icon Re: pushing moves & tokens (+1)  
navithmastero wrote:
The bug in this thread has become kind of part of the DROD player's repertoire (at least in my opinion).

While this didn't show up in an official hold, it feels widely accepted by people
When there are very few rooms that depend on this and a lot of people considered it a bug, it's hardly fair to call this widely accepted behavior.

Having different behavior for mimics and decoys isn't ideal, but imo having different behavior for players and mimics is worse.

Even if this ends up staying in the game due to being too much of a pain to change, it's not a trick that I'd be happy to see as a lynchpin in new holds. Avoid exploiting quirks, players aren't DROD scientists, etc.

In the grand scheme of things I don't feel too strongly about this, but from an architect's point of view it's a bit of a shame that setups like this aren't airtight at the moment:

Click here to view the secret text


[Last edited by Doom at 07-28-2021 12:52 PM]
07-28-2021 at 11:34 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
navithmastero
Level: Smitemaster
Avatar
Rank Points: 625
Registered: 01-03-2012
IP: Logged
icon Re: pushing moves & tokens (+1)  
There are only a few rooms which rely on this behaviour but there a quite a few which could be impacted by this behaviour. I say this seems widely accepted as of the people who I've spoken to in chat most of them seem to agree that this is acceptable and just part of our game. Maybe the number that feel that this is a bug is more than those who don't but if that is the case they're not exactly appearing in full force!

While I agree that architects shouldn't be purposefully exploiting bugs I don't think that this particular trick falls into that category. This interaction is very easily discoverable and generally when you discover new interactions you treat them as being part of the game and not some bug. A lot of the time when I'm building rooms I start off by trying out some specific combinations of elements to see if anything magical happens if the player does certain things with them, and then I can make that into a room if I find something I particularly like. While DROD players aren't scientists, at the same time the discovery of new interactions is what keeps things interesting and avoids overly homogeneous rooms, at least imo.

Idk exactly how strongly I feel about this being changed. For this specific bug I don't think it's a super huge deal if it were to be changed but at the same time I think it kinda sets the precedent that certain interactions could be changed which had been acceptable for the past however many years, which isn't great in my book.

____________________________
Member of the Snake Appreciation Society

One of your local HAs.

My stuff:
Click here to view the secret text


[Last edited by navithmastero at 07-28-2021 01:34 PM]
07-28-2021 at 01:23 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Nuntar
Level: Smitemaster
Avatar
Rank Points: 4775
Registered: 02-20-2007
IP: Logged
icon Re: pushing moves & tokens (+2)  
Doom wrote: Even if this ends up staying in the game due to being too much of a pain to change, it's not a trick that I'd be happy to see as a lynchpin in new holds. Avoid exploiting quirks, players aren't DROD scientists, etc.

This soundbite gets thrown around a lot, and I disagree with it on a very fundamental level. Take, for example, the fact that brains don't understand either force arrows or orthosquares, and when constructing paths, they treat force arrows as walls and orthosquares as open floor. It's weird and it's definitely not something new players could be expected to guess. But it's such a powerful enforcement mechanism that our ability to make brain-themed or even brain-containing puzzles would be utterly crippled if we couldn't use that quirk. And this is just one example. Serpents have notoriously quirky behaviour. Shallow water requires you to remember everything that can go in it or can't. Movement order and stuff-within-a-turn order can get really weird, especially when it comes to multiple activations of orbs, tokens and so forth. Where do you draw the line between what's acceptable and what isn't? Who gets to draw the line?

DROD is an extremely complex game, and most of the people who've stuck around since TSS are those who enjoy the complexity and the enormous puzzle potential it provides. And I say this as someone who abandoned the game and the community twice, years apart, because after TCB came out I couldn't get my head around how much the complexity had increased. What brought me back to the game was being able to start with GatEB and work my way up slowly, step by step.

GatEB is not flawless, but it is a really good beginner hold and introduction to the game. (I'm pretty sure this opinion is shared by the majority of the community.) It is also not shy about expecting the player to "be a DROD scientist" and learn for themselves how soldiers and guards work, quirks and all, from the very early levels. As Pinnacle said in one of the early discussions when we were just starting the EP project: "I think it's both safe and necessary to assume the player has a brain." At some point the new player has to learn these weird and quirky behaviours, or they won't be able to get anywhere with the thousands of weird and wonderful puzzles that use them.

And I agree with navithmastero that with careful puzzle construction, the discovery of a new mechanic can be turned into a rewarding experience. At the risk of blowing my own trumpet a bit, I'll give an example from one of my EP rooms. The room consists of a number of chambers, with the connections between them blocked by mud and tar blobs, some of which can be cut, some cannot. There is one mud/tar switch in the room, on a trapdoor. You don't have to remove all the tarstuff, but you have to reach a number of the chambers to get at some mimic and decoy potions, which are used for killing isolated monsters.
Click here to view the secret text


____________________________
50th Skywatcher
07-28-2021 at 04:26 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
Doom
Level: Smitemaster
Avatar
Rank Points: 3311
Registered: 07-05-2004
IP: Logged
icon Re: pushing moves & tokens (+1)  
Nuntar wrote:
Where do you draw the line between what's acceptable and what isn't?
The line is "this behavior is unintuitive to the point where it looks more like a bug than a design choice". Obviously this is subjective, which why sometimes there's a debate.

A lot of DROD rules are arbitrary and I'm sure a new player can understand that things had to be decided one way or another. They're going to be able to make pretty good educated guesses about how things probably work, then experiment to get the answers for the less obvious stuff that could go a number of ways. No problem with this process.

But it's not satisfying to solve a puzzle that you've been stuck on when the answer turns out to be an interaction that you had no idea existed, or worse, feels wrong and like it shouldn't have worked at all. Nuntar's examples don't belong to this category because for the most part they make sense in hindsight, even if you couldn't think of the trick and had to look it up. Compare to getting stuck on The Custom Element Contest Compilation : Net Benefits : 2 North, 1 East, only to learn that the trick is
Click here to view the secret text

I haven't seen any EP rooms so I'm not sure how deep it goes into obscure DROD-stuff, but the risk of trying to cover everything is that there are some ugly rules that aren't normally a problem because in practice nobody makes rooms that require knowing every little detail. Think about flaws in Slayer AI (iirc there's a way to kill him in a plain, rectangular room). How various elements decide tiebreakers. Even waterskipper pathfinding is kinda ridiculous. You could build rooms in which the player gets to experiment until they learn the rules, but it wouldn't be fun.

TLDR: Discovery of new mechanics can be rewarding. Discovery of bugs and implementation details can not.
07-28-2021 at 05:53 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
disoriented
Level: Smitemaster
Avatar
Rank Points: 2402
Registered: 08-07-2007
IP: Logged
icon Re: pushing moves & tokens (0)  
Doom wrote:
The Custom Element Contest Compilation : Net Benefits : 2 North, 1 East

Click here to view the secret text


____________________________
34th Skywatcher

Best to PM me, since I might miss your message on CaravelNet chat.
07-28-2021 at 07:21 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged
icon Re: pushing moves & tokens (+2)  
Doom wrote:
In the grand scheme of things I don't feel too strongly about this, but from an architect's point of view it's a bit of a shame that setups like this aren't airtight at the moment....
I'm going to be fair here, and note two things. First, even if this got fixed for Mimics, it would still be divergent for Clones (since it seems the prevailing opinion is that Clones feel more passive than Acive). Secondly, the setup demonstrated could be fixed by adding two extra 1-tile wide Trapdoors before the token: one sadly isn't enough if you have a throwaway double to push into a pit square (since it would survive long enough to push the Mimic on the opposite side).

I'm also a bit surprised on the level of importance being assigned to keeping Mimics and Decoys as identical as possible. While I accept they should always retain certain similarities due to their nature as potion-created Beethro Doubles, their designed function already creates several differences between them... though naturally, these are generally based on "Mimics moves, Decoys are a target". Though I will note that the biggest difference I could find is the somewhat interesting quirk in that Slayer Wisps will always avoid Decoy Swords, but not any other entity's swords (including inactive Clones). In any case, to me, if we're discussing token differences as a property of the Active vs Passive nature of doubles, I'd personally expect this to be another natural difference between Mimics and Decoys.





Anyways, moving on. With regards to 5.1.1, I would agree with Mike that the behavior shouldn't be altered right now, at least for Mimics and Characters.

Changing it for Temporal Clones may be worthwhile though, for both Tokens and Fuses. (I will note that the issue with Tokens and Fuses are the same here: Token/Fuses are only triggered on an entity's turn, with the exception of Beethro, who can activate them on push. The main difference is that Fuses don't care if you didn't move on your own turn.) This *can* be left for 5.2 as well if necessary though.

However, one thing I'm definitely interested in is how many rooms would be affected by changing Mimics. And we do have a method of investigating this which does not involve "make the change then see what breaks". I think only Schik and I used it though, so I'm going to go over it here just to get people on the same page.

In this case, what you need to do, is to add the following to CArmedMonster::PushInDirection after the pGame declaration:
   #ifdef TEST_SPIDER
      if (this->wType == M_MIMIC)
      {
         if (pGame->pRoom->GetTSquare(this->wX, this->wY) == T_TOKEN)
            CueEvents.Add(CID_TestSpiderFailure, this);
      }
   #endif
(Hopefully I didn't botch that -- been a while since I coded anything in C++, and I still don't have a coding system setup.)

The TEST_SPIDER define is something that isn't used by either the regular Demo Spider or any released version of DROD, and instead we can use it to flag a demo to break on the Test Spider if a particular situation occurs in it that we want to take a closer look at. This is naturally very customizable (we could even tighten the above code to ignore Vision, Temporal Splits or Persistent Movement Tokens, or even Weapon Tokens that wouldn't trigger because the Mimic already has the correct weapon, but in this case the extra demos from not doing so shouldn't be too much of an issue to manually check).



Oh, and as another aside, there is definitely something wrong with roomsearch.php when using a (x OR y) AND (a OR b) format. After seeing far fewer results with things I was actually looking for, I did a test with "((Squad Horn >= 1 OR Soldier Horn >= 1) AND (Spider >= 1 OR Fegundo >= 1))", and the only rooms that appeared was the one that satisfied "(Squad Horn >= 1 AND Spider >= 1)"; the other criteria were ignored.






Finally, I want to quickly touch on what room breaks I'm expecting to see once the Test Spider is run. If only Mimics are changed, then the two types of breaks I'd expect to predominate are the following:


1. Rooms that can no longer be completed as they depend on a pushed Mimic not activating a token. If the change goes through, these rooms would need to be updated. Waiting for 5.2 is beneficial in this case, since we can consider more tools that might help -- but it may be difficult to completely replicate the required behavior for the room to work identical to before. There's definitely a few examples where a token has been used as a failure state, preventing a passage from being used by any player tool except for a pushed double.

I've been toying with the idea of coding/requesting a meta-element that would immediately kill Beethro and Temporal Clones (and maybe Clones as well) if they move over it -- that sort of thing would preserve the "only Mimics/etc can go down this route" without having to create some bulky machine that could break some other way. (You could mostly script this, except that scripts can only check on their own turn, so multiple pushes would continue to be a problem.) But such an element still wouldn't preserve the requirement of pushing the Mimic onto it, and it would also be less subtle than the current use of pre-existing tokens. More thought and discussion will be necessary if we do get this far.


2. Demos that accidentally pushed a double onto a token. The room isn't built to require it, it just happened by accident. Hopefully this will be limited in number, and be a small percentage of demos for any room they affect. If a large number of the topmost demos for a room are affected, we can look to see if the room can be tweaked a bit to preserve the demos without changing the solution of the room.


There is a third type of break that we can't detect via demos: ones that introduce unintended solutions. This means that the change has granted the player a new tool that would not have previously allowed the room to have been completed, and as a result, no demo features it. In this case, the tool is only that when pushed, a Mimic will still activate a token. Since Mimics already activate tokens through normal movement, I am *not* expecting many of these at all, since it would require a setup where a Mimic activating a Token would allow an easy completion of a room, but the Mimic can only be Pushed into that tile and cannot get there normally. There are definitely theoretical setups that could cause this (Staff-wielding Entity guards Token tile; Player can't make correct diagonal movement to naturally reach token), but I don't think the majority of these would happen by accident, so they should be rare and/or notable.

This is the sort of thing we should be willing to update if and when they're pointed out though, since it'd be a US introduced by a patch rather than a mistake on the architect's part.
07-30-2021 at 09:54 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Schik
Level: Legendary Smitemaster
Avatar
Rank Points: 5428
Registered: 02-04-2003
IP: Logged
icon Re: pushing moves & tokens (+3)  
TFMurphy wrote:
Oh, and as another aside, there is definitely something wrong with roomsearch.php when using a (x OR y) AND (a OR b) format. After seeing far fewer results with things I was actually looking for, I did a test with "((Squad Horn >= 1 OR Soldier Horn >= 1) AND (Spider >= 1 OR Fegundo >= 1))", and the only rooms that appeared was the one that satisfied "(Squad Horn >= 1 AND Spider >= 1)"; the other criteria were ignored.
In the timeliest of fashions, I believe this is now fixed. It's kinda hard to test. I fixed problems in both the parsing of (some) rooms, and in the formation of certain queries.

If anyone wants to test this, please do! And if you find either rooms that shouldn't show up but do, or rooms that should show up but don't, please give me details and I'll see if I can fix it.

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi
09-18-2024 at 04:46 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores Quote Reply
1
Page 2 of 2
New Topic New Poll Post Reply
Caravel Forum : DROD Boards : Bugs : pushing moves & tokens
Surf To:


Forum Rules:
Can I post a new topic? No
Can I reply? No
Can I read? Yes
HTML Enabled? No
UBBC Enabled? Yes
Words Filter Enable? No

Contact Us | CaravelGames.com

Powered by: tForum tForumHacks Edition b0.98.8
Originally created by Toan Huynh (Copyright © 2000)
Enhanced by the tForumHacks team and the Caravel team.