Team Server Meeting Minutes - Strange4/RenaEngine GitHub Wiki

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.
image
  • 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

⚠️ **GitHub.com Fallback** ⚠️