Graphics and audio docs

design/src/SUMMARY.md

@@ -7,7 +7,14 @@
   - [Game Thesis](./high-level/game-thesis.md)
   - [Genre Analysis](./high-level/genre-analysis.md)
   - [Genre Mechanics](./high-level/genre-mechanics.md)
+  - [Graphics: Case Studies](./high-level/analysis-graphics.md)
   - [Mapping genre mechanics to _Emergence_](./high-level/mechanical-translation.md)
+  - [Sound Design](./high-level/design-sound-design.md)
+  - [Sound Design: Case Studies](./high-level/analysis-sound-design.md)
+  - [Soundtrack](./high-level/design-soundtrack.md)
+  - [Soundtrack: Case Studies](./high-level/analysis-soundtrack.md)
+  - [UX](./high-level/design-ux.md)
+  - [UX: Case Studies](./high-level/analysis-ux.md)
   - [Creative Automation](./high-level/creative-automation.md)
   - [Creative Automation: Case Studies](./high-level/creative-automation-case-studies.md)
 - [Production Chains](./production-chains/index.md)

design/src/high-level/analysis-graphics.md

@@ -0,0 +1,77 @@
+# High-Level Analysis: Graphics
+
+## Case Studies
+
+### Terra Nil
+
+[A reverse civilization builder solar punk game](https://store.steampowered.com/app/1593030/Terra_Nil/) where the player is tasked with making a barren planet bustling with life. The player builds machines to purify water, soil, and air to breathe life back into the game world.
+
+- A _2D world_ with an _isometric camera with constrained motion_.
+
+- Animals and some player buildings' _2D assets_ have _outlines drawn with, and cell shading using, shaders_ to add definition to assets.
+
+- Various animals have _'random' animations_ that add a sense of life to the game.  
+
+- The color palette is _vivid colors for greenery_, _muted colors for wasteland_, and _soft hues of bold colors for buildings_ which helps fit the game's theme of _rejuvenating nature_.
+
+- _Textures_ give the assets _varying levels of depth_.
+
+- _Ambient lighting_ gives depth to the world, _casts shadows_, and helps _ambient clouds add texture/depth_.
+
+- Assets have a _pastoral, hand drawn aesthetic_ with mild _cell shading_.
+
+### Warcraft 3
+
+### Factorio
+
+### Minecraft
+
+### Dorfromantik
+
+### Frostpunk
+
+### Rim World
+
+### Breath of the Wild
+
+### Don't Starve Together
+
+### Paper Mario
+
+### Nova Draft
+
+### Paper Sorcerer
+
+### Journey
+
+### N++
+
+[N++](https://store.steampowered.com/app/230270/N_NPLUSPLUS/) is a fast-paced, momentum-based platformer about darting around obstacles, narrowly evading enemies and collecting gold in a beautiful minimalist landscape.
+
+- A _2D world_ with an _orthogonal, fixed camera_.
+
+### Heads Run
+
+### Jet Set Radio Future
+
+### Okami
+
+### Everything
+
+The game [_Everything_](https://store.steampowered.com/app/582270/Everything/) has the player control a collective consciousness that is a part of everything in the universe. The player is tasked with exploring our universe as a disembodied consciousness that can control anything in the (game's) universe as philosophy lectures play in the background. Built with Unity.
+
+- A _3D world_ with a _third-person perspective camera with full rotational freedom_ to allow the player to view every angle of the world.
+
+- The creator chose _low-poly models_ as assets, with the creative choice _not to use animations_ for movement but to instead move the full model in a uniform way.
+
+- _Simple shapes_ are used for the models which helps _reduce total polygon count_ for the models.
+
+- The color choices are a _soft palette_ with _neutral tones_ for background objects and _bold colors_ for playable things.
+
+- Dependent on the scale the player is at, things in the world are are visually different. _When a player zooms in, things that clutter the world are removed and the important things are left_. This is _emphasized with thing color choices_.
+
+## What are Common Style Choices?
+
+### Shader Choices
+
+### Asset Selection

design/src/high-level/analysis-sound-design.md

@@ -0,0 +1,3 @@
+# High Level Analysis: Sound Design
+
+To make our game more immersive and alive, we need to add sound effects for all of our in game content.

design/src/high-level/analysis-soundtrack.md

@@ -0,0 +1,9 @@
+# High-Level Analysis: Soundtrack
+
+A solid original soundtrack can keep players thinking about your game for hours after they finish a session. Below we will examine ways to add depth to the game's atmosphere using by examining some games that have a solid soundtrack
+
+## Case Studies
+
+### Everything
+
+### Timberborn

design/src/high-level/analysis-ux.md

@@ -0,0 +1,31 @@
+# High-Level Analysis: UX
+
+User experience can make or break a game. Below we will look at some good examples of UX to guide our future design choices.
+
+## Case Studies
+
+### Factorio
+
+### Timberborn
+
+### Don't Starve
+
+### Oxygen not Included
+
+### XCOM
+
+### Atrio
+
+### Roller Coaster Tycoon 1
+
+### Roller Coaster Tycoon 3
+
+### Shapez
+
+### Shapez 2
+
+### Warcraft 3
+
+#### Against the Storm
+
+## Common Style Choices

design/src/high-level/design-sound-design.md

@@ -0,0 +1 @@
+# Design Guide: Sound Design

design/src/high-level/design-soundtrack.md

@@ -0,0 +1 @@
+# Design Guide: Soundtrack

design/src/high-level/design-ux.md

@@ -0,0 +1 @@
+# Design Guide: UX

dimension-discussion.md

@@ -0,0 +1,116 @@
+<!---
+This document is a draft that will be gutted and used in the design docs later. 
+--->
+
+# Considerations for Representing the Game World
+
+## How Things Work
+
+### Terrain
+
+Our current terrain and pathfinding systems work by defining normal ground, high ground, and rocky terrain, with the rocky terrain then labelled as impassible. However, most insects can climb vertical surfaces and most non-insect animals planned are far larger than insects and thus unencumbered by most terrain we're currently representing. This means no terrain should be impassible for our units and only certain terrain types should be "impassible" to fungi and plants given the substrate requirements either kingdom of life have to grow. We also need to consider how to represent the traversal of our terrain: will units walk across ground and respond to variations in it or will they simply know to go to certain tiles given the labels?
+
+### Movement
+
+Our current movement system has all the ants moving randomly across the map by spawning and de-spawning between tiles. We need to decide on how we wish to animate these movements. We will also need to consider how to process all of our unit actions. Current pathfinding is processed as time passes in the game with a unified system to process all units using pathfinding at once. For performance, we will need to consider how to distribute the processing load for large numbers of organisms pathfinding all at once.
+
+## Planning for Development
+
+### Basic Traversal
+
+To make units moving around the world look more alive, we will want to add animations to smooth out character movement, decide how the units will move across different terrain, and how to represent the terrain. Our best solution for general pathfinding will be to rework our current impassible terrain functions and instead label the height of a tile. A height allows us to use the integer value to let organisms with walking mechanics know they cannot pass a tile/to know they will have to walk differently on this terrain as well as tell the renderer what terrain type to show.
+
+We are planning to add new assets, a new lighting system, and a day/night cycle, which will all make height easier to represent. The most limiting factors for each choice of dimensions will then be the assets and extra work needed to finesse our game to be more performant and beautiful.
+
+### Making the World 2D
+
+Most factory builders tend to be 2D
+
+    * We make units able to respond to height.
+        - Pros:
+          * We can generalize our movement system and adapt it to each organism as needed. 
+          * If organisms have some level of awareness of their surroundings, most of the way that assets interact can be handled through this system with out needed finesse to pull off a good looking end result. 
+          * It may be easy for us to add this to our current systems.
+          * Signal transduction may be easier to work out
+          * It's easier to work with
+        - Cons: 
+          * There are a lot of 2d factory sim type games, so looking unique will take a lot of thought
+          * Will need to trouble shoot our assets for clear visibility 
+          * Will likely require adding a physics engine (may also be a pro)
+
+    * Smaller units look like they're getting larger as they climb up and get closer to the camera or appear to get slightly smaller as they climb down. Meanwhile, larger units are able to semi easily move across most terrain  
+        - Pros:
+          * Looks unique
+          * May be easier to deal with animations ( we will only need the walking and smaller up/down sprites vs full animation set)
+        - Cons:
+          * Likely requires a query for each tile type (computationally intensive)
+          * Less straight forward to implement than regular animation
+
+    * Some mixture of the above 2 options
+        - Pros: 
+          * Could prove to be unique
+          * Can adapt to any art style in unique ways
+          * Flexibility in design offers developer ergonomics
+        - Cons:
+          * Could be more resource (time, computation, and/or asset) intensive 
+          * Less straight forward to implement than either a physical world 
+
+### Making the World 2.5D
+
+There is no real consensus on what 2.5D means. This allows us to get extremely creative as to how we show the game world. We can:
+
+     * Add 2D sprites to a 3D world, 
+        - Pros
+          * Can look interesting and add texture/personality to the game
+          * Is easier to produce and manage assets for than full 3D
+          * Makes some aspects of representation, such as depth and height, easier than fully 2D/3D
+        - Cons
+          * More labor and computationally expensive than just 2D
+          * Adds complexity to the design/production process that may be less straight forward to deal with than fully either 2D/3D
+
+    * Create a 3D world with a constrained camera,
+        - Pros
+          * You have all assets in 3D (render issues will be because of easier to troubleshoot 3D vs  potentially difficult mixed dimension)
+          * Fits the genre well
+          * Makes terrain easy to work with from a traversal perspective
+        - Cons
+          * You have all assets in 3D (you have to make, store, and deal with 3D assets meaning more time/money)
+          * Added complexity
+          * 
+
+    * Mix 2D and 3D assets to our hearts' content (and coding/asset production ability). 
+        - Pros 
+          * Flexible and offers us the ability to use assets/techniques that are easiest for the task at hand
+          * Is as unique as we can make it (More artistic freedom)
+          * Allows us to accent/emphasize certain game world features that may help with UX and making the game easy to learn
+
+        - Cons
+          * Troubleshooting could get difficult
+          * There will always be a need to troubleshoot rendering/ensuring assets are consistent across the board
+          * Mostly uncharted territory, especially in bevy
+          * Need to come up with a new design plan
+          * May become difficult to pull off with more features/assets
+
+### Making the World 3D
+
+3D will make representation easier but adds layers of difficulty to design and production that may make it less practical than 2/2.5D.
+
+    * 3D with isometric camera with freedom on the constrained axis
+        - Pros
+            *
+        - Cons
+            * 
+
+    * Add ,
+        - Pros
+          * 
+          * 
+        - Cons
+          * 
+          * 
+
+    * Mix 
+        - Pros 
+          *
+        - Cons
+          * 

tools/debug_tools/src/console.rs

@@ -1,28 +1,4 @@
 //! Create and manage `bevy_console` commands.
+// TODO: Add MIT/Apache 2.0 compatible console implementation
 
-use crate::*;
-
-// Modified from the log command example (https://github.com/RichoDemus/bevy-console/blob/main/examples/log_command.rs)
-/// Prints given arguments to the console
-#[derive(ConsoleCommand)]
-#[console_command(name = "log")]
-pub struct PrintToLog {
-    /// Message to print
-    msg: String,
-    /// Number of times to print message
-    num: Option<i64>,
-}
-
-// TODO add more useful commands
-/// allow command line statements to print to console N number of times
-pub fn print_to_log(mut log: ConsoleCommand<PrintToLog>) {
-    if let Some(Ok(PrintToLog { msg, num })) = log.take() {
-        let repeat_count = num.unwrap_or(1);
-
-        for _ in 0..repeat_count {
-            reply!(log, "{msg}");
-        }
-
-        log.ok();
-    }
-}
+// use crate::*;