~/meetings / 2026-09-10
Meeting #17

> 2026-09-10

A two-person Project Big Mart working session that moved the game from its design outline into concrete class and component architecture. Most of the meeting went to sketching a UML-style class diagram — Player and GameState as orchestrators, plus UI, Enemy, and Items classes and reusable Movement, Animation, and Stamina components — alongside a running debate about composition-over-inheritance in Godot, where UI state should live, and how to structure the codebase now so a later multiplayer pass stays additive rather than a rewrite. The rest was a hands-on Godot walkthrough: touring the scene tree, inspector, and @export wiring, reading through the proto controller script, consolidating the loose controller into a dedicated Player scene with stamina fields, and committing the day's work to a personal branch. It closed on a long tangent about how refreshing it felt to design and code without AI, and where that leaves developer craft and identity.

2 attendees(Whit, Yohannes)
##topics covered
  1. 01.Decision to move Project Big Mart from its design outline into concrete class/component architecture, sketching structure before writing more code
  2. 02.Progress since the last session: a player controller and a test environment scene exist in the repo, nothing beyond that yet
  3. 03.Draft class list — Player and GameState as orchestrators, plus UI, Enemy (store entities with AI behavior), and Items/Interactables
  4. 04.GameState responsibilities: task list and assignment, hauntings, paranormal events (possibly a subclass), win/loss conditions, and a shift timer/clock
  5. 05.Reusable node components identified: Movement, Animation, and Stamina
  6. 06.Player and enemy movement kept as separate components — input-driven vs. AI/algorithmic — rather than one shared class
  7. 07.Animation as a single shared component connected to both player and enemy nodes, keeping animation logic in one place
  8. 08.Composition-over-inheritance in Godot: reusable components (health bar, hitbox/hurtbox, movement) attached via @export slots instead of deep inheritance trees, with examples like reusing a health-bar component across entities or making an arbitrary object player-controllable by adding a movement component
  9. 09.Where UI state should live — settled on a UI overlay shown in the gameplay scene once the player starts, with UI values reflecting underlying player/game-state values; a UI state machine considered but deemed optional
  10. 10.Scene structure: a menu scene and a gameplay scene, with UI overlaid on gameplay
  11. 11.Multiplayer deferred — build single-player first but structure state around a central collective game-state tracker (the eventual server authority) so the later multiplayer pass stays additive (more conditionals, swapping hard-coded values for state-fed ones)
  12. 12.MVP scope re-confirmed from the prior night's notes: single-player first, one map, simple tasks, a few paranormal events, one stat
  13. 13.MVP uses stamina instead of health — a slowly draining, sanity-style meter that drains faster while sprinting or during certain activities; the store-wide haunting meter is separate level state and rises faster when paranormal events are solved
  14. 14.Inventory as a simple Roblox-style single-row hotbar — starts empty, items appear as picked up, with a holster/bag expansion floated for later
  15. 15.Departments handled through GameState and config-driven task assignment rather than a Department class or per-player job/training system (judged too rigid and less fun) — everyone is a generic associate given varied tasks
  16. 16.Tunable values (movement speeds, stamina drain) exposed through Godot's inspector via @export, overriding code defaults so tuning needs no code edits
  17. 17.Godot walkthrough — the scene/node tree, inspector, and script view, and how @export creates typed, type-safe slots for wiring a component node into a parent so the parent can call its functions
  18. 18.Read-through of the proto controller script: _ready() as the on-load/constructor step, mouse capture/release and look-around handling, a free-fly debug mode, and _physics_process as a 60fps per-physics-frame state observer
  19. 19.Controller movement math — read input, normalize, move_toward, move_and_slide (with a note not to remove move_and_slide) — plus a fix to the camera look/rotation clamp so it respects a scaled-up controller instead of the default height
  20. 20.Scene restructure — a dedicated Player scene holding the proto controller plus a stamina script, swapped into the game scene in place of the loose controller, with the player capsule scaled back up
  21. 21.Environment nodes (lighting, floor) grouped under a level/map node; a separate UI scene created under scenes/
  22. 22.Stamina fields added to the player script live — an exported max_stamina (int, 100) and an exported stamina defaulting to max; snake_case adopted as the naming convention; no minimum-stamina constant, just a <= 0 death threshold with a guard against negatives
  23. 23.Note that Godot's inspector shows an exported value as 0 until runtime because exported defaults resolve at runtime; missing script autocomplete traced to a stale Godot language server rather than a Copilot feature
  24. 24.Godot version mismatch between the two machines (4.7 vs a newer 4.x patch) — opening the project on a newer version marks files changed, forces a discard-before-pull, and risks build incompatibility
  25. 25.Version-control workflow — the day's work committed to a personal branch in the shared repo; forking considered but rejected to avoid juggling multiple repos, with a plan to grant push access and merge between personal branches; VS Code's 'generate commit message' feature (from Supermaven) noted alongside a preference for conventional commit messages
  26. 26.Testing kept to manual playtesting for now
  27. 27.Extended tangent on designing and coding without AI — working through architecture on pen and paper and how fulfilling it felt — and on AI's effect on developer craft and identity
  28. 28.Whether AI output will become indistinguishable from work made with intent and passion, across art and software
  29. 29.LLMs framed as pattern recognition and information banks with no internal motives, dependent on external input, with an argument that the GPT training approach may be plateauing and something more fundamental is needed for AGI
  30. 30.'Grokking' and generalization — visualizing it in a model's vector-embedding space, the origin of the name 'Grok', and AGI as a possible paradigm shift that may be centuries away, if it happens at all
##decisions & next steps
  • →Big Mart moves from design outline into class/component architecture, kept on scope with a UML-style class diagram
  • →Build single-player first, with state structured around a central game-state tracker so multiplayer can be layered on later without a rewrite
  • →Draft class/component list agreed — Player and GameState as orchestrators; UI, Enemy, and Items classes; separate Movement components for player and enemy; one shared Animation component; a Stamina component
  • →Departments handled via GameState and config-driven task assignment — no Department class or per-player job system
  • →MVP uses a stamina meter rather than health; inventory is a single-row Roblox-style hotbar
  • →Proto controller consolidated into a dedicated Player scene (controller plus stamina) and swapped into the game scene; environment nodes grouped under a level node; a separate UI scene created
  • →Version control: one shared repo with work on personal branches merged between them (no forks), with push access to be granted for that
  • →Testing stays manual playtesting for now
##notes
Attendees inferred from an unnamed in-person transcript and confirmed with Whit.
← meeting #16