Team Server Meeting Minutes

Template:

Attendance: <people’s names>
Absent: <people’s names>
Note taker:
Notes:
Action items: <bullet points on what you will do, ideally linked to issues>

---

Meeting #1: Game Server Architecture and Networking Discussion

Date: 11:38 AM - 2:01 PM, Oct 3, 2026

Attendance: CanadianMaple-Syrup, Dopyo, Marian-Hristov, Strange4

Absent: NONE

Note taker: Dopyo

Notes:

• Three Execution Modes:
  • Debugging: Local development on personal machines, allowing breakpoints/pauses (time.sleep) without timeouts.
  • Testing: Automated match against an administrative/test agent in an isolated Docker container to verify stability, memory limits, and basic action responses.
  • Playing: Live tournament/competitive matches inside isolated Docker containers against real opponents.
• Resource Limits & Containerization:
  • CPU and Memory limits will be enforced per user agent container (not bundled together) to isolate and identify crashes/out-of-memory (OOM) errors.
  • Unhandled exceptions or OOM events result in an immediate test/match failure for that player agent.
• Server Authority:
  • The server remains the single source of truth for the game loop, timing, turn order, and state transitions.
• Turn/Tick Architecture & State Distribution:
  • The server maintains global game state and distributes filtered states to eligible players.
  • Server sends states and waits for responses up to a configurable tick timeout (e.g., 0.5s – 1.0s).
  • If all expected players reply before the timeout, the server advances the tick immediately.

• Late Responses & Out-of-Sync Actions:
  • If an agent misses the tick window, the server executes a default/empty action for that tick.
  • Late actions will be queued and evaluated on subsequent ticks (similar to network lag/tick handling in multiplayer games).
  • Action spamming or multiple actions per tick will be discarded/limited to the first valid submission.
• Game Developer Flexibility:
  • The core engine stays generic; handling of invalid moves, penalties, timeouts, or turn skipping is left to the game developer’s custom implementation via engine interfaces.
  • The architecture supports multi-agent/team games conceptually, but the team agreed to focus development and testing primarily on 1v1 turn-based mechanics for the MVP.
• Hybrid Tournament Flow:
  • ELO-based matchmaking using bucketing/rounds to distribute and rank participants based on algorithm performance.
  • Top bracket (e.g., Top 32 / Top 16) single/double elimination bracket broadcasted for the final event.
• Game Recording & Viewer:
  • Matches will record state/object coordinate diffs (lightweight event streams) rather than full video files to conserve storage and enable lightweight playback in the custom viewer.
• Orchestration:
  • Consensus to use Docker / Docker Compose with lightweight code-level process management for the MVP; Kubernetes is considered out-of-scope/overkill for current requirements (pending further research).
• Code Delivery:
  • Core engine will be structured as a C# library project alongside a host program.
  • Game creators will import the library and configure the server via options/middleware setup (e.g., setting HTTP/1 and HTTP/2/gRPC ports, asset paths, and registering game singletons) without modifying engine source code.
• Project Board Structure:
  • Epic 0 is dedicated to basic scaffolding and CI/CD. Epics should remain unassigned to iterations; only child stories/tasks are assigned to the current sprint.
• Code Coverage & Quality:
  • Targeting ~80% code coverage enforced in GitHub Actions (SonarQube/linters).
• Pair Programming Attribution:
  • Use GitHub Co-authored-by: commit trailers to ensure collaborative commit credit.

Action items:

• Refactor and update the specification document and state-flow diagrams to accurately reflect the hybrid tick/queued-action model
• Set up the solution structure with the core library, sample game host runner, and configure CODEOWNERS for the engine directory.
• Configure GitHub Actions for automated linting, test suites, and SonarQube code coverage tracking (~80% target).
• Remove iteration tags from high-level Epics and ensure all sub-tasks/stories for the current sprint are appropriately assigned and estimated.
• Confirm feasibility of Docker Compose vs. lightweight container runners for managing concurrent 1v1 match instances without Kubernetes overhead.

AI Acknowledgement: Gemini was used to organize the meeting notes into concise bullet points for this meeting