[Showcase + Discussion] Teleporter corner cases

[IchoTolot]

Simon and I found teleporter corner cases and we've made a test level! Attached with solution.

Save a Lem from every hatch using teleporter mechanics!

(Design loosely inspired by fishthekiller )



4 lems, save 3.
Middle hatch spawns 2 lems, others spawn 1 each.
2 climbers,
1 bomber,
1 builder,
1 platformer.

Solutions:

Spoiler

Upper case: Not only permanent skills are transported, but even builders,diggers etc. This behavior is weird at the start, but makes sense; the rule is: The lem is being transported as it is.

Middle case: Of course climbers can be teleported and they even keep climbing, but here they need to arrive one pixel closer to the right. You have to use the bomber to make the climber go in a pixel more to the right and the arrival position actually depends on the entry position ---> climber keeps on climbing.

Lower case: The same case here just vertical. You need that 1 pixel more height the platformer can provide you here.

These are extreme corner cases, but we wanted to share them with everyone

IchoTolot suggests to keep the current receiver output behavior. As if we change the output to put lemmings always in the same spot like a hatch; this change would affect every teleporter level in existance.
The continuing of skills is debatable and both possibilities would make sense. Keeping and changing are both viable options. + this trick hasn't been used yet to my knowledge

Simon isn't sure what to suggest. The output offset irritates him most, more than the kept skill irritates.

-- Simon and Icho

[Dullstar]

The kept skill seems reasonable, but so does cancelling the skill. I feel like the teleporter should probably dump the lemming in the same place every time in order to discourage level designs based around knowing that you can do this.

[ccexplore]

This is vaguely reminiscent of, say, Lix simplifying basher behavior by making the steps created by a partial stroke not possible, or (a looser analogy) taking away the ability change the release rate.  There are a few usual general reasons to consider reducing the possibilities of some parts of a game's physics.  Of course, I think we had more than mere corner cases to examine when it came to those other examples.

I don't know what we can reasonably expect people to assume when it comes to teleports, since there is no real-life experiences other than maybe other games, and I'm sure it's not very consistent from game to game either.  I haven't tested it, but I'm guessing Lemmings 2's teleports are probably skill-canceling and outputs to same location.  On the other hand, although I haven't played those games at all, I have a feeling those portals in the "Portals" series of games probably behave much more like what we have here, where a lot of state get transferred directly to the output.

I think it's more important to understand if the current behavior are actually creating situations where the level author and level players can easily shoot themselves in the foot?  That is, the level author isn't intentionally making use of, say, the output offset behavior, but the behavior introduces unwanted precision for the level players in a level, and at the same time the level author can't easily tweak the level to remove the precision?  This would make for more convincing arguments than corner cases, otherwise it feels a little like hidden traps, where we've simply been "handling" things by telling people they are lame.

I also think that for discoverability, it would be easy enough to create an introductory level for teleports that directly require and illustrate these two behaviors, by making it obvious in the level that the player have to, say, use one single builder who gets teleported mid-build.  It would at least directly show the skill-preserving behavior, and the more observant may also see the offset-preserving behavior as well.

It may also be interesting to think about consistency, even though there is no direct requirement for unrelated things to share similar behaviors.  For example, blockers' effects on other lemmings are at least skill-preserving in most if not all cases (not sure a clear analogy can be made there for the output offset aspect).

[IchoTolot]

I don't know what we can reasonably expect people to assume when it comes to teleports, since there is no real-life experiences other than maybe other games, and I'm sure it's not very consistent from game to game either.  I haven't tested it, but I'm guessing Lemmings 2's teleports are probably skill-canceling and outputs to same location.  On the other hand, although I haven't played those games at all, I have a feeling those portals in the "Portals" series of games probably behave much more like what we have here, where a lot of state get transferred directly to the output.

Interesting point. In fact the L2 teleporters are extremely different: They can teleport as many lemmings as they want + even the entrance has just a 1 pixel trigger as every other object there, which I would say is a big disadvantage as you can easily cover up a 1 pixel trigger by accident.
The portals from Portal are a good analogy here

I think it's more important to understand if the current behavior are actually creating situations where the level author and level players can easily shoot themselves in the foot?  That is, the level author isn't intentionally making use of, say, the output offset behavior, but the behavior introduces unwanted precision for the level players in a level, and at the same time the level author can't easily tweak the level to remove the precision?  This would make for more convincing arguments than corner cases, otherwise it feels a little like hidden traps, where we've simply been "handling" things by telling people they are lame.

I also think that for discoverability, it would be easy enough to create an introductory level for teleports that directly require and illustrate these two behaviors, by making it obvious in the level that the player have to, say, use one single builder who gets teleported mid-build.  It would at least directly show the skill-preserving behavior, and the more observant may also see the offset-preserving behavior as well.

It may also be interesting to think about consistency, even though there is no direct requirement for unrelated things to share similar behaviors.  For example, blockers' effects on other lemmings are at least skill-preserving in most if not all cases (not sure a clear analogy can be made there for the output offset aspect).

The hidden trap treatment could work although I feel this even less stinky as it still displays everything and in itself the action is logical as you get toknow the background. An introduction level could also be very helpful.

There are more problems with changing the recievers trigger area to 1 pixel than the fixing of levels and a ton of replays:

Every tileset creator would need to change up their tileset to the new standard (+ new tileset creators must know about this). Given the way that not every person is quick on the updates (or even ignores them; compare to the background image change disaster) this could lead to even more inconsistancies as sometimes the new, sometimes still the old standard applies. This would end in pure chaos as I know how those things tend to end here!
Tilesets included in most packs would also need to be updated otherwise more chaos.


I must say after discovering it: The teleportation of the current skill like a builder is a cool mechanic that could open up for interesting puzzles   Make a quick introduction level in your pack and then use it advanced situations.

[Simon]

If you keep the output offset, change the output animation. It's misleading to show a fake lemming on the receiver, then offset him after the animation's done. I'd have never guessed this offset from the gadget's animation.

Make a proper lemming sprite that animates at the correct position relative to the receiver? Like drowners in water.

-- Simon

[namida]

Keeping and changing [the continuing of skills] are both viable options. + this trick hasn't been used yet to my knowledge

I don't know of any levels (other than levels made purely for the purpose of showing off or testing this mechanic) that use it, but I can think of at least one level that was still affected by this - USS Lemterprise from LPO2, ignoring the existance of this behaviour made a backroute possible. The final version, of course, is set up so that this backroute no longer works.

Make a proper lemming sprite that animates at the correct position relative to the receiver? Like drowners in water.

There are many different receivers, which have different animations for the lemming appearing. And usually, a different number of frames it happens over. Most likely, changing this would break just as much (if not more) than changing to a single point. Additionally, teleporters and receivers tend to have small enough trigger areas that this isn't too noticable.

One workaround that should at least keep things mostly backwards compatible would be to use the center of the trigger area on graphic sets that haven't been updated. Alternatively, the change could be made when the new formats are introduced, meaning there are no graphic sets that are both (a) compatible with versions that have the new behaviour and (b) have old-behaviour-based trigger areas. Of course, there is the very real possibility that some people will just blindly plug their graphic sets into the convertor app without paying any attention to this. The aforementioned workaround could be used here too - if the receiver's trigger area size isn't 1x1, use the center point of it when converting.

[IchoTolot]

Simply centering it would be bad as the lem would spawn into the air.

Horizontal center + vertical bottom (so ground level) would be better if changes were to be made to the receiver. The would most likely just break replays that are using teleporters (but levels need to be rechecked).

[namida]

I've looked at the teleporters in the default graphic sets, and found the following trigger areas.

Marble: To spawn a lemming on the ground, it would need to spawn 1px below the bottom of the object. Trigger area extends to 2px below the bottom of the object.
Purple, Martian: To spawn a lemming on the ground, it would need to spawn exactly at the bottom of the object. Trigger area extends to 1px below the bottom of the object.
Psychedelic, Circuit, Abstract: To spawn a lemming on the ground, it would need to spawn 1px below the bottom of the object. Trigger area extends to 2px below the bottom of the object.
Space (LPIV): To spawn a lemming on the ground, it would need to spawn exactly at the bottom of the object. Trigger area extends to 1px below the bottom of the object.
Machine: To spawn a lemming on the ground, it would need to spawn 1px below the bottom of the object. Trigger area extends to 1px below the bottom of the object.
Space (L2): To spawn a lemming on the ground, it would need to spawn 1px below the bottom of the object. Trigger area extends to 1px below the bottom of the object.
Shadow (L3): To spawn a lemming on the ground, it would need to spawn 1px below the bottom of the object. Trigger area extends to 1px below the bottom of the object.

"Bottom of the trigger area" works only for Machine.
"Bottom of the trigger area, but no more than 1px below the bottom of the object" does not work for Purple/Martian or Space (LPIV); it works for the rest.

I don't think there is one rule that fits all of these, let alone teleporters in other graphic sets, and a manual fix is the only way that will work.

[namida]

Latest experimental implements a single-pixel-point system for receivers. Graphic sets should be modified to have a 1x1 trigger area at the exact point for receivers. There is a fallback rule for graphic sets where this isn't the case; future GSTool updates will disallow such graphic sets in the first place.

[Simon]

I feel the 1x1 receiver zone stays most honest with the animation.

Were you ever concerned about asymmetry? Most gadgets have even width, and an even-width trigger area.

-- Simon