Player Triggering Change Issues

[Francesco]

Hi all,
I was playing around with the PTC ref. element, and just discovered a nice way to trick the RnD engine

Here is the archive:
http://www.zomis.net/rnd/download.php?id=553

The first level is called The Room of Infinite Teleporting... well, it is not infinite, anyway, but since it "stops the time" (at least for the RnD engine) it goes close to that

Better that you take a look to the tape, to see the tricked engine

Now the second level: Teleporting YamYams... you won't believe me, but I was able to show the Player Triggering Change element on the level during the gameplay! Again, see the tape to have the proof. (Hey, I know, it's quite easy to do so, but I didn't mean "by putting it directly on the map" )

Well, this is more a change request than a bug report: I'd like to have an editor that forbids me to put more than a PTC in an Extended Change Target.

Since they work also inside of normal elements like YamYams and Amoebas, it would be nice to avoid those special elements to be put inside of these normal elements.

Maybe it's matter of tastes, but those "permissions" could lead to additional compatibility code, in the future, if someone has the nice idea to use them to make tens of levels...

[Francesco]

I was reading this topic, that is about the restart of the level after reloading. It also mentions the doubled player, which is exactly what happens in my first level above. I don't really know if there is some link between the two things, just noticed the similarity.

Again from the first level above, it is quite clear that the screen is being updated more than once in a frame. In a first time I thought that this would have been a bottleneck for tape reloading, but then I realized that it shouldn't apply to it, because the screen is not updated in that faster reloading... so, again, I don't know. In any case, I don't see the need for updating the screen more than once per frame, but I fear it would make no difference changing this.

Hope that these thoughts could be useful in some way

Addon to my first post above: it should be forbidden also to put more than one single "normal player" element, in the ECT, not only the PTC. I think it could work as just it already works on the map: if you put a second yellow player, the first yellow player is removed.

[Daniel H.]

Well, sometimes you want to have the ECT be:

• 
  
  

(where "Yellow Player" may be "Player Triggering Change" instead)

This ensures that the yellow player (or PTC) gets teleported to the lower right location, unless that location is blocked by something indestructible. Then it will try other locations.

[Francesco]

Yes Daniel, that technique can be used, but I see it more like a buggy thing used as a feature, than a real feature.

For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.

Furthermore, the need of such a "try this, then try that", looks like a badly designed level: it's quite easy to ensure that the destination tile is free for teleporting the player.

[Zomis]

For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.

Well... you could use "Set engine scan mode = reverse"

Even though it's indeed a bug to show the "PTC" in your testlevel #2, what else should be shown instead? Since the player is already dead, he shouldn't be ressurected again, right? So should there be empty space or the famours question mark '?'?

[Francesco]

For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.

Well... you could use "Set engine scan mode = reverse"

Yes, you're right. But what if I'd wanted the middle-left to be the final destination, and if it were occupied, any of the other? Read below.

Even though it's indeed a bug to show the "PTC" in your testlevel #2, what else should be shown instead? Since the player is already dead, he shouldn't be ressurected again, right? So should there be empty space or the famours question mark '?'?

That was just a side effect of being able to put such a special element in a normal element like a YamYam.

To be sincere, most of the knowledge I have about such games (BD, EM and so on) is limited to RnD. But I don't think there is any kind of teleporter in the original versions.

The issue is more about being able to put more than a player element in a ECT, or to be able to put it inside a normal element like the amoeba. In my opinion, it should be avoided.

I don't really see the need of such a multiple-destination teleporter, also because, as it is now, it tricks the graphical engine. Also, try putting the yellow player inside of the amoeba, you will see another example of the tricked engine.

[Daniel H.]

[...]but I see it more like a buggy thing used as a feature, than a real feature.

OK, that's a point, but what if you aren't particular about which side the player comes out? In multiplayer games, it would make it harder for one player to keep another from using the Player Teleportation Unit.

[Francesco]

I don't know if my last work applies to your argumentation, Daniel.
I still think that shouldn't be allowed more than a player element in a ECT.

In any case, I've just made a MP level where the first player that collects 25 gems wins (and gains the freedom). The fake open door is not a safe place to stand nearby, furthermore because the player should be inside of the cage collecting gems
http://www.zomis.net/rnd/download.php?id=555

[Francesco]

Another highlighter, as Holger didn't post here yet.

[Holger]

Haven't missed it (just not replied yet), but thanks anyway. :)

Well, yes. The "player relocation" stuff is handled independently from the rest of the engine (as all player actions), so it's not the whole playfield that is updated more than once per frame, but only all player the locations. In this case, all relocation stuff is handled before the engine continues. (It's most probably easy to do infinite loops, which is probably a bad thing.)

And yes, if you put "player triggering change" elements into normal elements, it could cause them to be displayed in the game, which should probably be prevented.

But I think it does not cause much harm (besides looking strange), so one should probably just not use them in such circumstances. But maybe it's indeed wise to technically prevent this...

[Francesco]

Thus the solution(s) shoud be to:

- forbid putting more than one of "player element" or "player REF element" in a ECT;

- forbid putting any of these elements in a standard (classic) editable element.

Am I right?

[Holger]

Well, completely forbidding to put these elements in certain drawing areas may not be the best solution, but instead handling them accordingly by the game engine.

For example, if you cannot draw elements in a drawing area, this surely feels "wrong" -- you would at least have to display an error message to make this clear.

Preventing to add more than one element of a kind into a certain drawing area could also be misleading (for example, if you wanted to delete the others a few seconds later anyway).

[Francesco]

I beg your pardon, but isn't it the way that the map works when you try to add more than one player start location? What's misleading there? I feel it as the normal behaviour... well, maybe I have expressed it in the wrong way: putting a duplicate in a ECT should result in the removal of the previous duplicates, just like it works for the map.

About putting special elements in a normal element, an error message would be good indeed, unless you think that it could be used as a feature, then you could leave it as it is now. Killing one YamYam and being teleported to its death-ground could have its interesting aspects and usages

[Zomis]

I think it could be used as a feature. For example, a teleport which teleports you to a position unless it's completely blocked, that would need more than one player 1 / PTC in the change target.