Add README

as5/README.md

@@ -9,11 +9,11 @@ cd cs381
 git submodule update --init --recursive
 ```
 
-Navigate to the `as4` directory, create a build directory, and run CMake to
+Navigate to the `as5` directory, create a build directory, and run CMake to
 generate the build files:
 
 ```sh
-cd as4
+cd as5
 mkdir -p build
 cd build
 cmake ..
@@ -25,47 +25,44 @@ Compile the code using `make`:
 make
 ```
 
-This should create an executable named `as4` in the `build` directory. You can
+This should create an executable named `as5` in the `build` directory. You can
 run the executable with the following command:
 
 ```sh
-./as4
+./as5
 ```
 
 # Instructions on how to use the program
 
-Hold W and S to accelerate the selected entity forward and backward. Use A and
-D to change heading direction. This allows you to steer the entity around the
-environment.
+If the selected entity is a penguin, hold W and S to accelerate it forward and
+backward. Use A and D to change heading direction.
 
-Use TAB to switch between entities. The currently selected entity will
-be drawn with a bounding box.
-
-When the eagle is selected, press Q and Z to change the pitch.
+Use TAB to switch between entities. The currently selected entity will be drawn
+with a bounding box.
 
 # Readme Question
 
-The entity selection system works by when TAB is pressed (key down only on one
-frame), the program increments the index of the currently selected entity.
-Selection wraps around to the first entity when it exceeds the number of
-entities in the game. Movement keys only apply to the selected entity, which is
-determined by the selected index. When drawing, the selected index is compared
-to the index of each entity, and if they match, a bounding box is drawn around
-the entity to indicate that it is selected.
+Having a bool stored per object to dictate whether or not to draw the bounding
+box could be storage inefficient as it requires an additional byte per object.
+This is less apparent when using a component-based architecture (although might
+not be the best solution), as the visibility component is only added to
+entities that need it (you can compose it down further by having a component
+specifically for bounding boxes). In the monolithic architecture, this would
+require every entity to have this. In the ad-hoc architecture, it is simply not
+scalable as it requires tracking multiple booleans and requires a lot of
+branching logic to determine which entities should have bounding boxes drawn.
 
-Both monolithic and ad-hoc approaches to entity management are fast to setup
-since they require the least amount of code/boilerplate to get something
-working. However, monolithic entities are easier to scale, since in ad-hoc, you
-have to write the entire state and behavior of the entity (its variables,
-methods, etc) for each entity that exists. Ad-hoc is faster to work with only
-when managing few entities with very different behavior.
+Calculating whether or not to draw the bounding box in the rendering system can
+be more efficient, especially in a monolithic architecture. This does not
+require additional storage per entity, and can be done by simply checking if
+the entity is the currently selected entity. This can however cause a lot of
+branching logic in the rendering system.
 
-For this particular assignment, the monolithic approach is more suitable since
-most of the entities share similar behavior (change velocity) and state
-(position, speed, heading). This however still became more difficult to manage
-when adding the eagle that had an additional pitch variable and flying
-behavior.
+Splitting bounding box drawing into a separate system can be more efficient in
+terms of computation and storage. However, it is harder to maintain, since if
+you want to modify how a bounded model is drawn, you would have to modify the
+draw calls in multiple places.
 
 # Extra Credit
 
-The eagle can move in 3D space with an additional DOF compared to the penguins.
+The camera follows the currently selected entity using similar.