¶ 1. Überblick
¶ 1.1 Kurzbeschreibung
"It's (not) a crime" zeigt, welchen Risiken LGBTIQ* in manchen Ländern bis heute ausgesetzt sind: Inhaftierung, Anfeindungen, Mord. In diesem Spiel muss man aus einer Zelle ausbrechen, denn in der Zelle zu bleiben ist keine Option. Arbeitslager, Todesmarsch… was immer käme, wäre nur schlimmer als ein misslungener Ausbruch. Dabei machen es einem sowohl der Mitinsasse als auch die Minigames nicht leicht, hier einen Fortschritt zu erzielen.
Das Spiel entstand im Rahmen des Kurses Media Design 1 im Sommersemester 2026 (Eric Jannot) im Studiengang Media Systems (B.Sc.).
¶ 1.2 Teamübersicht
¶ Gruppenmitglieder |
¶ Matrikelnummer |
¶ Verantwortlichkeit |
¶ Studiengang |
¶ Erreichbarkeit |
| Grewe, Sebastian | 2743109 | Game Design, Dialoge, Sound, UI, Programmieren | Media Systems | |
| Kotte, Oskar | 2730598 | 3D Modelle und Texturen, Game Design, Programmieren | Media Systems | |
| Wendel, Florian | 2736433 | Programmieren, Implementieren von Dialogen und Mingames, Minigame Design | Media Systems |
Die Verantwortlichkeiten haben sich oft überschnitten. Wurde etwa ein Minigame entwickelt, dann umfasste dies einerseits die Entwicklung, aber auch die Implementierung im Code und die Verwendung von AudioStreamPlayern und Ähnlichem.
¶ 1.3 Grundidee, Zielsetzung und Scope
¶ 1.4 Message/Story
Das Spiel spielt in einem nicht näher bezeichneten Land, in dem LGBTIQ* verfolgt und inhaftiert werden. In manchen Fällen wird sogar die Todesstrafe ausgesprochen. Dies soll kritisiert werden.
¶ 1.5 Gameplay-Video-Capture und Screenshots
¶ 2. Inspiration
¶ 2.1 Referenzspiele und Vorbilder
Als Referenzen dienten visuell vor allem Spiele, die den Playstation 1-Artstyle emulieren. Dazu gehören zum Beispiel Low-Poly-3D-Modelle und grobe Texturen.
| Mouthwashing | |
|---|---|
|
|
| Eclipsium |
|---|
|
| What Remains of Edith Finch |
|---|
|
¶ 2.2 Abgrenzung
- Kein Horrorgame, also keine Jumpscares
- Kein Splattergame, keine Darstellung von physischer Gewalt oder Blut
¶ 2.3 Moodboard
| Moodboard (Mood Board OneDrive Link) |
|---|
|
¶ 2.4 Skizzierung
|
|
|
|
¶ 3. Technische Umsetzung und Mechanics
¶ 3.1 Steuerung/Funktionsweise
- Die / Der Spieler*in bewegt sich in First Person mit WASD. Mit der Maus kann die Kamera in alle Winkel rotiert werden.
- E ist der allgemeine Interaktionsbutton - man kann mit Objekten und dem Mitinsassen interagieren.
- Dialoge werden mit E oder der Maus weitergeklickt. Minispiele erfordern die Maus oder kontextabhängigen Input, der im Minigame angezeigt wird.
¶ 3.2 Engine und Genre
- Godot 4.6.3 mit Plugin Dialogic 2
- First Person “Walking Simulator”
- Atmospheric
¶ 3.3 Gameplay Features
- First Person Steuerung
- Charaktere und Gegenstände interagierbar, dadurch können…
- Kamerafahrten zu Points of Interest passieren
- Minigames gestartet werden
- Dialoge gestartet werden
- Escape Room artige Minigames
- Minigames können nur mit passendem Item gestartet werden
- Belohnung aus Minigame A ermöglicht Spielen von Minigame B, Event Kette von A nach B nach C
¶ 3.4 Player Actions/Game Prinzip
- Bewegen
- Erkunden
- Interagieren
- kontextabhängige Minigames
¶ 3.5 Game Loop
Spieler*innen können sich in der Zelle bewegen, dadurch erfolgt gleichzeitig Erkunden.
Auf einem gefundenen Objekt, mit dem interagiert werden kann, startet die kontextabhängige Interaktion (Minigame, Dialog, Kamerafahrt).
Ist dies ein Minigame wird das Minigame gestartet. Sobald die Interaktion endet, kann der/die Spieler*in sich wieder bewegen und erkunden.
¶ 4. Entwicklung
¶ 4.1 Herausforderungen
Erstes Arbeiten an einem 3D Game in Godot, Dialoge schreiben und Minigames designen.
¶ 4.2 Milestones
- 13.05.2: In Zelle bewegen können
- 20.05.26: Ein funktionierendes Rätsel
- 27.05.26: Demoversion (POC), die bereit für den ersten Playtest ist
- 08.07.26: Prototyp, der die Anforderungen an eine Abgabe erfüllt
¶ 4.3 Verworfene/ verschobene Ideen
Es gab die Idee, ein animiertes Intro zu entwickeln, in dem die Verhaftung der spielenden Figur zu sehen ist (aus der Egoperspektive). Für die Umsetzung des Projektes im Rahmen des Kurses wirkte dies jedoch unrealistisch und die Idee wurde rasch verworfen.
Es bestand die Idee eines Rattenlochs, in das man Gegenstände legen kann, um ein Item (bspw. Cracker/Käse) gegen ein anderes Item (für den Rätselfortschritt) einzutauschen. Die Idee besteht weiterhin, aber im Prozess sind wir immer mehr zu einzelnen Minigames mit Belohnung übergegangen, anstatt Rätsel einzubauen.
Eine Wache sollte auf und ab laufen, um den Spieler bei “illegalen” Aktivitäten zu bestrafen oder in der aktuellen Aktivität zu unterbrechen. Diese Idee wurde aus Zeitgründen verworfen, da es eine AI-Navigation, ein Modell mit Animationen und Erkennung des/der Spieler*in benötigt hätte. Für zukünftige Builds könnte alternative eine Drohne verwendet werden, die auf und ab fliegt, um den Entwicklungsaufwand zu verringern.
Der/Die Spieler*in hätte in der Lage sein sollen, mit anderen Zellengenoss*innen aus den Zellen gegenüber kommunizieren zu können. Aus Zeitgründen wurden keine weiteren Charaktere und Dialoge erstellt.
Eine weitere Idee war, dass sich die Zelle bunt färbt für jedes gelöste Rätsel (Einfärben von einzelnen Gegenständen), um dem drögen/grauen Look entgegenzuwirken und sich der Thematisierung anzunähern. Auch diese Idee wurde aus Stil- und Zeitgründen verworfen.
¶ 5. Aesthetics
¶ 5.1 Game Design Pillars
- Gefängnis als Kulisse, um die Kriminalisierung der LGBTIQ* kurz und knapp auf den Punkt zu bringen
- Feindliche Atmosphäre, ausgedrückt durch kalte Farben, unangenehme Geräuschkulisse und ablehnende Sprache einzelner Personen
- Minigames, welche den Spieler*innen Geschicklichkeit abverlangen und sich nicht allzu leicht lösen lassen sollen, um damit die allgegenwärtig ablehnende Umgebung widerzuspiegeln
¶ 5.2 Art Style und Design Intentions
- 3D-Playstation-1-Grafik emulieren mit Low-Poly-3D-Modellen und groben Texturen. Dies soll für einen markanten Style sorgen.
- Unfairness der Inhaftierung von LGBTIQ* Menschen darstellen, indem Spieler*innen ohne viel Vorwissen in eine Zelle gesperrt werden.
- Die Minispiele sollen eher monoton, unfair und nervig sein, ohne zu sehr zu frustrieren, mit der Intention die Spieler*innen vor eine “unfaire” Aufgabe zu stellen (äquivalent zur Unfairness, mit der LGBTIQ* konfrontiert sind).
¶ 5.3 Character & Environment Design
- Charaktere wurden neutral gehalten: Den spielbaren Charakter kann man nicht sehen, der/die Zellengenoss*in soll möglichst neutral wirken.
- Das Environment in der Zelle ist grau und dunkel gehalten, nur eine Halogenlampe mit monotonem Surren sorgt für Licht.
- Optionale Informationsartikel (Brief, Zeitung) sind in der Zelle verteilt, um weitere Informationen über die Thematik LGBTIQ*-Kriminalisierung zur Verfügung zu stellen.
¶ 6. Management und Dokumentation
¶ 6.1 Allgemein/Verwaltung
Wöchentliche Meetings, agiles Arbeiten lose nach Scrum.
Jede Woche wurden Tickets mit notwendigen Aufgaben oder Bugs im Jira erstellt und den Teammitgliedern zugewiesen. Die Zuweisung erfolgte nach Motivation und Aufgabengebiet (siehe oben). Zusätzlich wurden Tickets mit geplanten Ideen für den Backlog erstellt, die beizeiten in einem aktuellen Sprint eingeplant werden konnten. In Jira hätte noch viel mehr Management stattfinden können, aus Zeitgründen haben wir es hauptsächlich zur Ticketverwaltung verwendet.
Dank der Tickets konnte auch im Nachhinein verfolgt werden, wer welche Aufgabe erledigt hat und wie viel Zeit dafür geschätzt und letztendlich aufgewandt wurde.
¶ 6.2 Zeitliche Planung & Assets und Feature List
Siehe Anhang 8.1
¶ 6.3 Stundenaufstellung
| Person | Geplante Stunden | Tatsächliche Stunden |
|---|---|---|
| Florian | 75 | 86 |
| Oskar | 89 | 99 |
| Sebastian | 75 | 90 |
¶ 6.4 Fazit
¶ 6.4.1 Was lief gut
- Meetings und Absprachen
- Regelmäßiger Termin war Mittwochvormittag um 10 Uhr
- Jeder hat sich gut eingebracht und am Spiel partizipiert.
- Tickettracking mit Jira hat die Organisation und das Management vereinfacht.
- Alle gesetzten Ziele wurden mit einzelnen Ausnahmen jede Woche erreicht.
- Die gemeinsame Vision wurde gut umgesetzt.
- Der Scope wurde gut eingehalten, es kam nicht zu Zeitdruck.
¶ 6.4.2 Was könnte nächstes mal besser laufen
Vor allem die Codestruktur ist verbesserungswürdig:
- Viele Dopplungen in der aktuellen Codebasis
- “Player” ist aktuell eine Superklasse, in der der Großteil der Logik steckt. Das sollte verändert werden.
- Robustheit ist aktuell noch nicht gegeben (viele hardcodierte “magic numbers", Strings und Booleans, die an unterschiedlichen Stellen im Code geändert werden und zu schlechter Wartbarkeit führen).
¶ 6.4.3 Welche alten Annahmen haben sich verändert und wie
Wir haben unter anderem erwartet, dass das Dialogsystem sehr aufwendig wird. Glücklicherweise wurden wir auf Dialogic 2 hingewiesen, welches sich zu einem essenziellem Godot-Addon für uns entwickelt hat.
Die Implementierung hat somit statt den erwarteten 6 Stunden nur 2 gedauert. Das Installieren und Verwenden des Addons ist sehr intuitiv und ist nur zu empfehlen für dialoglastige Games.
Im Design-Prozess sind wir immer mehr zu einzelnen Minigames übergegangen, um ein Item zu erhalten, statt ein Rätsel-Game zu entwickeln, in dem Items bspw. miteinander kombiniert werden können.
¶ 6.4.4 Ausblick
In Projekt C sind weitere Features geplant:
- Code Base Refactoring für bessere Weiterarbeit sowie ausführlichere Niederschrift zu Arbeitskonventionen in Code und Engine
- Mehr Interaktionen in der Zelle (Tickets aus unserem Backlog). Aktuell ist das Game sehr linear.
- Das Ende erweitern: Der Schlüssel, den man aktuell früh erhält, sollte noch nicht direkt die Tür öffnen oder erst später gefunden werden.
- Hinzufügen von weiteren NPCs, Integration der Rätsel und Umgebung in den Ansatz einer Geschichte, die abstrahiert Kriminalisierung von LGBTIQ* vertieft darstellen soll
- Einbindung der Kontext-Elemente (Zeitung, Brief) in aktives Gameplay
¶ 7. Quellenangaben und Abbildungen
¶ 7.1 Assets
¶ 7.1.1 Game Assets
Mouse UI Icon by SmashIcons on https://www.flaticon.com/
¶ 7.1.2 Sounds
Fabric Rip by fotoshop on Pixabay
¶ 7.2 Abbildungen/Links
¶ 8. Anhang
¶ 8.1 Zeitliche Planung & Assets und Feature List
¶ Bereich |
¶ Aufgaben |
¶ Erwarteter Zeitaufwand |
¶ Tatsächlicher Zeitaufwand |
¶ Priorität |
¶ Zuweisung |
¶ Arbeitsfortschritt |
| Programmierung | Toilet Minigame | 6 | 12 | Hoch | Florian | Fertig |
| Programmierung | Knife Cut Minigame | 8 | 15 | Hoch | Florian | Fertig |
| Programmierung | Inventar System | 5 | 5 | Hoch | Florian | Fertig |
| Programmierung | Interaktionssystem | 6 | 6 | Hoch | Florian | Fertig |
| Implementation | Dialog System | 8 | 2 | Hoch | Florian | Fertig |
| Programmierung | Item in Hand rendern | 4 | 5 | Hoch | Florian | Fertig |
| Programmierung | First Person Movement | 2 | 3 | Hoch | Florian | Fertig |
| Implementation | Level Blockout | 4 | 3 | Hoch | Florian | Fertig |
| Story / Dialoge | Dialoge geschrieben | 2 | 3 | Mittel | Florian | Fertig |
| Story | Hintergrund Story | 2 | 2 | Mittel | Florian | Fertig |
| UI | Icons eingefügt | 3 | 5 | Mittel | Florian | Fertig |
| Art | Erstellung und Texturierung verschiedener 3D-Assets: Insasse, Betten, Bettwäsche, Toilette, Zeitung, Brief, Schreibtisch mit Lampe und Hocker, Zellengitter und Zellentür, Deckenlampe, Handitems (Metallstück, Schlüssel) | 22 | 30,5 | Hoch | Oskar | Fertig |
| Art | Texturen für Wand, Boden und Decke | 3 | 2,5 | Hoch | Oskar | Fertig |
| UI | Dialogbox Styling | 1 | 1 | Mittel | Oskar | Fertig |
| UI | 2D Icons für Handitems | 3 | 3 | Mittel | Oskar | Fertig |
| UI / Programmierung | Globales Einstellungsmenü | 3 | 5 | Mittel | Oskar | Fertig |
| Design | Simple Konzeptskizzen für Insassendesign sowie Grundriss des Level Layouts | 4 | 5 | Mittel | Oskar | Fertig |
| Design / Implementation / Programmierung | Demo-Ende Konzept + Implementation nach Öffnen der Zellentür | 9 | 7 | Hoch | Oskar | Fertig |
| Implementation | Willkommensdialoge einbauen | 2 | 1 | Mittel | Oskar | Fertig |
| Programmierung | Camera-Shader für allgemeinen Look und Fix des Lightings entsprechend | 3 | 2 | Mittel | Oskar | Fertig |
| Bugfixing | Animationsbugs bei Kameraschwenk zu Interactables; Abweichende Rotation der Handitems in Relation zueinander; UI-Skalierung auf mehreren Geräten abweichend; |
3,5 | 6 | Mittel | Oskar | Fertig |
| Bugfixing | Zusammenfassung für Bugfixes, die außerhalb der dokumentierten Arbeit, jedoch zusätzlich angefallen sind, welche vom Umfang aber nicht ausreichend waren, um ihnen eigene Positionen zuzuordnen | 6 | 6 | Mittel | Oskar | Fertig |
| Dokumentation | Itch Page | 1,5 | 1,5 | Mittel | Oskar | In Bearbeitung |
| Dokumentation | Wöchentliche Sprint-Meetings im losen SCRUM-Arbeitsablauf mit Dokumentationsaufwand im Ticketsystem inklusive zusätzlichem Zeitaufwand für Absprachen unter der Woche | 25 | 25 | Oskar, Sebastian, Florian | ||
| Sonstiges | Buildtests für Web, Windows und Linux | 3 | 3,5 | Mittel | Oskar | Fertig |
| Ideation | Idee entwickeln und konkretisieren | 3 | 4 | Hoch | Sebastian | Fertig |
| Moodboard | Visual Style festlegen | 4 | 3,5 | Hoch | Sebastian | Fertig |
| Dokumentation | Erstellen einer Übersicht über alle benötigten Assets inklusive Priorität, Zuständigkeit und dem Arbeitsaufwand | 2 | 3,5 | Hoch | Sebastian | Fertig |
| Dialoge, Rätsel | Dialogoptionen, Interaktionen | 5,5 | 8 | Hoch | Sebastian | Fertig |
| UI | Interaktionsboxen, Menüs, Inventar | 13 | 14,8 | Hoch | Sebastian | Fertig |
| Assets | Waschbecken | 1 | 1,5 | Hoch | Sebastian | Fertig |
| Sounds | Hintergrund, diverses auditives Feedback | 5,5 | 6,5 | Hoch | Sebastian | Fertig |
| Implementierung | Anwendung der Dialoge und Funktionalität der Menüs in der Engine implementieren | 6,5 | 6,2 | Hoch | Sebastian | Fertig |
| Programmierung | Entwicklung eines Minispiels, das beim Interagieren mit der Tür auftaucht. Umfasst auch die nachträgliche leichte Handhabung der Variablen zur Einstellung der Schwierigkeit | 5 | 9,2 | Mittel | Sebastian | Fertig |
| Programmierung | Bugfixes, Refaktorieren | 2 | 4 | Mittel | Sebastian | Fertig |
| Dokumentation | Erstellung, Überarbeitung GDD | 2 | 4 | Hoch | Sebastian | Fertig |