Can't create a locked exit level.

Started by Minim, February 11, 2016, 10:33:44 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Minim

QuoteLocked Exits and Unlock Buttons

These two objects go hand-in-hand. A locked exit is like a normal exit, except it can't be used until all the unlock buttons have been pushed (by having a lemming walk over them). No special setup is needed for them; just place them in the level and they'll work.

I'm trying to create a simple 'activate the switches to unlock the exit' level. However, my exit is still open no matter how many switches are there. Is this an error or just a not-detailed-enough explanation from the guide?

Here's an attachment of the level I've been trying to work on.
Level Solving Contest creator. Anybody bored and looking for a different challenge? Try these levels!

Neolemmix: #1 #4 #5 #6
Lix: #2  #7
Both Engines: #3

namida

You're still using the regular exit (object 0). Use the locked one (object 14 in the Metal style) instead.

The reason for this is to allow a single level to have both types of exits, if anyone were to come up with a design that requires this.

I edited the guide to stress this point.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Minim

I see... thanks namida. I think I just made the assumption that there was no point about using another exit object when there's one already.
Level Solving Contest creator. Anybody bored and looking for a different challenge? Try these levels!

Neolemmix: #1 #4 #5 #6
Lix: #2  #7
Both Engines: #3

Simon

#3
Log from IRC:

<SimonN> "The reason for this is to allow a single level to have both types of exits, if anyone were to come up with a design that requires this."
<SimonN> NO NO NO this is not how you design
[game mechanics]
<SimonN> YES YES YES would be: the exit is forced to be closed, and people have to clamor for special rules. Most likely, nobody needs the special rule. Then you benefit massively from easier UI, and prevent errors like that
<namida42> the locked exit is a completely different object type (just with similar behaviour) internally. thus, forcing that would be an artificial restriction
<namida42> and i am sure there would be potential use for it, in a level where different lemmings go to different exits (think something along the lines of Utopia)
<SimonN> you should have designed the code such that it would have been a natural corollary
<SimonN> so you decided that the elusive use case warrants making several gadgets, allowing users to pick the wrong one
<namida42> the locked exit and regular exit look entirely different, but some levels use the locked one (without any buttons) just to have a different exit graphic
<namida42> no; at the time locked exits were implemented i barely knew what the hell i was doing, and somehow managed to make them work
<namida42> and because they work perfectly fine - and on top of that has these two (admittedly, minor, but as mentioned, one of them has actually been made use of) advantages - i've seen no reason to change it
<SimonN> Minim running into problems is perfectly fine, I get it


Usability remains important despite cultural moss.

-- Simon

ccexplore

I wouldn't necessarily go so far as only allowing one type of exits in the level, but perhaps the editor could provide a warning on save when it detects unlock buttons on a level with no locked exit, and/or maybe just not allow unlock buttons to be placed until there is already at least one locked exit in the level (with a popup explaining what is happening).  This is the kind of usability issue that is a one-time thing once the user is educated, as opposed to something that would continually bother the user day-to-day with no satisfactory workaround.

Having only one type of exit is certainly simpler and may well be enough for most cases.  Still, I think I generally rather leave things to the discretion of level designers, unless the reason not to is compelling enough.

ccexplore

I guess it's worth mentioning that perhaps one could also support two types of exits by making the "usual" one the locked version (with the current behavior where no buttons means it's effectively unlocked, hence making this proposal tenable for the default case where you just want a normal exit), and have the alternative one be always unlocked regardless of buttons.  Somehow this feels more confusing than having the alternative one be the locked version, but that might just be misguided intuition.

I would also have made it so that the locked version has distinct animations for its locked and unlocked states (and optionally a 3rd animation for the transition).  Maybe this already exists in NeoLemmix, I haven't tried it out.

Nepster

I would simply treat all exits as locked exits by default. Then setting the L- or S-value to some specific number turns them into exits that are always open.
This way it will be somewhat more difficult to create levels having both locked and open exits. But as there is already an update pending to replace the L- and S-value settings in the editor by something more user-friendly, it will be not for too long.

Quote from: ccexplore on February 12, 2016, 07:40:50 PM
I would also have made it so that the locked version has distinct animations for its locked and unlocked states (and optionally a 3rd animation for the transition).  Maybe this already exists in NeoLemmix, I haven't tried it out.
The locked and open states are already visually different and there is an opening animation as well.

ccexplore

Quote from: Nepster on February 12, 2016, 08:25:30 PMI would simply treat all exits as locked exits by default. Then setting the L- or S-value to some specific number turns them into exits that are always open.

Ah, forgot about the LS values.  Yeah, that would work and should address all conceivable needs and concerns.  Giving LS values more friendly names would help further.