Level design specifications

README.md

@@ -34,19 +34,29 @@ Additional notes:
 - Export normal maps to 16-bit if possible for maximum quality
 - IronPress can be avoided with a customized Substance export setup
 
-## Animation Guides
+## Resources and Guidelines
+### Animation Guides
 Guides for animation:
 - [Setting Up a New Animation](docs/animation.md/#setting-up-a-new-animation)
 - [Finalizing an Animation](docs/animation.md/#finalizing-an-animation)
 - [Editing Existing Animations](docs/animation.md/#editing-existing-animations)
 
-## Asset Guidelines
+### Asset Guidelines
 Guidelines for asset making:
 - [Topology](docs/assets.md#topologydetail-density)
 - [Texturing](docs/assets.md#texturing)
 - [Scale](docs/assets.md#scale)
 
-## Automation
+### Level Design Guidelines
+Guidelines for level design:
+- [Minimum Requirements](docs/level_design.md)
+- [Spatial Requirements](docs/level_design.md#making-space)
+- [Use of Space](docs/level_design.md#use-of-space)
+- [Introducing Mechanics and Enemies](docs/level_design.md#introducing-mechanics-and-enemies)
+- [Difficulty Ramping](docs/level_design.md#difficulty-ramping)
+- [Innovation](docs/level_design.md#final-notes)
+
+### Automation
 If you need results from an automated process, see the `pipeline` directory. Each shell script should export the corresponding textures to a folder within the `export` directory.
 
 For animations, please include the `pipeline/export_anims.py` script in your Blender file. This allows one-click exporting of FBX animations (may be fully automated with a script later).

docs/level_design.md

@@ -1,6 +1,8 @@
 # Level Design Guidelines
 
-The name of the game is ***rapid iteration***. **Throw shit together**, see if it works, if it doesn't, **scrap it and start over**.
+The name of the game is ***rapid iteration***. **Throw shit together**, see if it works, 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
@@ -8,25 +10,36 @@ In each level, we're looking for, at minimum:
     - 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
-        - Do not enforce any specific mechanic unless player needs to be taught it
+        - 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 pallates of crates, but at the same time the crates should accomplish a gameplay purpose such as cover.
+        - 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
+    - *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. It should be noted that play testers are very good at finding issues or things they dont like in games, but they typcally arent very good at solving those issues. So 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.
+    - 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!
+- Feel free to make separate levels for testing ideas
+
+As with all forms of design, **level design should speak for itself**.
+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.
@@ -37,28 +50,62 @@ Here are some guidelines for creating engaging spaces:
 - 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 inbetween each floor for players to utilize
+    - 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 2 meters width and height, and 1 meter depth)
+- 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 need large open areas for more chaotic encounters to take place.
+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 a 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
@@ -66,6 +113,13 @@ When teaching a player a new mechanic, follow these guidelines:
 - Keep instructions minimal, but clear
 - Lead the player to the solution with context clues
 
+Ideally, we do not have to directly tell the player what they need to do.
+We may do this for clarity's sake, but the level design should make it clear with lighting, leading lines, and other rules of composition.
+
+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.
+
+### 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
@@ -73,5 +127,24 @@ When introducing a new enemy type to the player, follow these guidelines:
 - The player should have available options to counter the given enemy
     - for example, weaving between cover against the ranged turret
 
-## Difficulty Ramping
+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 encourage the player to move ahead.
+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 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 is 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).