a few more rounds

Author: snow-jallen

.dockerignore

@@ -0,0 +1,33 @@
+**/.git
+**/.vs
+**/.vscode
+**/bin
+**/obj
+**/out
+**/*.user
+**/*.suo
+**/*.sln.docstates
+**/*.log
+.dockerignore
+Dockerfile
+docker-compose.yml
+docker-compose.override.yml
+README.md
+CONTRIBUTING.md
+LICENSE
+.gitignore
+.editorconfig
+.gemini/
+.claude/
+.specify/
+specs/
+docs/
+tests/
+node_modules/
+npm-debug.log
+yarn-error.log
+.env
+.env.*
+appsettings.Development.json
+appsettings.Local.json
+secrets.json

.github/dependabot.yml

@@ -0,0 +1,19 @@
+version: 2
+updates:
+  - package-ecosystem: "nuget"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    open-pull-requests-limit: 10
+
+  - package-ecosystem: "docker"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    open-pull-requests-limit: 10
+
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    open-pull-requests-limit: 10

.github/workflows/ci.yaml

@@ -0,0 +1,33 @@
+name: CI
+
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v4
+
+    - name: Setup .NET
+      uses: actions/setup-dotnet@v4
+      with:
+        dotnet-version: 10.0.x
+
+    - name: Restore dependencies
+      run: dotnet restore
+
+    - name: Build
+      run: dotnet build --no-restore --configuration Release
+
+    - name: Test
+      run: dotnet test --no-build --configuration Release --collect:"XPlat Code Coverage"
+
+    - name: Upload coverage reports to Codecov
+      uses: codecov/codecov-action@v5
+      with:
+        token: ${{ secrets.CODECOV_TOKEN }}

.gitignore

@@ -157,7 +157,6 @@ BenchmarkDotNet.Artifacts/
 .aspire/
 
 # Docker
-.dockerignore
 docker-compose.override.yml
 
 # Temporary files

CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing to NetRTS
+
+Thank you for your interest in contributing to NetRTS! This project follows strict architectural and testing guidelines.
+
+## Development Workflow
+
+We follow a **Test-First Development (TDD)** approach.
+
+1.  **Define Requirements**: Understand the feature or bug you are working on.
+2.  **Write Tests**: Write BDD scenarios (Gherkin) in `tests/NetRts.ContractTests` and unit tests in `tests/NetRts.UnitTests`.
+3.  **Ensure Failure**: Run the tests and ensure they fail.
+4.  **Implement**: Write the minimum amount of code required to make the tests pass.
+5.  **Refactor**: Clean up the code while ensuring tests remain green.
+
+## Architecture
+
+We use **Clean Architecture** with the following layers:
+
+- **Domain**: Core entities, value objects, and business rules. No dependencies.
+- **Application**: CQRS handlers (MediatR), interfaces, and application services.
+- **Infrastructure**: Persistence (EF Core), background services, and external integrations.
+- **Api**: Minimal APIs, SignalR hubs, and middleware.
+- **Client**: Blazor WebAssembly frontend.
+- **Contracts**: Shared DTOs and event models.
+
+## Coding Standards
+
+- Use C# 12 features (primary constructors, collection expressions, etc.).
+- Adhere to the `.editorconfig` rules.
+- Add XML documentation to all public members.
+- Use structured logging with Serilog.
+
+## Pull Request Process
+
+1.  Create a new branch for your feature or fix.
+2.  Ensure all tests pass locally (`dotnet test`).
+3.  Submit a PR with a clear description of the changes.
+4.  Maintain high test coverage (minimum 80%).

Directory.Build.props

@@ -30,6 +30,11 @@
     <IsPackable>false</IsPackable>
     <GenerateDocumentationFile>false</GenerateDocumentationFile>
     <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
+    <!-- Coverage Settings -->
+    <CollectCoverage>true</CollectCoverage>
+    <CoverletOutputFormat>opencover,cobertura</CoverletOutputFormat>
+    <Threshold>80</Threshold>
+    <ExcludeByFile>**/Migrations/*.cs</ExcludeByFile>
   </PropertyGroup>
 
   <!-- Package Metadata (for libraries) -->

README.md

@@ -0,0 +1,74 @@
+# NetRTS - Real-Time Strategy Game Engine for Programming Competitions
+
+NetRTS is a specialized RTS game engine designed for programming competitions where players control their units through a REST API.
+
+## Features
+
+- **Tick-Based Engine**: Consistent 1-second game ticks.
+- **REST API for Bots**: Complete control over units and buildings via simple JSON commands.
+- **Fog of War**: Real-time vision calculations using QuadTree spatial indexing.
+- **Resource Management**: Gather resources, build structures, and produce units.
+- **Upgrades**: Enhance unit and building capabilities through research.
+- **Real-Time UI**: Blazor-based web client for monitoring matches.
+- **Distributed Observability**: Built with .NET Aspire for comprehensive logging and telemetry.
+
+## Getting Started
+
+### Prerequisites
+
+- [.NET 10.0 SDK](https://dotnet.microsoft.com/download/dotnet/10.0)
+- [Docker Desktop](https://www.docker.com/products/docker-desktop) (for PostgreSQL)
+
+### Running the Application
+
+The easiest way to run the entire system is using .NET Aspire:
+
+```bash
+dotnet run --project src/NetRts.AppHost
+```
+
+This will start:
+- **API**: The backend game engine.
+- **Client**: The Blazor web dashboard.
+- **Database**: PostgreSQL container for persistence.
+
+### Accessing the Dashboard
+
+Once started, the Aspire dashboard will be available at the URL shown in your console (usually `http://localhost:18888`). From there, you can access the API Swagger UI and the Web Client.
+
+## Bot Development
+
+Bots interact with the engine using standard HTTP requests.
+
+### Basic Workflow
+
+1. **Register/Login**: Get a JWT token.
+2. **Join Lobby**: Find or create a match.
+3. **Get Game State**: `GET /api/v1/matches/{matchId}/state`
+4. **Queue Commands**: `POST /api/v1/matches/{matchId}/commands`
+
+### Example Move Command
+
+```json
+{
+  "commands": [
+    {
+      "commandType": "Move",
+      "unitIds": [1, 2, 3],
+      "targetPosition": { "x": 50, "y": 50 }
+    }
+  ]
+}
+```
+
+## Architecture
+
+- **Domain**: Pure domain logic, entities, and business rules.
+- **Application**: CQRS handlers using MediatR, command validation with FluentValidation.
+- **Infrastructure**: EF Core persistence, background game loop, spatial indexing.
+- **API**: Minimal APIs for low-latency command queueing.
+- **Client**: Blazor WebAssembly for real-time visualization.
+
+## License
+
+MIT

docker-compose.yml

@@ -0,0 +1,38 @@
+services:
+  api:
+    image: netrts-api
+    build:
+      context: .
+      dockerfile: src/NetRts.Api/Dockerfile
+    ports:
+      - "5000:8080"
+    environment:
+      - ASPNETCORE_ENVIRONMENT=Development
+      - ConnectionStrings__netrtsdb=Host=db;Database=netrts;Username=postgres;Password=postgres
+    depends_on:
+      db:
+        condition: service_healthy
+
+  client:
+    image: netrts-client
+    build:
+      context: .
+      dockerfile: src/NetRts.Client/Dockerfile
+    ports:
+      - "5001:8080"
+    depends_on:
+      - api
+
+  db:
+    image: postgres:16-alpine
+    environment:
+      - POSTGRES_DB=netrts
+      - POSTGRES_USER=postgres
+      - POSTGRES_PASSWORD=postgres
+    ports:
+      - "5432:5432"
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      timeout: 5s
+      retries: 5

docs/adr/0001-spatial-indexing.md

@@ -0,0 +1,31 @@
+# ADR 0001: Spatial Indexing for Fog of War and Collision Detection
+
+## Status
+Accepted
+
+## Context
+The game engine needs to perform frequent spatial queries, such as:
+- Calculating visibility (Fog of War) for units and buildings.
+- Finding units within range for combat.
+- Checking for collisions during movement and building placement.
+
+With up to 100 concurrent matches and hundreds of entities per match, a naive O(N^2) approach for distance checks would be too slow to maintain a 1-second tick interval.
+
+## Decision
+We will use a **QuadTree** data structure for spatial indexing.
+
+A QuadTree is a tree data structure in which each internal node has exactly four children. It is used to partition a two-dimensional space by recursively subdividing it into four quadrants or regions.
+
+## Alternatives Considered
+1. **Naive O(N^2)**: Too slow for the required scale.
+2. **Grid-based Partitioning**: Simple to implement but less efficient for unevenly distributed entities.
+3. **R-Tree**: Good for range queries but more complex to implement and maintain than a QuadTree for point-based entities.
+
+## Consequences
+- **Pros**:
+    - Reduces query complexity from O(N) to O(log N) on average.
+    - Efficiently handles clusters of units and sparse regions.
+    - Well-suited for 2D game worlds.
+- **Cons**:
+    - Requires rebuilding or updating the tree every tick as units move.
+    - Slightly more memory overhead than a simple list or grid.

k8s/api.yaml

@@ -0,0 +1,57 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: netrts-api
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: netrts-api
+  template:
+    metadata:
+      labels:
+        app: netrts-api
+    spec:
+      containers:
+      - name: api
+        image: netrts-api:latest
+        imagePullPolicy: IfNotPresent
+        ports:
+        - containerPort: 8080
+        envFrom:
+        - configMapRef:
+            name: netrts-config
+        - secretRef:
+            name: netrts-secrets
+        readinessProbe:
+          httpGet:
+            path: /health
+            port: 8080
+          initialDelaySeconds: 10
+          periodSeconds: 10
+        livenessProbe:
+          httpGet:
+            path: /health
+            port: 8080
+          initialDelaySeconds: 15
+          periodSeconds: 20
+        resources:
+          requests:
+            memory: "128Mi"
+            cpu: "250m"
+          limits:
+            memory: "512Mi"
+            cpu: "500m"
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: netrts-api
+spec:
+  selector:
+    app: netrts-api
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: 8080
+  type: LoadBalancer