2.00 Interactive objects - Arbitrary shapes / sizes / etc for trigger areas?

[namida]

I've mentioned this idea in passing elsewhere, but no feedback has been received on it so time to give it its own topic, especially since I'm getting towards the point where a decision on this has to be made (otherwise a large amount of reworking will need to take place later to implement it).

Should arbitrary-shape/size trigger areas be allowed, rather than just rectangular ones? I would guess the primary use of it would be to allow circular trigger areas, but in general doing it this way would remove the need to add more supported shapes in future, since anything is allowed. It could also be used more creatively, for example, to create an exit with more than one region from which it can be entered (perhaps a large building that allows using a window, as well as a door). The only real downside (aside from an almost-negligable increase in file sizes) would be the potential for very annoying and illogical usage, but arguably that can be done (albeit not as complexly) even without such support. So for those of you who say no, it'd be good if you could post about why you feel that way.

[ccexplore]

The Lix buzzsaw hazard is probably a good example of where a non-rectangular trigger area is desirable (namely circular, obviously).  I'm always a little bothered that with the current trigger area, the lix can be closer to the buzzsaw than the visual graphics would imply, but of course with a rectangular trigger area and a circular visual shape, you just can't win--the trigger will always be too large or too small.

Looking beyond that, having other-shapes support could allow, for example, versions of the Lix laserbeam hazard that can be at any angle, not just horizontal or vertical.

So as you said, it's not that we want to promote crazy shapes, but clearly there are at least a few good shapes, and being able to support more arbitrary shapes on the outset would prevent needing to add more supported shapes in future updates.

I'm less convinced of the need to allow multiple-disjoint-regions trigger, mostly because in most cases it seems like you can achieve the same effect via multiple objects, each with their own continuous-shape trigger, that can be put together to achieve the effect.  But for that same reason (ie. seems like it can be emulated anyway even when disallowed), I'm not opposed to it.

[Simon]

I haven't felt like the buzzsaw is too lenient, altough I can imagine why it's bothering. I don't feel circles are neccesary are absolutely required, use a bigger buzzsaw to clearly block the path. Circles can be interesting.

For video games in general, if the character slightly enters the dangerous sprite and is not killed, nobody cares much. If the character doesn't enter the sprite, and is killed nonetheless, everybody will rage.

The argument for diagonal lasers is more compelling. When you're designing a specification, you can shoot for this.

Gadget designers should not get too fancy; they should make connected and idiomatic gadgets that clearly look like all/most of it is dangerous/desirable. The diagonal laser satisfies this, exits with multiple archways do not. The L1 Hell flamethrower looks like it has safe pauses, but it is always deadly. The L2 Sports exit is horrible.

You want to infer trigger areas from a text file, with a handful of simple commands for rectangles and circles; or from a second image, as a mask. Again, this dove-tails into the issue of graphic sets, and that you shouldn't gobble data into a format that no commonplace tool can understand.

-- Simon

[geoo]

I voted for only allowing rectangles, though the diagonal laser is a compelling reason to allow some other shapes as well.

In the end it comes down to the following: The player of a level should be able to predict the trigger area of an object by just looking at it. If limited to rectangles, that's an easier task. But if a graphic set designer is responsible, whatever he comes up with will be at least as good as a rectangle (in fact in most instances he will probably just use a rectangle). But if your graphics set designer is dumb (and you certainly seem to take that into account with the argument that he might just distribute half of his graphics set), then maybe restricting the number of ways he can do dumb things is good? Certainly I don't want to see exits where you can enter through the window in addition to the main door.
In the end, this should be self-regulatory, and thus if your graphics set it dumb hopefully it won't be used very much; but if used the wrong way it has a strong potential to fool the player. Either way, there are reasons for both, and I'm not sure I still stand by my vote.

[namida]

I'm thinking that the best way forward on this for now is to support it internally, while not supporting it in the actual file format; this way, if the decision is against supporting it, then no changes need to be made, while if the decision is in favor of supporting it, only a quick (and more likely than not, backwards-compatible) change to the file format is needed rather than entirely reworking how objects are implemented.

In the meantime, feel free to continue discussion / voting on whether or not it should ultimately be supported.

[namida]

I'm going to allow these - although opinions are mixed, the arguments put forward for why they should be allowed is very convincing. For those worried about the extra work of implementing it - no worries, simply specifying a rectangular area in the metadata (rather than making an image to define a trigger area) will still be possible.

Yes, it can be abused - but so can plain rectangular areas. And the circumstances presented under which this could be used to good effect are indeed things that I can see being useful.