mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-14 19:01:08 +02:00
5589765180
Add ManaVoxel — a 2D top-down pixel platform for creating and programming miniature worlds in the browser. This commit includes: - SvelteKit + PixiJS 8 web app with chunk-based tilemap renderer - Game engine: camera (scroll/zoom), input (keyboard/mouse/touch), player with AABB collision, editor/play mode toggle - Pixel editor tools: brush, eraser, flood fill, pipette, box fill, line (Bresenham), undo/redo stack - Shared types package: materials, areas, items, network protocol, inventory - Demo world generator with terrain, buildings, trees - Material palette UI with 15 materials, keyboard shortcuts - Comprehensive design documents (Roblox analysis, tech stack options, voxel resolution analysis, 2D alternative comparison, full project plan) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
826 lines
34 KiB
Markdown
826 lines
34 KiB
Markdown
# ManaVoxel 2D: Die Pixel-Variante
|
||
|
||
## Gleiche Vision, eine Dimension weniger -- was aendert sich?
|
||
|
||
---
|
||
|
||
## 1. Die 2D-Vision
|
||
|
||
```
|
||
3D-Version (GAME-PLAN.md):
|
||
Bevy + wgpu + WebGPU + Rust + 10cm Voxel
|
||
→ 18-24 Monate, Rust lernen, komplexe Engine
|
||
|
||
2D-Version:
|
||
PixiJS/Phaser + Canvas/WebGL + TypeScript + Pixel-Grid
|
||
→ 3-6 Monate, bestehende Sprachen, simpler Stack
|
||
→ GLEICHE Kern-Features: Bauen, Programmieren, Teilen, Spielen
|
||
```
|
||
|
||
### Was bleibt gleich?
|
||
|
||
```
|
||
✓ Alles entsteht im Spiel (Pixel-Editor statt Voxel-Editor)
|
||
✓ Items sind programmierbar (3 Ebenen: Slider → Trigger → Code)
|
||
✓ Browser-first, kein Download
|
||
✓ Local-First, Offline-Editor
|
||
✓ Multiplayer
|
||
✓ Self-Hosted
|
||
✓ Creator Economy (70% Revenue)
|
||
✓ AI-Integration (NPCs, Asset-Gen)
|
||
✓ Cross-Game Items
|
||
✓ Guest Mode
|
||
```
|
||
|
||
### Was aendert sich?
|
||
|
||
```
|
||
3D Voxel: 2D Pixel:
|
||
Perspektive von allen Seiten Top-Down oder Side-Scroller
|
||
Kamera: Orbit, Fly, First-Person Kamera: Scroll, Zoom
|
||
3D Physik (Rapier, Gravitation) 2D Physik (Rapier2D oder planck.js)
|
||
3D Meshing (Greedy, LOD) Tilemap oder Sprite-Rendering
|
||
Beleuchtung (Schatten, AO) 2D Lighting (Raycasting, einfach)
|
||
GPU-intensiv (WebGPU noetig) CPU-freundlich (Canvas/WebGL reicht)
|
||
Rust/Bevy (neu lernen) TypeScript (bereits beherrscht)
|
||
Komplexe Kamera-Steuerung Simple Kamera (Pfeiltasten + Maus)
|
||
```
|
||
|
||
---
|
||
|
||
## 2. Zwei 2D-Ansaetze
|
||
|
||
### Option A: Top-Down (wie Zelda / Pokemon / Stardew Valley)
|
||
|
||
```
|
||
┌────────────────────────────────┐
|
||
│ ████████████████████████████ │
|
||
│ █ █ │
|
||
│ █ ┌──┐ ┌────────┐ █ │
|
||
│ █ │🪑│ │ Tisch │ █ │
|
||
│ █ └──┘ │ ▫▫▫▫ │ █ │
|
||
│ █ └────────┘ █ │
|
||
│ █ █ │
|
||
│ █ 🧑 (Spieler) █ │
|
||
│ █ █ │
|
||
│ █ 🗡️ (Item am Boden) █ │
|
||
│ █ █ │
|
||
│ ████████░░░░████████████████ │
|
||
│ (Tuer) │
|
||
└────────────────────────────────┘
|
||
|
||
Ansicht: Von oben, leicht schraeg (RPG Maker / Zelda-Style)
|
||
Bewegung: 8 Richtungen
|
||
Welt: 2D Grid aus Pixeln/Tiles
|
||
```
|
||
|
||
**Vorteile Top-Down:**
|
||
|
||
- Raeume und Gebaeude natuerlich darstellbar
|
||
- Moebel, Items, NPCs klar erkennbar
|
||
- Klassisches Genre, Spieler kennen die Steuerung
|
||
- Einfachste Physik (nur X/Y, keine Gravitation)
|
||
- Perfekt fuer: Dungeons, Haeuser, Doerfer, Overworld
|
||
|
||
**Nachteile:**
|
||
|
||
- Keine Hoehe (kein Springen, keine Ebenen ohne Tricks)
|
||
- Weniger "wow" als 3D
|
||
- Gebaeude von oben = kein Innenraum sichtbar (braucht Layer-System)
|
||
|
||
### Option B: Side-Scroller (wie Terraria / Starbound / Noita)
|
||
|
||
```
|
||
┌────────────────────────────────────────┐
|
||
│ ☀️ ☁️ │
|
||
│ │
|
||
│ 🧑 ← Spieler │
|
||
│ ████ │
|
||
│ ██████ ┌──────┐ │
|
||
│ ████████████████ │ Haus │ ████████ │
|
||
│ ████████████████ │ │ ████████ │
|
||
│ ████████████████ └──────┘ ████████ │
|
||
│ ██████████████████████████████████ │
|
||
│ ██████████████████████████████████ │
|
||
│ ██████████████████ 💎 ███████████ │
|
||
│ ██████████████████████████████████ │
|
||
└────────────────────────────────────────┘
|
||
|
||
Ansicht: Seite (wie ein Querschnitt)
|
||
Bewegung: Links/Rechts + Springen
|
||
Welt: 2D Grid, mit Gravitation
|
||
```
|
||
|
||
**Vorteile Side-Scroller:**
|
||
|
||
- Gravitation und Springen → dynamischeres Gameplay
|
||
- Terraria hat bewiesen: 2D + Bauen + Kaempfen = Mega-Erfolg
|
||
- Hoehlen, Untergrund, Himmel → vertikale Exploration
|
||
- Gebaeude sieht man im Querschnitt (Inneneinrichtung natuerlich sichtbar!)
|
||
- Zerstoerung sieht besser aus (Pixel fallen runter)
|
||
|
||
**Nachteile:**
|
||
|
||
- Nur eine "Tiefe" (kein Hinter/Vor, ausser mit Layern)
|
||
- Weniger geeignet fuer Top-Down-Genres (RPG, Strategie)
|
||
|
||
### Empfehlung: Side-Scroller (Terraria-Ansatz)
|
||
|
||
```
|
||
Warum Side-Scroller > Top-Down fuer unsere Vision:
|
||
|
||
1. INNENRAEUME: Im Side-View sieht man automatisch in Gebaeude rein
|
||
→ Moebel, Items, Details sofort sichtbar
|
||
→ Bei Top-Down muss man Daecher entfernen oder Layer wechseln
|
||
|
||
2. PHYSIK: Gravitation macht Items und Zerstoerung spannender
|
||
→ Bloecke fallen, Schutt rieselt, Wasser fliesst
|
||
→ Items fliegen durch die Luft beim Kampf
|
||
|
||
3. BEWIESENES KONZEPT: Terraria hat >58 Millionen Kopien verkauft
|
||
→ Das Genre funktioniert, die Zielgruppe ist riesig
|
||
|
||
4. DETAIL: Seitenansicht zeigt mehr Detail pro Bildschirm
|
||
→ Ein Schwert ist als Sprite viel erkennbarer als top-down
|
||
|
||
5. BAUEN: Haeuser bauen in Side-View ist intuitiver
|
||
→ Wand, Boden, Dach -- wie ein Puppenhaus
|
||
→ Top-Down: Man sieht nur den Grundriss
|
||
```
|
||
|
||
---
|
||
|
||
## 3. Das Pixel-Grid-System
|
||
|
||
### Dreistufig (wie 3D, aber in 2D)
|
||
|
||
```
|
||
STUFE 1: Welt-Pixel (10cm = 10 Pixel/Meter) ← MVP
|
||
Terrain, Gebaeude, grosse Strukturen
|
||
Max Welt: 500m × 200m = 5.000 × 2.000 Pixel = 10M Pixel
|
||
Das ist RIESIG fuer 2D (Terraria: ~8.400 × 2.400)
|
||
|
||
STUFE 2: Detail-Zonen (5cm = 20 Pixel/Meter) ← Post-MVP
|
||
Altaere, Vitrinen, Mechanismen
|
||
Max 5 Zonen, je 10m × 10m
|
||
|
||
STUFE 3: Sprite-Editor (1-2 Pixel/cm = frei) ← Post-MVP
|
||
Items, Charaktere, Dekorationen
|
||
64×64 oder 128×128 Canvas
|
||
Wie ein Mini-Aseprite im Spiel
|
||
```
|
||
|
||
### Resolution-Vergleich (2D vs 3D)
|
||
|
||
```
|
||
Gleiche physische Groesse: 10cm
|
||
|
||
3D bei 10cm:
|
||
Ein Wuerfel: 1 Voxel = u16 = 2 Bytes
|
||
Ein Raum (3m × 4m × 3m): 30 × 40 × 30 = 36.000 Voxel = 72 KB
|
||
|
||
2D bei 10cm:
|
||
Ein Quadrat: 1 Pixel = u16 = 2 Bytes
|
||
Ein Raum (3m × 4m): 30 × 40 = 1.200 Pixel = 2.4 KB
|
||
|
||
→ 2D braucht ~30× WENIGER Speicher als 3D
|
||
→ Bei gleichem Budget: 30× groessere Welten moeglich!
|
||
```
|
||
|
||
### Welten-Groessen in 2D
|
||
|
||
| Welt | Pixel-Groesse | Speicher (roh) | Speicher (kompr.) | Vergleich |
|
||
| -------------------------------- | ----------------- | -------------- | ----------------- | ----------- |
|
||
| Zimmer (5m × 4m) | 50 × 40 | 4 KB | <1 KB | Trivial |
|
||
| Haus (20m × 15m) | 200 × 150 | 60 KB | ~5 KB | Trivial |
|
||
| Dungeon (100m × 50m) | 1.000 × 500 | 1 MB | ~50 KB | Winzig |
|
||
| Dorf (200m × 100m) | 2.000 × 1.000 | 4 MB | ~200 KB | Klein |
|
||
| **Terraria-Gross (500m × 200m)** | **5.000 × 2.000** | **20 MB** | **~1 MB** | **Locker** |
|
||
| Mega-Welt (1.000m × 300m) | 10.000 × 3.000 | 60 MB | ~3 MB | Moeglich |
|
||
| Ultra (2.000m × 500m) | 20.000 × 5.000 | 200 MB | ~10 MB | Grenzwertig |
|
||
|
||
**In 2D koennen Welten 10-30× groesser sein als in 3D bei gleichem Budget!**
|
||
|
||
Eine Terraria-grosse Welt (500m × 200m) braucht komprimiert ~1 MB. Das ist nichts.
|
||
|
||
---
|
||
|
||
## 4. Der Pixel-Editor (In-Game)
|
||
|
||
### Welt-Editor (Side-Scroller)
|
||
|
||
```
|
||
┌────────────────────────────────────────────────────┐
|
||
│ [Pinsel][Radierer][Fuellen][Pipette][Box][Linie] │
|
||
│ [Auswahl][Kopieren][Einfuegen][Undo][Redo] │
|
||
├────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ☀️ │
|
||
│ │
|
||
│ ┌─────────────┐ Cursor: ▓ │
|
||
│ │ │ (zeigt wo Pixel gesetzt │
|
||
│ │ HAUS │ wird) │
|
||
│ │ │ │
|
||
│ ███████│ ┌──┐ ┌──┐│██████████████ │
|
||
│ ███████│ │ │ │ ││██████████████ │
|
||
│ ███████└──┘──└──┘──┘██████████████ │
|
||
│ ██████████████████████████████████ │
|
||
│ ██████████████████████████████████ │
|
||
│ │
|
||
├────────────────────────────────────────────────────┤
|
||
│ Palette: [█ Stein][█ Holz][█ Gras][█ Sand][...] │
|
||
│ Layer: [Hintergrund ▼] [Vordergrund ▼] │
|
||
│ Zoom: [−] ████████████ [+] 100% │
|
||
└────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### Sprite-Editor (Items + Charaktere)
|
||
|
||
```
|
||
┌───────────────────────────────────────────────┐
|
||
│ SPRITE EDITOR: "Flammenklinge" │
|
||
├───────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌──────────────────────┐ ┌───────────────┐ │
|
||
│ │ ░░░░░░░▓░░░░░░░░░░░ │ │ Vorschau: │ │
|
||
│ │ ░░░░░░▓▓▓░░░░░░░░░░ │ │ │ │
|
||
│ │ ░░░░░▓███▓░░░░░░░░░ │ │ 🗡️ │ │
|
||
│ │ ░░░░▓█████▓░░░░░░░░ │ │ (animiert) │ │
|
||
│ │ ░░░░░▓███▓░░░░░░░░░ │ │ │ │
|
||
│ │ ░░░░░░▓█▓░░░░░░░░░░ │ │ Frames: 1/4 │ │
|
||
│ │ ░░░░░░░▓░░░░░░░░░░░ │ │ [▶][⏸][⏹] │ │
|
||
│ │ ░░░░░░░▓░░░░░░░░░░░ │ └───────────────┘ │
|
||
│ │ ░░░░░░░▓░░░░░░░░░░░ │ │
|
||
│ │ ░░░░░░▓▓▓░░░░░░░░░░ │ Werkzeuge: │
|
||
│ │ ░░░░░▓▓▓▓▓░░░░░░░░░ │ [Pinsel][Radierer] │
|
||
│ │ ░░░░░░░▓░░░░░░░░░░░ │ [Fuellen][Spiegeln]│
|
||
│ │ ░░░░░░░▓░░░░░░░░░░░ │ [Frame +][Frame -] │
|
||
│ └──────────────────────┘ │
|
||
│ Canvas: 16 × 32 Pixel │
|
||
│ Palette: [█][█][█][█][█][█][█][█][+Custom] │
|
||
│ Anchor: [Mitte-Unten ▼] │
|
||
│ Hitbox: [Auto ▼] │
|
||
├───────────────────────────────────────────────┤
|
||
│ [Testen] [Properties] [Speichern] │
|
||
└───────────────────────────────────────────────┘
|
||
```
|
||
|
||
**Sprite-Groessen:**
|
||
|
||
| Item-Typ | Canvas | Beispiel |
|
||
| ----------------------------- | ---------------------- | ------------------- |
|
||
| Klein (Ring, Muenze) | 8 × 8 | 64 Pixel, 128 Bytes |
|
||
| Mittel (Schwert, Trank) | 16 × 32 | 512 Pixel, 1 KB |
|
||
| Gross (Schild, Ruestung) | 32 × 32 | 1.024 Pixel, 2 KB |
|
||
| Charakter | 32 × 48 | 1.536 Pixel, 3 KB |
|
||
| Charakter animiert (4 Frames) | 128 × 48 (Spritesheet) | 6.144 Pixel, 12 KB |
|
||
| Boss / Grosses Objekt | 64 × 64 | 4.096 Pixel, 8 KB |
|
||
|
||
Items sind in 2D winzig. Hunderte Items = wenige KB. Kein Performance-Problem, nie.
|
||
|
||
---
|
||
|
||
## 5. Programmierbare Items (identisch zu 3D)
|
||
|
||
Die drei Programmier-Ebenen funktionieren exakt gleich:
|
||
|
||
### Ebene 1: Sliders
|
||
|
||
```
|
||
Gleiches UI wie in 3D.
|
||
Schaden, Element, Haltbarkeit, Reichweite, Sound, Partikel, Seltenheit.
|
||
```
|
||
|
||
### Ebene 2: Trigger-Actions
|
||
|
||
```
|
||
Gleiche Trigger und Actions, aber 2D-spezifisch:
|
||
|
||
TRIGGER (2D):
|
||
Spieler beruehrt, Item benutzt, Timer, HP unter X,
|
||
Spieler springt auf Item, Spieler steht drauf,
|
||
Pixel darunter zerstoert, Regen, Nacht...
|
||
|
||
ACTIONS (2D):
|
||
Schaden, Partikel (2D), Sound, Teleportieren,
|
||
Pixel setzen/loeschen, Gravitation an/aus,
|
||
Licht erzeugen, Wasser fliessen lassen,
|
||
Explosion (Pixel-Krater), Nachricht anzeigen...
|
||
```
|
||
|
||
### Ebene 3: TypeScript
|
||
|
||
```typescript
|
||
import { onUse, damage, particles, voxel } from '@manavoxel/api';
|
||
|
||
onUse((event) => {
|
||
// Schwert-Hieb: Bogen von Pixeln zerstoeren
|
||
const arc = getArc(player.position, player.facing, 3);
|
||
for (const pos of arc) {
|
||
voxel.destroy(pos);
|
||
particles.spawn('spark', pos);
|
||
}
|
||
damage.area(arc, 15);
|
||
});
|
||
```
|
||
|
||
---
|
||
|
||
## 6. Technischer Stack (2D)
|
||
|
||
### Architektur
|
||
|
||
```
|
||
╔═══════════════════════════════════════════════════╗
|
||
║ BROWSER (Zero Install, PWA) ║
|
||
║ ║
|
||
║ ┌──────────────────┐ ┌──────────────────────┐ ║
|
||
║ │ PixiJS 8 │ │ Svelte 5 UI │ ║
|
||
║ │ (WebGL/WebGPU) │ │ │ ║
|
||
║ │ Tilemap Renderer │ │ Pixel-Editor │ ║
|
||
║ │ Sprite Renderer │ │ Sprite-Editor │ ║
|
||
║ │ 2D Lighting │ │ Property Sliders │ ║
|
||
║ │ Particle System │ │ Trigger-Actions │ ║
|
||
║ │ Planck.js (Physik)│ │ Code Editor │ ║
|
||
║ └────────┬─────────┘ └──────────┬───────────┘ ║
|
||
║ │ │ ║
|
||
║ ┌────────▼────────────────────────▼────────────┐║
|
||
║ │ Dexie.js -- Local-First ║║
|
||
║ └──────────────────┬───────────────────────────┘║
|
||
╚═════════════════════╪═════════════════════════════╝
|
||
│ WebSocket + REST
|
||
╔═════════════════════╪═════════════════════════════╗
|
||
║ GAME SERVER (Go oder Bun/Hono) ║
|
||
║ Welt-State, Physik-Validierung, Script-Sandbox ║
|
||
╠═══════════════════════════════════════════════════╣
|
||
║ BACKEND (bestehende Services, unveraendert) ║
|
||
╠═══════════════════════════════════════════════════╣
|
||
║ DATA: PostgreSQL │ TigerBeetle │ Redis │ MinIO ║
|
||
╚═══════════════════════════════════════════════════╝
|
||
```
|
||
|
||
### Stack-Vergleich: 2D vs 3D
|
||
|
||
| Schicht | 3D Stack | 2D Stack | Aenderung |
|
||
| ------------------ | ------------------------ | ----------------------- | --------------------- |
|
||
| **Sprache Engine** | Rust (Bevy) | TypeScript (PixiJS) | **Kein Rust noetig!** |
|
||
| **Rendering** | wgpu → WebGPU | PixiJS → WebGL/Canvas | Viel simpler |
|
||
| **Physik** | Rapier (Rust) | Planck.js oder Rapier2D | JS-nativ |
|
||
| **Meshing** | Greedy Meshing (komplex) | Tilemap (trivial) | Entfaellt fast |
|
||
| **Lighting** | Shadow Maps, SSAO | 2D Raycast Lighting | Viel simpler |
|
||
| **Networking** | WebTransport (QUIC) | WebSocket (reicht!) | Simpler |
|
||
| **Game Server** | Rust (Bevy headless) | **Go oder Bun** | Kein Rust! |
|
||
| **Scripting** | WASM (Wasmtime) | WASM oder V8 Isolates | Flexibler |
|
||
| **UI** | Svelte 5 | Svelte 5 | Gleich |
|
||
| **Local-First** | Dexie.js | Dexie.js | Gleich |
|
||
| **Auth** | mana-auth | mana-auth | Gleich |
|
||
| **Economy** | TigerBeetle | TigerBeetle | Gleich |
|
||
| **AI** | mana-llm, etc. | mana-llm, etc. | Gleich |
|
||
|
||
**Der groesste Unterschied: Kein Rust.** Der gesamte Engine-Layer wird TypeScript -- eine Sprache die wir bereits perfekt beherrschen.
|
||
|
||
### Game Server in 2D: Go oder Bun?
|
||
|
||
**Option 1: Go (empfohlen)**
|
||
|
||
```
|
||
mana-game-server (Go):
|
||
├── 1 Goroutine pro Welt-Instanz
|
||
├── Welt-State als 2D-Array im Memory
|
||
├── Physik: Einfache 2D-Kollision (eigene Impl, ~200 Zeilen)
|
||
├── Scripting: wazero (WASM in Go) ODER
|
||
├── Scripting: Deno-Subprocess (V8 Isolate)
|
||
├── Networking: gorilla/websocket (bestehend)
|
||
└── Persistenz: PostgreSQL + mana-sync
|
||
|
||
Vorteile: Bestehende Expertise, goroutines perfekt fuer viele Instanzen,
|
||
kein GC-Problem bei 20-30 Ticks/sec (2D braucht keine 60Hz Server)
|
||
```
|
||
|
||
**Option 2: Bun/Hono**
|
||
|
||
```
|
||
mana-game-server (Bun + Hono):
|
||
├── Worker pro Welt-Instanz
|
||
├── Gleiche Sprache wie Client (TypeScript)
|
||
├── Physik: Planck.js (gleicher Code Client+Server!)
|
||
├── Scripting: V8 Isolate (nativ in Bun)
|
||
└── Networking: Bun WebSocket (eingebaut, sehr schnell)
|
||
|
||
Vorteile: Ein Language fuer alles, Code-Sharing Client/Server,
|
||
Bun-WebSocket ist extrem performant
|
||
```
|
||
|
||
**Empfehlung: Go fuer Server** -- konsistent mit unserer Architektur, goroutines skalieren besser als Bun-Worker, bewaehertes Pattern aus mana-sync.
|
||
|
||
---
|
||
|
||
## 7. Performance-Vergleich: 2D vs 3D
|
||
|
||
### Rendering
|
||
|
||
```
|
||
3D (Bevy + WebGPU):
|
||
500 Chunks × Greedy Mesh = ~1.8M Dreiecke
|
||
GPU-intensiv, WebGPU noetig
|
||
60fps Desktop, 30fps Mobile
|
||
|
||
2D (PixiJS + WebGL):
|
||
5.000 × 2.000 Tilemap = 10M Tiles (aber nur ~2.000 sichtbar)
|
||
GPU-trivial, WebGL reicht (laeuft ueberall)
|
||
60fps auf ALLEM (sogar alte Handys)
|
||
```
|
||
|
||
### Memory
|
||
|
||
```
|
||
3D Welt (32m × 32m × 16m bei 10cm):
|
||
50M Voxel × 2 Bytes = ~100 MB roh, ~5-30 MB komprimiert
|
||
+ Meshes: ~50 MB GPU
|
||
= ~80 MB total
|
||
|
||
2D Welt (500m × 200m bei 10cm):
|
||
5.000 × 2.000 Pixel × 2 Bytes = 20 MB roh, ~1 MB komprimiert
|
||
+ Sprites: ~5 MB GPU
|
||
= ~6 MB total
|
||
|
||
→ 2D braucht ~13× weniger Speicher
|
||
```
|
||
|
||
### Netzwerk
|
||
|
||
```
|
||
3D: 500 Chunks initial = ~2.5 MB komprimiert
|
||
2D: Ganze Welt initial = ~1 MB komprimiert (oder Chunk-weise ~100 KB)
|
||
|
||
2D ist ~2-3× kleiner ueber die Leitung
|
||
```
|
||
|
||
### Physik
|
||
|
||
```
|
||
3D: Rapier 3D, 240Hz moeglich aber teuer
|
||
2D: Planck.js oder simple AABB, 60Hz trivial
|
||
|
||
2D Physik ist ~10-50× billiger
|
||
```
|
||
|
||
---
|
||
|
||
## 8. Entwicklungszeit-Vergleich
|
||
|
||
### 3D (aus GAME-PLAN.md)
|
||
|
||
```
|
||
Phase 0: Proof of Concept 6-8 Wochen Bevy + WebGPU + Greedy Meshing
|
||
Phase 1: Item-System 6-8 Wochen Editor, Properties, WASM
|
||
Phase 2: Multiplayer 4-6 Wochen Rust Server, WebTransport
|
||
Phase 3: Platform 4-6 Wochen Auth, Economy, Discovery
|
||
─────────────
|
||
20-28 Wochen (5-7 Monate)
|
||
|
||
+ Rust lernen: 8-12 Wochen
|
||
─────────────
|
||
TOTAL: 28-40 Wochen (7-10 Monate)
|
||
```
|
||
|
||
### 2D
|
||
|
||
```
|
||
Phase 0: Proof of Concept 2-3 Wochen PixiJS + Tilemap + Editor
|
||
Phase 1: Item-System 3-4 Wochen Sprite-Editor, Properties, WASM
|
||
Phase 2: Multiplayer 2-3 Wochen Go Server, WebSocket
|
||
Phase 3: Platform 3-4 Wochen Auth, Economy, Discovery
|
||
─────────────
|
||
10-14 Wochen (2.5-3.5 Monate)
|
||
|
||
+ Rust lernen: 0 Wochen (nicht noetig!)
|
||
─────────────
|
||
TOTAL: 10-14 Wochen (2.5-3.5 Monate)
|
||
```
|
||
|
||
### Warum 2D so viel schneller ist
|
||
|
||
| Aufgabe | 3D Aufwand | 2D Aufwand | Faktor |
|
||
| ------------------ | ------------------------------------ | ---------------------------- | ------ |
|
||
| Rendering Engine | Bevy+wgpu+WebGPU+Meshing (Wochen) | PixiJS Tilemap (Tage) | ~5× |
|
||
| Physik | Rapier 3D Collision (komplex) | AABB 2D (200 Zeilen) | ~10× |
|
||
| Kamera | Orbit+Fly+FPS (3 Modi) | Scroll+Zoom (trivial) | ~5× |
|
||
| Voxel/Pixel Editor | 3D Raycast+Cursor (schwer) | 2D Mausklick→Pixel (einfach) | ~3× |
|
||
| Level of Detail | Octree LOD, Chunk Streaming | Nicht noetig (2D ist billig) | ~∞ |
|
||
| Beleuchtung | Shadow Maps, SSAO, Future Is Bright | 2D Raycast (optional) | ~5× |
|
||
| Sprite-Editor | MagicaVoxel-aehnlich, 3D Rotation | Aseprite-aehnlich, flat | ~2× |
|
||
| Server | Rust/Bevy headless + Go Orchestrator | Go Server (einfach) | ~3× |
|
||
| Cross-Platform | WebGPU-Kompatibilitaet (Safari...) | WebGL (ueberall, sofort) | ~3× |
|
||
| **Rust lernen** | **8-12 Wochen** | **0** | **∞** |
|
||
|
||
---
|
||
|
||
## 9. Vor- und Nachteile: Die ehrliche Tabelle
|
||
|
||
### 2D Vorteile
|
||
|
||
| Vorteil | Detail |
|
||
| ----------------------------------- | ------------------------------------------------- |
|
||
| **3× schnellere Entwicklung** | 2.5-3.5 Monate statt 7-10 |
|
||
| **Kein Rust lernen** | Alles in TypeScript + Go (beherrscht) |
|
||
| **Laeuft ueberall** | WebGL auf jedem Browser, jedem Handy, sogar alten |
|
||
| **Viel groessere Welten** | 500m × 200m statt 32m × 32m bei gleichem Budget |
|
||
| **Simpelere Physik** | 2D Collision in 200 Zeilen, keine 3D-Ecken |
|
||
| **Einfachere Kamera** | Scroll + Zoom statt Orbit + Fly + FPS |
|
||
| **Kein LOD noetig** | 2D ist billig genug ohne Optimierung |
|
||
| **Bewiesenes Genre** | Terraria: 58M Kopien, Stardew Valley: 30M+ |
|
||
| **Geringere Barriere fuer Creator** | Pixel Art ist zugaenglicher als 3D-Modelling |
|
||
| **Sprite-Editor simpler** | 2D-Zeichnen ist einfacher als 3D-Sculpting |
|
||
| **Server in Go** | Keine zweite Systemsprache, bestehende Expertise |
|
||
| **Code-Sharing** | TypeScript auf Client UND (optional) Server |
|
||
| **Mobile-Performance** | 60fps auf 5 Jahre alten Handys |
|
||
| **Barrierefreiheit** | Pixel Art ist leichter zu erlernen als 3D |
|
||
|
||
### 2D Nachteile
|
||
|
||
| Nachteil | Detail |
|
||
| ------------------------------- | ----------------------------------------------------- |
|
||
| **Weniger "wow"** | 3D beeindruckt mehr beim ersten Sehen |
|
||
| **Kein Tiefengefuehl** | Keine Perspektive, kein "in die Welt eintauchen" |
|
||
| **Weniger immersiv** | First-Person-Erlebnis nicht moeglich |
|
||
| **"Nur ein Terraria-Klon"** | Vergleich ist unvermeidlich |
|
||
| **Weniger Bau-Freiheit** | In 3D kann man um Objekte herumgehen |
|
||
| **Limitierte Kamera** | Immer gleiche Perspektive |
|
||
| **Items weniger beeindruckend** | Pixel-Schwert vs. 3D-Voxel-Schwert |
|
||
| **Weniger Innovation** | 2D+Pixel ist bekannt, 3D+Voxel+Programmierbar ist neu |
|
||
| **Zielgruppe kleiner?** | Gen Alpha erwartet 3D (Roblox/Minecraft) |
|
||
| **Kein VR/AR** | 2D in VR macht keinen Sinn |
|
||
|
||
### 3D Vorteile (was man aufgibt)
|
||
|
||
| Was 3D kann, 2D nicht | Impact |
|
||
| ------------------------ | ------------------------- |
|
||
| Um Objekte herumgehen | Hoch -- immersiver |
|
||
| First-Person-Perspektive | Hoch -- "drin sein" |
|
||
| 3D Voxel-Skulpturen | Mittel -- beeindruckender |
|
||
| VR/AR-faehig | Niedrig (kleiner Markt) |
|
||
| Technisch beeindruckend | Marketing-Vorteil |
|
||
|
||
### 3D Nachteile (was man sich spart)
|
||
|
||
| Was 3D schwer macht | Impact |
|
||
| ----------------------- | -------------------------------- |
|
||
| Rust lernen | 8-12 Wochen, signifikante Huerde |
|
||
| WebGPU-Kompatibilitaet | Safari, alte Browser, Mobile |
|
||
| 3D-Physik Komplexitaet | Monate an Edge Cases |
|
||
| Greedy Meshing + LOD | Komplexer Rendering-Code |
|
||
| 3D-Kamera-Steuerung | UX-Challenge (besonders Mobile) |
|
||
| Performance-Optimierung | Endloser Aufwand |
|
||
|
||
---
|
||
|
||
## 10. Der Hybrid-Weg: 2D starten, 3D spaeter?
|
||
|
||
### Ist ein Uebergang moeglich?
|
||
|
||
```
|
||
Strategie: 2D MVP → 3D spaeter
|
||
|
||
Phase 1 (Monat 1-4): 2D-Plattform (PixiJS + Go)
|
||
→ Proof of Concept, Community aufbauen, Feedback sammeln
|
||
→ Creator-Economy validieren
|
||
→ Gameplay-Loop testen (Bauen → Programmieren → Teilen)
|
||
|
||
Phase 2 (Monat 5-12): Parallel 3D-Engine entwickeln
|
||
→ Rust/Bevy lernen waehrend 2D-Version lebt
|
||
→ 3D-Engine als separates Projekt
|
||
→ 2D-Welten → 3D-Konverter (Pixel → Voxel-Scheibe)
|
||
|
||
Phase 3 (Monat 12+): 3D-Version launchen
|
||
→ Bestehende Accounts, Economy, Items migrieren
|
||
→ 2D-Version bleibt als "Classic" / "Lite" erhalten
|
||
→ Items: 2D-Sprites werden zu 3D-Voxel extrudiert
|
||
```
|
||
|
||
**Problem: Item-Migration**
|
||
|
||
```
|
||
2D Schwert (16 × 32 Pixel): 3D Schwert (3 × 1 × 15 Voxel):
|
||
▓ Komplett anderes Format.
|
||
▓▓▓ Man kann 2D → 3D extrudieren
|
||
▓███▓ (Pixel → 1 Voxel tief),
|
||
▓█████▓ aber es sieht "flach" aus.
|
||
▓███▓
|
||
▓█▓ Creator muessten Items
|
||
▓ manuell in 3D neu bauen.
|
||
▓
|
||
▓▓▓
|
||
```
|
||
|
||
**Ehrliche Einschaetzung:** Der Uebergang ist **moeglich aber schmerzhaft**. Backend (Auth, Economy, Social) migriert trivial. Content (Welten, Items) muss neu erstellt oder automatisch konvertiert werden. Automatische Konvertierung (2D→3D) erzeugt nur maessige Qualitaet.
|
||
|
||
### Besser: Sich fuer einen Weg entscheiden
|
||
|
||
```
|
||
WENN das Ziel ist: Schnell launchen, Community validieren, iterieren
|
||
→ 2D. In 3 Monaten spielbar, in 6 Monaten polished.
|
||
|
||
WENN das Ziel ist: Langfristig die beeindruckendste UGC-Plattform
|
||
→ 3D. In 7-10 Monaten spielbar, aber technisch ueberlegener.
|
||
|
||
WENN das Ziel ist: Beides testen
|
||
→ 2D zuerst (3 Monate), dann entscheiden ob 3D-Investment lohnt.
|
||
Die Backend-Services (Auth, Economy, AI) sind identisch.
|
||
Nur Engine + Editor muessen neu.
|
||
```
|
||
|
||
---
|
||
|
||
## 11. 2D MVP Build-Plan
|
||
|
||
### Phase 0: Engine + Editor (3 Wochen)
|
||
|
||
```
|
||
Woche 1: PixiJS Setup + Tilemap
|
||
□ PixiJS 8 + SvelteKit-Integration
|
||
□ Tilemap-Renderer (Chunk-basiert, 32×32 Tiles pro Chunk)
|
||
□ Kamera: Scroll + Zoom
|
||
□ 10 Basis-Materialien
|
||
|
||
Woche 2: Pixel-Editor
|
||
□ Mausklick → Pixel setzen/loeschen
|
||
□ Pinsel, Radierer, Fuellen, Pipette
|
||
□ Material-Palette
|
||
□ Undo/Redo
|
||
□ Hintergrund/Vordergrund Layer
|
||
|
||
Woche 3: Spieler + Physik
|
||
□ Charakter-Sprite (Standard)
|
||
□ 2D-Kollision mit Tilemap
|
||
□ Gravitation, Laufen, Springen
|
||
□ Simple Beleuchtung (optional)
|
||
|
||
Ergebnis: Terraria-Creative im Browser, 60fps
|
||
```
|
||
|
||
### Phase 1: Items (4 Wochen)
|
||
|
||
```
|
||
Woche 4-5: Sprite-Editor + Items
|
||
□ In-Game Sprite-Editor (16×32, 32×32, 64×64)
|
||
□ Pixel-fuer-Pixel zeichnen
|
||
□ Animation Frames (Spritesheet)
|
||
□ "Als Item speichern"
|
||
□ Item im Inventar, in der Hand halten
|
||
|
||
Woche 6: Properties + Trigger-Actions
|
||
□ Property Sliders (Ebene 1)
|
||
□ Trigger-Action Editor (Ebene 2)
|
||
□ Trigger → WASM Kompilierung
|
||
□ WASM Sandbox (wazero in Go oder V8 in Bun)
|
||
|
||
Woche 7: Items in der Welt
|
||
□ Item benutzen (Primary/Secondary Action)
|
||
□ Items ablegen / aufheben
|
||
□ Partikel-System (2D)
|
||
□ Sound-System
|
||
□ Pixel-Zerstoerung (Explosion → Krater)
|
||
|
||
Ergebnis: Schwert zeichnen → Feuer-Schaden geben → benutzen → Pixel splittern
|
||
```
|
||
|
||
### Phase 2: Multiplayer (3 Wochen)
|
||
|
||
```
|
||
Woche 8: Go Game Server
|
||
□ mana-game-server (Go)
|
||
□ Welt-State im Memory (2D-Array)
|
||
□ WebSocket (coder/websocket, wie mana-sync)
|
||
□ Pixel-Sync (Delta-Kompression)
|
||
|
||
Woche 9: Multiplayer-Sync
|
||
□ Spieler-Positionen synchronisieren
|
||
□ Voxel-Aenderungen broadcasten
|
||
□ Server-autoritativ (Validierung)
|
||
□ Andere Spieler sehen
|
||
|
||
Woche 10: Multiplayer-Features
|
||
□ Item-Sync + Inventar
|
||
□ PvP (Items benutzen gegen andere)
|
||
□ Chat
|
||
□ Welt-Link teilen
|
||
|
||
Ergebnis: 2-20 Spieler bauen und kaempfen zusammen
|
||
```
|
||
|
||
### Phase 3: Platform (4 Wochen)
|
||
|
||
```
|
||
Woche 11-12: Auth + Persistence
|
||
□ mana-auth Integration
|
||
□ PostgreSQL Persistence
|
||
□ Local-First (Dexie.js ↔ mana-sync)
|
||
□ Guest Mode
|
||
|
||
Woche 13: Discovery + Economy
|
||
□ Welt veroeffentlichen
|
||
□ Welt-Suche (Meilisearch)
|
||
□ TigerBeetle Economy
|
||
□ Item Marketplace
|
||
|
||
Woche 14: Polish
|
||
□ Onboarding Tutorial
|
||
□ Welt-Templates (Hoehle, Insel, Haus, Arena)
|
||
□ Mobile-Optimierung
|
||
□ Bug Fixes
|
||
|
||
Ergebnis: MVP! Spielbare 2D-Pixel-Plattform im Browser.
|
||
```
|
||
|
||
### Timeline-Vergleich
|
||
|
||
```
|
||
Monat 1 Monat 2 Monat 3 Monat 4 Monat 5-7 Monat 8-10
|
||
|
||
2D: [Engine ] [Items ] [Multi] [Platform] Post-MVP Post-MVP
|
||
[Editor ] [Props ] [player] [Polish ] (Detail, (3D??)
|
||
[Trigger ] AI, etc.)
|
||
|
||
3D: [Rust lernen ] [Engine ] [Engine ] [Items ] [Multi ]
|
||
[Chunks ] [Meshing ] [Editor ] [Platf.]
|
||
[Physik ] [Camera ] [Trigger ] [Polish]
|
||
|
||
2D spielbar nach: ~10 Wochen (2.5 Monate)
|
||
3D spielbar nach: ~28 Wochen (7 Monate)
|
||
```
|
||
|
||
---
|
||
|
||
## 12. Entscheidungshilfe
|
||
|
||
### Wann 2D die richtige Wahl ist
|
||
|
||
```
|
||
✓ Du willst in 3 Monaten etwas Spielbares
|
||
✓ Du willst kein Rust lernen (jetzt)
|
||
✓ Du willst das Konzept validieren bevor du 10 Monate investierst
|
||
✓ Deine Zielgruppe sind Creator die Pixel Art moegen
|
||
✓ Du willst auf JEDEM Geraet laufen (auch alte Handys)
|
||
✓ Du willst grosse Welten (500m+) bei niedrigen Kosten
|
||
✓ Du planst eventuell spaeter eine 3D-Version
|
||
```
|
||
|
||
### Wann 3D die richtige Wahl ist
|
||
|
||
```
|
||
✓ Du willst die langfristig beeindruckendste Plattform
|
||
✓ Du bist bereit, Rust zu lernen
|
||
✓ Deine Zielgruppe erwartet 3D (Gen Alpha, Roblox-Spieler)
|
||
✓ Du willst VR/AR-ready sein
|
||
✓ Du willst dich maximal differenzieren (3D+Voxel+Programmierbar ist einzigartig)
|
||
✓ Du hast 7-10 Monate Zeit bis zum MVP
|
||
```
|
||
|
||
### Die pragmatische Empfehlung
|
||
|
||
```
|
||
OPTION: 2D zuerst, 3D evaluieren
|
||
|
||
Monat 1-3.5: 2D MVP bauen und launchen
|
||
Monat 4-6: Community aufbauen, Feedback, iterieren
|
||
Monat 5: Rust-Lernphase starten (parallel)
|
||
Monat 7: Entscheidung: Lohnt sich 3D-Investment?
|
||
JA → 3D-Engine parallel entwickeln
|
||
NEIN → 2D weiter ausbauen
|
||
|
||
Das Backend (Auth, Economy, AI, Sync) ist IDENTISCH.
|
||
Nur Engine + Editor aendern sich.
|
||
```
|
||
|
||
---
|
||
|
||
## 13. Zusammenfassung
|
||
|
||
```
|
||
2D (PixiJS) 3D (Bevy)
|
||
────────────────────── ─────────────────── ──────────────────
|
||
Entwicklungszeit 2.5-3.5 Monate 7-10 Monate
|
||
Neue Sprachen Keine Rust
|
||
Performance 60fps ueberall 60fps Desktop
|
||
Browser-Support Alle (WebGL) Modern (WebGPU)
|
||
Weltgroesse 500m × 200m 64m × 64m × 32m
|
||
Speicher ~6 MB ~80 MB
|
||
Komplexitaet Niedrig Hoch
|
||
Wow-Faktor Mittel Hoch
|
||
Genre-Vergleich Terraria+Roblox Minecraft+Roblox
|
||
Zielgruppe Pixel-Art-Fans 3D-Voxel-Fans
|
||
Items 2D Sprites 3D Voxel-Skulpturen
|
||
Programmierung Identisch Identisch
|
||
Economy Identisch Identisch
|
||
AI Identisch Identisch
|
||
Self-Hosting Identisch Identisch
|
||
Mobile Perfekt Eingeschraenkt
|
||
Risiko Niedrig Mittel-Hoch
|
||
```
|
||
|
||
**Kern-Erkenntnis:** Das was ManaVoxel einzigartig macht -- programmierbare Items, Creator Economy, In-Game-Editor, Local-First, Browser-nativ -- funktioniert in 2D genauso gut wie in 3D. Die dritte Dimension macht es beeindruckender, aber nicht besser.
|
||
|
||
---
|
||
|
||
_Erstellt: 28. Maerz 2026_
|