Infinite Maze test

[TheOnyxGuy]

Just a little concept I was dreaming about few years. I thought if I'll begin making infinite maze it shall take very much time. But I made this in two hours. Mechanism is extremely easy. Yeah, this the simplest and most primitive maze but I'm planning to use it in future level sets.
P.S: Hold Drop item Button to run

https://yadi.sk/d/MJsi3ngmvwDhP

[AutofireII]

That's pretty cool! At first, I was doubtful that it was endless...so I wasted 170 seconds by running through the maze.

I have just two complaints:

Why a run button? It's an interesting idea, but I think it is just a little annoying to have to hold this other key down all the time. Also, rather than making the player's inventory be flooded with this run item, you can give the player one run item, and then, on the run item's CONFIG 1 page, make the run item have a CE score of 0. Then the item will be infinite.

My other quibble is an idea for improvement, but I don't exactly know how to implement it in your level. Rather than making...um...64 custom elements for wrapping around, you could probably use 3-6 elements. If you've ever played the Zelda levelsets, the way they deal with wrapping around is to have these special elements that follow the player but only stay on the edge of the map. When the player passes through one, then the player is sent to the one on the opposite side. (Once the next room has been loaded, that is.)

This only works, however, because the rooms in Zelda are placed in empty space, so players cannot see this thing moving around on the edge of the world. You, however, make the looping totally invisible to the player (which is awesome). The problem, though, is I don't know how you can make this special element stay totally invisible with all those steel walls. There's probably a clever way, but I don't know it.

Otherwise, it's a great idea!

[Holger]

Both the "wrap-around maze" and the "run button/element" are very cool!

I've did such a "invisible wrap-around level" (with similar technique) by myself once, but only with a single "teleport corridor" on both ends of the level -- in comparison, being able to move in any direction on the playfield and have the level wrapped is quite impressive!

Regarding implementation of the "run button": Yes, AutoFireII is right, this can be optimized just as he described it!

[filbo]

I know this is only vaguely related, but -- is there any chance we'll eventually see wraparound levels supported? Many levels in the Emerald Mine Club hierarchy are broken due to no wrap. (The CE tricks under discussion here only make the universe wrap around for the player, not other moving entities, right?)

[Holger]

is there any chance we'll eventually see wraparound levels supported? Many levels in the Emerald Mine Club hierarchy are broken due to no wrap.

This is indeed an open issue in the native EM engine.

(The CE tricks under discussion here only make the universe wrap around for the player, not other moving entities, right?)

Yep, right -- as there's in fact no real wrapping around, but only a teleportation of the player (to a destination tile with surroundings which may be designed just as those around the source tile, giving the illusion of a wrap-around of the level), this also only affects the player and no other moving entities. Of course, it's possible to build CEs that also teleport selected other elements.

Regarding the EM engine, I already wanted to integrate a newer version of the code (with support for wrap-around EM levels) for that engine years ago, but unfortunately, there was a huge controversy with the author of the original source code regarding licensing issues (regarding the question if it is possible to reject an open source license at a later point, and what this means for the original code that was once released under that open source license). As a result, I turned towards other sub-projects within R'n'D...

[filbo]

Regarding the EMC code controversy: I don't know what all features & fixes might be present in the updated version of that engine, but if it is simply not available due to license issues, it might as well not exist...

It seems to me (out of whatever naivete) that implementing left-right wraparound, only, without anything else that might be missing, would be (A) fairly easy, and (B) fix something like 90% of EMC currently problematic EMC levels.

Is there a worry that doing that small step would re-ignite the code ownership controversy?

[Holger]

I don't know what all features & fixes might be present in the updated version of that engine

As far as I remember, the newer versions of the code mainly contain the following two fixes:
- wrap-around movement
- corrected chain explosions

Both issues affect a number of currently unsolvable EMC levels.

Another (rare) problem that currently does not work right in the current native EM engine is the fake acid element.

but if it is simply not available due to license issues, it might as well not exist...

Theoretically, all existing versions of the code are "affected" by that issue. From my understanding of "license revocation" (and that of others with more legal knowledge than I have), revoking an open source license cannot be done retroactively, but only for new versions/revisions/releases of code released under some open source license. (Just think about potential license revocation regarding open source projects like the Linux kernel, the MySQL database, the Apache web server or whatever else open source software that comes to your mind -- but not for the next version (people would then fork the last "free" version of the software into a new open source project), but retroactively for all versions that were ever released.)

For that reason, I will continue treating source code that was once released under an open source license as still available under those license terms. Regarding the EM/EMC engine code, I have half a dozen of versions here that are newer than the version integrated into R'n'D (with the above mentioned features and fixes). Some of these versions have open source licenses that are compatible with the GPL that R'n'D is released under (like the 3-clause BSD license or a zlib style license), some have incompatible licenses (like the 4-clause BSD license). I will only use those compatible versions, of course.

It seems to me (out of whatever naivete) that implementing left-right wraparound, only, without anything else that might be missing, would be (A) fairly easy, and (B) fix something like 90% of EMC currently problematic EMC levels.

Yes, you may indeed be right. Please send patches!

For the last few years, due to those licensing annoyances, I haven't bothered to check if it could be done easily or not by myself...

(But I may change my mind and do the fix by myself one day, or just replace the current version of the EM/EMC engine with the last "license compatible" version of the code as described above.)

Is there a worry that doing that small step would re-ignite the code ownership controversy?

No.

[bear&clara]

I read a while ago that somewhere in Greek mythology there was a labyrinth with a Minotaur. In any case, it was some guy who came out of the maze by holding his right arm on the right wall and follow the wall to the end. This really works? If it worked with right arm, should in that case, also work with the left.

[Holger]

Although generally being a good approach if you're lost in a labyrinth, there may be cases where it does not work. Consider the following case:










In this case, it would only work for the left arm, but not for the right arm.