Level Design Guidelines

Before starting to build, please read the documentation to learn how to use the editor.

When designing levels for LOLBeans, there are some important guidelines to consider. These guidelines will help ensure that the levels are enjoyable and fair for players of varying skill levels.

All of the items below will be taken into consideration to determine whether or not to publish your level.

Always test your level with less experienced players (and on mobile) before trying to publish your level.

You can submit your level for feedback in our Discord server

Level description

Provide a sufficiently clear and consistent description of your level design and any instructions the player may require. Be specific in describing the type of experience and genre (exploration, parkour, speedrun, contemplation, puzzle, etc.).

The description and title must be written in English.

Level design quality

Making a quality level design improves the chances of it being published.

Design with an underlying concept in mind

Establish a cohesive concept that ties together the obstacles, environment, and challenges. Ensure that the level design reflects the game's overall theme and concept.

Consider average player skill and mobile players

When designing levels, consider the average player skill level (low) and that the level must also be playable on mobile devices. Rather than creating a very difficult level, it's better to design levels that allow for different paths with different levels of difficulty and different risk/reward profiles.

Avoid the need to change the camera too frequently, as many players have trouble doing this (e.g. on mobile or without a mouse), especially when it needs to be done while jumping or running.

Place blocks precisely and avoid overlaps

When placing elements, be precise and avoid overlapping blocks. Use snapping and coordinate values to place blocks precisely.

• Overlapping surfaces
  
   Avoid overlapping elements, these cause visual glitches (called z-fighting).

        ❌        ✅

When blocks really need to intersect, a trick to fix z-fighting is placing them at slightly different positions (sometimes a 0.01 difference is enough). When you do this, make sure it does not affect the movements of the player, otherwise you would need 2 blocks (one visible with no collider and slightly displaced, another one invisible with a collider at the right place)

• Intersecting moving blocks
  
   When moving blocks intersect other blocks it can have unintended effects on the players (getting stuck inside colliders, or flying off the stage)
  

Spawn players on safe spots

Spawn points should be placed on safe spots to ensure that players do not spawn into danger or off the stage. Avoid respawning players close to ledges or in mid-air. Add a respawn delay when the player respawns near a danger to let them stop moving. This will make the experience more enjoyable and prevent frustration for players.

Make sure all respawn points are equally fair for going on with the race: they should be aligned side-by-side, not in front of each other. Avoid spawns that are too close to each other. Help yourself with the button to create surrounding spawns from an existing spawn.

        ❌        ❌        ❌

        ❌        ✅

Guide the player

Use architectural and visual cues to guide the player towards their goal, you should avoid unintended situations where the player feels lost or disoriented.

• Use clear architecture to guide players
• Use logical and consistent visual cues and conventions, e.g. red = danger
• Use arrows to indicate unnatural turns
• Mark kill zones or dangerous areas with obvious visual cues (spikes, red blocks or another convention)
• Design jump pads or boosters with an animated pad/ring and a trigger (see documentation), avoid unexpected jumpads (invisible jumpads)
• Finish lines should be prominently marked
• Use the “kill respawn delay” option on killing blocks to prevent player disorientation after a respawn
• Checkpoints can optionally be marked to provide intermediate waypoints
• Avoid big vertical jumps where the player needs to turn around (especially without any clue)

Avoid camera occlusion

Avoid as much as possible creating situations in which the player camera will be blocked. Watch out for respawns that would be in front of large objects. Avoid placing large moving elements close together on the depth axis and always test your level design to ensure that camera behaviour is acceptable.

You may set the ‘Camera Collision’ property to alter this behavior. Large slowly moving objects can be set to ‘Always’. For fast moving objects, or anywhere you need to block the camera, you may add an invisible block with no collider and ‘Camera Collision’ set to ‘Always’.

Make difficulty progressive

Establish a consistent difficulty curve throughout the level. Gradually increase the challenge as the player progresses through the level, or at least have rests after long & hard challenges. You can also decide to provide different routes with different levels of difficulty and risk/rewards.

Use dynamic objects carefully

If your level design relies on dynamic objects to function consistently, ensure either these will not be removed from the stage by the players or that they will be replaced by using object spawners. Avoid placing too many dynamic objects on the level as this can lead to messiness and excessive physics calculations.

Avoid excessive repetition

Avoid creating a long sequence of stairs or platforms by duplicating the same element over and over again, especially if placed imprecisely. This usually isn’t an interesting challenge.

Make levels visually appealing

Be deliberate and careful with architecture, avoid placing elements randomly. Symmetry and precise alignments are good practices that result in better visuals. Design using a combination of different textures that serve as an aid for reading the space. Messiness and visual noise is to be avoided.

Fairness

Avoid design choices (whether deliberate or not) that can cause player frustration and perception of unfairness.

Checkpoint frequency

Ensure that checkpoints are placed in a fair way, avoid creating frustration by requiring players to repeat a sequence of obstacles they’ve already passed before getting to the last obstacle they’ve failed. It’s good practice to add a checkpoint before a particularly hard obstacle, to favor faster retries, and after a hard obstacle to avoid forcing the player to redo them.

Limit randomness

Don’t leave progress to chance. Players need to feel they have a sense of agency, avoid creating obstacles or interactive elements that behave completely randomly or always produce different results. These include:

• Imprecise long jumps. That can happen easily with jumpads or with a kinematic collision like a hammer. Test a lot and ensure the jumps are consistent and leave a margin for player placement error. Watch out for high-speed collisions with static elements at the start that would randomly alter the trajectory
  
• Unpredictable moving blocks
  
   These are blocks that either move at excessive speed or have an unpredictable pattern.
  
• Spawning large amounts of objects
  
  Avoid the temptation of spawning large amounts of objects using object spawners, this causes excessive randomness and can cause devices to slow down. Design each object spawner to have precise path and timing so that it provides an interesting challenge for players. Always prefer quality over quantity.
  

Trolling

Trolling level designs are acceptable only to a certain point, use common sense and moderation when adding any of these to your level design:

• Invisible obstacles
• Invisible kill zones or mismatching visuals for killing block colliders
• Misleading floor surfaces with “no collider” (leading players to unexpected falls)

Annoyances

These are any situations that cause unnecessary frustration for the players, including:

• Slow kills
  
  Don’t make the player wait too long when they’ve made a fatal mistake. Prefer killing the player and respawning them quickly.
  
• Long falls
  
  Avoid fatal falls that last more than a couple of seconds, shorten the falls by placing kill zones under the stage.
  
• Loss of control
  
  Situations where players are shocked or lose control for an extended amount of time should be avoided. Be particularly careful with
  

• vertical jump pads that can cause the player to remain stuck in a perpetual jumping loop after being shocked by a collision. It’s good practice to angle your jump pads a little to avoid this.
• inescapable holes (e.g donut)

• Unreasonable precision
  
  Don’t design for pixel-perfect jumps or movements as this can be near impossible for certain players (mobile devices and poor internet connections). This includes tiny landing surfaces, extremely slippery surfaces and very narrow or convoluted paths.
  
• Obstacle timing and failing fast
  
  Avoid obstacles with a very long cycle, for example a platform that takes too long to move between origin and destination, for example use multiple side by side elevators with different time offsets. Always prefer having the player fail fast and retry over having them exercise patience.
  

Hidden finish lines

Don’t create a finish line for your own use just to have the record for the level. Use common sense when designing secret or special routes through your level, hidden paths should be hinted at in some way.

Teleports

Teleports should make sense in the flow of the level, not add an unnecessary delay. If two parts of the level could be put end to end, just move them with multi-select (toggle x-ray) instead of adding a teleport for your own comfort.

Timed races

With a level type ‘timed race’, the time and level will be shared among all players that may be at different stages on the level. Therefore it is not recommended to create obstacles relying on dynamic objects that will never be reset. Use triggers with caution and make sure the state of the activated objects is reset quite fast.

Competitive races

For ‘competitive race’ levels, all players start and finish at the same time, and collide with each other, so you better make sure they don’t interfere (too much) with each other.

Make sure your level has properly spaced and numbered (start position) start spawns, and enough checkpoint respawns so that players don’t respawn on top of each other.

Make sure the path is wide enough for 30 players starting at the same time, and multiple people racing side to side at every stage of the level. You may duplicate the same paths & challenges at the start, preserving fairness as much as possible, like in most battle royale maps.