Ship

Die Check-ins am 18.12. und 04.01. waren freiwillig. Für alle, die sie nachholen oder beim nächsten Projekt so arbeiten wollen: Ein guter Post hat drei Teile.

1. Ein lauffähiger Stand. Ein Clip von 30 bis 60 Sekunden, aufgenommen im Build, nicht im Play-Modus des Editors. Wer kann, hängt den Build an.
2. Drei offene Aufgaben, jede so klein, dass sie an einem Nachmittag fertig wird, in der Reihenfolge, in der sie drankommen.
3. Höchstens eine Frage, mit dem, was schon versucht wurde.

Schwach: „Läuft so halb, muss noch einiges machen.“

Stark: „Clip im Anhang: Der Raum ist komplett, die Tür geht mit dem Schlüssel auf. Offen: 1. Die Falle setzt noch nicht zurück. 2. Neustart per Taste R. 3. Ein Ton für die Tür. Frage: Der Build startet mit schwarzem Bild, die Szene steht in der Scene List. Was fehlt noch?“

Am 04.01. kommt eine Zeile dazu: Welche der drei Aufgaben vom 18.12. sind erledigt?

Wer heute weder einen getesteten Build noch einen Doku-Entwurf hat, macht trotzdem überall mit: Im zweiten Block wird notfalls im Play-Modus des Editors gespielt, und der Abgabe-Check zeigt, was in den nächsten 14 Tagen zuerst drankommt.

Die Aufgabenstellung nennt nur die Überschrift „Idee und Konzept“. So lese ich sie: Zählt, wie klar die Idee ist und wie gut das Spiel sie einlöst. Das PDF belegt, dass das Erlebnis geplant war: Was sollten die Spielenden erleben, welche anderen Wege gab es, welche Frage wurde im Test beantwortet? Die Kapitel 1 bis 4 aus DOKUMENTATION.md (Idee, Alternativen, Designfrage, Spec) tragen diesen Teil.

Das Zitat stammt aus der Aufgabenstellung. Bilder sind ausdrücklich erwünscht, Konzeptzeichnungen auch. Die Kapitel 5 bis 9 aus DOKUMENTATION.md (Tests, Überarbeitungen, ein System, Reflexion, Quellen und KI) tragen diesen Teil.

Wer kein Devlog geführt hat: Der Verlauf ist das Gerüst. Jeder Commit hat ein Datum, und aus den Nachrichten lässt sich rekonstruieren, wann sich was geändert hat. Die Playtest-Karten werden in Kapitel 5 ausgewertet (Tabelle: Datum, wer, Beobachtung, Änderung); Fotos der Karten kommen in den Anhang.

HIGH WATER entstand in einer Game Jam. Vor dem Start stand fest, was zuerst wegfällt, wenn die Zeit knapp wird, und was nie wegfällt: das Gefühl jedes Treffers. Gestrichen oder verschoben wurden unter anderem die höhere Auflösung (sie hätte etwa 1,78-mal so viel Rechenarbeit pro Bild gekostet), Charaktermodelle aus Polygonen (ersetzt durch Voxel-Figuren), eine Ausrüstungsseite und eigene Zug- und Fabriklevel, die nur als einzelne Momente blieben.

Ein zweites Stück Making-of steckt in den Zahlen. Das Designdokument plante für den dritten Schlag einen Stoß von 11 nach vorn und 5 nach oben. Im Code steht nach dem Tuning 8,5 und 4,5, dazu ein Anteil aus dem Tempo der Spielfigur. Das Dokument hält die erste Absicht fest, der Code den getunten Wert. Beides gehört ins Making-of: was geplant war und was der Test daraus gemacht hat.

Spiel: limeminister.itch.io/high-water.

Kapitel 7 in DOKUMENTATION.md: ein System so erklären, dass jemand ohne Unity-Erfahrung versteht, was es auslöst, was es prüft und was es verändert. Das System darf mit einem Agenten gebaut sein. Die Erklärung kommt von euch. Ein Screenshot des Graphen oder des Inspectors hilft.

Der vollständige Auftrag zum Kopieren:

Lies DOKUMENTATION.md und KI-VERZEICHNIS.md in diesem Projekt und die Checkliste unter https://www.allknivesnobagel.com/teaching/gec1/druck/abgabe-check.html. Liste als Fragen auf, was in der Dokumentation fehlt oder für eine fremde Person unklar ist. Ordne nach Wichtigkeit. Schreib keinen Text für die Dokumentation und ändere keine Datei.

Danach drei Fragen auswählen, die stimmen, und die Antworten selbst schreiben. Fragen, die nicht stimmen, streichen. Wer keinen Agenten zur Hand hat, tauscht den Entwurf mit der Person daneben und stellt dieselben Fragen von Hand.

Die Regel: Eine Zeile bekommt jeder Auftrag, dessen Antwort in die Arbeit eingeht. Das gilt auch, wenn der Agent nur eine Diagnose stellt und ihr die Änderung selbst ausführt, und hier, wenn er Lücken findet und ihr den Text selbst schreibt. Die Notiz sagt, was von euch ist.

Die Richtlinie der Hochschule vom 28.04.2025 verlangt für generierte Elemente, die in die Arbeit übernommen werden, eine Quellenangabe an der Stelle mit Verweis auf den Prompt, auch nach eigener Überarbeitung. Dafür die verwendeten Prompts unter einer Nummer aufheben, am einfachsten in einem Abschnitt „Prompts“ unten in KI-VERZEICHNIS.md: P1, P2 … mit Datum, Werkzeug und Wortlaut. Die Zeile in der Tabelle nennt die Nummer, die Quellenangabe im Text auch.

Auch Kürzen, Glätten und Rechtschreibprüfung durch eine KI bekommen eine Zeile, sobald das Ergebnis in der PDF steht. Generierte Inhalte im Spiel (Bilder, Ton, Texte) brauchen außerdem einen Credit im Spiel oder im Abspann.

Dieselbe Reihenfolge gilt zur Abgabe mit dem Tag abgabe: speichern, committen, bauen, den Build auf einem fremden Rechner testen, dann genau diesen Commit taggen und pushen. Wer heute keinen getesteten Build hat, setzt den Tag beta erst, wenn ein Build woanders gelaufen ist.

Im Terminal geht es auch. Die Kennung des Build-Commits steht in GitHub Desktop unter History:

git tag beta 7c1e0a2
git push origin beta

Auf GitHub liegt zu jedem Tag unter Code › Tags ein Download Source code (zip). Er enthält genau den gepushten Stand des Tags, ohne Library/ und ohne Temp/. Das ist das sauberste Projekt-ZIP für die Abgabe. Was nicht gespeichert, committet und gepusht ist, fehlt darin.

Im Making-of einen Commit so zitieren: Datum, Nachricht, die ersten sieben Zeichen der Kennung, etwa „04.12., Falle entfernt (7c1e0a2)“. Ein Screenshot aus dem Reiter History in GitHub Desktop zeigt einen Abschnitt des Verlaufs auf einen Blick. Wer Jonas Zugriff auf das Repository gegeben hat (freiwillig, auf GitHub unter Settings › Collaborators), kann zusätzlich den Link angeben; nötig ist das nicht.

Die Checkliste zum Ausdrucken: Abgabe-Check. Sie führt durch alles, was bis zum 22.01. zu prüfen ist: Dateinamen, Inhalt der beiden ZIPs, Build-Test auf einem fremden Rechner, Teile der PDF, Größe.

Paare werden so gebildet, dass in jedem ein Windows-Laptop ist; sie bleiben für den zweiten Block zusammen. Wer einen Mac hat, testet den eigenen Build auf dem Windows-Laptop der anderen Person. Der Build reist per USB-Stick oder Cloud-Link, am besten schon vor 14:15 fertig gezippt. Der entpackte Build bleibt für den zweiten Block auf dem Laptop liegen.

Gibt es weniger Windows-Laptops als Paare, stehen zwei Gemeinschaftsstationen bereit. Paare ohne Windows-Gerät tragen sich dort in die Zeitliste ein: je 10 Minuten für Entpacken, Starten und einmal Durchspielen.

Pandoc ist ein kostenloses Umwandlungsprogramm, das ohne Installation und ohne Administratorrechte läuft. Getestet mit Pandoc 3.12: Bilder aus bilder/ und Tabellen kommen mit.

1. Auf github.com/jgm/pandoc/releases/latest das ZIP laden: Windows pandoc-…-windows-x86_64.zip, Mac mit Apple-Chip pandoc-…-arm64-macOS.zip, ältere Macs pandoc-…-x86_64-macOS.zip.
2. Entpacken, etwa nach Dokumente/pandoc.
3. Im Projektordner ein Terminal öffnen (GitHub Desktop: Repository › Open in Command Prompt bzw. Open in Terminal) und den Befehl in einer Zeile ausführen, mit dem Pfad zu Pandoc vorn, etwa C:\Users\Name\Documents\pandoc\pandoc-3.12\pandoc.exe oder ~/Documents/pandoc/pandoc-3.12-arm64/bin/pandoc: pandoc DOKUMENTATION.md KI-VERZEICHNIS.md -o Dokumentation.docx Den Befehl kann auch der Agent ausführen.
4. Dokumentation.docx öffnen, Titelseite ergänzen, Bilder und Tabellen ansehen, als PDF exportieren. Word: Datei › Speichern unter › PDF. LibreOffice: Datei › Als PDF exportieren. Pages: Ablage › Exportieren › PDF.

Wer lieber in Word, InDesign oder Google Docs gestaltet, übernimmt den Text von Hand. Am Ende zählt eine PDF mit allen Teilen aus dem Abgabe-Check.

Wer einen Mac hat, zeigt den eigenen Build am Windows-Laptop der anderen Person aus dem Paar; dort liegt er seit dem ersten Block. Wer einen Windows-Laptop hat, zeigt am eigenen oder am Laptop der anderen Person. Ohne Windows-Gerät im Paar: An den zwei Gemeinschaftsstationen zeigt in jedem 7-Minuten-Abschnitt eine andere Person ihren Build, nach der Zeitliste.

Was darf sich jetzt noch ändern? Der Feature-Freeze war am 11.12. Erlaubt sind Reparaturen an dem, was schon da ist, dazu Ton, Licht, Texte und die Dokumentation. Neue Interaktionen kommen nicht mehr dazu. Die einzige Ausnahme: Fehlt noch eine der zwei Pflicht-Interaktionen aus der Aufgabenstellung, wird sie fertig gebaut. Nach jeder Änderung den Build noch einmal auf einem fremden Rechner testen.

Der Build startet woanders nicht. Der Reihe nach prüfen: Wurde das ZIP entpackt, oder läuft die .exe aus der ZIP-Vorschau heraus? Liegt der ganze Ordner bei, mit dem Ordner, der auf _Data endet? Stehen alle Szenen in der Scene List, die Startszene oben? Windows zeigt bei Spielen ohne Signatur „Der Computer wurde durch Windows geschützt“: Weitere Informationen › Trotzdem ausführen. Das ist normal und gehört als Hinweis in die PDF.

Das ZIP ist zu groß. Meist liegt Library/ im Projekt-ZIP; das Source-ZIP von GitHub hat das Problem nicht. Danach große Rohdateien in Assets/ prüfen (.wav, .psd, .blend, Videos). Im Build helfen kleinere Max Size bei Texturen und komprimierte Audioformate.

Was gehört in die PDF? Siehe Abgabe-Check, Teil F. Dazu eine kurze Spielanleitung: wie man das Spiel startet, die Steuerung, das Ziel.

Fremde Assets? Kostenlose sind erlaubt, mit Quelle und Lizenz in der PDF. Kostenpflichtige Pakete sind ausgeschlossen. Selbst gemachte Assets bewertet die Aufgabenstellung besser.

Der Post am 15.01. im Blackboard-Thread enthält: das Inhaltsverzeichnis der PDF, ein fertiges Kapitel, den Stand des Builds und ein Hindernis.

Die Stunden sind Richtwerte für Dokumentation und Abgabe; Reparaturen am Spiel kommen dazu. Wer neben dem Studium arbeitet, trägt die drei Blöcke fest in den Kalender ein, den letzten nicht auf den 22.01.

Nicht in der letzten Stunde hochladen. Über ein Gigabyte kann im Hochschul-WLAN lange dauern, und ein Fehler beim Upload lässt sich dann nicht mehr beheben. Die Abgabe geht als ein ZIP in den Prüfungsraum auf Blackboard. Das Devlog bekommt am Abgabetag einen letzten Eintrag.