The Map Model

The Map Model is a set of rules new maps must follow to ensure that maps function the same regarding some of the server's fundamental concepts like map signs and challenges. This is to prevent situations where players are confused on what to do and to avoid development problems when updating the server plugin. Most of the information on this page comes from this forum thread.

General

Maps on Zero can vary wildly in terms of gameplay, but there are some baseline attributes they all share. For example, every map is finished by clicking a [Finish] sign with its map code on it. This server-wide consistency gives us a number of benefits. As a new player, it helps you navigate and learn the server, as the absolute fundamentals are consistent no matter where you go. They reduce unexpected surprises (which you don't want when hours of progress are on the line). From a staff perspective, it also allows us to implement new features. For example, since we know every map has a checkpoint sign for its starting checkpoint (cp0), we can require the player to click that to suspend their challenge. If some maps didn't have that, we wouldn't be able to implement challenge suspension, since you wouldn't be able to use it reliably.

However, for the longest time, these set of attributes and assumptions have not been documented anywhere, only being passed along by word of mouth. So here, we will finally lay out the Map Model - the model for how maps should fundamentally work. This thread is split into sections. Each section has a guiding principle and then a bunch of specific notes on how that principle applies. While this model may read as a bunch of restrictions, it is not meant to restrict your creativity. Rather, it's to make all maps better for all players. It may sound cheesy, but it's true. This list isn't exhaustive, and there may be cases we have missed. This list may also be updated over time as the server evolves.

Maps are required to meet the requirements listed here in order to be published.

For the purposes of this thread, purple maps are considered to be a single map. The intent is that, in the future, maps will be treated the same way in-game.

Please bear in mind that the spirit of the rules is more important than the exact wording. Don't try to rules-lawyer to "circumvent" requirements. This is only a universal baseline for maps. Board reserves the right to disallow elements of maps on a case-by-case basis based on if they are relevant and/or fitting, even if this thread permits them.

Rules

Maps are completable by all players at all times.

A fresh player that just joined should be able to go to your map and complete it.

This means that:

• You must have at least one end sign for the map.

And you cannot require that a player:

• Be of a certain rank (or have certain permissions, or lack them).
• Have a specific mod installed.

As well:

• Maps must not contain mechanics that can make themselves unbeatable, even temporarily, or force the player to wait arbitrarily.
  • This includes being restricted from joining/starting the map.
  • For example, if a player fails a jump, you cannot lock them out of the map for 30 minutes.
  • This does not disallow day-night cycle mechanics.
• Maps may not restrict the sizes of player groups, except in cases of strict mechanical necessity.

Maps are started when a player attempts to set their checkpoint at the map's starting checkpoint (cp0).

The only thing required for a player to start a map is for them to attempt to set their checkpoint at cp0. (This is the primary function of join signs and /checkpoint join: checkpoint set + teleport + display information. There is no difference between joining a map and starting a map).

This means you cannot require that a player:

• Use a join sign or /checkpoint join to join the map. Clicking the starting checkpoint must be sufficient by itself.

A few other notes on checkpoints:

• Every checkpoint (including cp0) must have at least one accessible associated checkpoint sign.
• There must be an accessible cp0 sign near cp0's spawn location.
• The checkpoint signs for other checkpoints should be near their respective spawn locations unless they have a compelling reason not to be.
• A map may require that the player sets their checkpoint within it.

Maps are quit when a player exits the physical area of the map.

This may be by:

• Players walking out of the map's region
• Teleporting away (e.g. /spawn)
• Being teleported out (e.g. summoned by the party leader)
• Dying and respawning elsewhere
• Or other methods

Maps should only consider a player as "playing" a map when they are physically in the map's regions, regardless of what has been set by scripts (or other mechanisms).

Maps must also not attempt to block players from exiting them, except for the purposes of preventing players who haven't completed Hardcore from escaping into the overworld.

• This means that maps should not use the blocked-cmds or allowed-cmds flags on regions.

Each map is a fully independent and self-contained thing. Maps do not interact with other maps or other outside entities.

This means you cannot require that a player:

• Have (or have not) beaten another map.
• Leave the map.
• Restart the map (e.g. through /checkpoint restart or re-clicking cp0).
• Re-enter the map (e.g. through /checkpoint join).
• Enter another map during gameplay.
  • A map may require that, as a prerequisite to starting, a player enters another map beforehand.
• Set, or have previously set, a checkpoint in another map.
• Be (or not be) in a challenge.
• Be (or not be) in a party.
• Have (or not have) a timer from another map or challenge.
• Have knowledge that cannot be found within the map itself or isn't freely available on the internet.
• Have another player do any of these.

As above, a fresh player that just joined should be able to go directly to your map and complete it.

This principle also means that it must not be possible for the player to permanently softlock themselves (unable to escape even with /kill).

While purple maps are considered to be a single map, maps should not be arbitrarily combined into a purple map to circumvent these restrictions.

Maps also should not modify or affect players who are not currently playing them. Combined with the previous principle, maps should not affect players who are not physically present within the bounds of the map.

Maps should play nice with the server and plugin. They should use features as they are intended to be used.

This means that maps:

• Should use checkpoint signs instead of re-implementing checkpoints with scripts.
• Must not rely on bugs or abuse loopholes in the Minr plugin.
• Must not require the use of any commands except /kill.
• Must not use timer invalidation or nullification as a gameplay mechanic.
  • Progress savers and similar are fine.
• Must not manipulate players' recorded completions and times.

Bugs in the server itself (be it Vanilla or Paper) or other plugins may be used but are prone to being fixed over time. Use them at your own risk.

Maps are constrained by the server rules and staff directives (such as this thread).

• Maps cannot carve out exceptions to the server rules or directives.
• Maps cannot add their own staff-enforced rules or directives.
  • They can request players do or not do things, but those requests won't be binding.

If you have any questions, please feel free to ask (really). Questions that get asked frequently will be added to the FAQ below.

Frequently Asked Questions

What happens to the maps that are currently violating this?

They will remain in FFA grandfathered. Ideally, they will be brought into line over time, but there's no timeline on that.

What about Another Castle's collectible-gated maps?

Another Castle is a single package (much like Carnivale), so it is considered a purple map. As such, all of its collectibles are within a single map, so they're fine. However, something like Omniscience (if it still existed) wouldn't be fine, since it requires visiting Oculus 1, 2, and 3.

Long-term, the plan is to unify things like Another Castle and Carnivale into single actual purple maps (with submaps) that can be completed. Completing all of the submaps will give you a completion of the main map.

Doesn't Warped 1's Endstone island require you to leave the map?

It did when it was released, but it was changed later. The endstone island's critera has been clarified with an In: Warped condition.

Why is the scripting of a checkpoint-like system not allowed?

This is just a handful of things from the top of my head, I know I've missed many. Some of them only apply for script re-implementation of checkpoints, but many apply to a setCheckpoint() call as well.

• Inconsistent UI - having a single clear mechanism for setting your checkpoint and locking in progress server-wide is very valuable, especially in high-pressure situations where hours or even days of progress is on the line.
• Inconsistent functionality - with everyone implementing their own version of the system (be it just a frontend, or the tp-reset too), you have no idea what subtle differences there will be. With one system, you know exactly how it works.
• Tp-reset-style script checkpoints don't actually set your checkpoint - even if you get the big "CHECKPOINT RESET" message, there's no guarantee that you will actually respawn there. If your checkpoint wasn't in the map itself (definitely plausible - see Another Castle, Carnivale, Hardcore, no-cp challenges), then that "checkpoint" is ineffectual. Big violation of UX.
  • As a follow on to that, this means they also don't update your current map (e.g. Another Castle, Carnivale). This means e.g. resource packs won't be applied, /call restrictions/derestrictions won't update, /c cp will be misleading, and if you beat the map your completion will be rejected because you weren't considered to be in the map.
• Current checkpoint is not visible - you can always see your or anyone else's checkpoint with /c cp. With script checkpoints this is completely invisible (or if it is exposed, in a way that's bespoke to every map). You have no idea where you'll respawn if you fail or die. While this could be cool as a one-off trick in a puzzle, this is broadly undesirable. Also problematic for staff and investigations.
• Checkpoints aren't optional / difficult to avoid - if you accidentally fall back into a previous area of a map, are going back to check on your friends, or are just a staff member doing an investigation, and you enter a checkpoint area, it's impossible not to lose progress. Especially if the checkpoints aren't clearly marked. Anyone who's played the old versions of HFT knows how awful it is to fall onto a checkpoint below and lose hours of progress. I've done it myself; it is hell.
• Interacts badly with soul-link - script checkpoints undermine the whole checkpoint-getting aspect of soul link.
• Interacts badly with limited checkpoint challenges - there's no checkpoint sign to click to consume the checkpoint, and you weren't given an option in setting that checkpoint anyway.
  • "Just don't put this map in challenges" isn't a solution to these points. If we have large swathes of the server using script checkpoints (which will happen if its allowed), then these modifiers basically stop working. Maps that otherwise would have been perfect fits for them are now unusable.
• Constrains map suspension - say you've suspended a map. Now you're playing a challenge, and you run into that map again. You do it from start to finish, then complete the challenge. Now you come back to that map, but your progress has been wiped! If that map was using native checkpoints, then we could restore your suspended progress after completing the map in the challenge. May not seem useful for simple maps, but more complex maps (e.g. with multiple endings, multiple paths, etc.) are harmed here.
• If we make map suspension require you to click a checkpoint sign, then scripts aren't going to work here.
• Resilience and integrity - scripts can be updated over time, namespaces can be accidentally taken out, and script-stored progress can be lost. This can't happen with native checkpoints, they're always safely stored. And even in a catastrophe, native checkpoints are always logged, so we can conclusively determine if someone reached them or not. How many people will log script checkpoints? (And how will you look/grep for them, if they're all in different formats?)

So in short: it harms the user experience a lot, it seriously constrains our design space, potentially makes some requested features impossible, interact badly with existing features, and for scripts that try to work around not having native support, they don't integrate at all with the holistic checkpoints system and make the first two points worse. And the upside is essentially not having to click a sign. While it's a nice quality-of-life perk, the downsides massively outweigh it here.

I also don't think the ability for a checkpoint system to be deceptive is really an upside either. It could be a cool gimmick, but it will only work once in one map. It's not really something you broadly want as a feature. What snip answer sharing does is probably the best way you could go about doing something like that.