1

Topic: idiot check

I made a change to rlk's level locks.map

I added timers to the switches so that, once triggered, they no longer change back to red when you pass through them subsequently.
I thought this seemed a bit odd, given that they only activate the gates one time.

I think this is an improvement in the functional ceherence of the level.
It doesn't change the game play in any way, it only makes for visual consistency with the behavior of the mechanism.
If I am missing something obvious, or there is a reason why this is a bad idea, please let me know.

2

Re: idiot check

The implicit contract of a switch presented with the mtrl/switch texture is that the player is able to change its state at any time, i.e. from off to on and vice versa. With your change, this no longer holds true. There is now a difference in behaviour between locks.map and, say, gaps.map.

I agree, however, that letting the player reset a switch to "red" after the associated action has already finished can be irritating. What may be needed is a third kind of switch (texture) which signals that activating the switch will trigger an action that can neither be stopped, repeated nor reverted. This could then be used for locks and a couple of other levels.

3

Re: idiot check

A new texture sounds good to me. Or maybe different colors? Say yellow and purple?

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

4

Re: idiot check

I think we should stick with green and red, as they are universally understood as "on/off" or "open/closed"

I had this idea that, given the once only scenario is the exception, we could split the decal and have the star pattern in the center dip down into the floor when triggered (and disappear) leaving only the circle.

It would be a little extra work for the designer, but what the heck..
My fear is that another symbol might seem cryptic or be confusing..

5

Re: idiot check

The disappearing star sounds fine to me.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

6 (edited by Challenge Space Yard 2007-12-23 14:24:11)

Re: idiot check

Perhaps there should be a new attribute called "limit". It limits how many times a player can toggle the switch, with 0 (the default) disabling such a limit.

For those switches tones was messing with, the "limit" would be 1.

Welcome... to the Nevergalaxy!
(and also Neverputt Calendar)

7

Re: idiot check

Why not just change locks.map so that when you hit the switch again the barrier goes back up?

8

Re: idiot check

rlk wrote:

Why not just change locks.map so that when you hit the switch again the barrier goes back up?

Now there's an idea... does everyone like this?

9

Re: idiot check

Sure.

What about if we do want a one-time switch though?

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

10

Re: idiot check

jammnrose wrote:

What about if we do want a one-time switch though?

Seems to me that a disabled switch is best indicated by a lack of glow effect rather than a different color or decal.

11

Re: idiot check

Sounds good.
Probably wouldn't hurt to have the functionality. I don't think it matters for the level one way or another though.

I say we could have it switch from red -> green and then fade out instead of just red -> nothing.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

12

Re: idiot check

I agree that fading out is a better option, but it doesn't give any indication as to what sort of switch it is before you activate it (which may or may not be desirable).

Cheese
==========
cheesetalks.net

13

Re: idiot check

ok, I am revisiting this topic.

I want to do what rlk suggested, namely enable the locks to go back up when the switch is triggered again.
This will restore the "contract", as Elviz put it, of what a switch means functionally speaking so that the subsequent switch triggers will at least have a corresponding action from the gates.

I just looked at all the replays in the table to see if any would become obsolete. None of them involve re-entering the switch halos so there's no problem there.

In the meantime, anyone care to chime in with any objections before I commit the change?

In addition, maybe we could carry this conversation forward a little and try to resolve the quandary before a future release.

I would like to see:

1) A switch that signals on or off STATE ("moving" and "not moving") with its respective green and red halos. (this is what we have already)

2) An additional key that can designate a switch which initiates a one-time action (ie. has a timer) but signals instead the "on" or "off" POSITION of it's target. For example, the gates on locks.map could be red=closed, green=open. This would also mean that you would have to leave the halo and re-enter to trigger the change in position, it would function the same as a switch with no timer. (ie. hard level sync.map)

(side note: I never really felt a strong need for the ability to "disable" a switch, especially since we basically use blockers for that anyway, which I like. The red halo is an enticement to unblock and activate the switch. But I do understand that some other level designers may want to make use of one which becomes disabled after being triggered, which would be weird to use a blocker for)

14

Re: idiot check

P.S. You know there is one more idea for locks.map that I don't think has been suggested before and might be cool:

make the switches timers so that you have a set number of seconds to get in and out of the zone protected by each lock. This might increase the difficulty a little and may befuddle our set order, which would not be worth it.

Actually, on second thought, maybe this idea is just the basis for another neat level. Mym has already done the concept very well with backforth.sol

15

Re: idiot check

tonesfrommars wrote:

I want to do what rlk suggested, namely enable the locks to go back up when the switch is triggered again. [...] In the meantime, anyone care to chime in with any objections before I commit the change?

I had planned to reply to some of your thoughts, but put it off because it turns out that the question of switch design is surprisingly complex. To avoid entering into a potentially time-consuming discussion at this point, I'll offer just two quick remarks:

In r3456, the switches are now proper timers and therefore should no longer have the star texture. In general, whenever a visible switch deactivates itself and its associated path after a given amount of time, this behaviour should be conveyed to the player through the use of the timer texture.

Secondly, the change does cause some replays to look funny (example), although I only noticed that just now. If we keep the level this way, I think the map version needs to be increased.

16

Re: idiot check

Holy crap!
Now why would this replay be so whacky? I guess I didn't realize that the replay files are recording positions for things other than the ball. Thanks for bringing that to my attention.

I agree with you re: timer vs. switch. However I think I will revert this change for now until we can implement a more satisfactory switch/timer model.

I'll be interested to hear your (and others') thoughts when the time comes.