fix README, SYNC, DATENSCHUTZ

README.md

@@ -4,15 +4,18 @@
 
 ## **📖 About the Project**
 
-"Escape the Teacher" is a web game developed as a school project. You play as a student caught cheating, running away from an angry teacher. The game features increasing difficulty, power-ups, boss phases, and a competitive global leaderboard.
+"Escape the Teacher" is a web-based game developed as a final project (IT232). You play as a student caught cheating, running away from an angry teacher. The game features increasing difficulty, power-ups, boss phases, and a competitive global leaderboard.
 
-Unlike typical browser games, this project implements **competitive multiplayer architecture** usually found in games like *Agar.io* or FPS titles. The browser is just a "dumb" terminal; the server simulates the entire world.
+Unlike typical browser games, this project implements **competitive multiplayer architecture** usually found in shooters or RTS games. The browser is treated as a "dumb" display terminal; the server simulates the entire world to prevent cheating.
+
+**🔗 Repository:** [https://git.zb-server.de/ZB-Server/it232Abschied](https://git.zb-server.de/ZB-Server/it232Abschied)
+
+---
 
 ## **✨ Features**
 
 ### **🎮 Gameplay**
-
-* **Endless Progression:** The game speeds up over time.
+* **Endless Progression:** The game speed increases over time.
 * **Controls:**
     * **Jump:** Space / Arrow Up / Tap / Left Click.
     * **Crouch:** Arrow Down / Swipe Down (Mobile).
@@ -20,56 +23,54 @@ Unlike typical browser games, this project implements **competitive multiplayer
     * 🛡️ **Godmode:** Survives 3 hits.
     * ⚾ **Baseball Bat:** Eliminates the next teacher obstacle.
     * 👟 **Jumpboots:** Grants higher jumping power.
-    * 💰 **Coins:** Bonus points.
-* **Level Editor:** Custom chunks (platforms, enemies) can be designed in a secure Admin UI and are streamed into the game live.
-* **Juice:** Particle effects and retro sound system.
+    * 💰 **Coins:** Bonus points for the highscore.
+* **Level Editor:** Custom level segments ("Chunks") can be designed live in the Admin Panel and are streamed directly into active game sessions.
 
-### **🛡️ Security & Admin**
+### **🛡️ Security & Technology**
+* **Server-Authoritative:** Physics runs entirely on the server (Go). Speedhacks or Godmode cheats are impossible.
+* **Admin Panel:** Password-protected interface to manage levels, badwords, and leaderboards.
+* **Proof System:** Players receive an 8-character "Claim Code" to validate their high score offline.
 
-* **Server-Authoritative:** Physics runs on the server. Cheating (speedhack, godmode) is impossible.
-* **Admin Panel:** Create levels, manage badwords, and moderate the leaderboard.
-* **Proof System:** Players receive an 8-character "Claim Code" to prove their high score offline.
+---
 
 ## **🏗️ Technical Architecture**
 
-We moved from a traditional HTTP-Request model to a **Realtime Streaming Architecture**.
+The project utilizes a **Realtime Streaming Architecture** to handle latency and synchronization.
 
 1.  **Backend (Go):**
-    * Runs the physics simulation at a fixed **20 TPS (Ticks Per Second)**.
-    * Generates level segments ("Chunks") 5 seconds into the future.
-    * Streams object positions via **WebSockets** to the client.
+    * Simulates physics at a fixed **20 TPS (Ticks Per Second)** to save CPU.
+    * Generates level chunks 5 seconds into the future.
+    * Streams object positions and game state via **WebSockets**.
 2.  **Frontend (JS):**
-    * **Client-Side Prediction:** Inputs are applied immediately for zero-latency feel.
-    * **Buffering:** Incoming server data is buffered and played back smoothly.
-    * **Interpolation:** Although physics runs at 20 FPS, the game renders at 60+ FPS by interpolating positions (`lerp`).
+    * **Client-Side Prediction:** Inputs are applied immediately for a "Zero-Lag" feel.
+    * **Buffering & Interpolation:** Although the server calculates at 20 FPS, the client renders at 60+ FPS by interpolating positions (`Lerp`) between server ticks.
+    * **Lag Compensation (RTT):** The client measures Round Trip Time and visually shifts server objects to match the client's timeline.
 3.  **Database (Redis):**
-    * Stores active sessions, highscores, and custom level chunks.
+    * Stores highscores, active session states, and level editor chunks.
 
-### **Tech Stack**
-
-* **Backend:** Go (Golang) 1.22+ (`gorilla/websocket`)
-* **Frontend:** Vanilla JavaScript (Canvas API)
-* **Database:** Redis
-* **Containerization:** Docker (Multi-Stage Build)
-* **Orchestration:** Kubernetes
+---
 
 ## **🔧 Engineering Challenges & Solutions**
 
-### **1. The "Netflix" Approach (Streaming vs. RNG)**
-* **Problem:** Syncing Random Number Generators (RNG) between Client and Server caused "Butterfly Effects" where one wrong number broke the whole game state.
-* **Solution:** **Streaming.** The client no longer generates anything. The server generates objects in the future and streams them into a buffer on the client. The client simply plays back what it receives.
+Building a lag-free, cheat-proof game on the web came with significant hurdles. Here is how we solved them:
 
-### **2. Lag Compensation & RTT**
-* **Problem:** If the internet lags, the server's objects appear too late on the client, causing "Ghost Kills".
-* **Solution:** **RTT (Round Trip Time) Measurement.** The client constantly measures the Ping. Incoming objects are visually shifted based on latency (`Latency * Speed`), so they appear exactly where they are on the server.
+### **1. The "Netflix" Approach (Streaming vs. RNG Sync)**
+* **Problem:** Initially, we tried to sync the Random Number Generators (RNG) between Client and Server. However, a single floating-point deviation caused a "Butterfly Effect," desynchronizing the entire game world.
+* **Solution:** **Streaming.** The client no longer generates obstacles. The server pre-calculates the future and streams objects into a buffer on the client. The client simply plays back the stream, similar to a video player.
 
-### **3. Low Tick-Rate & Interpolation**
-* **Problem:** To save server CPU, we run physics at only **20 TPS**. This usually looks choppy (like a slideshow).
-* **Solution:** **Linear Interpolation.** The rendering loop runs at 60/144 FPS and calculates the visual position between two physics ticks. The game looks buttery smooth despite low server load.
+### **2. Low Tick-Rate & Interpolation**
+* **Problem:** To allow many concurrent players, the server physics runs at only **20 TPS**. Without smoothing, this looks choppy (like a slideshow) on a 144Hz monitor.
+* **Solution:** **Linear Interpolation.** The rendering engine calculates the visual position between the current and the previous physics state (`alpha = accumulator / dt`). The result is buttery smooth motion despite the low server update rate.
 
-### **4. "Instant" Death**
-* **Problem:** Waiting for the server to confirm "You died" feels laggy.
-* **Solution:** **Optimistic Client Death.** The client detects collisions locally and stops the game visually (`Game Over`). It sends a `DEATH` signal to the server, which then validates and saves the highscore.
+### **3. Latency & "Ghost Kills"**
+* **Problem:** If the internet lags (e.g., 100ms Ping), the server sees the player hitting an obstacle that appeared "safe" on the client screen.
+* **Solution:** **RTT Compensation.** The client constantly measures the network delay. Incoming objects from the server are visually shifted towards the player (`Latency * Speed`), ensuring they appear exactly where the server expects them to be at the moment of interaction.
+
+### **4. Vertical Synchronization (Platforms)**
+* **Problem:** Jumping onto platforms is tricky. At high speeds, the server might calculate that the player fell *through* a platform between two ticks ("Tunneling").
+* **Solution:** **Vertical Sweeping & Client Authority override.** The server checks the *path* of the player, not just the position. Additionally, if the client detects a safe landing, it forces a physics sync update to the server to prevent unfair deaths.
+
+---
 
 ## **🚀 Getting Started**
 
@@ -100,33 +101,30 @@ We moved from a traditional HTTP-Request model to a **Realtime Streaming Archite
     go run .
     ```
 
-## **📂 Project Structure**
+---
 
-```
-.
-├── k8s/                    \# Kubernetes manifests
-├── static/                 \# Frontend files
-│   ├── assets/             \# Images & Audio
-│   ├── js/                 \# Game Engine
-│   │   ├── audio.js        \# Sound Manager
-│   │   ├── logic.js        \# Physics & Buffer Logic
-│   │   ├── render.js       \# Drawing & Interpolation
-│   │   ├── network.js      \# WebSocket & RTT Sync
-│   │   └── ...
-│   ├── index.html          \# Entry Point
-│   └── style.css           \# Styling
-├── secure/                 \# Protected Admin Files (Editor)
-├── main.go                 \# HTTP Routes & Setup
-├── websocket.go            \# Game Loop & Streaming Logic
-├── simulation.go           \# Physics Core
-├── types.go                \# Data Structures
-└── Dockerfile              \# Multi-Stage Build
-```
+## **🎶 Credits**
 
-## **📜 Legal**
+This project was made possible by:
 
-This is a non-commercial educational project.
-* **Privacy:** No tracking cookies.
-* **Assets:** Font "Press Start 2P" hosted locally. Sounds generated via bfxr.net.
+* **Development & Code:** Sebastian Unterschütz
+* **Music Design:** Max E.
+* **Sound Effects:** Generated via [bfxr.net](https://www.bfxr.net/)
+* **Graphics:** [Kenney.nl](https://kenney.nl) / Sebastian Unterschütz
+* **Fonts:** "Press Start 2P" (Google Fonts / Local)
 
-**Run for your grade! 🏃💨**
+---
+
+## **⚖️ License & Rights**
+
+**© 2025 IT232 Final Project**
+
+This project is released under a proprietary, restrictive license:
+
+1.  **No Commercial Use:** The source code, assets, and the game itself may not be used for commercial purposes or sold.
+2.  **No Modification:** You are not allowed to modify, fork, or redistribute this project in modified form without express written permission from the authors.
+3.  **Educational Use:** Viewing and running the code for educational purposes within the context of the school project is permitted.
+
+---
+
+**Run for your grade! 🏃💨**