Merge branch 'master' of https://git.alanocull.com/triple-aaa-games/assets

README.md

@@ -4,10 +4,18 @@ Asset/art files for Hook, Line and Axe
 ## Naming Conventions
 Naming conventions are important for project organization and tooling.
 
-### Material Maps
-[IronPress](https://github.com/arocull/IronPress) requires naming conventions for texture maps to be properly used. IronPress is important as it enforces proper bit-depth, performs channel-packing, and for allows bulk texture resizing.
+For automation, **it is heavily preferred that all folders and file names are kept lowercase with no spaces**.
 
-All materials and material maps should start with the prefix `mat_` and followed by the material name, such as `mat_stone`. Lowercase is required.
+- **Characters** - Please store all character models, textures, rigs, etc in its relevant subfolder within the `characters` directory.
+- **Props** - Please store all within the `props` folder, within its relevant subfolder.
+    - When uploading models, please use either FBX or OBJ formats.
+- **Animation** - Character *animations* should instead be stored in the `animations` directory, within its relevant subfolder.
+    - Depending on who is animating, please start your filename with `anims-alan` (or `anims-tommy` or `anims-shelby`, etc) for batch-export automation purposes. Iterative saves are okay.
+
+### Material Maps
+[IronPress](https://github.com/arocull/IronPress) requires naming conventions for texture maps to be properly used. IronPress enforces proper bit-depth, channel-packing, and enables batch-resizing of textures.
+
+All materials and material maps should start with the prefix `mat_` and followed by the material name, such as `mat_stone`. **Lowercase is required**.
 
 Texture maps should be followed with specific names. Examples are provided
 - `mat_example_basecolor` - Basecolor/diffuse/albedo of material. If the material is transparent, alpha is stored on this as well
@@ -19,8 +27,39 @@ Texture maps should be followed with specific names. Examples are provided
 - `mat_example_opacity` - Opacity map, only use if necessary
 - `mat_example_mask` - Mask, only use if necessary
 
-## Animations
+Please store all textures under one folder in the relevant directory, named `textures` (in all lowercase).
+
+Additional notes:
+- If multiple materials use the same textures maps, please only store one copy of said texture map.
+- Export normal maps to 16-bit if possible for maximum quality
+- IronPress can be avoided with a customized Substance export setup
+
+## 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
+Guidelines for asset making:
+- [Topology](docs/assets.md#topologydetail-density)
+- [Texturing](docs/assets.md#texturing)
+- [Scale](docs/assets.md#scale)
+
+### 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).
+
+## Questions
+If there are any questions or feedback on these guidelines and conventions, please poke Alan with a sharp, pointy stick.

characters/infantry/notes.txt

@@ -0,0 +1,11 @@
+- Legs too short
+- Broader shoulders
+- Bigger forearms
+- Make helmet more angular
+	- Bring down brows, make more angry, sun-visor
+	- Slightly point down in middle of helmet
+- Smooth out vest
+	- Flatten pecs
+- Boots are way too big
+- Reduce folds around the boots
+

characters/insurrectionist/cfg_ironpress.json

@@ -18,6 +18,30 @@
 				"arm",
                 "normal"
             ]
+        },
+		"mat_grapplebody": {
+			"res_out": 1024,
+			"channels": [
+				"basecolor",
+				"arm",
+				"normal"
+			]
+		},
+		"mat_coil": {
+			"res_out": 512,
+			"channels": [
+				"basecolor",
+				"arm",
+				"normal"
+			]
+		},
+		"mat_grapplehook": {
+			"res_out": 512,
+			"channels": [
+				"basecolor",
+				"arm",
+				"normal"
+			]
 		}
     }
 }

docs/assets.md

@@ -0,0 +1,52 @@
+# Asset Guidelines and Considerations
+
+When making assets for games, there are many technical requirements and considerations that must be factored in to making said assets.
+
+## Topology/Detail Density
+When working on a model, there are a few questions you must ask yourself:
+- How close to my camera will the model get?
+- What proportion of my screen will this model take up?
+- How many of these will be present at any given time?
+- When, where, and in what context will this model be shown?
+- Does this model need to deform? Where?
+- Does the model move in-game? How fast?
+- How will the topology impact shading?
+- How will the topology impact the sillohouette?
+
+Use these answers to your advantage:
+- If a prop never gets close to the camera, it doesn't need much modeled detail!
+    - Contrarily, if a model takes up lots of screen space, it probably needs some extra detail to properly fill it out
+    - If the model is static and non-deforming, Unreal Engine may make some use of LOD to hide the unnecessary stuff for you. This is not guarunteed.
+- Enemies need a low polycount since many are on screen at once
+    - Contrarily, we only have one Insurrectionist, and he is close to the camera, so it is okay if he's a bit more detailed
+- If there is topology that does NOT impact the sillohouette, it is not necessary in the low-poly
+- There is no need to keep and texture topology that will never be seen. Delete it!
+
+## Texturing
+The same questions as above also goes in for texturing.
+- If a model takes up a lot of screen space, it's likely going to need a higher texture resolution to accomodate, or it'll look low-quality.
+- If a prop is exceptionally small (like the size of a character's fist), you could likely use a 512px map and be fine.
+
+If you are uncertain what resolution you should use, go straight for 4K or 2K, and we can painlessly resize the textures with IronPress
+(assuming that you followed the proper [Naming Conventions](../README.md#material-maps)).
+
+Ideally, even if a prop is broken into separate "parts," **keeping all related-parts on one texture set**:
+- Reduces file-system overhead
+- Reduces how many textures we have to import and manage
+- Optimizes rendering
+
+## Scale
+As we are working with asset packs grounded in realism, keeping scale consistent is important to the player's immersion and believability of the scene.
+In some cases, however, we may be required to push this in one direction or another for gameplay purposes specifically.
+
+Here are cases where we would want to exaggerate scale for gameplay purposes:
+- **Doorways** - Do not want the player's camera to bump against it as they move through
+- **Walkable platforms** - Players may accidentally stumble off of thin platforms
+- **Objectives (buttons and such)** - Player should be able to easily spot things of interest
+
+
+Regardless of if scale needs to be exaggerated or not, doing research on what conventional sizes for objects may be helpful.
+Context is key in these cases as well.
+
+For example, some pine trees may have an average height of 10 meters, whereas most oak varieties may have an average height of 20 meters.
+What does this mean for the size of our models when we're in a taiga versus a savanna?

docs/level_design.md

@@ -0,0 +1,150 @@
+# 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).

pipeline/pipeline_shipping_crate.cmd

@@ -0,0 +1,3 @@
+REM Insurrectionist textures
+ironpress.exe ..\props\ShippingCrate\cfg_ironpress.json
+pause > nul

pipeline/pipeline_turret.cmd

@@ -0,0 +1,3 @@
+REM Insurrectionist textures
+ironpress.exe ..\props\Turret\cfg_ironpress.json
+pause > nul

props/ShippingContainer/cfg_ironpress.json

@@ -0,0 +1,32 @@
+{
+    "out": "..\\..\\export\\turret\\textures",
+    "in": "Textures",
+    "flip_normals": false,
+    "materials": {
+		"mat_ShippingContainer": {
+            "res_out": 2048,
+            "channels": [
+				"arm",
+                "normal"
+            ]
+        },
+		"mat_ShippingContainerBlue": {
+            "res_out": 2048,
+            "channels": [
+				"basecolor"
+            ]
+        },
+		"mat_ShippingContainerGreen": {
+            "res_out": 2048,
+            "channels": [
+				"basecolor"
+            ]
+        },
+		"mat_ShippingContainerRed": {
+            "res_out": 2048,
+            "channels": [
+				"basecolor"
+            ]
+        }
+    }
+}

props/Turret/cfg_ironpress.json

@@ -0,0 +1,23 @@
+{
+    "out": "..\\..\\export\\turret\\textures",
+    "in": "textures",
+    "flip_normals": false,
+    "materials": {
+		"mat_turrethead": {
+            "res_out": 1024,
+            "channels": [
+                "basecolor",
+				"arm",
+                "normal"
+            ]
+        },
+		"mat_turretstand": {
+            "res_out": 1024,
+            "channels": [
+                "basecolor",
+				"arm",
+                "normal"
+            ]
+        }
+    }
+}