When you will start to understand the plugin possibilities, you will probably start wanting to create a whole puzzle campaign for your players.
Linking puzzle together can be a bit complicated depending to what you want to do. This tutorial is here to present you with the most common problems and the appropriate corresponding solutions.
The only problem that can occur is related to checkpoints:
According to what you defined in the config.yml file, and according to ether you created checkpoints and victory areas or not, players who dies or who connect to the server will (re)spawn to the latest checkpoints they activated. This can be a problem because then they may have no way to get out of your puzzle campaign.
There are several ways to overcome this problem:
- [SIMPLE] A /spawn command provided by another plugin allows players to get back to the spawn.
- [SIMPLE] Place your puzzle campaign in another world (using Multiverse or another plugin allowing you to have multiple worlds) and set
get_back_to_checkpoint_on_join: per_world_truein your config.yml file. Using this solution, when players joins the server they will be in your spawn world so they don't get teleported back to their last checkpoint. It's only when they will join your campaign specific world that they will get teleported back to their last checkpoints in this world. They can teleport back to the spawn world using a specific command or by leaving and joining back the server.
- [SIMPLE BUT EVIL] Don't put checkpoints or deactivate them inside the config.yml file. Players will have to do every room in a row to win. Leaving or being disconnected means starting back from the beginning.
- [ADVANCED] If you want to keep the plugin's checkpoints usual behavior but still let other plugins override it (for example the plugin teleporting players to the spawn on join) you can decrease this checkpoint teleport priority in the config.yml file
Redstone piston doors
- You may want to use nicer doors than the one provided by conditional disappearing blocks. To do so you should import a schematic (they are plenty of those online) or create the piston door yourself and then simply link those to your puzzle victory conditions using a conditional redstone block.
Using elevators to go from one puzzle to another is pretty simple: At the end of each puzzle there is an elevator that let you access to the next puzzle.
Room = the built room
E = Elevator
V = Victory area
The elevator conditions of activation are set to prevent players from using it if they did not solve the puzzle.
Just put a lock within the area that contains the door that should be opened when every other areas are solved.
The player will then collect keys in every areas and, when all keys are retrieved, open the lock that opens the last door.
You can also create optional areas by putting the same keys in multiple areas:
Using a central elevator + locks (each floor is accessible from start)
A central elevator that let players reach every puzzles. Each floors are always accessible but the last floor contains a door that will only open if its lock is opened.
This lock can only be opened by collecting every floors keys.
Using Elevators + Locks (preventing access to next floors)
Create a central area that contains the elevator.
To block the elevator's path and prevent it to go to the next floors you will need to place blocks on its way. Just put a sticky pistons to put a block on the elevators path.
To deactivate the path blockage put a lock in each floor of this central area. Then place a key at the end of each floor puzzle campaign.
But this way to do has a problem:
When a player has reached the last floor that was previously blocked and leaves the area, so the pistons will push back the blocks that prevent the elevator to move.
So it will not be able to get back to the first floor when a new player come in. To overcome this problem you will have to place a redstone block within the elevator cage. This redstone block will send a redstone signal for pistons to retract in order to let the elevator go backward.