assets/docs/level_design.md

# Level Design Guidelines

The name of the game is ***rapid iteration***. **Throw shit together**, see if it works, and if it doesn't, iterate.
If iteration doesn't help or becomes too slow, sometimes you need to **scrap it and start over**.
This lets you start with a clean slate for more creativity, and make better use of lessons you learned while testing.

In each level, we're looking for, at minimum:
- **15 minutes of gameplay** on average
    - Newbies might take up to 30 minutes
    - Experienced players can maybe complete this in 5 or 10 minutes minimum
- 3 set-piece combat encounters in separate arenas
- Space for player choice
    - Do not enforce any specific mechanic unless player has not been taught it yet
    - **Gameplay-wise** - how player decides to approach a problem
        - Strategizing enemy encounters (cover, enemy spawns, enemy types, etc)
        - Using resources (choosing one ability over the other, choosing between cover, etc)
    - **Movement-wise** - how player decides to navigate an area (grappling, mantling, dashing, etc)
        - Multiple possible paths and approaches
        - Reward exploration, but don't make it a focus
- A reason for design choices
    - Be able to explain why choices were made, and what they accomplish
    - Choices should be functional in context of the setting
        - for example, a warehouse would have palletes of crates, but at the same time the crates should accomplish a gameplay purpose such as cover

For designing levels, it is **heavily suggested** to make use of:
- **[Connor's Design Tools](https://docs.google.com/document/d/1qqGXGvcrOnxmK5h-GlrCC_Kd_aNqT2hy5wNHmMnwfJo/edit)**
    - *Especially* the wall-builder tool for blockouts. No more constant fiddling with scale!
- BSPs ('Geometry' tab on 'Place Actors' panel)
- Frequent playtesting and iteration
    - Recommended to have **other people** play as often as possible
    - Play testers are very good at finding issues or things they don't like, but typically aren't good at solving them
        - Pay close attention to the way they play and the criticisms they have, but take any potential solutions they give with a grain of salt
    - Recording playtests so you can rewatch them later for reference is often beneficial
    - If you have to explain a design to a playtester, then the design might need more work
- Testing each level segment individually before working on the next segment
- ...and then testing each segment together at once!
- Make separate, small levels for testing specific ideas

As with all forms of design, **the level's design should speak for itself** to players.
The player should naturally be pulled to whatever solution the developer asks, but be left open for resolution themself.

The following guidelines are here to reduce friction between the player and the game, while providing tools for innovation.

## Making Space
As our game is heavily focused on mobility, and makes use of a third-person character, we need ***lots*** of space for navigating, attacking, and moving the camera.

Here are some guidelines for creating engaging spaces:
- Minimum of 7.25 meters width and 8 meters height in hallways
    - Preferably, incentivize players to stay in the middle of the hallway
- Minimum of 15 meters width and 10 meters height in rooms
    - In open spaces, this means a platform diameter of at least 10 meters
- In arenas, at least two floors of vertical space for both player and enemy navigation
    - Include platforms and/or ramps inbetween each floor for players to utilize
    - Include points dedicated to grappling to in upper levels
- After every other combat encounter, have at least one accessible health pickup

Cover also requires special consideration when being placed:
- Should fully cover the player (at least 1.25 meters width and 2 meters height)
- Should be thoughtfully placed relative to enemies
    - Cover must be in the path of enemies
    - Cover must block sightlines
- Should be functional in context of the setting
    - i.e. piles of barrels or crates, a large shipping crate, a pillar, etc

Ideally, platforms and cover should be evenly scattered throughout a level, but still placed with functional purpose in mind.
Additionally, arenas will need some large open areas for sightlines and more chaotic encounters to take place.

## Use of Space
Now that we have all this space, how do we gamify it for the player to enjoy?

### Design Tools
As stated before, Connor has created a series of [level design tools]((https://docs.google.com/document/d/1qqGXGvcrOnxmK5h-GlrCC_Kd_aNqT2hy5wNHmMnwfJo/edit)) to enhance level creation.
These are example use-cases for these tools, but feel free to innovate or request changes as needed.
See his document for more refined details on usage.

Platforming and navigation:
- **Elevator** - Can be used for area transitions before grappling hook is obtained. Can also be used for enemy traversal.
- **Folding Platform** - Can be used to enforce precise timing on platforming, like teaching a dash. These are most relevant before the grappling hook is obtained.
- **Electric Fence** - Damages player over time. Disincentivizes player from grappling or clinging to specific areas. Can be toggled dynamically.
- **Laser Walls** - Like the electric fence, but designed for floors or ceilings.
- **Void** - Instantly kills player, intended for pitfalls, dark and endless appearance.

Progression:
- **Doors** - Can be used to dynamically open and close areas. Please use this BP instead of leaving holes in walls if possible, so the intent of the doorway is clear. Use the `Start Open` parameter if necessary for testing.
- **Enemy Spawner** - Great for spawning waves of enemies in arenas, or having enemies appear dynamically in encounters. Use multiple spawners for a more chaotic experience.
- **Checkpoint/Respawn Pillar** - Use between sections after a significant amount of progress has been made. Players can apply points to their skill-tree upon reaching, and respawn here after death.

Events:
- **Interact Button** - Lets player trigger an event at their own will, prompts player to interact.
- **Trigger Box** - Triggers an event when the player collides with it.

### Arenas
Since the game is focused on both combat and movement, creating large arenas are ideal for set-piece combat encounters.
If you've played any Batman Arkham games, or something of the likes, you will notice that these areas are designed to test the player's knowledge and strategy by rewarding methodical and creative solutions, while discouraging the unprepared.
These are not like typical encounters, as enemy placement relative to the map geometry is extra strategic: including heavy use of sightlines, mantle points, layers of verticality, and areas for sneaking.

While our game is less strategic, set-piece encounters are the ideal place for letting players enter their "flow state."
While throwing enemies in hallways prevents the game from being a walking simulator,
arenas let the player develop their own style of combat by giving **lots of room for movement** while providing **continuous enemy presence** to **put the player under pressure**.

Feel free to mix in platforming tools into arenas well, but they should be impactful to combat, such as encouraging vertical movement, or discouraging willy-nilly grappling.

## Introducing Mechanics and Enemies
It is important to give the player a fundamental understanding of the tools they are given,
as well as the challenges they might encounter.
First impressions are just as important in-game as they are out of game.

### Mechanics
When teaching the player a new mechanic, follow these guidelines:
- Give the player a safe space to fail in
- Ensure that the problem can only be solved with the given mechanic if possible
- Ensure that the problem makes sense within the context of the setting
- Keep instructions minimal, but clear
- Lead the player to the solution with context clues

Giving players a safe space for failure allows experimentation and learning, without creating stress.
As soon as the player becomes frustrated, they are not enjoying the game, and we have failed our objective.

Ideally, we do not have to directly tell the player what they need to do.
We might do this anyway for clarity's sake, but the level design should make it clear with lighting, leading lines, and other rules of composition.

### Enemies
When introducing a new enemy type to the player, follow these guidelines:
- Only one of that type of enemy should be in the given encounter
- The level should accomodate that enemy's abilities
    - for example, a ranged turret works well for suppressive fire
- The player should have available options to counter the given enemy
    - for example, weaving between cover against the ranged turret

As before, we do not want to overwhelm the player with something new, while putting them in a dangerous situation.
Giving them time to observe, think, and react is better than dropping them into hot-water on something they've never seen before.

## Difficulty Ramping
As stated before, players should be eased into combat and new enemies initially.
Using small amounts of enemies in initial encounters with those types allow players to develop strategies without being overwhelmed.
Once you think a player has "mastered" something, test their skills by ramping the intensity, or mixing in other underused mechanics.
Spawning more enemies, using platforming hazards, and etc can further challenge the player.
This can easily be done with [**arenas**](#arenas), as mentioned before.

The same goes for platforming. As the player becomes more acquainted with their tools, mixing up movement combinations or creating more hazards can encourage the player to think more creatively.
Combining platforming and combat can lead to a successful flow state, but requires careful planning and lots of iteration.

## Final Notes
While there are a lot of considerations to making a level, these are still ideas and not entirely rigid rules.
*Sometimes, rules are best broken*, and this applies to game design as well.

If you think something enhances an experience but challenges these guidelines, *test it and see how it plays out*.
Have other devs try it! Have playtesters try it! If it enhances the game, then you've successfully iterated.

See other project guidelines [here](../README.md#resources-and-guidelines).