Official Everybody Edits Forums

Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?

You are not logged in.

#1 2015-08-09 20:59:08

Rocatox
Member
Joined: 2015-02-19
Posts: 83

The Switchkey Multiplier

This is a new (somewhat, I heard there were similar things but not ones designed specifically this way which makes it much more efficient, and versatile) machine I made. It's a bit complicated, but I'll do my best to explain it. Tl;dr: The machine makes switches global (in a way).
It's recommended that you go to the example world with a friend, as you need 2 people to actually operate it.

Part 1: The heart of the machine.
D9oK5Q0.png

IMPORTANT EDIT: For the top picture, I messed up the portal values. They should actually be: 1 -> 0, 2 -> 1, 3 -> 0, and 4 -> 3. Sorry about that.

So, like I said above, the machine basically creates global switches, or something like them. I don't call them switches because really they're not, the term I will be using for them for the rest of the post will be "switchkeys". Now I'll get started onto how it actually happens. Consider, in the bottom pic, each column of keys and key gates to be a switchkey. So, in this version of the machine, there are nine switchkeys. The top pic is the first phase of the switchkey being triggered. In this phase, the player(s) get tagged with a switchkey ID. A switchkey ID is the specific combination of switches hit by the player. In the version of the switchkey multiplier, there are nine different switchkey ID's: 1,4; 1,5; 1,6; 2,4; 2,5; 2,6; 3,4; 3,5; 3,6. Which switchkey ID the player is given depends upon which switch key activated. For an example, imagine a player went down the second to leftmost column. First, that player would hit the red key, causing any players in the machine pictured in the top pic to be dropped as well as to hit the the #1 switch. After waiting for the red key gate to reopen, the player in the bottom pic would continue to fall and hit the green key. This would cause the player(s) in the top pic to hit the #5 switch. The player(s) in the top pic have a switchkey ID of 1,5.

Part 2: The second phase of switch key triggering.
l5yUBio.png

So, everyone from the top pic in part 1 will be teleported to the top left of this picture. This phase is fairly self-explanatory, but I still feel I should go over it. This is basically a sorting phase. The player(s) will first go through portal 1, 2, or 3 depending on the first number of their switchkey ID. Then, they'll be teleported to a set of 4, 5, and 6 portals. They'll go through the portal that aligns with the last digit of their switchkey ID. From there they'll be teleported to whatever area they're meant to be. So a short review: We've been able to, without edit, globally affect players in 9 different ways. Magic already.

Part 3: Why 9? And how to determine the amount of outcomes.
vPX9OEg.png

This machine is adaptable in many ways. One of those way is the number of switchkeys. In the part I'm going to show you how to be able to identify how many switchkeys there are, and how to create more switchkeys. To find the number of switchkeys there are, multiply the number of columns within each row in phase 1 of the switchkey machine by each other. For example, this machine has 2 rows (outlined in red) with 3 columns per row (outlined in green) so to find the number of switchkeys you would multiple 3 x 3 to get 9. Here are some oft heard assumptions that are NOT true: There have to be an equal number of columns for each row; this is assumed because my example does have an equal number of columns for each row, but this doesn't always have to be the case. If I wanted 10 switchkeys, then I could have a row with 2 columns and a row with 5 columns. I've also seen people think that the limit of columns per row is 3 or that there can only be 2 rows. Both of these are wrong, the limit of columns per row is 6, because there are 6 different keys. There is no limit on the number of rows. The rest of this part will be tips on creating switchkeys. First, I'm going to say straight up that a flaw with the machine is that it can't do prime numbers. Sorry. If someone finds a solution to this, post it. Moving on, when creating columns,  make sure you're not repeating any switch numbers. This could cause a break in the machine. Also, you can put columns in any order for this format (I'll get into other formats in the next part). If you have a row of 5 columns and a row of 2 columns, you can go 5x2 or 2x5, doesn't matter.

Part 4: Are switches necessary? And other variations.
i9hRpds.png

First of all, I want to address the format of the phases. Within my level, the format used actually takes up more space than is needed. This is simply for clarity purposes, but the (probably) most compact way of making both phase 1 and phase 2 is shown outlined in blue. This does the exact same thing as mine, but it is A. More compact and B. Eliminates a key by using no-key as an option (Pssst this might mean you can have 7 columns per row, I haven't actually looked into that. If anyone creates a version with 7 columns per row, I'd like to see that, thanks!).  The version outlined in blue can be compacted slightly further using portals as well. So, why is spacing such a concern? This machine is meant to (usually) work along side other machines to create a fairly complex game. Even by itself, its practical uses often exceed just 9 switchkey options. I once needed 270 switchkeys, but that's a story for another day. The point is, having a compact version of a switchkey machine can be, in many cases, essential. Now it's time to get to the big question: Are switches necessary? The answer, not always. If your using switchkeys to drop the player(s) into a certain area and that's IT, then switches are completely useless. In fact, you can see a switchkey machine outline in red with no switches involved. It's even a little smaller than the version in blue with switches. Even within my example world, the switches are unnecessary. So why did I put them in it? Because they CAN have uses and often do for more complex games. If a certain passageway needs to open/shut when the switchkey is activated, switches are needed. Any time in which the player needs to do more besides be placed in a certain area, switches are needed. If the player needs his swichkey ID later on in the game after he is sorted into a location, then he needs switches in his machine. For an example, say I was trying to make a non-bot version of Shift. I could do this by filling the arena with switch gates, each tile in the arena a different number switch, then have all the players go through a switchkey machine. Within the machine, the switchkey ID that the players receive would solidify specific blocks within the arena, creating the level. For this to work, switches would be needed (Also, I acknowledge that to make that concept, it would be easier done without a switchkey machine altogether, but I was trying to think of an example off of the top of my head) In summary, switches aren't always needed, but they often are.

Part 5: Uses
This will be a short part because in the part above I already talked somewhat about how this could be used. The switchkey machine is mostly meant to be used along side other machines in a complex game. In more complex games it becomes more and more essential to have more global options than 6, and that's what this does. I can think of a few examples of this: I once tried to create the popular game of Mafia/Werewolf in an EE landscape, and for that I used a switchkey machine. I used it specifically to determine which player was what role within the game. I've also used it in an RPG level I was creating with a buddy where each player could use different abilities on others. Even though it may not seem true, I've found that the switchkey machine actually has a lot of uses.

Here's the link again if you didn't already go to the world.


c9R1guC.png
Credit goes to Onjit.

Offline

Wooted by:
Rocatox1439150348528592

Board footer

Powered by FluxBB

[ Started around 1716112801.8137 - Generated in 0.116 seconds, 10 queries executed - Memory usage: 1.38 MiB (Peak: 1.47 MiB) ]