Stefan Franke
502131f07c
Erste lauffähige Fassung: 3D-Raum, Echtzeit-Multiplayer (WebSocket), Python-IDE via Pyodide im Browser, eigener Arbeitsplatz mit Live-Code-Monitor. Modularer, self-hostbarer Aufbau (Three.js + Node/Express + ws), ohne CDN- Abhängigkeit zur Laufzeit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
109 lines
4.7 KiB
Markdown
109 lines
4.7 KiB
Markdown
# VR ProgrammierHub
|
||
|
||
Ein browserbasierter, begehbarer **3D-Lernraum** für die hybride Programmier-Lehre.
|
||
Studierende betreten als Avatar einen virtuellen Seminarraum, setzen sich an ihren
|
||
Arbeitsplatz und programmieren dort **Python direkt im Browser** – während sie sehen,
|
||
woran die anderen gerade arbeiten.
|
||
|
||
Entstanden für den Grundlagenkurs *Objektorientierte Programmierung (Python)* an der
|
||
PH Weingarten, der teils in Präsenz, teils per Zoom stattfindet.
|
||
|
||
---
|
||
|
||
## Didaktischer Wert
|
||
|
||
Das Projekt adressiert drei Kernprobleme hybrider Programmier-Lehre – und leitet daraus
|
||
seinen didaktischen Anspruch ab:
|
||
|
||
**1. Sichtbarkeit statt stiller Einzelarbeit (Peer-Learning).**
|
||
In klassischen Online-Settings arbeitet jede:r isoliert vor sich hin. Der Hub macht die
|
||
Arbeit *sichtbar*: Man sieht die Avatare der anderen, ihren Aufgaben-Status und kann ihnen
|
||
buchstäblich „über die Schulter schauen“. Das ermöglicht beiläufiges Lernen am Modell der
|
||
Peers (sozial-konstruktivistisch, Vygotskys *Zone der nächsten Entwicklung*), das in
|
||
Videokonferenzen komplett wegfällt.
|
||
|
||
**2. Soziale Eingebundenheit für Remote-Teilnehmende.**
|
||
Wer zuhause sitzt, ist in reinen Zoom-Formaten „abgehängt“. Ein gemeinsamer Raum mit
|
||
verkörperten Avataren erzeugt Präsenz- und Zugehörigkeitsgefühl (*relatedness* im Sinne der
|
||
Selbstbestimmungstheorie) – ein bekannter Faktor gegen Abbruch und für Lernmotivation.
|
||
|
||
**3. Niedrigste Einstiegshürde – Fokus aufs Programmieren, nicht auf Setup.**
|
||
Kein Download, keine lokale Python-Installation, keine IDE-Konfiguration: Seite öffnen,
|
||
einloggen, loslegen. Python läuft via **Pyodide (WebAssembly) im Browser** der Studierenden.
|
||
Das entfernt die klassische Anfänger-Hürde („bei mir läuft es nicht“) und verlagert die
|
||
kognitive Last dorthin, wo sie hingehört: auf das Erlernen von Konzepten.
|
||
|
||
**Für die Lehrperson** entsteht *formative* Transparenz: Man sieht in Echtzeit, wer woran
|
||
arbeitet und wer hängt – auch remote – und kann gezielt und rechtzeitig unterstützen, statt
|
||
auf Zuruf zu reagieren. Ein sichtbares **Hilfe-Handzeichen** senkt zusätzlich die Hemmschwelle,
|
||
um Hilfe zu bitten.
|
||
|
||
**Nicht zuletzt** ist der Hub selbst Anschauungsobjekt: Er verbindet Web-, 3D- und
|
||
Netzwerk-Programmierung in einem realen, motivierenden Kontext und eignet sich als
|
||
Gegenstand studentischer Projekt- und Abschlussarbeiten.
|
||
|
||
---
|
||
|
||
## Was schon funktioniert
|
||
|
||
- Begehbarer 3D-Raum (WASD + Maus/Pointer-Lock, Pfeiltasten als Tastatur-Fallback)
|
||
- Echtzeit-**Multiplayer**: alle sehen alle Avatare live, mit Namensschild, Blickrichtung
|
||
und Hilfe-Marker; framerate-unabhängige Interpolation
|
||
- **Python-IDE** als 2D-Fenster: Code ausführen via Pyodide, Ausgabe direkt sichtbar
|
||
- Eigener **Arbeitsplatz** mit Monitor; **Hinsetzen** (Taste `E`) öffnet die IDE
|
||
- Der eigene Code wird **live auf den 3D-Monitor** gerendert (Grundlage für die
|
||
„über-die-Schulter“-Einsicht der anderen)
|
||
|
||
## Roadmap (Auszug)
|
||
|
||
- Broadcast des Codes → andere sehen ihn auf dem jeweiligen Monitor
|
||
- Login/Auth (Rollen `student` / `teacher`) und Persistenz der Workspaces
|
||
- Klick auf fremden Monitor → Code-Snapshot; Lehrenden-Dashboard; Hilfe-Warteschlange
|
||
- CodeMirror statt Textarea; optionaler VR-Zugang (WebXR)
|
||
|
||
---
|
||
|
||
## Architektur
|
||
|
||
- **Frontend:** [Three.js](https://threejs.org) (WebGL), modulare ES-Module, kein Build-Schritt
|
||
- **Python:** [Pyodide](https://pyodide.org) (CPython als WebAssembly, läuft im Browser)
|
||
- **Backend:** Node.js + Express + `ws` (ein Prozess: liefert Assets aus **und** hält den
|
||
Echtzeit-Raumzustand im WebSocket-Hub)
|
||
- **Prinzip:** komplett self-hostbar, keine CDN-Abhängigkeit zur Laufzeit, kein Vendor-Lock-in
|
||
|
||
```
|
||
public/
|
||
index.html schlankes Markup + Import-Map
|
||
css/style.css
|
||
js/
|
||
main.js Orchestrator + Render-Schleife
|
||
scene.js Weltaufbau (Raum, Licht, Arbeitsplätze)
|
||
controls.js WASD + Maus-Blick (Pointer Lock)
|
||
avatars.js fremde Avatare, Namensschilder, Interpolation
|
||
net.js WebSocket-Client + Protokoll
|
||
ide.js Python-IDE-Overlay (Pyodide)
|
||
codescreen.js Code als Live-Textur auf dem 3D-Monitor
|
||
ui.js Overlay, Toolbar, HUD
|
||
vendor/ Three.js + Pyodide (per Setup-Skript, nicht eingecheckt)
|
||
server.js Express + WebSocket-Hub
|
||
```
|
||
|
||
---
|
||
|
||
## Installation & Start
|
||
|
||
```bash
|
||
npm install
|
||
./scripts/setup-vendor.sh # lädt Three.js + Pyodide nach public/vendor/
|
||
npm start # startet den Server auf http://localhost:3000
|
||
```
|
||
|
||
Dann `http://localhost:3000` im Browser öffnen (Chrome/Edge empfohlen).
|
||
Für den Betrieb hinter einer Domain zusätzlich einen Reverse-Proxy mit TLS davorschalten
|
||
(WebXR/VR benötigt HTTPS).
|
||
|
||
---
|
||
|
||
## Lizenz
|
||
|
||
Noch nicht festgelegt. © Stefan Franke, PH Weingarten.
|