Update README to explain overall Game code structure

README.md

@@ -99,6 +99,62 @@ bin/rake
   <img alt="Game Board" src="https://github.com/pdobb/minesweeper_alliance/blob/main/public/screenshots/erd-dark.webp?raw=true">
 </picture>
 
+Note: Much of the complexity in this app comes from the need for varying content based on current Game state. Especially given the "War Room" (home page) dynamically adjusts to current game state by:
+
+1. Showing the "New Game" content when no current Game exists,
+2. Showing the "Current Game" content when a current Game exists,
+3. Showing "Just Ended" Game content (to all participating Users) on Game end.
+
+Plus, there are various ways of displaying past Games:
+
+1. Sweep Ops Archive
+2. Metrics
+3. User context
+
+The overall structure of the view templates and [View Models](#view-models) to support this looks like:
+
+```
+Current Game:
+- Game status ("Standing By" vs "Sweep in Progress")
+- Rules of Engagement
+
+Just ended Game:
+- Game "Title"
+- Game status ("Mines Win" vs "Alliance Wins")
+- "Signature" section for signing Username + <hr> above it
+- Metrics + Duty Roster
+
+Sweep Ops Archive: Standard view of past Games.
+- Game "Title"
+- Game status ("Mines Win" vs "Alliance Wins")
+- Metrics + Duty Roster
+
+Metrics -> Games:
+- Game "Title"
+- Metrics + Duty Roster
+
+User -> Games:
+- Game "Title"
+- Metrics + Duty Roster
+
+# Plus:
+New Game:
+- Standard: Beginner, Intermediate, or Expert
+- Random (one of the Standard Games, plus a small chance for a random Pattern Game)
+- Custom Game
+```
+
+### View Models
+
+View Models are POROs that:
+
+- Insulate view templates from ActiveRecord Models,
+- Handle view-specific logic ("display" versions of Model attributes, conditionals, etc.),
+- Live alongside the view templates/partials they support, and
+- Are easily unit testable (though there are currently very view View Model tests in this project).
+
+View Models are somewhat similar to, yet much simpler than, GitHub's ViewComponent pattern/gem. They make no attempt to intervene in the rendering stack or to add a custom DSL. The only thing to learn about them is when to expect to use them and, to some extent, how.
+
 ### Users
 
 Visiting the site for the first time automatically creates a new User entry in the database. The primary key for this entry is a UUID. The UUID is stored in an HTTP cookie for re-identification of the current User in the future. It is easily possible to create multiple User records per actual user (e.g. by visiting on different browsers or computers), but this is an acceptable price to pay versus the pain of explicitly registering a User + credentials for such a simple site. This is also reminiscent of arcade games: just enter your username after finishing a game and that's trustworthy enough.