From 0eae8cfec1235152da27e3dceb4a7389021f71e0 Mon Sep 17 00:00:00 2001 From: Steven Hernandez Date: Thu, 22 Oct 2026 15:44:24 +0200 Subject: [PATCH 1/3] Neuer Bereich Level-Design: Orientierung & Exploration (LRN-27) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 14 Module in vier Tracks, 180 Übungen (choice 28, order 13, output 36, gap 14, bug 29, explain 24, practice 36), 48 Interview-Karten, vier Projekte mit Abschlussprojekt, 56 Glossarbegriffe, Spickzettel und Berufsseite. content:check ohne Hinweis, verify mit 31 Prüfungen. - Unterwegs (10 Module, place: unterwegs): Level lesen (Absicht, Hinweis, Verhalten), Blickführung in der Draufsicht, Wege, Landmarken und Sichtlinien, Maßstab und Dichte, Möglichkeiten einführen und variieren, Rhythmus, Umgebung als Information, Absicht und Skizze, Playtests beobachten, Überarbeiten. Analyse veröffentlichter Spiele, Skizzen auf Papier, Rasterkarten als text-Blöcke (höchstens 34 Zeichen breit) und kleine Python-Modelle, die im Browser laufen. - Am PC (4 Module, place: pc): Blockout in Godot mit Platzhalter-Tiles und getrennten Ebenen, Playtest mit Wegschreiber (CSV nach user://, Line2D-Spur, Zonen-Log, Übersichtsbild), Ausgestaltung mit Regressionstest, Werkstatt mit eigenem Abschnitt. Jedes Skript und jede zitierte Ausgabe stammt aus einem Lauf mit Godot 4.7.2 headless. - KI-Regel: Skripte und Projektgerüst darf eine KI liefern; Layouts, Orte, Hinweise und jede Designentscheidung bleiben beim Lernenden. Keine fertigen Orte, Begegnungen oder Handlungsideen für Project Delicate Flower; Beispiele sind veröffentlichte Spiele mit Quelle oder neutrale Lehrbeispiele. - Blockout und Ausgestaltung sind getrennt: Ausgestaltung erst nach einem bestandenen Test, eigene Ebene ohne Kollision, danach derselbe Test mit neuen Testern. Fertige Pixelart ist keine Voraussetzung. - Verweise statt Wiederholung: TileSet, Kollision, Export und Pixelraster im Godot-Kurs, Kacheln und Lesbarkeit im Pixelart-Kurs, Erzählen über die Umgebung und Playtest-Grundlagen in Erzählhandwerk, Kampfräume in Combat. Klang als Hinweis nur als Übergabesatz an den späteren Sound-Kurs. - Quellen: The Level Design Book, Lynch, Totten, Dan Taylor, Burgess (Skyrim-Kits), Valve (Booth, Ambinder, Portal-Post-Mortem, Mitchell), Hayashida/Nutt, Norman, NN/g, Iwata Asks, Godot-4.7-Doku. 157 URLs mit pnpm links geprüft. - Farbe #8EE06B, order 15. Co-Authored-By: Claude Opus 5.5 --- content/level-design/area.yaml | 35 + content/level-design/career.md | 87 +++ content/level-design/cheatsheet.md | 176 +++++ content/level-design/glossary.yaml | 113 ++++ content/level-design/interview.yaml | 334 ++++++++++ .../level-design/modules/absicht-skizze.yaml | 539 ++++++++++++++++ .../level-design/modules/ausgestaltung.yaml | 505 +++++++++++++++ .../level-design/modules/blickfuehrung.yaml | 495 ++++++++++++++ content/level-design/modules/blockout.yaml | 558 ++++++++++++++++ .../modules/einfuehren-variieren.yaml | 459 +++++++++++++ .../level-design/modules/massstab-dichte.yaml | 549 ++++++++++++++++ .../level-design/modules/orientierung.yaml | 478 ++++++++++++++ .../level-design/modules/playtest-godot.yaml | 602 ++++++++++++++++++ .../modules/playtest-methode.yaml | 507 +++++++++++++++ content/level-design/modules/raum-lesen.yaml | 443 +++++++++++++ content/level-design/modules/rhythmus.yaml | 495 ++++++++++++++ .../level-design/modules/ueberarbeiten.yaml | 436 +++++++++++++ .../modules/umgebung-informiert.yaml | 485 ++++++++++++++ .../modules/werkstatt-abschnitt.yaml | 475 ++++++++++++++ content/level-design/projects.yaml | 253 ++++++++ 20 files changed, 8024 insertions(+) create mode 100644 content/level-design/area.yaml create mode 100644 content/level-design/career.md create mode 100644 content/level-design/cheatsheet.md create mode 100644 content/level-design/glossary.yaml create mode 100644 content/level-design/interview.yaml create mode 100644 content/level-design/modules/absicht-skizze.yaml create mode 100644 content/level-design/modules/ausgestaltung.yaml create mode 100644 content/level-design/modules/blickfuehrung.yaml create mode 100644 content/level-design/modules/blockout.yaml create mode 100644 content/level-design/modules/einfuehren-variieren.yaml create mode 100644 content/level-design/modules/massstab-dichte.yaml create mode 100644 content/level-design/modules/orientierung.yaml create mode 100644 content/level-design/modules/playtest-godot.yaml create mode 100644 content/level-design/modules/playtest-methode.yaml create mode 100644 content/level-design/modules/raum-lesen.yaml create mode 100644 content/level-design/modules/rhythmus.yaml create mode 100644 content/level-design/modules/ueberarbeiten.yaml create mode 100644 content/level-design/modules/umgebung-informiert.yaml create mode 100644 content/level-design/modules/werkstatt-abschnitt.yaml create mode 100644 content/level-design/projects.yaml diff --git a/content/level-design/area.yaml b/content/level-design/area.yaml new file mode 100644 index 0000000..7190621 --- /dev/null +++ b/content/level-design/area.yaml @@ -0,0 +1,35 @@ +id: level-design +title: "Level-Design: Orientierung & Exploration" +short: Level-Design +tagline: Kleine begehbare Räume, in denen Spieler finden, was du ihnen zeigen willst. +description: > + Komposition und Blickführung in der Draufsicht, Wege, Landmarken und Sichtlinien, Maßstab und + Freiflächen, Einführung und Variation von Möglichkeiten, Rhythmus, Umgebung als Information, + Blockout mit einfachen Formen und Playtests, in denen du zusiehst statt zu erklären. Du lernst an + veröffentlichten Spielen und an eigenen kurzen Abschnitten. Jedes Layout, jeder Ort und jede + Entscheidung ist deine; eine KI darf Skripte und Projektgerüst liefern, aber keine Level oder Karten. + Module mit der Marke „Unterwegs“ gehen ganz am Handy, Skizzen auf Papier inklusive. „Am PC“ braucht + Godot 4 am Rechner; lesen kannst du diese Lektionen auch unterwegs. +color: "#8EE06B" +order: 15 +outcomes: + - Du **liest Level veröffentlichter Spiele**, trennst Gesehenes von Gedeutetem und beschreibst Absicht, Hinweise und Spielerverhalten eines Abschnitts. + - Du lenkst den Blick in der **Draufsicht** mit Kontrast, Rahmung, Linien und Bildausschnitt und rechnest aus, was ein Bildschirm zeigt. + - Du baust **Orientierung** aus Wegen, Kanten, Knoten, Bereichen und Landmarken, setzt Sichtlinien und Schleifen bewusst und erkennst, wo sich Spieler unbeabsichtigt verlaufen. + - Du legst **Maßstab und Dichte** aus den Werten deiner Spielfigur fest und nutzt Enge und Weite, Freiflächen und Rhythmus für deine Absicht. + - Du **führst Möglichkeiten ein**, lässt sie sicher erproben und variierst sie, und du nutzt die Umgebung als Information, ohne jeden Schritt zu markieren. + - Du baust einen **Blockout** in Godot mit Platzhalter-Tiles und getrennten Ebenen und hältst ihn getrennt von der späteren Ausgestaltung. + - Du **beobachtest Playtests**, ohne zu erklären, zeichnest Wege auf, vergleichst sie mit deiner Absicht und überarbeitest gezielt eine Stelle nach der anderen. +tracks: + - title: Räume lesen + description: Ein Level als Absicht, Hinweis und Verhalten lesen, Blickführung in der Draufsicht, Orientierung mit Landmarken und Sichtlinien, Maßstab und Dichte. + modules: [raum-lesen, blickfuehrung, orientierung, massstab-dichte] + - title: Spielen lassen + description: Möglichkeiten einführen und variieren, einen Rhythmus aus Bewegung, Beobachtung, Entdeckung und Begegnung bauen, die Umgebung informieren und erzählen lassen. + modules: [einfuehren-variieren, rhythmus, umgebung-informiert] + - title: Planen, bauen, beobachten + description: Absicht notieren und auf Papier skizzieren, am PC einen Blockout in Godot bauen, Playtests planen, durchführen und Wege aufzeichnen. + modules: [absicht-skizze, blockout, playtest-methode, playtest-godot] + - title: Überarbeiten und ausgestalten + description: Aus Beobachtungen Änderungen ableiten, den getesteten Blockout ausgestalten, ohne Hinweise zu verlieren, und zum Schluss einen eigenen Abschnitt vollständig durchlaufen. + modules: [ueberarbeiten, ausgestaltung, werkstatt-abschnitt] diff --git a/content/level-design/career.md b/content/level-design/career.md new file mode 100644 index 0000000..a670bb5 --- /dev/null +++ b/content/level-design/career.md @@ -0,0 +1,87 @@ +## Level-Design im Beruf + +Level-Design ist die Arbeit an den Räumen, durch die sich Spieler bewegen: wo sie hingehen, was sie sehen, wann sie etwas Neues lernen und wann sie auf Widerstand treffen. In größeren Studios ist das eine eigene Rolle neben Game-, Combat-, Narrative- und Technical Design und neben Environment Art. In kleinen Teams und bei Solo-Projekten macht es dieselbe Person, die auch den Rest des Spiels entwirft. + +Für dich ist der Anlass dein eigenes Spiel. Diese Seite zeigt trotzdem, wie die Arbeit in Studios aussieht und welche Fähigkeiten dort gefragt sind. Das hilft auch ohne Bewerbung: Wer weiß, woran Studios einen Level Designer messen, weiß, worauf er beim eigenen Abschnitt achten sollte. Die Zitate aus Stellenanzeigen stammen aus Anzeigen, die im Oktober 2026 online waren. Diese Seite ist keine Arbeitsmarktstudie. + +## Rollen und Jobtitel + +Titel bedeuten in jedem Studio etwas anderes. Lies die Aufgaben, nicht nur die Überschrift. + +| Rolle | Typische Titel | Alltag | +| --- | --- | --- | +| Level Design | Level Designer, Game/Level Designer | Abschnitte von der Idee über den Blockout bis zur fertigen Fassung verantworten, testen, überarbeiten | +| World Design | World Designer, Open World Designer | große Gebiete, Wege zwischen Orten, Landmarken und Orientierung über lange Strecken | +| Mission und Quest Design | Mission Designer, Quest Designer | Abläufe und Ziele innerhalb von Räumen, oft mit Skripten | +| Technical Level Design | Technical Level Designer | Skripte, Auslöser und Werkzeuge im Editor, damit Level funktionieren | +| Environment Art | Environment Artist | den Blockout ausgestalten, ohne Spielfluss und Hinweise zu zerstören | + +Die letzte Zeile gehört nicht zum Level-Design, aber eng daneben. Das Level Design Book beschreibt Environment Art als „the cosmetic decoration of a level or game world, while preserving its core functionality and gameplay“ und hält fest, dass Artists in der Regel „wait for a mature blockout before beginning an art pass“ ([Environment art](https://book.leveldesignbook.com/process/env-art)). Die Grenze zwischen Blockout und Ausgestaltung, die dieser Kurs zieht, ist also auch eine Grenze zwischen zwei Berufen. + +## Was Studios erwarten + +Die Anzeigen wiederholen sich in wenigen Punkten. Zwei Beispiele: + +- **KAIKO, Frankfurt am Main**, „Game Designer / Level Designer“: „Create whitebox/blockout levels for rapid prototyping and playtesting.“ – „Ensure strong pacing, composition, player guidance, and flow throughout levels.“ – „Take ownership of levels through the full production pipeline (concept -> blockout -> art -> final).“ ([DEVjobs.de](https://devjobs.de/job/057858f1b855dc9f6286960843cf3c5d)) +- **2K**, „Senior Level Designer“: „Create playable blockouts (greyboxing) of large-scale open zones, focusing on landmark readability, navigation flow, and gameplay spaces“ – „Quickly iterate on level layouts based on playtest feedback, moving efficiently from low-fidelity blockouts to final geometry without losing the core experience“ ([Hitmarker](https://hitmarker.net/jobs/2k-senior-level-designer-1645113)) + +Daraus lassen sich vier Erwartungen lesen, und alle vier übst du in diesem Kurs: + +- **Blockout zuerst.** Beide Anzeigen nennen Blockout oder Greybox als eigenen Schritt vor der Grafik ([Blockout in Godot](/level-design/blockout)). +- **Führung und Orientierung.** „player guidance“, „landmark readability“, „navigation flow“ sind die Inhalte von [Blickführung](/level-design/blickfuehrung) und [Orientierung](/level-design/orientierung). +- **Rhythmus und Komposition.** „pacing, composition“ entsprechen [Rhythmus](/level-design/rhythmus) und der Komposition in der Draufsicht. +- **Iterieren nach Playtests.** Beide verlangen, nach Tests zu überarbeiten, ohne den Kern zu verlieren ([Überarbeiten](/level-design/ueberarbeiten)). + +Dazu kommt die Arbeit im Editor der Engine, mit der das Studio baut. Was du in diesem Kurs lernst, hängt nicht an Godot: Blockout, Maße, Tests und Protokoll gehen in jedem Editor gleich. + +## Designtests und Gespräche + +Manche Studios schicken für Design-Stellen einen Test. Für Level-Design kann das heißen: einen kleinen Abschnitt in einer vorgegebenen Engine bauen und dokumentieren, in wenigen Tagen. Bewertet wird selten, ob der Raum schön ist, sondern wie du denkst. Wenn du einen bekommst: + +- **Kläre den Rahmen.** Was wird bewertet, wie viel Zeit ist vorgesehen, darf es ein Blockout bleiben? +- **Schreib die Absicht auf.** Ein Satz pro Abschnitt, dazu der erwartete Weg und woran man sieht, ob er gelingt ([Absicht und Skizze](/level-design/absicht-skizze)). +- **Zeig eine Draufsicht mit Anmerkungen.** Erwarteter Weg, Hinweise, Begegnungen, Maße in Einheiten des Spiels. +- **Belege mindestens einen Test.** Auch ein Test mit zwei Personen aus dem Bekanntenkreis zeigt, dass du beobachtest statt rätst. Schreib ehrlich hin, was nicht aufging. + +Im Gespräch fragen Designer gern nach einer Stelle, an der ein Test dich überrascht hat, wie du mit Rückmeldung wie „mach das rot“ umgehst und wie du einem Artist erklärst, welche Hinweise die Ausgestaltung nicht verdecken darf. Die Interview-Karten dieses Bereichs üben solche Antworten. + +## Portfolio: was zählt + +- **Vorher und nachher.** Blockout und fertige Fassung, oder Runde 1 und Runde 2 desselben Abschnitts, mit dem Grund für die Änderung. +- **Die Draufsicht mit Weg.** Eine Karte mit erwartetem Weg und aufgezeichneten Wegen von Testern sagt mehr als zehn Screenshots. +- **Die Absicht.** Ein Satz pro Abschnitt zeigt, dass du weißt, was du baust. +- **Ein kurzes Video.** Höchstens zwei Minuten, der Abschnitt einmal durchgespielt. +- **Analyse fremder Level.** Eine gründliche Analyse eines veröffentlichten Abschnitts zeigt, dass du Level lesen kannst ([Projekt Analyse](/level-design/projekte/analyse-abschnitt)). + +Ein Portfolio mit einem gut dokumentierten Abschnitt ist mehr wert als eines mit vielen schönen Bildern ohne Erklärung. Das [Abschlussprojekt](/level-design/projekte/abschluss-abschnitt) ist genau so geschnitten. + +## Lernplan in Wochen + +Der Plan rechnet mit einem Unterwegs-Modul pro Woche (etwa anderthalb Stunden auf dem Handy, mit Übungen) und drei bis vier Stunden am PC. PC-Arbeit kommt erst, wenn die Module davor gelesen sind, auf denen sie aufbaut. + +- **Woche 1** · unterwegs: [Level lesen](/level-design/raum-lesen) · am PC: Godot-Grundlagen, falls noch nicht da ([2D-Level aus Tiles](/godot/level-tilemap)) +- **Woche 2** · unterwegs: [Blickführung](/level-design/blickfuehrung) · am PC: Godot-Grundlagen +- **Woche 3** · unterwegs: [Orientierung](/level-design/orientierung) · am PC: – +- **Woche 4** · unterwegs: [Maßstab und Dichte](/level-design/massstab-dichte) · am PC: – +- **Woche 5** · unterwegs: [Möglichkeiten einführen](/level-design/einfuehren-variieren) · am PC: – +- **Woche 6** · unterwegs: [Rhythmus](/level-design/rhythmus) · am PC: [Analyse eines Abschnitts](/level-design/projekte/analyse-abschnitt), Abschnitt wählen und skizzieren +- **Woche 7** · unterwegs: [Umgebung als Information](/level-design/umgebung-informiert) · am PC: Analyse ausarbeiten +- **Woche 8** · unterwegs: [Absicht und Skizze](/level-design/absicht-skizze) · am PC: [Blockout in Godot](/level-design/blockout) +- **Woche 9** · unterwegs: [Playtests beobachten](/level-design/playtest-methode) · am PC: [Maßstabsraum und Baukasten](/level-design/projekte/massstab-baukasten) +- **Woche 10** · unterwegs: [Überarbeiten](/level-design/ueberarbeiten) · am PC: [Playtest am PC](/level-design/playtest-godot) +- **Woche 11** · unterwegs: Karten wiederholen · am PC: [Einführung testen](/level-design/projekte/einfuehrung-testen), Folge planen und bauen +- **Woche 12** · unterwegs: Tester anfragen, Notizen auswerten · am PC: Einführung testen, zwei Runden +- **Woche 13** · unterwegs: Karten wiederholen · am PC: [Ausgestaltung](/level-design/ausgestaltung) +- **Woche 14–19** · unterwegs: Karten, Tester anfragen, Notizen auswerten · am PC: [Werkstatt](/level-design/werkstatt-abschnitt) und [Abschlussprojekt](/level-design/projekte/abschluss-abschnitt), etwa vier Stunden pro Woche + +Hast du mehr Zeit am PC, zieh die Projekte vor, sobald ihre Module gelesen sind; die Unterwegs-Module kannst du unabhängig davon im Bus lesen. Für die PC-Module brauchst du die Grundlagen aus dem Godot-Kurs, vor allem [2D-Level aus Tiles](/godot/level-tilemap). + +## Ressourcen + +- [The Level Design Book](https://book.leveldesignbook.com/) von Robert Yang und anderen: frei, aktuell, mit Seiten zu Blockout, Maßen, Orientierung, Rhythmus und Playtests. +- Christopher W. Totten, [An Architectural Approach to Level Design](https://www.routledge.com/An-Architectural-Approach-to-Level-Design-Second-edition/Totten/p/book/9780815361367), 2. Auflage 2019. +- Dan Taylor, [Ten Principles of Good Level Design](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-), Game Developer 2013, und der [Vortrag auf YouTube](https://www.youtube.com/watch?v=iNEe3KhMvXM). +- Steve Lee, [An Approach to Holistic Level Design](https://www.youtube.com/watch?v=CpOoTAVeEcU), GDC 2017. +- Valve, [Publikationen](https://www.valvesoftware.com/en/publications) mit den Folien zu Playtests (2009), Portal (2008) und Left 4 Dead (2009). +- Tracy Fullerton, [Game Design Workshop](https://www.routledge.com/Game-Design-Workshop-A-Playcentric-Approach-to-Creating-Innovative-Games/Fullerton/p/book/9781032607009), 5. Auflage 2024, für Playtests im ganzen Entwurfsprozess. +- Godot-Doku: [Using TileMaps](https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html) und [Camera2D](https://docs.godotengine.org/en/stable/classes/class_camera2d.html). diff --git a/content/level-design/cheatsheet.md b/content/level-design/cheatsheet.md new file mode 100644 index 0000000..b9cedcf --- /dev/null +++ b/content/level-design/cheatsheet.md @@ -0,0 +1,176 @@ +## Grundmodell + +| Ebene | Wo | Was du tust | +| --- | --- | --- | +| Absicht | Notiz, ein Satz | vorher festlegen | +| Hinweis | Raum | bauen, ändern | +| Verhalten | Spieler | beobachten, notieren | + +Prüfsatz für Notizen: Könnte eine Kamera das aufnehmen? Wenn nein, ist es Deutung. + +## Absichtsnotiz + +```text +Abschnitt: +Absicht (ein Satz): + Der Spieler soll … +Erwarteter Weg: +Hinweise (wo, was, wofür): +Zeichen, dass es klappt: +Zeichen, dass es scheitert: +``` + +## Rasterkarte + +| Zeichen | Bedeutung | +| --- | --- | +| `#` | Wand, Fels: blockiert Weg und Sicht | +| `.` | Boden | +| `o` | niedriges Hindernis: blockiert Weg, nicht Sicht | +| `~` | Wasser, Abgrund: blockiert Weg, nicht Sicht | +| `+` | Durchgang, Tür | +| `S` `A` | Start, Ausgang | +| `L` `*` `B` `!` | Landmarke, Fundstück, Begegnung, Hinweis | +| `1`–`9` | Wegpunkte | + +## Bildschirm in Tiles + +| Spielbild | Tile | Tiles quer × hoch | +| --- | --- | --- | +| 320 × 180 | 16 | 20 × 11,25 | +| 384 × 216 | 16 | 24 × 13,5 | +| 480 × 270 | 16 | 30 × 16,9 | +| 640 × 360 | 16 | 40 × 22,5 | +| 640 × 360 | 32 | 20 × 11,25 | + +Karopapier: ein Kästchen = ein Tile, Rahmen 20 × 11 = ein Bildschirm bei 320 × 180 und 16 px. + +## Zeit und Weg bei 90 px/s (Platzhalter) + +| Strecke | Pixel | Sekunden | +| --- | --- | --- | +| 1 Tile | 16 | 0,18 | +| 2 Tiles | 32 | 0,36 | +| Ausweichen (Platzhalter) | 66 | 0,73 | +| halber Bildschirm hoch | 90 | 1,0 | +| halber Bildschirm quer | 160 | 1,8 | +| Bildschirm quer | 320 | 3,6 | +| drei Bildschirme quer | 960 | 10,7 | + +`Sekunden = Pixel / Tempo` · `Tiles = Pixel / Tilegröße` · Vorlauf bei Kamera in der Mitte: halbe Bildbreite bzw. -höhe. + +## Blickführung + +| Mittel | Wirkt durch | Vorsicht | +| --- | --- | --- | +| Tonwertkontrast | hell gegen dunkel | stärker als Farbe allein | +| Farbe, Sättigung | einzelner Akzent | viele Akzente heben sich auf | +| Licht | „Players tend to follow the light“ (Valve) | Licht am falschen Ort führt falsch | +| Bewegung | zieht sofort | Dauerbewegung wird Rauschen | +| Linien | Wege, Kanten, Zäune, Flüsse | zeigen auch weg vom Ziel | +| Rahmung | Öffnung um das Ziel | Rahmen nicht lauter als Ziel | + +Ein Hauptpunkt, wenige Nebenpunkte, viel Ruhe. Unschärfetest: Bildschirmfoto verwischen, was sticht noch hervor? + +## Orientierung nach Lynch + +| Element | Im Top-down-Spiel | Prüffrage | +| --- | --- | --- | +| Weg | Pfad, Gang, Brücke | Wohin führt er sichtbar? | +| Kante | Mauer, Fluss, Abgrund | Woran entlang orientiere ich mich? | +| Bereich | Gebiet mit eigener Gestalt | Weiß ich, wo ich bin? | +| Knoten | Kreuzung, Platz, Hub | Erkenne ich ihn wieder? | +| Landmarke | einzigartiger Bezugspunkt | Ist sie im Bild oder gemerkt? | + +Sichtlinie in der Draufsicht = Bildausschnitt + hohe Verdecker und Dächer + Licht und Dunkel. + +## Hilfen nach Sicherheit (Level Design Book) + +| Stufe | geschätzt | Beispiele | +| --- | --- | --- | +| subtil | 1–20 % | Anspielung auf bekannte Orte, Baumuster der Welt | +| grob | 35–60 % | Komposition, Sichtlinien, Landmarke in der Ferne, Licht, Farbe | +| situativ | 70–93 % | Figur, die vorausgeht, Spur aus Fundstücken, bewachter Ausgang | +| direkt | 95–98 % | tiefe, breite Barrieren, Zielmarker im HUD | + +„start at the top, and gradually incorporate less subtle methods in response to playtesting“ + +## Möglichkeiten einführen + +| Schritt | Kishōtenketsu (Hayashida) | Teach, Test, Twist | +| --- | --- | --- | +| 1 | einführen, sicher erproben | Teach | +| 2 | entwickeln | Test | +| 3 | wenden | Twist | +| 4 | abschließen | – | + +Pro Raum höchstens eine Neuheit. „Players Learn Better When Not Stressed.“ (Valve, Portal) + +## Rhythmus (Left 4 Dead, AI Director) + +| Phase | Was passiert | +| --- | --- | +| Build Up | Bedrohung bis zur Spitze | +| Sustain Peak | Spitze 3–5 s halten | +| Peak Fade | auf Minimum zurück | +| Relax | 30–45 s Ruhe, dann neu | + +Tätigkeiten im Wechsel: Bewegung · Beobachtung · Entdeckung · Begegnung. Vor großen Begegnungen ein Ort mit Überblick. + +## Vier Arten, einen Hinweis zu verfehlen + +| Art | Beleg im Protokoll | Hebel | +| --- | --- | --- | +| nicht bemerkt | kein Halt, kein Wort | Lage im Bild, Kontrast, Konkurrenz weg | +| falsch gelesen | geht hin, deutet anders | Form, visuelle Sprache, Zustand | +| nicht befolgt | sieht, entscheidet anders | Kosten, Belohnung zeigen, Reihenfolge | +| unbeabsichtigte Folge | Weg weicht ab | Kante, Kollision, Breite | + +Eine Änderung pro Runde, Erwartung vorher, frische Tester. + +## Iterationsprotokoll: eine Runde + +```text +Runde · Tester (neu?) +Stelle: +Gesehen: n von m … +Art: +Änderung: (genau eine) +Erwartung: (zählbar) +Ergebnis: (nach dem Test) +``` + +## Playtest + +| Tu das | Lass das | +| --- | --- | +| nur Steuerung erklären | Ziel oder Weg verraten | +| Weg, Halt, Umkehr, Blickrichtung notieren | Deutung als Beobachtung notieren | +| Fragen zurückgeben („Was denkst du?“) | helfen, entschuldigen, erklären | +| Eingriffe mit Zeit vermerken | still eingreifen | +| neue Tester je Runde | dieselben Tester für „wird es bemerkt?“ | +| keine Namen in Notizen | Wegdateien mit Namen | + +## Blockout und Ausgestaltung in Godot + +| Reihenfolge im Szenenbaum | Inhalt | Kollision | +| --- | --- | --- | +| `Ground` | Blockout-Boden | nein | +| `Dressing` | Ausgestaltung, erst nach getestetem Blockout | nein (`collision_enabled = false`) | +| `Cues` | beabsichtigte Hinweise, über der Grafik | nein | +| `Objects` → `Walls` | Wände des Blockouts, nach der Ausgestaltung unsichtbar | ja | +| `Objects` → `DressingHigh` | hohe Teile, y-sortiert mit der Figur | nein | + +Weiter unten im Szenen-Dock = weiter oben im Bild (`z_index` bei 0 lassen). Kollision folgt dem Blockout, nicht der Grafik. Nach der Ausgestaltung: derselbe Test mit neuen Testern. + +Blockout-Vokabel: je eine Tile für begehbar, blockiert hoch, blockiert tief, gefährlich, benutzbar, Hinweis – flache Tonwerte, wo nötig mit Formmarke. + +| Aufgabe | Godot 4.7 | +| --- | --- | +| Pixel → Zelle | `local_to_map(to_local(global_position))` | +| Zelle → Mitte der Zelle | `map_to_local(zelle)` | +| bemalte Fläche | `get_used_rect()` | +| Kamera begrenzen | `Camera2D.limit_left`, `limit_top`, `limit_right`, `limit_bottom` | +| Spur zeichnen | `Line2D.add_point(position)` | +| Datei für Wege | `FileAccess.open("user://…", FileAccess.WRITE)`, `store_line()` | +| Ebene ausblenden | `visible = false` (nur Bild, Kollision bleibt) · `enabled = false` (Bild und Kollision) | diff --git a/content/level-design/glossary.yaml b/content/level-design/glossary.yaml new file mode 100644 index 0000000..6fd154f --- /dev/null +++ b/content/level-design/glossary.yaml @@ -0,0 +1,113 @@ +terms: + - term: Absicht + definition: Was der Spieler an einer Stelle tun, bemerken oder verstehen soll, als ein Satz notiert. Sie steht in keinem Spiel, sondern in deiner Notiz, und lässt sich nur über Verhalten prüfen. + - term: Absichtsnotiz + definition: Die feste Vorlage dieses Kurses für einen Abschnitt – Abschnitt, Absicht in einem Satz, erwarteter Weg, Hinweise, Zeichen für Erfolg und Scheitern. Du schreibst sie vor dem Bauen. + - term: Hinweis + definition: Alles im Raum, das Blick oder Weg lenken soll – Licht, Kontrast, Form, Weg, Öffnung, Landmarke, Bewegung. Englisch oft „cue“. Der einzige Teil des Grundmodells, den du direkt gestaltest. + - term: Verhalten + definition: Was Spieler tatsächlich tun – Weg, Halt, Umkehr, Blickrichtung, Gesagtes. Wird beobachtet und notiert, nicht gedeutet. + - term: Draufsicht + definition: Kamera über dem Spielfeld, ohne Horizont, englisch „top-down“. Was der Spieler sieht, begrenzt der Bildschirm. Viele Spiele zeichnen dabei eine 3/4-Ansicht. + - term: 3/4-Ansicht + definition: Darstellung, bei der Wände und Figuren von vorn, Böden und Dächer von oben zu sehen sind. Hohe Objekte verdecken, was hinter ihnen liegt, auch innerhalb des Bildausschnitts. + - term: Bildausschnitt + definition: Der Teil der Welt, den die Kamera gerade zeigt. Bei 320 × 180 Pixeln und 16-Pixel-Tiles sind es 20 × 11 volle Tiles. + - term: Critical Path + definition: Der beabsichtigte Hauptweg durch ein Level, auch „golden path“. Das Level Design Book betont, dass die meisten Spieler davon abweichen, trödeln oder sich verirren. + - term: Flow + definition: Wie sich Spieler durch ein Level bewegen. Guter Flow ist laut Level Design Book der, der die beabsichtigte Erfahrung unterstützt, nicht ein bestimmtes Muster. + - term: Blickführung + definition: Gestaltung, die bestimmt, wohin der Blick zuerst, zweitens und drittens geht – über Kontrast, Licht, Bewegung, Linien und Rahmung. + - term: Tonwert + definition: Wie hell oder dunkel eine Fläche ist, unabhängig von der Farbe. Tonwertkontrast lenkt den Blick stärker als Farbunterschiede gleicher Helligkeit. + - term: Rahmung + definition: Ein Ziel wird von Wänden, Öffnungen oder Objekten eingefasst, sodass der Blick darauf fällt. + - term: Visuelles Rauschen + definition: Viele gleich laute Details ohne Rangfolge. Hinweise gehen darin unter. + - term: Unschärfetest + definition: Ein Bildschirmfoto verkleinern oder verwischen und prüfen, was dann noch hervorsticht. Schnelle Probe für die Rangfolge eines Bildes, kein Ersatz für einen Playtest. + - term: Wayfinding + definition: Orientierung (wo bin ich?) und Navigation (wie komme ich zum Ziel?) zusammen. Das Level Design Book ordnet Hilfen dafür nach geschätzter Sicherheit von subtil bis direkt. + - term: Weg (Lynch) + definition: Eines der fünf Elemente nach Kevin Lynch – Kanäle, auf denen man sich bewegt, im Spiel etwa Pfade, Gänge, Brücken. + - term: Kante (Lynch) + definition: Eine Grenze, die man nicht oder kaum überquert und an der man sich entlang orientiert, etwa ein Fluss, eine Mauer, ein Abgrund. + - term: Bereich (Lynch) + definition: Ein Gebiet mit eigener, wiedererkennbarer Gestalt. Englisch „district“. Spieler wissen dadurch, in welchem Teil der Welt sie sind. + - term: Knoten (Lynch) + definition: Ein Punkt, an dem sich Wege treffen oder an dem man ankommt, etwa eine Kreuzung oder ein Platz. Englisch „node“, im Spiel oft „hub“. + - term: Landmarke + definition: Ein auffälliger Bezugspunkt, den man nicht betritt, sondern sieht. Gute Landmarken sind einzigartig, sichtbar und bleiben an ihrem Platz. + - term: Mentale Karte + definition: Das Bild eines Gebiets, das sich ein Spieler beim Durchqueren im Kopf baut. Lynch nennt die Eigenschaft eines Ortes, ein starkes Bild hervorzurufen, „imageability“. + - term: Sichtlinie + definition: Was der Spieler von einer Stelle aus sehen kann. In der Draufsicht begrenzen sie Bildrand, hohe Verdecker, Dächer und Dunkelheit. + - term: Brotkrumen + definition: Eine Reihe kleiner Hinweise, die einen Weg nachzeichnen, etwa Fundstücke, Spuren oder Lichter. + - term: Schleife + definition: Ein Weg, der zu einem bekannten Knoten zurückführt, oft mit einer Abkürzung, die erst von der anderen Seite zu öffnen ist. + - term: Metriken + definition: Maße eines Spiels – Größe, Tempo, Ausweichweite der Figur und die daraus abgeleiteten Breiten, Abstände und Flächen. Englisch „metrics“. + - term: Maßstabsraum + definition: Eine Testszene mit Gängen, Durchgängen und Flächen in bekannten Größen, in der du die Metriken deiner Figur ausmisst. Englisch oft „gym“ oder „metrics map“. + - term: Freifläche + definition: Eine große, offene Fläche ohne Hindernisse. Spieler lesen sie oft als Ort für eine Begegnung. + - term: Enge und Weite + definition: Der Wechsel zwischen engen und weiten Räumen. Nach der Enge wirkt die Weite größer; englisch „compression and release“. + - term: Prospect und Refuge + definition: Nach Christopher Totten offene, ungeschützte Flächen (Prospect) und geschützte Orte mit Überblick (Refuge). Das Level Design Book hält das Modell für begrenzt anwendbar. + - term: Kishōtenketsu + definition: Vierteiliger Aufbau aus einführen, entwickeln, wenden, abschließen, den Koichi Hayashida für die Level von Super Mario 3D Land beschreibt. + - term: Teach, Test, Twist + definition: Dreischritt aus dem Level Design Book – eine Möglichkeit zeigen, ihr Verständnis prüfen, sie in einer neuen Lage wenden. + - term: Sichere Erprobung + definition: Eine neue Möglichkeit zuerst dort zeigen, wo ein Fehler wenig kostet, ohne Zeitdruck und mit kurzem Rückweg. + - term: Taktplan + definition: Eine Folge von Takten eines Levels mit Tätigkeit, Dauer und Intensität, englisch oft „beat chart“. Zeigt vor dem Bauen, wo Ruhe und wo Spitzen liegen. + - term: Takt + definition: Ein Abschnitt im Rhythmus eines Levels mit einer vorherrschenden Tätigkeit – Bewegung, Beobachtung, Entdeckung oder Begegnung – und einer Dauer. + - term: Pacing + definition: Reihenfolge und Rhythmus von Tätigkeiten und Ereignissen in einem Level. Im Kurs eingedeutscht als Rhythmus. + - term: AI Director + definition: System in Left 4 Dead, das die Intensität für die Spieler misst und die Gegnerzahl in den Phasen Build Up, Sustain Peak, Peak Fade und Relax steuert. + - term: Affordanz + definition: Was ein Ding oder Ort möglich macht, etwa dass eine Kiste sich schieben lässt. Begriff von J. J. Gibson, in die Gestaltung gebracht von Don Norman. + - term: Signifikant + definition: Das wahrnehmbare Zeichen, das eine Möglichkeit anzeigt. Don Norman schreibt, Design müsse vor allem Signifikanten liefern; englisch „signifier“. + - term: Visuelle Sprache + definition: Feste Zuordnung von Aussehen und Bedeutung in einem Spiel, etwa für begehbar, blockiert, gefährlich und interaktiv. Sie muss überall gelten. + - term: Signposting + definition: Deutliche Markierungen, die Weg oder Möglichkeiten anzeigen, etwa gelbe Farbe an Kletterkanten. Stärker als leise Hinweise, kostet aber das Finden. + - term: Blockout + definition: Ein spielbarer Rohbau eines Levels aus einfachen Formen ohne Ausgestaltung, auch Greybox, Whitebox oder Blockmesh. Billig zu ändern und das, was man testet. + - term: Blockout-Vokabel + definition: Deine Liste, welche Form und welcher Tonwert im Blockout was bedeutet, im Kurs mit sechs Kategorien – begehbar, blockiert hoch, blockiert tief, gefährlich, benutzbar, Hinweis. Sie gilt im ganzen Projekt. + - term: Platzhalter + definition: Ein einfaches Element, das später ersetzt wird – ein flaches Tile, ein graues Rechteck, ein Wert aus dem Kurs statt eines eigenen. + - term: Ausgestaltung + definition: Die Grafik, die einen getesteten Blockout bekleidet, ohne Spielfluss und Hinweise zu verändern. Englisch „set dressing“ oder „art pass“. + - term: Baukasten + definition: Ein Satz zusammenpassender Teile im gleichen Raster, aus dem man Level baut. Joel Burgess beschreibt Kits für Skyrim als Systeme, die mehr ergeben als die Summe ihrer Teile. + - term: TileMapLayer + definition: Godot-Node für eine Ebene aus Tiles. Seit Godot 4.3 nimmt man für Boden, Wände, Hinweise und Ausgestaltung je einen eigenen TileMapLayer. + - term: Playtest + definition: Jemand spielt dein Level, und du siehst zu, ob es wirkt. Das Verhalten zählt mehr als die Rückmeldung. + - term: Blind Playtest + definition: Ein Test mit möglichst wenig Anleitung. Der Tester spielt, als wäre er allein, und du beobachtest, was er tut. + - term: Lautes Denken + definition: Testpersonen sprechen beim Spielen aus, was sie denken. Englisch „thinking aloud“. Ergänzt die Beobachtung, ersetzt sie nicht. + - term: Frischer Tester + definition: Jemand, der den Abschnitt noch nicht kennt. Nur frische Tester zeigen, ob eine Stelle ohne Vorwissen bemerkt wird. + - term: Beobachtungsprotokoll + definition: Notizen aus einem Playtest mit Zeit, Ort, Handlung und Gesagtem, getrennt von der Deutung. + - term: Wegschreiber + definition: Ein kleines Skript, das die Position der Figur in festen Abständen speichert und als Linie zeichnet. Macht Wege mehrerer Tester vergleichbar. + - term: Abbruchregel + definition: Vor dem Playtest festgelegte Bedingung, wann du eingreifst, etwa nach einer bestimmten Zahl Minuten ohne Fortschritt. Jeder Eingriff kommt mit Zeit ins Protokoll. + - term: Hebel + definition: Eine Stelle im Raum, an der du etwas änderst, um eine bestimmte Ursache zu treffen – Lage im Bild, Kontrast, Form, Breite, Reihenfolge, Stärke einer Markierung. + - term: Iterationsprotokoll + definition: Je Runde ein kurzer Block mit Stelle, Beobachtung, Art, Änderung, Erwartung und Ergebnis. + - term: Regressionstest + definition: Derselbe Test nach einer Änderung, die nichts verbessern soll, etwa der Ausgestaltung. Prüft, ob etwas kaputtgegangen ist, das vorher trug. diff --git a/content/level-design/interview.yaml b/content/level-design/interview.yaml new file mode 100644 index 0000000..d350d09 --- /dev/null +++ b/content/level-design/interview.yaml @@ -0,0 +1,334 @@ +cards: + - id: was-ist-level-design + module: raum-lesen + q: Was macht ein Level gut? + a: | + Dass das Verhalten der Spieler zur Absicht passt. Ein Level ist ein Raum mit Absicht: Der Spieler soll an einer Stelle etwas tun, bemerken oder verstehen. Ob das klappt, sehe ich nicht am Entwurf, sondern beim Zusehen. Schön kann er außerdem sein, aber ein schöner Raum, in dem niemand den Ausgang findet, verfehlt seine Absicht. + tags: [grundlagen] + level: 1 + - id: absicht-hinweis-verhalten + module: raum-lesen + q: Was unterscheidet Absicht, Hinweis und Verhalten? + a: | + Die Absicht steht in meiner Notiz, der Hinweis im Raum, das Verhalten beim Spieler. Gestalten kann ich nur die Hinweise, etwa Licht, Wege, Kontrast oder eine Landmarke. Prüfen kann ich nur am Verhalten. Die Lücke zwischen Absicht und Verhalten ist das, woran ich überarbeite. + tags: [grundlagen] + level: 1 + - id: level-analysieren + module: raum-lesen + q: Wie analysierst du ein Level aus einem anderen Spiel? + a: | + Ich spiele die Stelle einmal unvorbereitet und notiere sofort meinen Weg, weil das nur einmal geht. Dann skizziere ich sie im Raster, markiere jeden Hinweis und trenne, was zu sehen war, von dem, was ich daraus schließe. Am Ende steht die vermutete Absicht in einem Satz, und die prüfe ich gegen eine Entwicklerquelle oder den Weg eines zweiten Spielers. + tags: [analyse, methode] + level: 1 + - id: draufsicht-besonderheit + module: raum-lesen + q: Was ist in der Draufsicht anders als in einem Spiel mit Kamera hinter der Figur? + a: | + Es gibt keinen Horizont. Der Spieler sieht nur den Bildschirm, bei 320 × 180 Pixeln und 16-Pixel-Tiles sind das 20 × 11 Tiles. Ferne Landmarken muss er sich merken, statt sie zu sehen. Dazu ist der Blick nach oben und unten im Breitbild kürzer als zur Seite, und hohe Wände verdecken in der 3/4-Ansicht, was dahinter liegt. + tags: [draufsicht] + level: 2 + - id: blick-lenken + module: blickfuehrung + q: Mit welchen Mitteln lenkst du den Blick in einem Raum? + a: | + Vor allem mit Kontrast, und zwar zuerst im Tonwert, dann in Farbe und Sättigung. Dazu kommen Bewegung, Licht, Linien wie Wege und Kanten und Rahmung durch Öffnungen. Wichtig ist die Rangfolge: ein Hauptpunkt, wenige Nebenpunkte, viel Ruhe dazwischen. Wenn alles laut ist, fällt nichts auf. + tags: [blickfuehrung, komposition] + level: 1 + - id: unschaerfetest + module: blickfuehrung + q: Wie prüfst du schnell, ob ein Raum lesbar ist? + a: | + Mit einem Unschärfetest: Ich mache ein Bildschirmfoto, verkleinere oder verwische es und schaue, was dann noch hervorsticht. Bleibt der Ausgang erkennbar und das Wichtigste der hellste oder kontrastreichste Fleck, trägt die Komposition. Verschwimmt alles zu einer Fläche, fehlt die Rangfolge. Ersetzen kann der Test einen Playtest nicht. + tags: [blickfuehrung, lesbarkeit] + level: 2 + - id: licht-fuehrt + module: blickfuehrung + q: Warum folgen Spieler dem Licht? + a: | + Weil Kontrast den Blick zieht und Spieler dorthin gehen, wo sie hinschauen. Valve hat das für Left 4 Dead als Regel notiert: „Players tend to follow the light“. Für mich heißt das: Ein beleuchteter Ausgang in einem dunklen Raum ist ein starker Hinweis. Steht dort aber ein Fundstück statt des Weges, lenkt dasselbe Licht in die falsche Richtung. + tags: [blickfuehrung, licht] + level: 1 + - id: lynch-elemente + module: orientierung + q: Welche Elemente helfen Spielern, sich zu orientieren? + a: | + Ich nutze die fünf Elemente von Kevin Lynch: Wege, Kanten, Bereiche, Knoten und Landmarken. Wege und Kanten ordnen die Bewegung, Bereiche mit eigener Gestalt sagen, wo man ist, Knoten sind Kreuzungen und Treffpunkte, Landmarken sind auffällige Bezugspunkte. In der Draufsicht kommt dazu, dass eine Landmarke im Bild sein muss, um zu wirken, oder sich so einprägen muss, dass man sie wiedererkennt. + tags: [orientierung, lynch] + level: 2 + - id: gute-landmarke + module: orientierung + q: Was macht eine gute Landmarke aus? + a: | + Sie ist einzigartig, gut sichtbar und bleibt an ihrem Platz. Zwei gleiche Brunnen an zwei Kreuzungen sind keine Landmarken, sie verwirren. Ich unterscheide außerdem globale Landmarken, die über weite Strecken Richtung geben, von lokalen, die einen Knoten unverwechselbar machen. + tags: [orientierung, landmarke] + level: 1 + - id: sichtlinie-draufsicht + module: orientierung + q: Was ist eine Sichtlinie in einem Top-down-Spiel? + a: | + Weniger eine Linie durch den Raum als die Frage, was im Bildausschnitt ist und was verdeckt wird. Der Bildrand begrenzt die Sicht, hohe Wände und Dächer verdecken in der 3/4-Ansicht, Dunkelheit verbirgt. Eine Sichtlinie öffne ich, indem ich einen Durchgang so lege, dass das Ziel ins Bild kommt, bevor der Spieler entscheiden muss. + tags: [orientierung, sichtlinie] + level: 2 + - id: verlaufen-gewollt + module: orientierung + q: Ist es schlecht, wenn sich Spieler verlaufen? + a: | + Nicht immer. Erkunden darf Umwege enthalten, und ein Labyrinth darf verwirren, wenn das die Absicht ist. Schlecht ist ungewolltes Verlaufen: Der Spieler kennt sein Ziel, findet keinen Weg und gibt auf. Den Unterschied sehe ich im Test: Wer erkundet, schaut sich um und probiert; wer verloren ist, läuft dieselbe Runde mehrmals und kehrt um. + tags: [orientierung, playtest] + level: 2 + - id: metriken-zuerst + module: massstab-dichte + q: Warum legst du Maße fest, bevor du ein Level baust? + a: | + Weil jeder Raum aus den Werten der Figur folgt: Tempo, Größe, Ausweichweite. Das Level Design Book nennt das „build at the player's scale“. Ich messe die Werte in einem Maßstabsraum aus und leite Regeln ab, etwa eine Mindestbreite für Gänge. Ändert sich das Tempo spät, prüfe ich die Regeln neu, statt jeden Raum nach Gefühl anzupassen. + tags: [metriken, blockout] + level: 2 + - id: gangbreite + module: massstab-dichte + q: Wie breit sollte ein Gang sein? + a: | + So breit, wie die Absicht und die Figur es verlangen. Für Skyrim hat Bethesda als Untergrenze „a minimum of two character widths“ genannt. In einem Top-down-Spiel mit Bewegung in alle Richtungen und Ausweichen prüfe ich zusätzlich, ob die Figur in dem Gang an einem Gegner vorbei- oder ausweichen können soll. Enge Gänge sind erlaubt, wenn ich sie für Spannung oder Kontrast will. + tags: [metriken] + level: 2 + - id: enge-weite + module: massstab-dichte + q: Wozu nutzt du Wechsel zwischen engen und weiten Räumen? + a: | + Für Kontrast und Erwartung. Nach einem engen Gang wirkt eine offene Fläche größer, und Spieler lesen große, leere Flächen oft als Ort für eine Begegnung. Ich nutze das bewusst, und wenn eine Freifläche keine Begegnung hat, prüfe ich im Test, ob Spieler trotzdem eine erwarten. + tags: [massstab, rhythmus] + level: 2 + - id: groesse-wirken-lassen + module: massstab-dichte + q: Wie lässt du einen Raum in der Draufsicht groß wirken? + a: | + Über Bezugsgrößen und den Bildausschnitt. Bekannte Dinge wie Türen, Bäume oder die Figur selbst zeigen den Maßstab. Ein Raum, der nicht auf einen Bildschirm passt, wirkt groß, weil die Kamera fahren muss. Frei zoomen kann ich bei pixelgenauer Darstellung nicht, nur in ganzen Faktoren. + tags: [massstab, kamera] + level: 3 + - id: kishotenketsu + module: einfuehren-variieren + q: Wie führst du eine neue Mechanik in einem Level ein? + a: | + In vier Schritten, wie Koichi Hayashida es für Super Mario 3D Land beschrieben hat: einführen, entwickeln, wenden, abschließen. Zuerst kann der Spieler die Mechanik ohne großen Preis eines Fehlers ausprobieren. Dann wird sie schwieriger, dann kommt eine Wendung, die sie in neuem Licht zeigt. Pro Raum bringe ich höchstens eine Neuheit. + tags: [einfuehrung, kishotenketsu] + level: 2 + - id: sicher-erproben + module: einfuehren-variieren + q: Warum soll man eine neue Möglichkeit zuerst sicher ausprobieren können? + a: | + Weil Menschen unter Druck schlechter lernen. Valve schreibt im Post-Mortem zu Portal: „Players Learn Better When Not Stressed.“ Wer beim ersten Versuch stirbt, weiß nicht, ob er die Regel falsch verstanden oder nur schlecht ausgeführt hat. Also führe ich ohne Zeitdruck und mit kurzem Rückweg ein und prüfe erst danach. + tags: [einfuehrung] + level: 2 + - id: ohne-text-lehren + module: einfuehren-variieren + q: Kann man eine Mechanik ganz ohne Text erklären? + a: | + Oft ja, und es zwingt zu klarerem Design. Das Team von Hyper Light Drifter wollte von Anfang an keinen Text im Spiel und musste deshalb andere Wege finden. Ich zeige die Mechanik in einer Lage, in der sie die naheliegende Lösung ist, lasse sie ohne Risiko ausprobieren und prüfe im Test, ob Tester sie ohne Erklärung finden. + tags: [einfuehrung, ohne-text] + level: 2 + - id: rhythmus-warum + module: rhythmus + q: Warum braucht ein Level Ruhephasen? + a: | + Weil dauernde Spannung ermüdet und dauernde Ruhe langweilt. Valve hat das für den AI Director von Left 4 Dead als Phasen beschrieben: Build Up, Sustain Peak, Peak Fade, Relax. Für meine Abschnitte heißt das, nach einer Begegnung kommt Bewegung oder Entdeckung, und vor einer großen Begegnung ein Moment zum Überblicken. + tags: [rhythmus, pacing] + level: 2 + - id: beat-chart + module: rhythmus + q: Wie planst du den Rhythmus eines Abschnitts? + a: | + Mit einem Taktplan, englisch oft „beat chart“: eine Folge von Abschnitten mit Tätigkeit, Dauer und Intensität. Die Dauer rechne ich aus Weglänge und Tempo der Figur. So sehe ich vor dem Bauen, ob drei Begegnungen ohne Pause aufeinanderfolgen oder ob eine lange Strecke ohne Ereignis kommt. Ob der Rhythmus sich so anfühlt, zeigt erst der Test. + tags: [rhythmus, planung] + level: 2 + - id: aussichtspunkt + module: rhythmus + q: Wozu dient ein Aussichtspunkt vor einer Begegnung? + a: | + Er gibt dem Spieler einen Moment, die Lage zu lesen und einen Plan zu machen, bevor er sich festlegt. Christopher Totten beschreibt das mit Prospect und Refuge: geschützte Orte mit Überblick über eine offene Fläche. Das Level Design Book sieht das Modell kritisch, ich nutze es deshalb als Idee, nicht als Regel, und prüfe im Test, ob Spieler dort wirklich innehalten. + tags: [rhythmus, prospect-refuge] + level: 3 + - id: affordanz-signifikant + module: umgebung-informiert + q: Was ist der Unterschied zwischen Affordanz und Signifikant? + a: | + Eine Affordanz ist, was ein Ding möglich macht, etwa dass eine Kiste sich schieben lässt. Ein Signifikant ist das wahrnehmbare Zeichen, das das anzeigt. Don Norman schreibt, Design müsse vor allem Signifikanten liefern. Im Level heißt das: Was der Spieler tun kann, muss er sehen können, sonst gibt es die Möglichkeit für ihn nicht. + tags: [umgebung, norman] + level: 2 + - id: visuelle-sprache + module: umgebung-informiert + q: Was ist eine visuelle Sprache in einem Level? + a: | + Feste Zuordnungen zwischen Aussehen und Bedeutung: so sieht begehbar aus, so blockiert, so gefährlich, so interaktiv. Sie muss im ganzen Spiel gelten. Bricht ein Raum die Regel, etwa eine zerstörbare Wand, die aussieht wie jede andere, ohne dass das ein bewusstes Geheimnis ist, fühlt der Spieler sich zu Recht betrogen. + tags: [umgebung, lesbarkeit] + level: 2 + - id: gelbe-farbe + module: umgebung-informiert + q: Was hältst du von deutlichen Markierungen wie gelber Farbe an Kletterkanten? + a: | + Sie lösen ein echtes Problem: In detaillierter Grafik gehen leise Hinweise unter, und Spieler hängen fest. Sie kosten aber das Finden und die Glaubwürdigkeit der Welt. Ich fange mit leisen Mitteln an und werde deutlicher, wo der Test es verlangt, auf Pflichtwegen eher als bei Geheimnissen. Und ich halte die Markierung konsistent. + tags: [umgebung, signposting] + level: 2 + - id: information-oder-erzaehlung + module: umgebung-informiert + q: Wie unterscheidest du Umgebung als Information von Umgebung als Erzählung? + a: | + Information beantwortet „Was kann ich hier tun?“, Erzählung „Was ist hier passiert?“. Eine Blutspur kann beides: Sie zeigt einen Weg und erzählt von einem Kampf. Ich prüfe beides getrennt. Folgen Spieler der Spur, wirkt sie als Information; können sie hinterher sagen, was passiert ist, wirkt sie als Erzählung. + tags: [umgebung, erzaehlen] + level: 2 + - id: absichtsnotiz + module: absicht-skizze + q: Was steht bei dir in einer Absichtsnotiz? + a: | + Der Abschnitt, die Absicht in einem Satz, der erwartete Weg, die Hinweise mit Ort und Zweck und je ein beobachtbares Zeichen für Erfolg und Scheitern. Die Zeichen sind das Wichtigste: „soll geheimnisvoll wirken“ kann ich nicht abhaken, „wird am Seitengang langsamer“ schon. Ändere ich die Absicht später, kommt die neue Fassung mit Datum dazu. + tags: [planung, absicht] + level: 1 + - id: skizze-vs-blockout + module: absicht-skizze + q: Warum reicht eine gute Skizze nicht? + a: | + Weil niemand eine Skizze spielt. Das Level Design Book sagt es deutlich: „the player never plays your drawing.“ Die Skizze hilft mir, Absicht, Maße und Weg zu klären, bevor ich baue. Ob der Raum wirkt, zeigen erst Blockout und Playtest. + tags: [planung, blockout] + level: 1 + - id: umfang-klein + module: absicht-skizze + q: Wie groß sollte ein Abschnitt für den ersten eigenen Test sein? + a: | + Klein, zwei bis vier Bildschirme. Bei 90 Pixeln pro Sekunde sind drei Bildschirme in elf Sekunden durchquert. Ein kleiner Abschnitt lässt sich in einem Abend bauen, mit mehreren Testern prüfen und überarbeiten. Ein großer bleibt halb fertig, und ich lerne nichts über die einzelne Stelle. + tags: [planung, umfang] + level: 1 + - id: warum-blockout + module: blockout + q: Warum baust du zuerst einen Blockout? + a: | + Weil graue Formen billig zu ändern sind und fertige Grafik teuer. Im Blockout teste ich Grundriss, Maße und Hinweise, ohne dass Ausgestaltung das Urteil verfälscht. Das Level Design Book sagt: Eine Skizze kann man nicht testen, einen Blockout schon, und genau dafür ist er da. + tags: [blockout] + level: 1 + - id: ebenen-trennen + module: blockout + q: Wie organisierst du einen Blockout in Godot? + a: | + Mit getrennten TileMapLayer-Ebenen: Boden, Wände mit Kollision, eine Ebene für die beabsichtigten Hinweise und später eine eigene für die Ausgestaltung. So kann ich die Hinweise ausblenden, um zu prüfen, ob der Raum ohne sie trägt, und die Ausgestaltung ändern, ohne die Kollision anzufassen. Das TileSet ist eine Palette aus flachen Tonwerten mit meiner visuellen Sprache. + tags: [blockout, godot] + level: 2 + - id: ki-im-level + module: blockout + q: Wofür nutzt du KI bei der Level-Arbeit, und wofür nicht? + a: | + Für Technik: Skripte wie einen Wegschreiber, Editorhilfen, das Projektgerüst. Layouts, Orte und Hinweise entwerfe ich selbst. Ein erzeugter Raum würde mir nichts darüber sagen, ob meine Absicht trägt, und ich würde die Lücke zwischen Absicht und Verhalten an einem fremden Entwurf studieren. + tags: [ki, arbeitsweise] + level: 1 + - id: worauf-achten + module: playtest-methode + q: Worauf achtest du, wenn jemand dein Level spielt? + a: | + Auf das, was er tut: wo er hingeht, wo er stehen bleibt, wohin die Figur schaut, wo er umkehrt, an Wänden entlangläuft oder Kanten abtastet. Dazu notiere ich, was er sagt, getrennt. Valve hat es so formuliert: „Importance of what people do—not what they say“. Deutungen wie „verwirrt“ schreibe ich erst später dazu. + tags: [playtest, beobachten] + level: 1 + - id: nicht-helfen + module: playtest-methode + q: Was tust du, wenn ein Tester fragt, wohin er gehen soll? + a: | + Ich beantworte die Frage nicht, sondern gebe sie zurück: „Was denkst du?“ Die Nielsen Norman Group nennt das Boomerang. Jede Antwort von mir würde das Verhalten ändern, das ich beobachten will. Wann ich doch eingreife, lege ich vorher in einer Abbruchregel fest, etwa eine Zahl an Minuten ohne Fortschritt, und notiere jeden Eingriff mit Zeit. + tags: [playtest, moderation] + level: 2 + - id: erkunden-oder-verwirrt + module: playtest-methode + q: Wie unterscheidest du beim Zusehen Erkunden von Verwirrung? + a: | + Am Muster. Wer erkundet, wählt neue Wege, schaut in Ecken und kommt mit etwas zurück. Wer verwirrt ist, läuft dieselbe Runde mehrmals, kehrt um, ohne etwas gefunden zu haben, oder bleibt lange stehen. Sicher bin ich mir erst mit dem, was der Tester dazu sagt, und mit dem Vergleich zu anderen Testern. + tags: [playtest, beobachten] + level: 2 + - id: wie-viele-tester + module: playtest-methode + q: Wie viele Tester brauchst du? + a: | + Pro Runde wenige, dafür mehrere Runden. Jakob Nielsen hat für Usability-Tests geschrieben, die besten Ergebnisse kämen aus Tests mit höchstens fünf Personen und so vielen kleinen Runden wie möglich. Für Level gilt dasselbe: Nach jeder Runde ändere ich etwas, und für jede neue Runde brauche ich Leute, die den Abschnitt noch nicht kennen. + tags: [playtest, planung] + level: 2 + - id: wege-aufzeichnen + module: playtest-godot + q: Wie hältst du fest, welche Wege Tester gegangen sind? + a: | + Mit einem kleinen Wegschreiber im Spiel, der die Position der Figur in festen Abständen in eine Datei schreibt und als Linie über die Karte zeichnet. Den erwarteten Weg lege ich als zweite Linie daneben. Auf Papier mitzeichnen geht auch, ist aber ungenauer. Die Dateien sind anonym, ohne Namen. + tags: [playtest, godot] + level: 2 + - id: testversion + module: playtest-godot + q: Was bereitest du vor einem Playtest am PC vor? + a: | + Eine Testversion, die ohne Editor läuft, einen ruhigen Platz, die Absichtsnotiz für mich, den Wegschreiber und ein Protokollblatt. Ich sage dem Tester nur, was er steuern kann, nicht wohin er soll. Und ich frage vorher, ob ich Weg und Gesagtes notieren darf. + tags: [playtest, vorbereitung] + level: 1 + - id: kette-reisst + module: ueberarbeiten + q: Tester übersehen einen Hinweis. Was tust du? + a: | + Ich bestimme zuerst, wo die Kette reißt: nicht bemerkt, falsch gelesen, nicht befolgt oder eine Folge, die ich nicht wollte. Dazu nehme ich Ort, Zeit, Blickrichtung und Gesagtes aus dem Protokoll. Dann prüfe ich, ob meine Absicht noch stimmt, ändere eine Sache mit schriftlicher Erwartung und teste mit Leuten, die den Abschnitt nicht kennen. + tags: [ueberarbeiten, diagnose] + level: 2 + - id: vorschlag-tester + module: ueberarbeiten + q: Ein Tester sagt „Mach den Weg rot“. Was machst du damit? + a: | + Ich notiere es als Beobachtung: Er hat den Weg nicht als Weg gelesen. Ob Rot die Lösung ist, entscheide ich. Vielleicht reicht ein breiterer Durchgang oder ein anderer Boden. Der Vorschlag zeigt, wo das Problem liegt, nicht wie es zu lösen ist. + tags: [ueberarbeiten, rueckmeldung] + level: 1 + - id: eine-aenderung + module: ueberarbeiten + q: Warum änderst du pro Runde nur eine Sache? + a: | + Damit ich weiß, was gewirkt hat. Ändere ich Kontrast, Breite und Belohnung zugleich und jetzt finden alle den Gang, lerne ich nichts für den nächsten Raum. Valve beschreibt Designs als Hypothesen und Playtests als Experimente, und ein Experiment hat eine Variable. + tags: [ueberarbeiten, methode] + level: 2 + - id: wann-ausgestalten + module: ausgestaltung + q: Wann fängst du mit der Ausgestaltung an? + a: | + Wenn der Blockout getestet ist und die wichtigsten Stellen tragen. Das Level Design Book sagt, Environment Artists warten auf einen reifen Blockout. Vorher wäre jede Grafik, die ich nach einem Test wegwerfe, verlorene Arbeit, und schöne Grafik verdeckt Probleme im Grundriss. + tags: [ausgestaltung, blockout] + level: 2 + - id: hinweise-behalten + module: ausgestaltung + q: Wie stellst du sicher, dass die Ausgestaltung die Hinweise nicht verdeckt? + a: | + Die Kollision folgt dem Blockout, nicht der Grafik. Die Tonwertrangfolge bleibt: Was im Blockout hervorstach, sticht auch danach hervor. Und ich wiederhole denselben Test mit neuen Testern und vergleiche die Wege mit denen aus dem Blockout. Ein Hinweis, der im Grau trug und in Farbe untergeht, ist ein häufiger Fall. + tags: [ausgestaltung, regressionstest] + level: 3 + - id: atmosphaere-vs-lesbarkeit + module: ausgestaltung + q: Atmosphäre oder Lesbarkeit, was gewinnt? + a: | + Die Absicht entscheidet. Dunkelheit, Nebel und dichte Details können genau das sein, was ein Raum will, aber sie kosten Lesbarkeit. Ich lege fest, welche Hinweise auf jeden Fall lesbar bleiben müssen, und prüfe nach der Ausgestaltung, ob sie es sind. Alles andere darf Atmosphäre sein. + tags: [ausgestaltung, atmosphaere] + level: 3 + - id: werkstatt-vergleich + module: werkstatt-abschnitt + q: Wie zeigst du, ob ein Abschnitt seine Absicht erreicht hat? + a: | + Mit einem Vergleich Stelle für Stelle: links die Absicht und das erwartete Zeichen, rechts das, was Tester getan haben, mit den aufgezeichneten Wegen als Bild. Ich nenne auch die Stellen, an denen es nicht aufging. Ein ehrlicher Vergleich ist mehr wert als ein Abschnitt, der angeblich perfekt funktioniert. + tags: [werkstatt, dokumentation] + level: 2 + - id: absicht-aendern + module: ueberarbeiten + q: Wann änderst du die Absicht statt des Levels? + a: | + Wenn das beobachtete Verhalten für das Spiel besser ist als mein Plan. Gehen Tester zuerst in den Seitengang und haben dabei mehr vom Raum, ändere ich die Absicht bewusst, schreibe die neue Fassung mit Datum auf und teste gegen sie. Was ich nicht tue: die Absicht still an das anpassen, was gerade passiert ist. + tags: [werkstatt, absicht] + level: 3 + - id: designtest-level + q: Du bekommst einen Level-Design-Test. Wie gehst du vor? + a: | + Ich kläre Rahmen, Zeit und was bewertet wird. Dann schreibe ich die Absicht auf, skizziere mit Maßen aus der Figur, baue einen Blockout und teste ihn mit mindestens zwei Personen, die nichts darüber wissen. Abgeben würde ich Blockout, Draufsicht mit Weg und Hinweisen, Protokoll und eine ehrliche Liste offener Punkte. + tags: [karriere, designtest] + level: 2 + - id: zusammenarbeit-art + q: Ein Environment Artist will einen Durchgang mit Pflanzen zuwachsen lassen, weil es schöner aussieht. Was tust du? + a: | + Ich zeige ihm, welche Aufgabe der Durchgang hat und was der Test im Blockout gezeigt hat. Dann suchen wir eine Fassung, die beides schafft, etwa Pflanzen am Rand und eine freie, helle Mitte. Wenn wir uneinig bleiben, testen wir beide Fassungen mit neuen Leuten und entscheiden nach dem Verhalten. + tags: [karriere, zusammenarbeit] + level: 2 + - id: lieblingslevel + q: Welches Level aus einem anderen Spiel hast du zuletzt genau gelesen, und was hast du gelernt? + a: | + Die Antwort ist persönlich. Eine gute Antwort nennt Spiel und Stelle, beschreibt einen Hinweis konkret, etwa „der einzige beleuchtete Durchgang im ersten Raum“, sagt, was der eigene Weg war, und was man daraus für eigene Abschnitte übernommen hat. Allgemeines Lob wie „das Level ist einfach gut gemacht“ zeigt nichts. + tags: [karriere, analyse] + level: 1 diff --git a/content/level-design/modules/absicht-skizze.yaml b/content/level-design/modules/absicht-skizze.yaml new file mode 100644 index 0000000..6bbd043 --- /dev/null +++ b/content/level-design/modules/absicht-skizze.yaml @@ -0,0 +1,539 @@ +id: absicht-skizze +title: Absicht notieren, Layout skizzieren +level: 2 +minutes: 90 +summary: Bevor du baust – eine Absichtsnotiz mit beobachtbaren Zeichen, ein Raumdiagramm aus Blasen in Textform, eine Skizze auf Karopapier im Tile-Maßstab mit Bildschirmrahmen, erwartetem Weg und Hinweis-Symbolen, daraus abgeleitete Testfragen und ein Umfang, der klein genug bleibt, um ihn zu testen. +place: unterwegs +goals: + - Du füllst eine Absichtsnotiz vollständig aus, mit einer Absicht in einem Satz, nummeriertem Weg, Hinweisen mit Ort, Art und Zweck und beobachtbaren Zeichen. + - Du zeichnest ein Raumdiagramm aus Blasen und Verbindungen in Textform und liest daraus Knoten, Sackgassen und Sperren. + - Du skizzierst einen Abschnitt auf Karopapier im Tile-Maßstab mit Bildschirmrahmen und rechnest aus, wie viele Bildschirme er umfasst und welche Hinweise von einem Wegpunkt aus im Bild sind. + - Du leitest aus der Notiz Testfragen ab, die du beim Zusehen beantwortest, ohne den Tester zu fragen. + - Du hältst den Umfang bei zwei bis vier Bildschirmen und streichst, was der Absicht nicht dient. +resources: + - title: The Level Design Book · Layout + url: https://book.leveldesignbook.com/process/layout + - title: The Level Design Book · Critical path + url: https://book.leveldesignbook.com/process/layout/criticalpath + - title: The Level Design Book · Playtesting, „Prepare for playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#id-1.-prepare-for-playtest + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf +lesson: | + Lehrbeispiel: Du hast eine Idee für einen Abschnitt. Der Spieler soll in einem Lagerhof zuerst das Tor sehen und erst über eine Seitenkammer dorthin kommen. Du öffnest Godot und setzt Tiles. Nach einer Stunde hast du sechs Bildschirme gebaut, und auf die Frage, woran du im Test erkennst, ob es klappt, fällt dir nur „wenn es Spaß macht“ ein. Zehn Minuten mit Stift und Karopapier hätten dir eine bessere Antwort gegeben, und zwar vor dem ersten Tile. + + Dieses Modul zeigt, wie du vor dem Bauen planst: eine vollständige Absichtsnotiz, ein Raumdiagramm aus Blasen, eine Skizze im Tile-Maßstab mit erwartetem Weg und Hinweisen, daraus Testfragen und ein Umfang, den du bauen und testen kannst. Alles geht unterwegs, mit Papier, Stift und Handy. Die Vorlage der Absichtsnotiz kennst du aus [Level lesen: Absicht, Hinweis, Verhalten](/level-design/raum-lesen). Hier füllst du sie vollständig aus. Das Level Design Book warnt vorab: „A layout drawing cannot tell you if your level works, only a blockout and playtest can begin answering that question.“ ([Layout](https://book.leveldesignbook.com/process/layout)) + + > [!MERKE] Die Skizze ist ein Plan für den Test + > Notiz und Skizze beweisen nichts. Sie legen fest, was du baust und woran du im Playtest erkennst, ob es wirkt. + + ## Die Absichtsnotiz Feld für Feld + + Die Felder bleiben in diesem Kurs immer dieselben: + + ```text + Abschnitt: + Absicht (ein Satz): + Der Spieler soll … + Erwarteter Weg: + Hinweise (wo, was, wofür): + Zeichen, dass es klappt: + Zeichen, dass es scheitert: + ``` + + **Abschnitt.** Name und Größe in Bildschirmen, etwa „Lagerhof, 2 Bildschirme“. Die Größe zwingt dich, früh an den Umfang zu denken. + + **Absicht (ein Satz).** Sie beginnt mit „Der Spieler soll …“ und endet mit etwas, das man beobachten kann: bemerken, finden, wählen, zurückkehren, überblicken. Das Level Design Book nennt so ein Ziel experience goal und fragt: „What should the player learn, feel, or do, in this level?“ Dazu: „But more specific = easier to design.“ ([Pre-production plan](https://book.leveldesignbook.com/process/layout#id-1.-pre-production-plan)). Brauchst du ein „und“, sind es oft zwei Absichten. Teil sie auf zwei Abschnitte auf oder entscheide, welche zählt. + + **Erwarteter Weg.** Die Wegpunkte in der Reihenfolge, in der du sie erwartest, mit denselben Nummern wie in der Skizze. Das Buch nennt diesen Hauptweg critical path und rät, Start und Ausgang zu markieren und „Mark, label, and number any major beats“ ([Critical path](https://book.leveldesignbook.com/process/layout/criticalpath#how-to-plan-a-critical-path)). + + **Hinweise (wo, was, wofür).** Jeder Hinweis hat drei Angaben: den Ort als Wegpunkt oder Stelle in der Skizze, die Art (Licht, Öffnung, Landmarke, Kontrast, Spur) und den Teil der Absicht, dem er dient. Ein Hinweis ohne „wofür“ ist Dekoration oder steht für etwas, das du noch nicht entschieden hast. Wie stark ein Hinweis sein muss, behandelt [Umgebung als Information](/level-design/umgebung-informiert). + + **Zeichen, dass es klappt oder scheitert.** Beobachtbar und an einen Ort gebunden, etwa „hält an 3 oder schaut nach rechts“. Ein gutes Zeichen kannst du zählen: Bei wie vielen von vier Testern ist es eingetreten? + + Ein vollständiges Lehrbeispiel: + + ```text + Abschnitt: Lagerhof, 2 Bildsch. + Absicht (ein Satz): + Der Spieler soll das Tor im + Norden sehen, bevor er den + Weg über die Kammer findet. + Erwarteter Weg: + S, 1 Hofmitte, 2 Tor (zu), + 3 Öffnung, 4 Hebel, A + Hinweise (wo, was, wofür): + 2: Licht am Tor, Ziel zeigen + 3: Licht in der Kammer, + Weg zur Kammer zeigen + 4: Hebel heller als Boden, + benutzbar zeigen + Zeichen, dass es klappt: + geht zuerst zu 2, dann zu 3 + Zeichen, dass es scheitert: + läuft an 3 vorbei, kehrt + mehrmals zwischen 1 und 2 um + ``` + + ## Raumdiagramm: Blasen und Verbindungen als Text + + Bevor du Wände zeichnest, klärst du, welche Bereiche es gibt und wie sie zusammenhängen. Das Level Design Book nennt das bubble diagram, ein Blasendiagramm: „The goal of the bubble diagram is to establish proportions and relationships in your level. What needs to be big? What needs to connect to each other?“ ([Bubble diagrams](https://book.leveldesignbook.com/process/layout#id-3.-bubble-diagrams)). Am Handy zeichnest du es als Text. Für das Lehrbeispiel: + + ```text + (A Ausgang) + | + [2 Tor, zu] <~ Hebel in 3 + | + (S) -- (1 Hof, groß) -- (3 Kammer) + ``` + + Die Zeichen: `( )` ist ein Bereich mit Nummer, Name und Größe, `[ ]` eine Sperre, `--` und `|` sind Wege in beide Richtungen, `<~` ist eine Wirkung von anderswo, hier der Hebel, der das Tor öffnet. + + Was du daraus abliest: + + - **Knoten.** Der Hof hat drei Verbindungen. Dort entscheidet der Spieler, wohin er geht, und dort braucht er Orientierung. + - **Sackgassen.** Die Kammer hat nur einen Zugang. Das ist in Ordnung, solange dort etwas liegt, das der Spieler braucht oder will. + - **Sperren und Ursachen.** Das Tor ist zu, die Ursache liegt in einem anderen Bereich. Der Spieler muss das Tor gesehen haben, bevor der Hebel Sinn ergibt. + - **Größen.** Ein großer Bereich zwischen kleinen fällt auf. Ob das zur Absicht passt, entscheidest du. + + Das Buch rät, mehrere Fassungen zu zeichnen: „Draw at least 3 bubble diagrams to imagine multiple arrangements and sizes.“ Und es tröstet: „A bad bubble diagram is good.“ Ein schlechtes Diagramm zeigt dir das Problem, bevor du es gebaut hast. Schreib in jede Blase, welche Art von Takt dort liegt, dann siehst du auch den Rhythmus ([Rhythmus](/level-design/rhythmus)). + + ## Karopapier im Tile-Maßstab + + Auf Karopapier steht **ein Kästchen für ein Tile**. Mit den Platzhaltern dieses Kurses, 16-Pixel-Tiles und 320 × 180 Pixeln Spielbild, ist ein Rahmen von **20 × 11 Kästchen ein Bildschirm**. Deine echten Werte legst du mit deiner Grafik fest ([Pixelraster](/godot/pixelraster)). + + Zeichne zuerst die Bildschirmrahmen, dann die großen Formen. Das Level Design Book gibt für Grundrisse knappe Regeln, darunter „START BIG“, „BE BOXY“ und „WE'RE NOT ARCHITECTS. Draw the minimum needed to imagine the player experience.“ ([Floor plan](https://book.leveldesignbook.com/process/layout#id-4.-floor-plan)). Fast alle Ecken sind rechtwinklig und liegen auf dem Raster. Dekoration lässt du weg. + + Für die Zeichen nimmst du die Legende des Kurses. Dann kannst du einen Ausschnitt jederzeit als Textblock abschreiben. Das Lehrbeispiel, ein Bildschirm Hof und links der Anfang des zweiten Bildschirms mit der Kammer: + + ```text + #########A######################## + #.......!2!.......################ + #.................#.........###### + #..o..o.....o..o..#......!..###### + #.................#.........###### + #........1.......3+......4h.###### + #.................#.........###### + #..o..o.....o..o..#.........###### + #.................#.........###### + #........S........################ + ################################## + ``` + + Legende: `#` Wand · `.` Boden · `o` Kisten, niedrig, sperren den Weg, nicht die Sicht · `+` Durchgang · `S` Start · `A` Ausgang, hier das Tor · `!` beabsichtigter Hinweis · `1`–`4` Wegpunkte · `h` Hebel (eigenes Zeichen für dieses Beispiel) + + Die 21. Spalte von links ist die erste des zweiten Bildschirms. Der Abschnitt ist 34 Tiles breit und 11 hoch, also zwei Bildschirme quer. Am Handy passen 34 Zeichen in eine Zeile, also knapp zwei Bildschirme; auf Papier zeichnest du größer. + + > [!WARNING] Bildschirm ist ein Maß, keine Wand + > Folgt die Kamera der Figur, schneidet sie keine festen Bildschirme aus. Der Rahmen zeigt dir, wie viel auf einmal zu sehen ist. Wechselt dein Spiel dagegen Bildschirm für Bildschirm, ist der Rahmen auch eine Grenze im Spiel. + + ## Erwarteter Weg und Hinweise einzeichnen + + Den erwarteten Weg trägst du als Ziffern ein, `1` bis `9`, in der Reihenfolge, die du erwartest. Diese Nummern sind deine Wegpunkte. Sie stehen gleich in der Skizze, in der Notiz und später im Protokoll des Playtests, deshalb heißen sie in diesem Kurs auch „WP 3“ und so weiter. Hinweise bekommen ein `!`. Zu jedem `!` steht in der Notiz, wofür es da ist. + + Dann prüfst du jeden Hinweis gegen den Bildschirm: Ist er von dem Wegpunkt aus im Bild, an dem er wirken soll? Hält die Kamera die Figur in der Mitte, reicht der Blick rund 10 Tiles zur Seite und gut 5 nach oben und unten. Im Lehrbeispiel liegt das Licht in der Kammer 16 Spalten rechts von Wegpunkt 1. Von der Hofmitte aus ist es nicht zu sehen, an Wegpunkt 3 ist es nur noch 8 Spalten entfernt. Das passt zur Absicht: Erst zieht das Tor, dann die Kammer. Wie Kameragrenzen und Bildausschnitt genauer zusammenspielen, zeigt [Wege, Landmarken und Sichtlinien](/level-design/orientierung). + + Miss auch den Weg. Mit dem Tempo der Testszene (90 Pixel pro Sekunde, Platzhalter) dauert ein Tile 0,18 Sekunden. Der Weg von `S` über `1` zu `2` ist 8 Tiles lang, also knapp anderthalb Sekunden. So erfährst du schon auf Papier, ob der Abschnitt so lang ist, wie er sich anfühlt. + + ## Von der Notiz zu Testfragen + + Vor einem Playtest fragt das Level Design Book unter anderem: „Focus: Which parts are most important to test? What are your biggest questions?“ und „Data: What data are you collecting? How will you collect it?“ ([Prepare for playtest](https://book.leveldesignbook.com/process/blockout/playtesting#id-1.-prepare-for-playtest)). Valve listet unter direkter Beobachtung auch: „Have a design goal“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Deine Absichtsnotiz ist dieses Ziel. Die Testfragen leitest du daraus ab: + + - Aus jedem **Zeichen** wird eine Frage, die du durch Zusehen beantwortest, mit Ort und Zählung. + - Aus jedem **Hinweis** wird eine Frage, ob sich das Verhalten nach dem Hinweis ändert, sobald er im Bild ist. + - Aus dem **erwarteten Weg** wird eine Frage nach der Reihenfolge der Wegpunkte. + + Für das Lehrbeispiel: + + ```text + F1 Wie viele gehen zuerst zu 2? + (zählen: x von 4) + F2 Hält der Tester an 3 oder + dreht er nach rechts? + F3 Wie oft kehrt er zwischen + 1 und 2 um? + ``` + + Andrew Yoder, dessen Skizzen das Buch zeigt, prüft seine Entwürfe mit ähnlichen Fragen: „Does the player know the goal? Can they anticipate a solution and plan for it?“ ([Layout, Andrew Yoder](https://book.leveldesignbook.com/process/layout#untitled-for-quake-1-by-andrew-yoder)). Bleib bei drei bis fünf Fragen pro Runde. Eine Frage, die du dem Tester stellen müsstest, etwa „Hast du das Licht gesehen?“, ist keine Testfrage zum Zusehen. Sie verrät den Hinweis. Offene Fragen nach dem Spiel behandelt [Testlesen und Playtest](/narrative/testlesen-playtest), das Zusehen selbst [Playtests beobachten](/level-design/playtest-methode). + + > [!PRAXIS] Pläne, die sich im Test ändern + > Das Level Design Book zeigt ein Whiteboard von Valve für Half-Life 2: Episode Two, mit einer Skizze des Layouts und daneben dem Ablauf, und merkt an: „note that this drawing differs a bit from the final game“. Für die Karte Warpath aus Team Fortress Classic beschreibt Robin Walker, wie die Designgruppe Karten skizzierte, die Level-Designer sie bauten und die Playtests begannen, „often resulting in drastic changes to original plans for the map“. Das Team von Super Mario 64 hat laut Shigeru Miyamoto keine Pläne vorab gezeichnet, es gab nur Konzeptskizzen und kurze Notizen ([Layout](https://book.leveldesignbook.com/process/layout#against-layouts)). Eine Skizze ist ein Werkzeug zum Denken und Testen. Wie viel du zeichnest, hängt davon ab, was du vor dem Bauen klären musst. + + ## Klein anfangen, unterwegs arbeiten + + Halte einen Abschnitt bei zwei bis vier Bildschirmen. Vier Bildschirme quer sind mit den Platzhaltern gut 14 Sekunden Weg (4 × 320 / 90 = 14,2), genug für vier bis acht Takte. Jeder weitere Bildschirm bringt Hinweise, die du im Test beobachten musst, und Tiles, die du bauen und bei jeder Änderung anfassen musst. Das Level Design Book nutzt den critical path ausdrücklich zum Kürzen: „If something isn't on the critical path, then only some players will see it. Is it worth making?“ ([Critical path as scoping tool](https://book.leveldesignbook.com/process/layout/criticalpath#critical-path-as-scoping-tool)). + + Streich, bevor du baust: + + - Bereiche, die keine Rolle in der Absicht haben. + - Hinweise ohne „wofür“. + - Eine zweite Absicht. Sie wird ein eigener Abschnitt. + + Unterwegs reichen Karopapier, Bleistift und Handy. Bei 5-Millimeter-Karo ist ein Bildschirm 10 × 5,5 Zentimeter groß, zwei passen nebeneinander auf eine A4-Seite. Fotografier die Skizze und gib dem Foto einen Namen mit Abschnitt, Version und Datum, etwa `lagerhof-v2-2026-10-22`. Die Notiz schreibst du mit der Vorlage in eine Notiz-App. So liegen Fassungen nebeneinander, und du siehst später, was sich nach welchem Test geändert hat. + + > [!NOTE] Deine Skizze + > Absicht, Bereiche und Grundriss entscheidest du. Lass dir keine Layouts oder Varianten erzeugen, auch nicht aus dem Foto deiner Skizze. Technische Hilfe ist in Ordnung, etwa ein kleines Skript, das aus deinen Wegpunkten Längen und Sekunden rechnet. + + > [!INTERVIEW] „Wie bereitest du einen Abschnitt vor, bevor du ihn baust?“ + > Ich schreibe die Absicht in einem Satz, mit einem Verhalten, das ich beobachten kann. Dann zeichne ich mindestens drei Blasendiagramme und wähle eins. Auf Karopapier lege ich die Bildschirmrahmen an, zeichne große, eckige Formen, nummeriere den erwarteten Weg und setze die Hinweise. Für jeden Hinweis prüfe ich, ob er von dem Wegpunkt aus im Bild ist, an dem er wirken soll. Zum Schluss leite ich drei bis fünf Testfragen ab und streiche alles, was der Absicht nicht dient. + + ## Häufige Fehler + + - **Zwei Absichten in einem Satz.** „Der Spieler soll die Kammer finden und den Hof erkunden.“ Du weißt im Test nicht, welche du prüfst. Entscheide dich oder teil den Abschnitt. + - **Hinweise ohne Zweck.** In der Skizze stehen fünf `!`, in der Notiz drei mit „wofür“. Die anderen zwei sind Dekoration oder eine Absicht, die du noch nicht aufgeschrieben hast. + - **Kein Bildschirmrahmen.** Ein Hinweis und das, worauf er zeigt, liegen weiter auseinander, als ein Bildschirm zeigt. Ohne Rahmen fällt das erst im Blockout auf. + - **Zu viel Detail.** Kisten, Fässer und Pflanzen ohne Funktion machen die Skizze unlesbar. Das Buch rät: „don't clutter your layout drawing with unnecessary design features.“ + - **Der Weg steht nur im Kopf.** Ohne nummerierte Wegpunkte kannst du im Playtest nicht notieren, wo etwas passiert. + - **Zu großer Umfang.** Acht Bildschirme für den ersten Test. Fang mit zwei an. + - **Die Skizze für das Ergebnis halten.** Eine stimmige Skizze heißt nur, dass du einen Plan hast. Ob er trägt, zeigt der Playtest. + + ## Zusammenfassung + + - Die Absichtsnotiz hat feste Felder. Die Absicht ist ein Satz mit einem beobachtbaren Verhalten, jeder Hinweis hat Ort, Art und Zweck. + - Ein Blasendiagramm in Textform zeigt Bereiche, Größen, Verbindungen, Knoten, Sackgassen und Sperren, bevor eine Wand steht. + - Auf Karopapier ist ein Kästchen ein Tile und ein Rahmen von 20 × 11 Kästchen ein Bildschirm (Platzhalter). + - Wegpunkte sind nummeriert und heißen in Skizze, Notiz und Protokoll gleich. Hinweise bekommen ein `!`. + - Jeder Hinweis muss von dem Wegpunkt aus im Bild sein, an dem er wirken soll. + - Testfragen kommen aus den Zeichen, den Hinweisen und dem erwarteten Weg. Du beantwortest sie durch Zusehen, nicht durch Fragen. + - Zwei bis vier Bildschirme reichen. Was der Absicht nicht dient, streichst du vor dem Bauen. +exercises: + - id: absicht-ein-satz + type: choice + title: Welche Absicht kannst du prüfen? + prompt: | + Lehrbeispiel: vier Fassungen der Absicht für einen Lagerhof. Welche taugt für eine Absichtsnotiz? + options: + - text: Der Spieler soll die Kammer finden, bevor er zum Tor zurückgeht. + correct: true + why: Ein Satz, eine Absicht, und die Reihenfolge der Orte kannst du im Test beobachten. + - text: Der Hof soll groß und verlassen wirken. + correct: false + why: Hier fehlt der Spieler, und „wirken“ ist ein Gefühl. Woran du es beim Zusehen erkennst, steht nicht da. + - text: Der Spieler soll die Kammer finden und den Hof erkunden und den Brunnen bemerken. + correct: false + why: Drei Absichten in einem Satz. Im Test weißt du nicht, welche du prüfst, und Hinweise für die eine stören die andere. + - text: Der Spieler soll Spaß haben. + correct: false + why: Ein Ziel für das ganze Spiel, nicht für diesen Abschnitt. Es sagt nichts darüber, was der Spieler hier tut. + explanation: | + Eine brauchbare Absicht beginnt mit „Der Spieler soll …“, enthält ein Verhalten, das man sehen kann, und hat genau einen Kern. Das Level Design Book sagt dazu „more specific = easier to design“. Aus der richtigen Fassung folgt sofort ein Zeichen für Erfolg: Der Tester betritt die Kammer, bevor er zum Tor zurückkehrt. + hints: + - Streich zuerst alle Sätze ohne Spieler. + resources: + - title: The Level Design Book · Layout, „Pre-production plan“ + url: https://book.leveldesignbook.com/process/layout#id-1.-pre-production-plan + + - id: blasen-lesen + type: choice + title: Was das Diagramm zeigt + prompt: | + Lehrbeispiel: ein Blasendiagramm. `( )` ist ein Bereich, `[ ]` eine Sperre, `--` und `|` sind Wege in beide Richtungen, `*` ein Fundstück. Welche Aussagen stimmen? + lang: text + code: | + (S) -- (1 Halle, groß) -- (2 Gang) + | | + (3 Nische, *) [4 Tor] + | + (A) + options: + - text: Die Halle ist ein Knoten, an dem sich drei Wege treffen. + correct: true + why: Sie verbindet Start, Nische und Gang. Dort entscheidet der Spieler, wohin er geht. + - text: Die Nische ist eine Sackgasse mit einem Fundstück. + correct: true + why: Sie hat nur eine Verbindung, zur Halle, und das Fundstück gibt ihr einen Zweck. + - text: Vom Gang führt ein zweiter Weg zurück zur Halle, eine Schleife. + correct: false + why: Gang und Halle sind nur einmal verbunden. Eine Schleife bräuchte eine zweite Verbindung. + - text: Das Diagramm zeigt, dass der Gang 12 Tiles lang ist. + correct: false + why: Blasendiagramme zeigen Beziehungen und grobe Größen, keine Maße. Die stehen erst in der Skizze auf Karopapier. + explanation: | + Ein Blasendiagramm beantwortet die Fragen „What needs to be big? What needs to connect to each other?“, wie das Level Design Book schreibt. Knoten, Sackgassen und Sperren siehst du darin sofort. Maße und Sichtlinien kommen erst mit dem Raster dazu. + hints: + - Zähl die Verbindungen jeder Blase. + resources: + - title: The Level Design Book · Layout, „Bubble diagrams“ + url: https://book.leveldesignbook.com/process/layout#id-3.-bubble-diagrams + + - id: vom-satz-zur-skizze + type: order + title: Vom Satz zur Skizze + prompt: | + Bring die Arbeitsschritte vor dem Bauen in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Schreib die Absicht als einen Satz, der mit „Der Spieler soll“ beginnt. + Zeichne drei Blasendiagramme und wähle eines davon aus. + Zeichne auf Karopapier die Bildschirmrahmen mit je 20 × 11 Kästchen. + Trag Wände, Böden und Durchgänge als große, eckige Formen ein. + Nummeriere den erwarteten Weg mit Wegpunkten vom Start bis zum Ausgang. + Setz die Hinweise als Ausrufezeichen und notier zu jedem, wofür er da ist. + Leite aus den Zeichen für Erfolg und Scheitern die Testfragen ab. + explanation: | + Die Absicht steht am Anfang, weil sie entscheidet, welche Bereiche es braucht. Die Blasen klären Beziehungen, bevor Maße dazukommen; so ordnet auch das Level Design Book seine Schritte. Die Rahmen kommen vor den Wänden, damit du in Bildschirmen denkst. Weg und Hinweise brauchen die Wände, und die Testfragen brauchen alles davor. + hints: + - Erst Beziehungen, dann Maße, dann Weg. + resources: + - title: The Level Design Book · Layout, „How to design a layout“ + url: https://book.leveldesignbook.com/process/layout#how-to-design-a-layout + + - id: bildschirme-zaehlen + type: output + title: Wie viele Bildschirme? + prompt: | + Drei Skizzen mit Breite und Höhe in Tiles. Ein Bildschirm ist 20 × 11 Tiles (Platzhalter). Was gibt das Modell aus? + lang: python + code: | + import math + + # Tiles je Bildschirm, Platzhalter + BILD_B = 20 + BILD_H = 11 + + def bildschirme(b, h): + quer = math.ceil(b / BILD_B) + hoch = math.ceil(h / BILD_H) + return quer * hoch + + print(bildschirme(34, 11)) + print(bildschirme(40, 12)) + print(bildschirme(18, 30)) + expected: | + 2 + 4 + 3 + hints: + - "`math.ceil` rundet auf: 34 / 20 = 1,7 wird 2." + - 12 Reihen passen nicht in 11. + explanation: | + 34 × 11 sind zwei Bildschirme quer. 40 × 12 klingt nach zwei, sind aber vier, weil die zwölfte Reihe eine zweite Reihe Bildschirme anfängt. Der Spieler sieht dann nie die ganze Höhe auf einmal. 18 × 30 sind drei Bildschirme übereinander. Eine Reihe zu viel kann also einen Abschnitt verdoppeln. Folgt die Kamera der Figur, ist das Ergebnis ein Maß für die Größe, keine Zahl fester Bildschirme. + resources: + - title: Python · math.ceil + url: https://docs.python.org/3/library/math.html#math.ceil + + - id: hinweis-im-bild + type: output + title: Von wo ist das Licht zu sehen? + prompt: | + Lehrbeispiel aus der Lektion: Das Licht in der Kammer liegt bei Spalte 25, Reihe 3, gezählt ab 0 von links oben. Die Kamera hält die Figur in der Mitte und hat keine Grenzen. Vereinfacht reicht der Blick 10 Tiles zur Seite und 5 nach oben und unten. Was gibt das Modell aus? + lang: python + code: | + # halbe Bildbreite und -höhe + # in Tiles, vereinfacht + HALB_B, HALB_H = 10, 5 + wp_orte = {"1": (9, 5), + "3": (17, 5)} + lx, ly = 25, 3 # Licht, Kammer + for wp, (x, y) in wp_orte.items(): + dx = abs(lx - x) + dy = abs(ly - y) + im_bild = (dx <= HALB_B + and dy <= HALB_H) + print(wp, im_bild) + expected: | + 1 False + 3 True + hints: + - Von Wegpunkt 1 sind es 16 Spalten, von Wegpunkt 3 nur 8. + explanation: | + Von der Hofmitte ist das Licht 16 Spalten entfernt und nicht im Bild. An Wegpunkt 3, direkt vor der Öffnung, sind es 8 Spalten und 2 Reihen, das Licht ist zu sehen. Das passt zur Absicht, denn das Tor soll zuerst ziehen und die Kammer erst danach. Läge das Licht bei Spalte 19, direkt hinter der Wand, wäre es schon von der Hofmitte aus im Bild und würde mit dem Tor konkurrieren. Kameragrenzen verschieben den Ausschnitt am Rand des Abschnitts ([Orientierung](/level-design/orientierung)); die Grundprüfung bleibt dieselbe. + resources: + - title: Godot Docs · Camera2D + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html + + - id: begriffe-skizze + type: gap + title: Fünf Begriffe für die Skizze + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Auf dem Karopapier steht ein Kästchen für ein ⟦Tile⟧. Ein Rahmen von ⟦20⟧ × 11 Kästchen zeigt einen Bildschirm. Eine Zeichnung aus Bereichen als Blasen mit Verbindungen heißt ⟦Blasendiagramm⟧. Den beabsichtigten Hauptweg nennt das Level Design Book ⟦critical path⟧, und seine Stationen nummerierst du als ⟦Wegpunkte⟧. + gaps: + - label: ein Kästchen + hint: Die Kachel der Tilemap, englisch. + accept: ["Tiles", "Kachel", "Feld"] + - label: Breite + hint: 320 Pixel durch 16. + accept: ["zwanzig"] + - label: Diagramm + hint: Englisch bubble diagram. + accept: ["Raumdiagramm", "bubble diagram", "Blasendiagramme", "Bubble-Diagramm"] + - label: Hauptweg + hint: Zwei englische Wörter, auch golden path genannt. + accept: ["golden path", "kritischer Pfad", "kritischen Pfad"] + - label: Stationen + hint: In Skizze, Notiz und Protokoll als WP abgekürzt. + accept: ["Wegpunkt", "WP"] + explanation: | + Mit Tile, Bildschirmrahmen und Wegpunkten sprechen Skizze, Notiz und Protokoll dieselbe Sprache. Das Blasendiagramm klärt vorher, welche Bereiche es gibt, der critical path, welcher Weg zählt. Alles, was nicht auf ihm liegt, sehen nur manche Spieler. + resources: + - title: The Level Design Book · Critical path + url: https://book.leveldesignbook.com/process/layout/criticalpath + + - id: dritter-ausgang + type: bug + title: Ein Ausgang zu viel + prompt: | + Lehrbeispiel: Ein Hof, ein Bildschirm groß. Er soll drei Durchgänge haben, `S` unten, `A` oben und `+` rechts. Eine Zeile der Skizze öffnet ungewollt einen vierten. Finde sie. + + Legende: `#` Wand · `.` Boden · `o` niedriges Hindernis · `+` Durchgang · `S` Start · `A` Ausgang · `L` Landmarke + lang: text + code: | + #########A########## + #..................# + #..o...........o...# + #..................# + #..................+ + #........L.........# + #..................# + ...................# + #..o...........o...# + #..................# + #########S########## + lines: [8] + explanation: | + In Zeile 8 fehlt die linke Wand. Auf dem Papier ist das ein Strich, im Blockout ein Loch im Rand, durch das der Spieler den Hof verlässt. Prüf an jeder Skizze die Ränder Zeile für Zeile: Jede Öffnung am Rand ist ein Durchgang, und jeder Durchgang muss in der Notiz stehen. Wenn du die Skizze als Text abschreibst, fallen solche Lücken leichter auf als auf Papier. + hints: + - Lies nur das erste und das letzte Zeichen jeder Zeile. + + - id: hinweis-gegen-absicht + type: bug + title: Ein Hinweis zieht in die falsche Richtung + prompt: | + Lehrbeispiel: Absicht „Der Spieler soll die Kammer erst finden, nachdem er am Tor war.“ Eine Zeile unter „Hinweise“ arbeitet gegen diese Absicht. Finde sie. + lang: prose + code: | + WP 2, Licht am Tor: zeigt das Ziel. + WP 1, Brunnen in der Hofmitte: Landmarke für den Rückweg. + WP 3, Fundstück hell beleuchtet in der Kammer, schon vom Start S aus im Bild: zieht in die Kammer. + WP 4, Hebel heller als der Boden: zeigt, dass er benutzbar ist. + lines: [3] + explanation: | + Ein hell beleuchtetes Fundstück, das schon vom Start aus zu sehen ist, konkurriert mit dem Licht am Tor und zieht den Spieler zuerst in die Kammer. Das widerspricht der Reihenfolge der Absicht. Entweder kommt das Fundstück erst ins Bild, wenn der Spieler an Wegpunkt 3 steht, oder es wird leiser. Ändert sich deine Meinung über die Reihenfolge, änderst du bewusst die Absicht. + hints: + - Welcher Hinweis wirkt schon am Start? + resources: + - title: The Level Design Book · Wayfinding aids + url: https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids + + - id: testfrage-verraet + type: bug + title: Eine Frage, die den Hinweis verrät + prompt: | + Testfragen zum Lehrbeispiel, die du während des Spiels durch Zusehen beantworten willst. Eine passt nicht dazu. Finde sie. + lang: prose + code: | + Wie viele Tester gehen zuerst zu WP 2? + Wie lange steht jeder Tester an WP 3? + Hast du das Licht in der Kammer gesehen? + Wie oft kehrt ein Tester zwischen WP 1 und WP 2 um? + Nach wie vielen Sekunden erreicht ein Tester den Hebel? + lines: [3] + explanation: | + Frage 3 kannst du nicht durch Zusehen beantworten, du müsstest sie dem Tester stellen. Damit zeigst du ihm den Hinweis, und alles, was er danach tut, sagt nichts mehr darüber, ob der Hinweis allein wirkt. Außerdem lässt sie nur Ja oder Nein zu. Beobachtbar wäre etwa, ob der Tester die Figur zur Kammer dreht, sobald das Licht im Bild ist. Offene Fragen nach dem Spiel behandelt [Testlesen und Playtest](/narrative/testlesen-playtest). + hints: + - Welche Frage richtet sich an den Tester statt an dich? + resources: + - title: NN/g · Avoid Leading Questions + url: https://www.nngroup.com/articles/leading-questions/ + + - id: skizze-kein-level + type: explain + title: Warum zeichnen, wenn es nichts beweist? + prompt: | + Das Level Design Book über Layout-Zeichnungen. Erkläre in drei bis fünf Sätzen, was eine Skizze nicht leisten kann und wofür du sie trotzdem zeichnest. + lang: prose + code: | + But remember: plans aren't magic. A layout drawing cannot tell you if your level works, only a blockout and playtest can begin answering that question. A layout is NOT a level, the player never plays your drawing. + points: + - Eine Skizze kann nicht zeigen, wie Spieler sich verhalten. Das zeigt erst ein Playtest am Blockout. + - Sie macht Absicht, Bereiche, Weg und Hinweise sichtbar, bevor du baust, und Fehler werden billig. + - Mit Bildschirmrahmen und Tile-Maßstab prüfst du Größe, Weglängen und ob Hinweise im Bild sind. + - Aus ihr leitest du die Testfragen ab, mit denen du den Blockout prüfst. + explanation: | + Eine Zeichnung wird nicht gespielt, also verrät sie nicht, ob Spieler die Kammer finden. Das kann nur ein Test am Blockout. Trotzdem ist die Skizze der billigste Ort für Fehler: Ein zu großer Abschnitt, ein Hinweis außerhalb des Bildes oder ein vergessener Rand fallen auf, bevor ein Tile gesetzt ist. Vor allem aber legt die Skizze fest, was du im Test beobachtest, denn Wegpunkte und Hinweise stehen dort mit Nummern. Wer ohne Skizze baut, entscheidet das oft erst nach dem Test, und dann passt die Absicht sich still an das an, was passiert ist. + hints: + - Trenne, was die Skizze prüfen kann, von dem, was nur Spieler zeigen. + resources: + - title: The Level Design Book · Layout + url: https://book.leveldesignbook.com/process/layout + + - id: notiz-zu-fragen + type: explain + title: Was du beim Zusehen prüfst + prompt: | + Lehrbeispiel: eine Absichtsnotiz für einen Gang mit Seitengang. Erkläre in drei bis fünf Sätzen, welche Testfragen daraus folgen und welche Beobachtung die Absicht widerlegen würde. + lang: prose + code: | + Abschnitt: Gang mit Seitengang, 2 Bildschirme. + Absicht: Der Spieler soll den Seitengang bemerken, aber zuerst geradeaus bis zur Tür gehen. + Erwarteter Weg: S, 1 Abzweigung, 2 Tür, zurück zu 1, 3 Seitengang. + Hinweise: 1 Fundstück halb sichtbar im Seitengang (bemerken lassen); 2 Licht an der Tür (Ziel zeigen). + Zeichen, dass es klappt: wird an 1 langsamer oder dreht kurz zum Seitengang, geht zur Tür, kommt danach zurück. + Zeichen, dass es scheitert: geht an 1 sofort in den Seitengang, oder kommt von 2 nicht zurück. + points: + - Eine Frage zur Reihenfolge, etwa wie viele Tester zuerst zur Tür gehen. + - Eine Frage zum Bemerken an Wegpunkt 1, etwa ob die Figur langsamer wird oder sich zum Seitengang dreht. + - Eine Frage zur Rückkehr, etwa wie viele nach der Tür in den Seitengang gehen. + - Widerlegt wäre die Absicht, wenn Tester an 1 ohne Halt vorbeigehen und nicht zurückkommen oder sofort abbiegen. + explanation: | + Die Notiz enthält schon fast alle Fragen. Aus dem Weg folgt die Frage nach der Reihenfolge: Wie viele von vier Testern gehen zuerst zur Tür? Aus dem Hinweis an Wegpunkt 1 folgt die Frage nach dem Bemerken: Wird die Figur dort langsamer oder dreht sie zum Seitengang? Aus der Rückkehr folgt die dritte: Wer kommt nach der Tür zurück und biegt ab? Widerlegt ist die Absicht in zwei Richtungen. Gehen Tester sofort in den Seitengang, zieht das Fundstück zu stark. Gehen sie ohne Halt vorbei und kommen nicht zurück, war es zu schwach oder nicht im Bild. + hints: + - Geh die Felder „Erwarteter Weg“, „Hinweise“ und „Zeichen“ nacheinander durch. + resources: + - title: The Level Design Book · Playtesting, „Prepare for playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#id-1.-prepare-for-playtest + + - id: drei-blasendiagramme + type: practice + title: Drei Anordnungen + prompt: | + Für einen Abschnitt, den du selbst wählst: Zeichne auf Papier drei verschiedene Blasendiagramme. Notiere hier je Diagramm in einer Zeile die Bereiche mit Größe und ihre Verbindungen, etwa „S – Hof (groß) – Kammer (klein); Hof – Tor; Hebel in Kammer öffnet Tor“. Schreib zum Schluss, welches du nimmst und warum. + lang: prose + starter: | + Absicht (ein Satz): + Diagramm 1: + Diagramm 2: + Diagramm 3: + Gewählt, weil: + checklist: + - Über den Diagrammen steht eine Absicht in einem Satz, mit einem beobachtbaren Verhalten. + - Jedes Diagramm hat einen Start und einen Ausgang. + - Jeder Bereich hat einen Namen und eine grobe Größe. + - Mindestens zwei Diagramme unterscheiden sich in Reihenfolge oder Verbindungen, nicht nur in Namen oder Größen. + - Die Begründung bezieht sich auf die Absicht, etwa auf Reihenfolge, Knoten oder Sackgassen. + explanation: | + Drei Fassungen zwingen dich, Alternativen zu sehen, bevor du dich festlegst. Das Level Design Book rät genau dazu, und ein schlechtes Diagramm ist dort ausdrücklich gut, weil es ein Problem früh zeigt. Die Begründung am Ende ist der wichtigste Teil: Sie verbindet die Form mit der Absicht. + hints: + - Verschieb in der zweiten Fassung den Knoten, in der dritten die Sperre. + resources: + - title: The Level Design Book · Layout, „Advice for bubble diagrams“ + url: https://book.leveldesignbook.com/process/layout#advice-for-bubble-diagrams + + - id: notiz-und-skizze + type: practice + title: Notiz, Skizze, Testfragen + prompt: | + Wähle einen eigenen Abschnitt von zwei bis vier Bildschirmen; was dort passiert, entscheidest du. Zeichne ihn auf Karopapier mit Bildschirmrahmen, Wegpunkten und Hinweisen, schreib die vollständige Absichtsnotiz daneben oder in deine Notiz-App und fotografier beides. Hier trägst du nur Absicht und drei Testfragen ein und hakst den Rest ab. + lang: prose + starter: | + Absicht (ein Satz): + Testfrage 1: + Testfrage 2: + Testfrage 3: + checklist: + - Die Skizze hat Bildschirmrahmen von 20 × 11 Kästchen oder deinem eigenen Maß, und du hast notiert, welches. + - Die Absicht ist ein Satz mit einem beobachtbaren Verhalten. Steht ein „und“ darin, hast du geprüft, ob es zwei Absichten sind. + - Der erwartete Weg nennt die Wegpunkte mit denselben Nummern wie die Skizze. + - Jeder Hinweis hat Ort, Art und Zweck. + - Du hast für jeden Hinweis geprüft, ob er von seinem Wegpunkt aus im Bild ist. + - Die drei Testfragen lassen sich durch Zusehen beantworten und nennen einen Ort. + explanation: | + Diese Notiz ist die Grundlage für alles Weitere: Nach ihr baust du den Blockout ([Blockout in Godot](/level-design/blockout)), nach ihren Testfragen beobachtest du ([Playtests beobachten](/level-design/playtest-methode)), und gegen sie vergleichst du später das Verhalten der Tester. Heb das Foto der Skizze mit Version und Datum auf. + hints: + - Fang mit zwei Bildschirmen an. Erweitern kannst du nach dem ersten Test. + resources: + - title: The Level Design Book · Layout, „Gameplay markup“ + url: https://book.leveldesignbook.com/process/layout#id-5.-gameplay-markup diff --git a/content/level-design/modules/ausgestaltung.yaml b/content/level-design/modules/ausgestaltung.yaml new file mode 100644 index 0000000..98f26b0 --- /dev/null +++ b/content/level-design/modules/ausgestaltung.yaml @@ -0,0 +1,505 @@ +id: ausgestaltung +title: Vom Blockout zur Ausgestaltung, ohne Hinweise zu verlieren +level: 3 +minutes: 120 +summary: Einen getesteten Blockout ausgestalten, mit eigenen Tiles oder dem Prüfmuster aus dem Godot-Kurs – auf einer eigenen Ebene, mit Kollision aus dem Blockout statt aus der Grafik, mit gehaltenen Tonwerten, einem Baukasten statt Einzelstücken und einem Regressionstest, der zeigt, ob die Hinweise die Grafik überlebt haben. +place: pc +goals: + - Du beginnst die Ausgestaltung erst, wenn der Blockout einen Test bestanden hat, und hältst dessen Ergebnis als Vergleichswert fest. + - Du legst die Grafik auf eine eigene Ebene `Dressing` ohne Kollision und lässt `Walls` als unsichtbare Kollision des Blockouts stehen. + - Du prüfst mit einem Skript, ob die Ausgestaltung Kollision mitbringt oder Wände ohne Bild hinterlässt. + - Du hältst die Tonwerte der Blockout-Vokabel und rechnest nach, ob ein Hinweis nach der Ausgestaltung noch genug Kontrast hat. + - Du baust die Ausgestaltung aus einem kleinen Baukasten und wiederholst danach denselben Test mit neuen Testern. +resources: + - title: The Level Design Book · Environment Art + url: https://book.leveldesignbook.com/process/env-art + - title: Joel Burgess, Nate Purkeypile · Skyrim's Modular Level Design (Folien, GDC 2013) + url: https://www.slideshare.net/slideshow/gdc2013-kit-buildingfinal/17728576 + - title: Godot Docs · TileMapLayer + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html + - title: Godot Docs · 2D lights and shadows + url: https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html +lesson: | + Lehrbeispiel: Dein Hof hat im Blockout einen Test bestanden. Drei von drei Testern sind über den Hof zum Tor gegangen, der gelbe Hinweis daneben hat gewirkt, das Übersichtsbild zeigt drei fast gerade Spuren. Dann gestaltest du aus: Steinwände, Gras mit Blumen, eine warme Laterne am Tor, ein paar Kisten am Rand. In der nächsten Runde findet einer von drei Testern das Tor direkt. Die anderen zwei laufen zu den Blumen, und einer bleibt an einer Kiste hängen, die er für Deko hielt. Am Layout wolltest du nichts ändern. + + Joel Burgess beschreibt diese Lage aus der Sicht von Level-Designern, die fertige Grafik für ihre Level bekommen: „Level designers often inherit a litany of unforeseen problems when receiving final art for their levels.“ Eines seiner Beispiele: „A wall intended as a visual blocker is now a see-though [sic] chain-link fence“ ([Transkript des GDC-Vortrags](http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html)). Das Level Design Book definiert die Ausgestaltung, dort „environment art“, als „the cosmetic decoration of a level or game world, while preserving its core functionality and gameplay“ ([Environment Art](https://book.leveldesignbook.com/process/env-art)). Dieses Modul zeigt, wie du den zweiten Halbsatz einhältst. Du kannst mit eigenen Tiles arbeiten ([Umgebung und Tiles, die Figuren tragen](/pixelart/umgebung-tiles)) oder mit dem Prüfmuster aus [2D-Level aus Tiles](/godot/level-tilemap); fertige Pixelart brauchst du nicht. Das Prüfskript ist technisches Gerüst, eine KI darf es schreiben. Wie dein Ort aussieht, entscheidest du. + + ## Erst testen, dann ausgestalten + + Das Level Design Book beschreibt die Reihenfolge in Studios so: „the environment artist is usually supposed to wait for a mature blockout before beginning an art pass.“ Allein am Projekt heißt das: Du wartest auf dich selbst. Ausgestalten darfst du, wenn der Blockout eine Runde mit Testern bestanden hat, in der die Zeichen aus deiner Absichtsnotiz eingetreten sind ([Werkstatt](/level-design/werkstatt-abschnitt) und [Playtest am PC](/level-design/playtest-godot)). + + Vor dem ersten ausgestalteten Pixel sicherst du drei Dinge: + + - den Tag des getesteten Blockouts, etwa `blockout-r3`, + - das Übersichtsbild und die Zonen-Logs dieser Runde, + - zwei, drei Zahlen aus der Runde: Wie viele Tester haben das Ziel erreicht, in welcher Zeit, mit welchen Halten? + + Diese Zahlen sind dein Vergleichswert. Ohne ihn kannst du nach der Ausgestaltung nicht sagen, ob es schlechter geworden ist. + + > [!MERKE] + > Die Ausgestaltung darf ändern, wie der Ort aussieht, nicht, was der Spieler dort tut. Ob das gelungen ist, zeigt derselbe Test vorher und nachher. + + ## Eine eigene Ebene: Dressing über dem Blockout + + Die Grafik kommt auf einen eigenen `TileMapLayer` namens `Dressing`, mit einem eigenen TileSet aus deinen Tiles. `Ground` und `Walls` bleiben, was sie im Blockout waren. Die Kollision folgt dem Blockout, nicht der Grafik: `Walls` behält seine Kollisionsformen und wird nur unsichtbar, `Dressing` kollidiert nie. Im Ausschnitt aus `main.tscn` fehlt die `unique_id`, die Godot 4.7.2 in jede Node-Zeile schreibt: + + ```ini title=main.tscn + [node name="Dressing" type="TileMapLayer" parent="."] + tile_set = ExtResource("3") + collision_enabled = false + + [node name="Walls" type="TileMapLayer" parent="Objects"] + visible = false + y_sort_enabled = true + tile_set = ExtResource("1") + ``` + + Zwei Eigenschaften klingen ähnlich und tun Verschiedenes. `visible = false` blendet einen Layer aus, die Kollision bleibt ([CanvasItem.visible](https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-visible)). `enabled = false` schaltet ihn laut Doku „completely“ ab, „rendering, collision, navigation, scene tiles, etc.“ ([TileMapLayer.enabled](https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-property-enabled)). Mit Godot 4.7.2 nachgeprüft, Wand in Spalte 8, Figur läuft von x = 40 nach rechts: + + | `Walls` | Figur bleibt stehen bei | + | --- | --- | + | sichtbar | x = 123 | + | `visible = false` | x = 123 | + | `enabled = false` | läuft durch | + | `collision_enabled = false` | läuft durch | + + `collision_enabled = false` an `Dressing` ist eine Sicherung ([collision_enabled](https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-property-collision-enabled)). Hat dein Dressing-TileSet keine Physik-Ebene, kollidiert es ohnehin nicht. Kopierst du aber das Blockout-TileSet als Grundlage, bringt jede Tile ihr Kollisionspolygon mit. Nachgestellt: Eine Kiste auf `Dressing` mit Polygon und ohne die Sicherung hält die Figur bei x = 75 auf, mitten im Weg, den der Blockout frei hatte. + + Hohe Teile wie Baumkronen oder Mauerkronen, hinter die die Figur laufen kann, brauchen eine Ebene in der Y-Sortierung unter `Objects`, unten `DressingHigh` genannt. Wie das geht, steht in [2D-Level aus Tiles](/godot/level-tilemap); auch diese Ebene bekommt `collision_enabled = false`. + + ### Reihenfolge der Ebenen: Grafik unter den Hinweisen + + Godot zeichnet Geschwister in der Reihenfolge des Szenenbaums: Was im Szenen-Dock weiter unten steht, liegt im Bild darüber. `Dressing` enthält auch Boden-Tiles und deckt alles zu, was vor ihm gezeichnet wird. Es gehört deshalb zwischen `Ground` und `Cues`: + + ```text + Main (Node2D) + ├── Ground (TileMapLayer) Blockout-Boden, unter der Grafik + ├── Dressing (TileMapLayer) Grafik, collision_enabled aus + ├── Cues (TileMapLayer) Hinweise, über der Grafik + ├── Objects (Node2D) y_sort_enabled + │ ├── Walls (TileMapLayer) visible aus, Kollision des Blockouts + │ ├── DressingHigh (TileMapLayer) hohe Teile, collision_enabled aus + │ └── Player + └── Notes (Node2D) + ``` + + Mit Godot 4.7.2 nachgeprüft, je eine Tile von `Dressing` und `Cues` in derselben Zelle: In dieser Reihenfolge zeigt das Bild den gelben Hinweis, mit `Dressing` hinter `Cues` die grüne Grafik. Lass `z_index` an beiden auf 0, sonst zählt die Reihenfolge im Baum nicht mehr ([z_index](https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-z-index)). Die Grafik des Hinweises selbst, etwa eine Laterne statt der gelben Tile, malst du auf `Cues` an die Stelle des Platzhalters. Ein TileSet kann dafür mehrere Atlanten enthalten, den Platzhalter und deine Hinweis-Tiles ([Using TileSets](https://docs.godotengine.org/en/stable/tutorials/2d/using_tilesets.html#merging-several-atlases-into-a-single-atlas)). So bleibt jeder Hinweis auf seiner Ebene, auch ausgestaltet. Hohe Teile auf `DressingHigh` liegen dagegen über `Cues`; wo sie einen Hinweis verdecken können, steht im Abschnitt zur Atmosphäre. + + ### Ein Prüfskript nach jeder Runde + + Zwei Fehler sieht man im Editor schlecht: Kollision, die mit der Grafik hereinkommt, und Wände, die unsichtbar geworden sind, weil an ihrer Stelle kein Bild liegt. Dieses Skript prüft beides gegen den Blockout: + + ```gdscript title=check_dressing.gd + extends SceneTree + + ## Prüft nach jeder Ausgestaltungsrunde drei Dinge gegen den Blockout: + ## Kollision in Dressing, Dressing über Cues und Wand-Zellen ohne Bild in Dressing. + ## Aufruf im Projektordner: godot --headless --path . -s check_dressing.gd + ## Technisches Gerüst, keine Designentscheidung. + + + func _initialize() -> void: + var level: Node = load("res://main.tscn").instantiate() + var walls: TileMapLayer = level.get_node("Objects/Walls") + var dressing: TileMapLayer = level.get_node("Dressing") + var cues: TileMapLayer = level.get_node("Cues") + if dressing.collision_enabled and dressing.tile_set.get_physics_layers_count() > 0: + print("Dressing kann kollidieren: collision_enabled ausschalten") + if dressing.get_index() > cues.get_index(): + print("Dressing wird nach Cues gezeichnet und verdeckt Hinweise") + for cell in walls.get_used_cells(): + if dressing.get_cell_source_id(cell) == -1: + print("Wand ohne Bild: ", cell) + level.free() + quit() + ``` + + `get_used_cells()` liefert alle belegten Zellen von `Walls`, `get_cell_source_id()` gibt −1 zurück, wenn in `Dressing` an dieser Stelle nichts liegt ([get_cell_source_id](https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-method-get-cell-source-id)). `get_index()` ist die Position unter den Geschwistern im Baum ([get_index](https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-index)). Mit Godot 4.7.2 nachgeprüft: vier Wandzellen, auf einer davon fehlt das Bild, Ausgabe `Wand ohne Bild: (9, 6)`. Mit einem Dressing-TileSet mit Physik-Ebene und ohne die Sicherung kommt die erste Meldung dazu, mit `Dressing` hinter `Cues` die zweite. Liegen deine Wandbilder auf mehreren Ebenen, lass dir das Skript für jede erweitern. + + Was das Skript nicht findet: Grafik, die wie eine Wand aussieht, wo keine ist, etwa ein Busch, durch den man laufen kann. Das zeigt nur der Test. + + ## Tonwerte und Vokabel halten + + Im Blockout war alles lesbar, weil es nichts anderes gab. Das Level Design Book beschreibt, was beim Ausgestalten passiert: „as we add additional visual details to the world, the level geometry becomes less distinct and more noisy.“ Und an anderer Stelle: „everything is ivy, everything in environment art has a readability function.“ Das Buch erklärt den Satz an The Last of Us Part II: Dort zeigt Efeu, dass ein Gebäude geschlossen ist, und fehlender Efeu, dass man es betreten soll ([Environment Art, Readability](https://book.leveldesignbook.com/process/env-art)). + + Für dich heißt das: Die Vokabel aus dem Blockout überlebt die Ausgestaltung. Was blockiert, bleibt dunkler als der Boden, oder du hast eine andere, ebenso deutliche Regel. Die Farbe, die im Blockout den Hinweisen gehörte, gehört auch jetzt nur ihnen. Das Level Design Book nennt Spiele, die Farben reservieren, „only explosive barrels are red!“. Wie du Tonwerte prüfst, zeigen [Licht, Schatten und Tonwerte](/pixelart/licht-werte) und [Prüfen, überarbeiten, dokumentieren](/pixelart/lesbarkeit-pruefen): Mach von derselben Stelle einen Screenshot im Blockout und einen nach der Ausgestaltung, stell beide in Graustufen nebeneinander, und vergleich die Reihenfolge der Helligkeiten. + + Ob ein Hinweis noch heraussticht, kannst du auch rechnen. Der Pixelart-Kurs nutzt dafür die relative Leuchtdichte und das Kontrastverhältnis nach WCAG ([Farbe, Rampen und begrenzte Paletten](/pixelart/farbe-paletten)): 1 heißt gleich hell, 21 heißt Schwarz auf Weiß. + + ```python run + def kanal(v): + s = v / 255 + return s / 12.92 if s <= 0.04045 else ((s + 0.055) / 1.055) ** 2.4 + + def leuchtdichte(hexwert): + r, g, b = (int(hexwert[i:i + 2], 16) for i in (1, 3, 5)) + return 0.2126 * kanal(r) + 0.7152 * kanal(g) + 0.0722 * kanal(b) + + def kontrast(a, b): + hell, dunkel = sorted((leuchtdichte(a), leuchtdichte(b)), reverse=True) + return (hell + 0.05) / (dunkel + 0.05) + + print(round(kontrast("#3c3c3c", "#8c8c8c"), 1)) # Wand gegen Boden, Blockout + ``` + + Die Zahl ist ein Messwert, keine Regel. Sie sagt dir, ob zwei Flächen in Graustufen verschmelzen. Ob dein Hinweis wirkt, sagt der Test. + + Die Debatte um gelbe Markierungen in großen Spielen, „yellow paint“, dreht sich um genau diese Wirkung: Je mehr Detail im Bild ist, desto stärker muss ein Hinweis sein, um bemerkt zu werden. Die Stimmen aus der Debatte stehen in [Umgebung als Information](/level-design/umgebung-informiert) und [Überarbeiten](/level-design/ueberarbeiten), dort auch, wie stark eine Markierung sein soll. + + ## Baukasten statt Einzelstücke + + Bethesda hat Skyrim aus modularen Baukästen gebaut, „kits“. Burgess: „Kits, first and foremost, are systems.“ Ein Kit rastet in einem Raster ein, und „the most important attribute of a kit is that it adds up to far more than the sum of its parts.“ Für Tiles in der Draufsicht ist das Raster schon da. Die Regel zu Grundflächen überträgt sich trotzdem: „a 512x512x512 room will always tile nicely with a 256x256x256 hallway, but a 384x384x384 room will eventually create gaps and/or overlaps.“ Größere Teile, die über mehrere Zellen gehen, haben bei dir Maße in ganzen Tiles, 32 oder 48 Pixel bei 16er-Tiles, nie 24. + + Ein kleiner Baukasten für einen Abschnitt kann so aussehen: ein Boden mit höchstens zwei Varianten, Wandkanten mit Ecken (dafür sind Terrains gemacht, siehe [2D-Level aus Tiles](/godot/level-tilemap)), eine Wandkrone, ein Durchgang, die Hinweis-Teile und vielleicht ein einziges Stück für eine Landmarke. Welche Teile dein Baukasten hat, entscheidest du aus deiner Blockout-Vokabel: Jede Tile der Vokabel braucht mindestens ein Gegenstück. + + Zwei Ratschläge aus den Quellen helfen beim Bauen. Burgess rät, „one visually-complete piece“ fertigzustellen, bevor die Varianten kommen. Wenn sich die Richtung ändert, änderst du ein Teil statt zwanzig. Das Level Design Book rät zu einer Testszene mit allen Teilen: „Make a scene or level with every prop / art asset, and walk around in it.“ Das ist dein Maßstabsraum aus dem Blockout-Modul, diesmal mit Grafik. + + ## Atmosphäre ohne Hinweisverlust + + Licht, Farbe und Dichte machen einen Ort, und alle drei können Hinweise verdecken. + + - **Licht.** Ein `CanvasModulate` färbt den ganzen Canvas, etwa dunkler für Nacht ([CanvasModulate](https://docs.godotengine.org/en/stable/classes/class_canvasmodulate.html)), ein `PointLight2D` hellt Stellen auf ([2D lights and shadows](https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html#point-lights)). Valve hat für Left 4 Dead Licht gezielt zur Wegführung genutzt; auf der Folie steht: „Players tend to follow the light“ ([Mitchell, MIGS 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf)). Machst du den Ort dunkler, muss der Hinweis heller bleiben als alles um ihn herum. + - **Dichte.** Das Level Design Book rät, Details in Gruppen zu setzen, „in clusters of related details“. Viele einzelne Details gleich verteilt machen den ganzen Boden laut. Halte den Weg ruhiger als die Ränder, wenn er der Weg sein soll. + - **Hohe Teile.** In der Draufsicht verdeckt ein hohes Teil, was oberhalb von ihm liegt. Eine Baumkrone eine Zeile unter dem Hinweis kann ihn ganz zudecken. Lauf jeden Hinweis aus der Richtung an, aus der Tester kommen. + + Auch Klang kann ein Hinweis sein; das behandelt der spätere Sound-Kurs. + + ## Regressionstest: derselbe Test nach der Ausgestaltung + + Ein Regressionstest wiederholt einen bestandenen Test, um zu sehen, ob eine Änderung etwas kaputt gemacht hat. Hier heißt das: dieselbe Absichtsnotiz, dieselben Zonen, derselbe Wegschreiber, dieselbe Zahl an Testern, aber neue Tester, die den Abschnitt nicht kennen. Vorher läuft `check_dressing.gd` ohne Meldung, und der Stand hat einen eigenen Tag. + + Danach legst du die Übersichtsbilder vorher und nachher nebeneinander und vergleichst die Zahlen. Rückschritte sind: weniger Tester am Ziel, längere Zeiten, neue Halte oder Umwege an ausgestalteten Stellen, Tester, die an einer unsichtbaren Wand hängen bleiben oder in etwas hineinlaufen, das wie eine Wand aussieht. Findest du einen, änderst du zuerst die Ausgestaltung an dieser Stelle, nicht das Layout; das Layout hat seinen Test bestanden. Wie du eine Stelle diagnostizierst und eine Änderung pro Runde machst, steht in [Überarbeiten](/level-design/ueberarbeiten). + + > [!PRAXIS] Kunst und Level-Design arbeiten zusammen, nicht nacheinander + > Burgess schildert die übliche Übergabe: Das Design arbeitet am Layout, gibt es an die Grafik ab, die Grafik macht einen Art-Pass, und erst danach zeigt sich, dass Deckung zu dünnen Stangen und Sichtblocker zu Zäunen geworden sind. Bethesda setzt deshalb Kit-Artist und Level-Designer von Anfang an zusammen und bringt die Kits so früh wie möglich in einen „functional-but-ugly“ Zustand. Allein am Projekt bist du beides. Dann hilft die Trennung in zwei Ebenen und ein Test nach jedem Art-Pass ([Transkript](http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html), [Folien](https://www.slideshare.net/slideshow/gdc2013-kit-buildingfinal/17728576)). + + > [!INTERVIEW] + > „Nach dem Art-Pass finden Tester den Ausgang nicht mehr. Was tust du?“ Gute Antwort: Ich vergleiche zuerst mit dem Test vor dem Art-Pass, gleiche Zonen, gleiche Aufgabe, neue Tester, damit ich weiß, ob es schlechter geworden ist. Dann prüfe ich, ob die Kollision noch dem Blockout entspricht und ob der Hinweis seinen Kontrast verloren hat, im Graustufen-Screenshot oder als Zahl. Ich ändere die Grafik an der Stelle, eine Sache pro Runde, und teste wieder. Das Layout fasse ich erst an, wenn sich auch die Absicht geändert hat. + + ## Häufige Fehler + + - **Ausgestalten vor dem Test.** Dann gibt es keinen Vergleichswert, und jede Beobachtung kann vom Layout oder von der Grafik kommen. + - **Kollision aus der Grafik.** Ein Dressing-TileSet mit Kollisionspolygonen ändert den Weg. `collision_enabled = false` an jeder Dressing-Ebene. + - **`enabled` statt `visible`.** `Walls` mit `enabled = false` hat keine Kollision mehr, die Figur läuft durch alle Wände. + - **Dressing über den Hinweisen.** `Dressing` steht im Baum hinter `Cues`, und die Boden-Grafik deckt jeden Hinweis zu. Die Reihenfolge ist `Ground`, `Dressing`, `Cues`. + - **Wand ohne Bild.** `Walls` ist unsichtbar, und an einer Stelle fehlt das Bild. Der Tester stößt an Luft. + - **Bild ohne Wand.** Ein Busch oder Zaun sieht blockierend aus, ist aber begehbar, oder umgekehrt. Das findet nur der Test. + - **Hinweisfarbe überall.** Die Farbe der Hinweise taucht jetzt auch in Blumen und Dächern auf, und der Hinweis verschwindet zwischen ihnen. + - **Alles gleich detailliert.** Der Boden ist so laut wie die Ränder. Ruhe auf dem Weg, Details in Gruppen. + + ## Zusammenfassung + + - Ausgestaltet wird ein Blockout, der einen Test bestanden hat. Tag, Übersichtsbild und Zahlen dieser Runde sind der Vergleichswert. + - Die Grafik liegt auf `Dressing` mit `collision_enabled = false`. `Walls` bleibt mit `visible = false` als Kollision des Blockouts. + - `visible = false` behält die Kollision, `enabled = false` schaltet sie ab. + - Im Baum liegt `Dressing` zwischen `Ground` und `Cues`; die Grafik der Hinweise kommt auf `Cues`. + - `check_dressing.gd` meldet Kollision in `Dressing`, `Dressing` hinter `Cues` und Wandzellen ohne Bild. + - Die Tonwerte der Blockout-Vokabel bleiben erhalten; die Hinweisfarbe gehört nur Hinweisen. Graustufen-Screenshot oder Kontrastverhältnis prüfen das. + - Ein Baukasten hat Teile in ganzen Tiles, ein fertiges Teil vor den Varianten und eine Testszene mit allen Teilen. + - Licht, Dichte und hohe Teile dürfen Hinweise nicht verdecken. + - Der Regressionstest wiederholt denselben Test mit neuen Testern. Rückschritte behebst du zuerst in der Grafik. +exercises: + - id: bereit-fuer-ausgestaltung + type: choice + title: Wann fängst du an? + prompt: | + Wann ist dein Blockout bereit für die Ausgestaltung? + options: + - text: Wenn eine Runde mit Testern die Zeichen aus deiner Absichtsnotiz gezeigt hat und Tag, Übersichtsbild und Zahlen dieser Runde gesichert sind. + correct: true + why: Dann weißt du, dass das Layout funktioniert, und hast einen Vergleichswert für den Test danach. + - text: Wenn der Blockout im Editor vollständig aussieht und alle Ebenen bemalt sind. + correct: false + why: Vollständig heißt nicht getestet. Ob Spieler tun, was du willst, zeigt nur ein Test. + - text: Wenn du selbst den erwarteten Weg ohne Zögern findest. + correct: false + why: Du kennst die Absicht. Dein eigener Durchlauf prüft Technik und Maße, nicht ob ein Fremder den Weg findet. + - text: Wenn die Tiles für den Ort fertig gezeichnet sind. + correct: false + why: Fertige Grafik ist eine Frage der Grafik, nicht des Layouts. Wer sie einbaut, bevor das Layout getestet ist, baut sie oft zweimal. + explanation: | + Die Reihenfolge Blockout, Test, Ausgestaltung schützt dich vor zwei Fehlern: Grafik für ein Layout zu bauen, das sich noch ändert, und nach der Ausgestaltung nicht zu wissen, ob es schlechter geworden ist. Das Level Design Book nennt es einen „mature blockout“, auf den die Grafik wartet. + resources: + - title: The Level Design Book · Environment Art + url: https://book.leveldesignbook.com/process/env-art + + - id: was-darf-sich-aendern + type: choice + title: Was darf die Ausgestaltung ändern? + prompt: | + Lehrbeispiel: Du gestaltest den getesteten Hof aus. Welche Änderungen erhalten, was der Blockout im Test gezeigt hat? + options: + - text: Der graue Boden wird zu Gras-Tiles, die heller bleiben als die Wände. + correct: true + why: Das Aussehen ändert sich, die Tonwert-Ordnung der Vokabel bleibt. Was begehbar war, sieht weiter begehbar aus. + - text: Über der Wand am Nordrand hängen Ranken auf `Dressing`, ohne Kollision. + correct: true + why: Reine Grafik auf einer Wand, die schon blockiert hat. Weg und Kollision bleiben gleich. + - text: Eine Kiste mit Kollision kommt mitten in den Weg zum Tor, weil der Hof leer wirkt. + correct: false + why: Das ändert das Layout. Ein Hindernis im getesteten Weg gehört in den Blockout und in einen neuen Test, nicht in die Ausgestaltung. + - text: Die gelbe Hinweis-Tile wird zu einer braunen Laterne, die im Gras kaum heller ist als der Boden. + correct: false + why: Der Hinweis verliert seinen Kontrast. Er ist noch da, aber nicht mehr das, was im Test gewirkt hat. + explanation: | + Die Ausgestaltung darf alles ändern, was der Spieler nicht als Information liest, und muss alles halten, was er liest: begehbar und blockiert, Weg und Kollision, Stärke der Hinweise. Eine Laterne als Hinweis ist eine gute Idee, solange sie im Graustufenbild so heraussticht wie vorher die gelbe Tile. + hints: + - Zwei Änderungen sind in Ordnung. + resources: + - title: The Level Design Book · Environment Art, Readability + url: https://book.leveldesignbook.com/process/env-art + + - id: walls-unsichtbar + type: output + title: Hält die unsichtbare Wand? + prompt: | + `Walls` hat Wand-Tiles mit vollem Kollisionsquadrat in den Zellen (8, 5) und (8, 6) und steht auf `visible = false`. `Dressing` zeigt Mauer-Tiles in denselben Zellen und eine Kiste in (5, 5) und (5, 6); `Dressing` hat `collision_enabled = false`. Tiles 16 × 16. Die Figur des Testgeländes, Fußform 10 × 6 mittig über dem Ursprung, startet bei (40, 100) und läuft 2 Sekunden mit 90 px/s nach rechts. Was gibt die Zeile danach aus? + lang: gdscript + code: | + print(roundi(player.position.x)) + expected: | + 123 + hints: + - Welche Ebene kollidiert überhaupt? + - Spalte 8 beginnt bei x = 128, die Fußform reicht 5 Pixel nach rechts. + explanation: | + Die Kiste auf `Dressing` hat keine Kollision, die Figur läuft durch. `Walls` ist unsichtbar, kollidiert aber weiter, weil `visible` nur das Zeichnen betrifft. Die rechte Kante der Fußform erreicht x = 128 bei x = 123. Gemessen mit Godot 4.7.2: 122,997, gerundet 123. Mit `enabled = false` an `Walls` wäre die Figur nach 120 Physik-Frames bei x = 220, durch die Wand hindurch; ebenfalls gemessen. + resources: + - title: Godot Docs · TileMapLayer.enabled + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-property-enabled + + - id: pruefung-vorhersagen + type: output + title: Was meldet das Prüfskript? + prompt: | + `Walls` hat Zellen in (8, 5), (8, 6), (9, 5) und (9, 6). `Dressing` hat Tiles in (8, 5), (8, 6), (9, 5) und (3, 2), ein TileSet ohne Physik-Ebene und `collision_enabled = false`, und `Dressing` steht im Baum vor `Cues`. Was gibt `check_dressing.gd` aus? + lang: gdscript + code: | + if dressing.collision_enabled and dressing.tile_set.get_physics_layers_count() > 0: + print("Dressing kann kollidieren: collision_enabled ausschalten") + if dressing.get_index() > cues.get_index(): + print("Dressing wird nach Cues gezeichnet und verdeckt Hinweise") + for cell in walls.get_used_cells(): + if dressing.get_cell_source_id(cell) == -1: + print("Wand ohne Bild: ", cell) + expected: | + Wand ohne Bild: (9, 6) + accept: + - "Wand ohne Bild: (9,6)" + hints: + - Die ersten zwei Bedingungen sind falsch. + - Das Skript geht die Zellen von `Walls` durch, nicht die von `Dressing`. + explanation: | + `collision_enabled` ist aus, die erste Meldung entfällt. `Dressing` steht vor `Cues`, die zweite entfällt auch. Von den vier Wandzellen hat nur (9, 6) kein Bild in `Dressing`; dort stößt ein Tester später an eine Wand, die er nicht sieht. Die Tile in (3, 2) ist Deko ohne Wand und kein Fehler, das Skript fragt nur in eine Richtung. Gemessen mit Godot 4.7.2. + resources: + - title: Godot Docs · TileMapLayer.get_used_cells + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-method-get-used-cells + + - id: kontrast-nachrechnen + type: output + title: Sticht der Hinweis noch heraus? + prompt: | + Das Modell rechnet das Kontrastverhältnis nach WCAG zwischen Hinweis und Boden, einmal mit den Farben des Blockouts, einmal mit den ausgestalteten. Was gibt es aus? + lang: python + code: | + def kanal(v): + s = v / 255 + return s / 12.92 if s <= 0.04045 else ((s + 0.055) / 1.055) ** 2.4 + + def leuchtdichte(hexwert): + r, g, b = (int(hexwert[i:i + 2], 16) for i in (1, 3, 5)) + return 0.2126 * kanal(r) + 0.7152 * kanal(g) + 0.0722 * kanal(b) + + def kontrast(a, b): + hell, dunkel = sorted((leuchtdichte(a), leuchtdichte(b)), reverse=True) + return (hell + 0.05) / (dunkel + 0.05) + + print(round(kontrast("#f0d23c", "#8c8c8c"), 1)) # Hinweis gegen Boden, Blockout + print(round(kontrast("#c9a227", "#a89a5a"), 1)) # dasselbe, ausgestaltet + expected: | + 2.2 + 1.2 + hints: + - Im Blockout ist der Boden mittleres Grau, der Hinweis helles Gelb. + - Der ausgestaltete Boden ist ein heller Ocker, die Laterne ein dunkleres Gold. + explanation: | + Im Blockout liegt das Kontrastverhältnis zwischen Hinweis und Boden bei 2,2 : 1. Ausgestaltet sind es 1,2 : 1, Laterne und Boden sind fast gleich hell; in Graustufen verschmelzen sie. Farbig mag die Laterne noch auffallen, aber sie hat den Unterschied verloren, der im Test gewirkt hat. Die Zahl ersetzt den Test nicht; sie sagt dir vor dem Test, wo du nachsehen solltest. Die Formel stammt aus WCAG 2.2, wie im Modul [Farbe, Rampen und begrenzte Paletten](/pixelart/farbe-paletten). + resources: + - title: W3C · WCAG 2.2 · Contrast ratio + url: https://www.w3.org/TR/WCAG22/#dfn-contrast-ratio + + - id: dressing-ebene + type: gap + title: Grafik ohne Kollision, Kollision ohne Grafik + prompt: | + Ergänze die Zeilen in `main.tscn`: `Dressing` zeigt die Grafik und kollidiert nie, `Walls` bleibt die Kollision des Blockouts und wird nicht gezeichnet. + lang: ini + code: | + [node name="Dressing" type="TileMapLayer" parent="."] + tile_set = ExtResource("3") + ⟦collision_enabled⟧ = false + + [node name="Walls" type="TileMapLayer" parent="Objects"] + ⟦visible⟧ = false + y_sort_enabled = true + tile_set = ExtResource("1") + gaps: + - label: Kollision des Layers + hint: Die Eigenschaft von `TileMapLayer`, die Kollisionen an- oder ausschaltet. + - label: nicht zeichnen + hint: Eine Eigenschaft von `CanvasItem`. Nicht `enabled`, das schaltet auch die Kollision ab. + explanation: | + `collision_enabled = false` sichert `Dressing` gegen Kollisionspolygone aus kopierten TileSets. `visible = false` an `Walls` blendet die grauen Tiles aus, die Kollision bleibt. Mit `enabled = false` wäre `Walls` ganz abgeschaltet, auch die Kollision; mit Godot 4.7.2 nachgeprüft, die Figur läuft dann durch die Wand. + resources: + - title: Godot Docs · TileMapLayer.collision_enabled + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-property-collision-enabled + + - id: kiste-im-gang + type: bug + title: Die Kiste, die nur Deko sein sollte + prompt: | + Nach der Ausgestaltung bleiben Tester im Gang vor einer Kiste hängen, die nur Deko sein soll. `Walls` hat an dieser Stelle keine Zelle. Dein Dressing-TileSet ist eine Kopie des Blockout-TileSet, die Kiste ist die Tile `2:0`, und `Dressing` hat in `main.tscn` keine Zeile `collision_enabled`. Finde die Zeile im Dressing-TileSet, die die Figur aufhält. + lang: ini + code: | + [sub_resource type="TileSetAtlasSource" id="atlas"] + texture = ExtResource("1") + 0:0/0 = 0 + 1:0/0 = 0 + 2:0/0 = 0 + 2:0/0/physics_layer_0/polygon_0/points = PackedVector2Array(-8, -8, 8, -8, 8, 8, -8, 8) + 3:0/0 = 0 + + [resource] + physics_layer_0/collision_layer = 1 + sources/0 = SubResource("atlas") + lines: [6] + explanation: | + Die Kiste hat ein volles Kollisionsquadrat, und weil `collision_enabled` an `Dressing` nicht ausgeschaltet ist, gilt der Standard `true`. Mit Godot 4.7.2 nachgestellt: Kiste in Spalte 5, die Figur bleibt bei x = 75 stehen. Zwei Abhilfen, am besten beide: die Zeile mit dem Polygon löschen und `collision_enabled = false` an `Dressing` setzen. `check_dressing.gd` hätte den Fehler vor dem Test gemeldet. + hints: + - Welche Zeile gibt einer einzelnen Tile eine Form? + resources: + - title: Godot Docs · Using TileSets · Adding collision + url: https://docs.godotengine.org/en/stable/tutorials/2d/using_tilesets.html#adding-collision-navigation-and-occlusion-to-the-tileset + + - id: krone-ueber-hinweis + type: bug + title: Der Hinweis ist weg + prompt: | + Lehrbeispiel: Im Blockout haben drei von drei Testern den Hinweis `!` beim Tor gesehen. Nach der Ausgestaltung läuft niemand mehr direkt zum Tor. Die Rasterkarte zeigt den ausgestalteten Hof. Legende: `#` Wand, `.` Boden, `+` Tor, `S` Start, `!` Hinweis, `T` Baum, zwei Tiles hoch; sein Bild ragt eine Zeile nach oben über die Zelle darüber. Finde die Zeile mit dem Element, das den Hinweis verdeckt. + lang: text + code: | + #################### + #..................# + #.................!+ + #.................T# + #S.................# + #..................# + #################### + lines: [4] + explanation: | + Der Baum steht direkt unter dem Hinweis. In der Draufsicht ragt sein Bild eine Zeile nach oben und deckt die Zelle mit `!` zu. Im Editor fällt das kaum auf, im Spiel siehst du statt der Markierung eine Baumkrone. Liegt der Baum auf einer Ebene unter `Objects`, wird er außerdem nach `Cues` gezeichnet, also immer darüber. Der Baum muss nicht weg; er darf nur nicht unter dem Hinweis stehen. + hints: + - Welche Zelle liegt direkt unter dem `!`? + resources: + - title: Godot Docs · Using TileMaps · Multiple TileMapLayers and settings + url: https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html#multiple-tilemaplayers-and-settings + + - id: kollision-folgt-blockout + type: explain + title: Warum die Kollision im Blockout bleibt + prompt: | + Erkläre in drei bis fünf Sätzen, warum die Kollision nach der Ausgestaltung aus `Walls` kommt und nicht aus der Grafik, und was diese Einstellungen dafür tun. + lang: ini + code: | + [node name="Dressing" type="TileMapLayer" parent="."] + tile_set = ExtResource("3") + collision_enabled = false + + [node name="Walls" type="TileMapLayer" parent="Objects"] + visible = false + y_sort_enabled = true + tile_set = ExtResource("1") + points: + - Der Blockout hat mit genau dieser Kollision einen Test bestanden; die Ausgestaltung soll das Aussehen ändern, nicht den Weg. + - "`visible = false` blendet die grauen Tiles aus, die Kollision von `Walls` bleibt erhalten." + - "`collision_enabled = false` sorgt dafür, dass keine Dressing-Tile den Weg verändert, auch wenn das TileSet Polygone mitbringt." + - Grafik und Kollision können jetzt auseinanderlaufen; deshalb prüft `check_dressing.gd` Wände ohne Bild, und der Regressionstest prüft den Rest. + explanation: | + Die Kollision ist das Ergebnis des Blockouts: Mit ihr sind die Tester den Weg gegangen, den du wolltest. Würde sie mit der Grafik neu entstehen, hätte jede Kiste und jede Mauerkante die Chance, den Weg zu verändern, und du müsstest das Layout neu testen. Deshalb bleibt `Walls` die einzige Kollision, nur ausgeblendet, und `Dressing` ist reine Grafik. Der Preis ist, dass beide auseinanderlaufen können: eine Wand ohne Bild oder ein Bild, das wie eine Wand aussieht. Das Erste findet das Prüfskript, das Zweite der Test mit neuen Testern. + resources: + - title: Godot Docs · CanvasItem.visible + url: https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-visible + + - id: baukasten-szene + type: practice + title: Ein kleiner Baukasten + prompt: | + Leg für deinen Abschnitt einen kleinen Baukasten an, mit eigenen Tiles oder mit dem Prüfmuster aus dem Godot-Kurs, und eine Testszene, in der jedes Teil einmal liegt. Welche Teile es gibt und wie sie aussehen, entscheidest du aus deiner Blockout-Vokabel. + lang: prose + starter: | + Vokabel-Tile → Baukasten-Teil(e): + checklist: + - Jede Tile deiner Blockout-Vokabel hat mindestens ein Gegenstück im Baukasten. + - Teile über mehrere Zellen haben Maße in ganzen Tiles. + - Ein Teil ist fertig, bevor es Varianten davon gibt. + - Das Dressing-TileSet hat keine Physik-Ebene, oder jede Dressing-Ebene hat `collision_enabled = false`. + - Die Testszene zeigt jedes Teil einmal, und du bist mit der Figur hindurchgelaufen. + - Die Hinweisfarbe kommt in keinem Teil vor, das kein Hinweis ist. + hints: + - Weniger Teile machen den Test leichter. Zwei Bodenvarianten reichen für den Anfang. + explanation: | + Der Baukasten ist die Übersetzung deiner Vokabel in Grafik. Wenn jedes Teil ein Gegenstück in der Vokabel hat, weißt du bei jedem Pixel, welche Information es tragen soll. Die Testszene zeigt dir, ob die Teile nebeneinander funktionieren, bevor sie im Abschnitt liegen. Wie du Tiles zeichnest, zeigt [Umgebung und Tiles, die Figuren tragen](/pixelart/umgebung-tiles). + resources: + - title: Joel Burgess · Skyrim's Modular Level Design (Folien, GDC 2013) + url: https://www.slideshare.net/slideshow/gdc2013-kit-buildingfinal/17728576 + - title: The Level Design Book · Environment Art, „Make a prop zoo“ + url: https://book.leveldesignbook.com/process/env-art + + - id: bildschirm-ausgestalten + type: practice + title: Einen Bildschirm ausgestalten + prompt: | + Gestalte einen Bildschirm deines getesteten Abschnitts aus, mit deinem Baukasten auf `Dressing`. Prüf danach Kollision, Wände und Tonwerte. Wie der Ort aussieht, entscheidest du; die Checkliste prüft nur, dass der Test von vorher noch gelten kann. + lang: prose + checklist: + - Der Blockout hat vorher einen Test bestanden, und Tag, Übersichtsbild und Zahlen sind gesichert. + - Die Grafik liegt auf `Dressing` oder Ebenen darunter, `Walls` steht auf `visible = false`, nicht auf `enabled = false`. + - Im Baum liegt `Dressing` zwischen `Ground` und `Cues`, und die Grafik der Hinweise liegt auf `Cues`. + - "`check_dressing.gd` läuft ohne Meldung." + - Du hast von derselben Stelle einen Screenshot im Blockout und einen danach in Graustufen verglichen, und blockierende Flächen sind weiter dunkler als der Boden oder folgen einer neuen Regel, die du notiert hast. + - Jeder Hinweis hat gegen seine Umgebung mindestens den Kontrast aus dem Blockout, gemessen oder im Graustufenbild verglichen. + - Kein hohes Teil steht direkt unter einem Hinweis. + hints: + - Fang mit dem Boden an, dann die Wände, die Hinweise zuletzt. Dann siehst du, ob sie gegen den fertigen Hintergrund noch wirken. + explanation: | + Ein Bildschirm reicht, um das Verfahren zu prüfen, bevor du den ganzen Abschnitt ausgestaltest. Die Checkliste prüft nichts am Aussehen, nur, dass die Information aus dem Blockout erhalten ist. Ob sie wirkt, zeigt erst der Regressionstest. + resources: + - title: The Level Design Book · Environment Art, „How to art pass“ + url: https://book.leveldesignbook.com/process/env-art + + - id: regressionstest + type: practice + title: Derselbe Test nach der Ausgestaltung + prompt: | + Wiederhole den bestandenen Test des Blockouts mit dem ausgestalteten Stand: gleiche Absichtsnotiz, gleiche Zonen, gleiche Zahl an Testern, neue Tester. Vergleiche vorher und nachher und notiere, was sich geändert hat. + lang: prose + starter: | + Stand vorher (Tag) / nachher (Tag): + Tester vorher / nachher: + Ziel erreicht vorher / nachher: + Zeit bis zum Ziel vorher / nachher: + Neue Halte oder Umwege (Ort, Zeit): + Nächste Änderung (eine): + checklist: + - Beide Stände haben einen Tag, und `check_dressing.gd` lief vor dem Test ohne Meldung. + - Die Tester kannten den Abschnitt nicht, auch nicht den Blockout. + - Die Zahlen vorher und nachher stammen aus Zonen-Logs oder Übersichtsbildern, nicht aus der Erinnerung. + - Jeder Rückschritt nennt Ort und Zeit, und Beobachtung und Deutung stehen getrennt. + - Die nächste Änderung betrifft die Ausgestaltung an einer Stelle; eine Änderung am Layout ist nur notiert, wenn sich die Absicht geändert hat. + hints: + - Leg die zwei Übersichtsbilder nebeneinander, bevor du die Protokolle liest. + explanation: | + Der Regressionstest beantwortet eine einzige Frage: Hat die Ausgestaltung etwas gekostet? Weil nur die Grafik anders ist, liegt ein Rückschritt vermutlich an der Grafik; prüf trotzdem mit dem Protokoll, ob die neuen Tester etwas anderes getan haben, das nichts mit ihr zu tun hat. Wie du die Stelle diagnostizierst und eine Änderung pro Runde machst, zeigt [Überarbeiten](/level-design/ueberarbeiten). + resources: + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting diff --git a/content/level-design/modules/blickfuehrung.yaml b/content/level-design/modules/blickfuehrung.yaml new file mode 100644 index 0000000..1b79bc4 --- /dev/null +++ b/content/level-design/modules/blickfuehrung.yaml @@ -0,0 +1,495 @@ +id: blickfuehrung +title: Komposition und Blickführung in der Draufsicht +level: 1 +minutes: 90 +summary: Womit du in einem Top-down-Bild den Blick lenkst – Tonwert, Sättigung, Licht, Bewegung, Linien und Rahmung –, warum ein Bildschirm einen Hauptpunkt und Ruhe drumherum braucht und was die Kamera mit Drag-Rändern vom Blick voraus übrig lässt. +place: unterwegs +goals: + - Du nennst die Mittel, die in der Draufsicht den Blick lenken, und erklärst, warum der Tonwert vor der Farbe kommt. + - Du baust für einen Bildschirm eine Hierarchie aus einem Hauptpunkt und wenigen Nebenpunkten und erkennst Lockvögel, die mit ihm konkurrieren. + - Du prüfst ein Bild mit Graustufen und zusammengekniffenen Augen darauf, ob der Hauptpunkt übrig bleibt. + - Du rechnest aus, wie weit der Spieler mit den Drag-Rändern der Godot-Kamera voraussieht. + - Du planst Blickführung im Blockout zuerst nur in Tonwerten und hältst sie getrennt von der Ausgestaltung. +resources: + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding + - title: Jason Mitchell, „Connecting Visuals to Gameplay at Valve“ (MIGS 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf + - title: The Level Design Book · Massing (Hierarchy, Readability) + url: https://book.leveldesignbook.com/process/blockout/massing + - title: Godot Docs · Camera2D + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html +lesson: | + Halt ein Spiel an, sobald ein neuer Raum im Bild ist, und frag dich, wohin dein Blick zuerst ging. Meist weißt du es, bevor du sagen kannst, warum. Das Level Design Book beschreibt eine solche Stelle aus Half-Life 2. Wenn Spieler den Bahnhof am Anfang verlassen, sehen sie die Stadt mit dem Turm der Zitadelle in der Mitte. Damit sie ihn bemerken, richteten Valves Level-Designer einen Türrahmen auf den Platz aus, und im selben Moment fliegt ein Schwarm Vögel auf ([Level Design Book, Wayfinding](https://book.leveldesignbook.com/process/blockout/wayfinding#signage-theory)). + + Rahmen, Bewegung, ein Ziel in der Bildmitte: Die Stelle ist komponiert. In einem Spiel in der Draufsicht hast du dieselben Mittel, aber einen anderen Rahmen. Es gibt keinen Horizont und keinen Blick nach oben, nur den Bildschirm, der mit der Figur mitfährt. Dieses Modul zeigt, womit du in diesem Rahmen den Blick lenkst, wie du einen Hauptpunkt gegen Lockvögel und Rauschen schützt und was die Kamera davon übrig lässt. Es baut auf [Level lesen: Absicht, Hinweis, Verhalten](/level-design/raum-lesen) auf. Ein Blickziel ist ein Hinweis; ob er wirkt, zeigt erst das Verhalten der Spieler. + + ## Drei Regeln für den Blick und was die Draufsicht daraus macht + + Aus dem Beispiel leitet das Level Design Book drei Leitlinien für die Komposition einer Szene ab: + + 1. „Players don’t look upwards unless something draws their eye.“ + 2. „Players look in the direction they are moving.“ + 3. „Players focus on contrast (in color, shape, lighting, and movement.)“ + + Die Regeln stammen aus einem Spiel in der Ich-Perspektive. Was davon in der Draufsicht gilt, ist eine Übertragung dieses Kurses, keine Aussage des Buchs. + + - **Die erste Regel verschiebt sich.** Nach oben schaut in der Draufsicht niemand, die Kamera ist fest. Die Grenze des Blicks ist der Bildrand. Was außerhalb liegt, sieht der Spieler nicht, so auffällig es auch ist. + - **Die zweite Regel wird schärfer.** Wer nach rechts läuft, schaut nach rechts, und dort zeigt das Bild bei mittiger Figur 160 Pixel, nach oben nur 90. Was den Blick lenken soll, muss in Laufrichtung im Bild sein. + - **Die dritte Regel gilt unverändert.** Kontrast in Helligkeit und Farbe, in Form, Licht und Bewegung zieht den Blick. Sie trägt den Rest dieses Moduls. + + Eine Einschränkung gehört dazu. Das Buch ordnet Hilfen zur Orientierung nach einer geschätzten Sicherheit, „a non-scientific estimate“, wie viele Spieler sie bemerken und nutzen. Licht und Farbe stehen dort bei 40 Prozent, Komposition und Sichtlinien bei 35 ([Wayfinding aids](https://book.leveldesignbook.com/process/blockout/wayfinding#coarse-35-60-certainty)). Blickführung ist ein Vorschlag an den Spieler, kein Befehl. Sie macht die Absicht wahrscheinlicher, und ob sie reicht, zeigt der Playtest. + + ## Tonwert vor Farbe: Kontrast, der auch in Graustufen trägt + + Der stärkste Kontrast ist der Unterschied in der Helligkeit, der **Tonwert**. Wie man Tonwerte sieht und plant, behandelt [Licht, Schatten und Tonwerte](/pixelart/licht-werte) mit einer Skala in neun Stufen, 1 hell bis 9 fast schwarz. Dieser Kurs nutzt dieselbe Skala für **Tonwertkarten**. Das sind Rasterkarten, in denen jede Ziffer den Tonwert eines Tiles angibt, keinen Wegpunkt. + + ```text + 9999999999 + 9777777779 + 9777777739 + 9777777779 + 9999999999 + ``` + + Wände in Stufe 9, Boden in Stufe 7, ein Tile in Stufe 3: Das Auge findet die 3 sofort, mit oder ohne Farbe. Zwei Farben mit gleichem Tonwert dagegen, etwa ein Rot und ein Grün, verschmelzen in Graustufen zu einer Fläche ([Prüfen, überarbeiten, dokumentieren](/pixelart/lesbarkeit-pruefen)). Farbe ist deshalb der zweite Kanal. Sie kann den Tonwert verstärken, aber nicht ersetzen. Das Level Design Book nennt als Beispiel für Farbkontrast eine „bright blue door in a dark orange landscape“. Diese Tür unterscheidet sich zweimal, kühl gegen warm und hell gegen dunkel. + + Auch **Sättigung** trennt. Valve hielt bei Team Fortress 2 die Umgebung blasser als die Figuren. Jason Mitchells Folie zur Umgebung nennt „Team distinction through material hue/value/saturation“ und „Desaturated relative to players“ ([MIGS 2008, Folien](https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf)). Was auffallen soll, darf satt sein, weil der Rest es nicht ist. Eine satte Farbe überall macht keine Stelle wichtig. + + > [!MERKE] Tonwert zuerst + > Plane den Kontrast in Helligkeit. Was in Graustufen nicht heraussticht, sticht für viele Augen auch in Farbe nicht genug heraus. + + ## Licht, Bewegung und Linien + + **Licht** ist Tonwert mit einem Grund. Für Left 4 Dead nennt Mitchell beim Licht in dunklen Szenen ausdrücklich „Aid navigation“ und „Players tend to follow the light“. Das Level Design Book listet bei Licht und Farbe den „path implied by light placement (Left 4 Dead)“ und „visibly lit entrances and exits“. In der Draufsicht heißt das: ein beleuchteter Durchgang in einem dunklen Raum, eine Reihe Laternen entlang eines Wegs, ein heller Fleck am Ende eines Gangs. Wie du Licht und Schatten in Pixelart zeichnest, steht im Pixelart-Kurs. Hier zählt, wo es liegt. + + **Bewegung** zählt nach der dritten Regel ebenso. In Half-Life 2 sind es die Vögel. Das Buch führt Tiere und Figuren, denen man folgt, als subtile Hilfe, „birds in Half-Life 2“ steht als Beispiel. In einem Standbild aus lauter ruhigen Tiles fällt eine bewegte Stelle auf: eine flackernde Flamme, Wasser, ein Tier. Daraus folgt auch das Gegenteil. Bewegt sich überall etwas, etwa animiertes Wasser über die halbe Karte, verliert Bewegung ihre Wirkung. + + **Linien** führen den Blick entlang ihrer Richtung: ein Weg aus anderem Boden, ein Zaun, ein Fluss, eine Kante zwischen zwei Bodenarten, eine Reihe Säulen. Das Buch nennt solche Führung „ground composition“ mit Beispielen wie „train tracks (Team Fortress 2)“ und betont die „clear gameplay function“. Eine Linie führt dorthin, wo sie endet. Endet sie an einer leeren Wand, kommt der Blick dort an und findet nichts. + + Dan Taylor fasst die Mittel für das Ziel eines Levels in einem Satz zusammen: Ziele sollen „visually distinct“ sein, „using location, form, lighting and animation to make them clearly stand out from their surroundings“ ([Ten Principles, Teil 1](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-)). Lage, Form, Licht und Bewegung, und zwar gegen die Umgebung. + + ## Rahmung und Hierarchie: ein Hauptpunkt, wenige Nebenpunkte + + **Rahmung** heißt, einen Punkt mit Dunkel oder Masse zu umgeben, damit er allein steht. Der Türrahmen in Half-Life 2 tut das, und das Buch nennt unter Komposition auch „window framing a specific view“. In der Draufsicht rahmt eine Lücke in einer Hecke, ein Tor zwischen zwei Pfeilern, ein Ring aus Bäumen um eine Lichtung oder ein dunkler Gang, der auf einen hellen Fleck zuläuft. + + **Hierarchie** heißt, dass nicht alles gleich wichtig ist. Das Level Design Book schreibt über Baumassen: „A bigger mass with a more unusual shape will feel more important than surrounding masses.“ ([Massing, Hierarchy](https://book.leveldesignbook.com/process/blockout/massing#hierarchy)) Für einen Bildschirm in der Draufsicht nutzt dieser Kurs eine Faustregel: + + | Ebene | Anzahl | Kontrast | Beispiel | + | --- | --- | --- | --- | + | Hauptpunkt | einer | der stärkste im Bild | der Ausgang, den die Absicht meint | + | Nebenpunkte | höchstens zwei | deutlich schwächer | Seitengang, Fundstück | + | Ruhe | der Rest | enger Tonwertbereich | Boden, Wände | + + Ruhe ist kein verschenkter Platz. Sie macht den Hauptpunkt erst sichtbar. Der Pixelart-Kurs zeigt mit großen Wertegruppen, warum ein Boden in einem engen Bereich die Figur trägt ([Licht, Schatten und Tonwerte](/pixelart/licht-werte)). + + Ein **Lockvogel** ist ein auffälliger Punkt ohne Bedeutung, etwa eine Fackel, die heller ist als der Ausgang. Das Buch erinnert daran, dass „everything in the game is a wayfinding aid“. Auch der Lockvogel ist also ein Hinweis, nur ein falscher. Spieler gehen ihm nach, finden nichts und lernen, dem Licht in diesem Spiel weniger zu trauen. + + > [!PRAXIS] Valve vereinfacht das Licht in Left 4 Dead + > Mitchells Folien zeigen ein frühes Bild aus der Produktion von Left 4 Dead mit der Überschrift „Too many areas of contrast“ und daneben die fertige Fassung als „Simplified lighting“. Weniger helle Stellen, und jede davon hat einen Grund. Dazu trennt Valve mit Nebel und Partikeln Vordergrund und Hintergrund, „Separate foreground from background“ ([MIGS 2008, Folien](https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf)). Das Studio hat Kontrast also weggenommen, damit der übrige wirkt. + + ## Visuelles Rauschen und der Unschärfetest + + **Visuelles Rauschen** entsteht, wenn viele kleine Kontraste gleich stark sind. Kein Punkt gewinnt, der Blick springt umher. Das Level Design Book unterscheidet lesbare Karten, die „relatively simple shapes into clear distinct groups“ ordnen, von wenig lesbaren mit „fragmented massing that feels like camouflage“ ([Massing, Readability](https://book.leveldesignbook.com/process/blockout/massing#readability)). Es fügt hinzu, dass wenig Lesbarkeit nicht schlecht sein muss. Für einen versteckten Durchgang willst du genau diese Tarnung, an dieser einen Stelle. + + Zwei Proben zeigen dir die Hierarchie eines Bildes in Sekunden, beide am Handy: + + - **Graustufen.** Screenshot machen und in der Galerie-App einen Schwarz-Weiß-Filter anlegen, oder den Graustufenmodus der Bedienungshilfen einschalten. Bleibt der Hauptpunkt der hellste oder dunkelste Fleck gegen seine Umgebung? + - **Unschärfe.** Augen zusammenkneifen oder das Handy auf Armlänge halten. Details verschwinden, die großen Kontraste bleiben. Was übrig bleibt, ist deine tatsächliche Hierarchie. + + Bleibt nach dem Zusammenkneifen der Lockvogel übrig und nicht der Ausgang, ist der Lockvogel dein Hauptpunkt, egal was in der Notiz steht. Beide Proben stammen aus dem Pixelart-Kurs, die Graustufenprobe aus [Prüfen, überarbeiten, dokumentieren](/pixelart/lesbarkeit-pruefen), das Zusammenkneifen aus [Licht, Schatten und Tonwerte](/pixelart/licht-werte). Sie prüfen das Bild, nicht das Spielen. Ob Spieler dem Hauptpunkt folgen, zeigt nur der Playtest. + + > [!TIP] Erst das Standbild, dann der Weg + > Prüf jeden Bildschirm, den ein Spieler beim Betreten zuerst sieht, einmal als Standbild mit beiden Proben. Das dauert eine Minute und findet Lockvögel, bevor ein Tester an ihnen hängen bleibt. + + ## Der Bildausschnitt: Figur in der Mitte, Kamera mit Drag-Rändern + + Hängt eine `Camera2D` an der Figur, hält sie die Figur standardmäßig in der Bildmitte (`anchor_mode` „Drag Center“). Dann gilt, was [Level lesen](/level-design/raum-lesen) ausgerechnet hat. Bei 320 × 180 Pixeln Spielbild, einem Platzhalter wie alle Werte hier, siehst du zur Seite 160 Pixel voraus, nach oben 90. + + Schaltest du `drag_horizontal_enabled` oder `drag_vertical_enabled` ein, folgt die Kamera erst, wenn die Figur einen Drag-Rand erreicht. Die Ränder `drag_left_margin`, `drag_right_margin`, `drag_top_margin` und `drag_bottom_margin` stehen auf 0,2. Laut Doku heißt 1, dass sich die Kamera erst am Bildrand bewegt ([Camera2D, drag_right_margin](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-drag-right-margin)). Der Wert ist also ein Anteil am halben Bild. Nachgemessen mit Godot 4.7.2 in einem Bild von 320 × 180 Pixeln: Läuft die Figur mit eingeschaltetem Drag nach rechts, steht sie 32 Pixel rechts der Bildmitte, und die Kamera zieht mit ihr. + + ```python run + # Platzhalter + BILD_B, BILD_H = 320, 180 + TILE = 16 + # Standard in Godot 4.7 + DRAG = 0.2 + + def voraus(halb): + return halb - DRAG * halb + + seite = voraus(BILD_B / 2) + oben = voraus(BILD_H / 2) + print(seite, seite / TILE) + print(oben, oben / TILE) + ``` + + Mit Drag siehst du beim Laufen nach rechts noch 128 Pixel voraus, 8 Tiles, und 192 Pixel hinter dir. Nach oben bleiben 72 Pixel, viereinhalb Tiles. Drag zeigt mehr von dem, woher du kommst, und weniger von dem, wohin du gehst. Auch `position_smoothing_enabled` lässt die Kamera der Figur hinterherlaufen. Willst du das Gegenteil, eine Kamera, die in Laufrichtung vorausschaut, brauchst du ein Skript, das `offset` verschiebt. Das Skript darf dir eine KI schreiben; wie weit die Kamera vorausschaut, entscheidest du. Weitere Kamera-Techniken für große Gegner stehen in [Große Kreaturen als Bosse](/combat/grosse-gegner). + + Für die Komposition heißt das: Ein Bildschirm in der Draufsicht ist kein festes Bild. Der Ausschnitt wandert mit. Plane den Hauptpunkt so, dass er im Bild ist, wenn der Spieler sich entscheiden muss, und rechne dafür mit dem Blick voraus deiner Kamera, nicht mit dem ganzen Bildschirm. + + ## Blickführung im Blockout: erst Tonwerte, dann Ausgestaltung + + Ein Blockout ist ein Level aus grauen Formen und flachen Platzhalter-Tiles. Er prüft das Layout, nicht die Grafik ([Blockout in Godot](/level-design/blockout)). Blickführung gehört schon hinein, aber nur als Tonwert. Vier bis fünf flache Werte reichen: Boden, Wand, Hindernis, Hauptpunkt, Nebenpunkt. Damit testest du, ob die Hierarchie trägt, bevor ein einziges fertiges Tile existiert. Fertige Pixelart brauchst du dafür nicht. + + Die Ausgestaltung kommt später und darf die Hierarchie nicht umwerfen. Das Level Design Book beschreibt Environment Art als „the cosmetic decoration of a level or game world, while preserving its core functionality and gameplay“ und rät, für den Art Pass auf einen „mature blockout“ zu warten ([Environment Art](https://book.leveldesignbook.com/process/env-art)). Wie du dabei Hinweise erhältst, zeigt [Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung). Wie Markierungen eine eigene visuelle Sprache bilden, behandelt [Umgebung als Information](/level-design/umgebung-informiert). + + > [!NOTE] Deine Komposition + > Welche Stelle eines Bildschirms der Hauptpunkt ist, folgt aus deiner Absicht. Eine KI darf dir ein Skript für eine Vorlaufkamera oder für Graustufen-Screenshots schreiben. Wohin der Blick gehen soll, legst du fest. + + > [!INTERVIEW] „Wie lenkst du in einem Top-down-Raum den Blick zum Ausgang, ohne einen Pfeil zu malen?“ + > Ich lege zuerst fest, welcher Ausgang gemeint ist, und gebe ihm den stärksten Tonwertkontrast im Bild, oft mit Licht. Boden und Wände halte ich in einem engen Bereich, damit nichts mit ihm konkurriert, und ich suche gezielt nach Lockvögeln, die heller sind oder sich bewegen. Dann prüfe ich das Standbild in Graustufen und mit zusammengekniffenen Augen und rechne nach, ob der Ausgang mit der eingestellten Kamera rechtzeitig im Bild ist. Ob es wirkt, zeigt ein Playtest ohne Erklärung. Erst wenn das nicht reicht, nehme ich stärkere Mittel wie Fundstücke oder Markierungen. + + ## Häufige Fehler + + - **Farbe statt Tonwert.** Eine rote Tür in grüner Wiese mit gleichem Tonwert verschwindet in Graustufen. Hell oder dunkel zuerst, Farbe danach. + - **Zwei Hauptpunkte.** Ausgang und Truhe gleich hell, und der Spieler wählt per Zufall. Entscheide, was zuerst kommt, und nimm dem anderen Kontrast weg. + - **Ein Lockvogel.** Die hellste Stelle im Bild ist eine Fackel ohne Bedeutung. Der Unschärfetest findet sie. + - **Rauschen.** Jedes Tile hat ein eigenes Detail, der Boden springt über die ganze Skala. Ruhe ist die Voraussetzung für einen Hauptpunkt. + - **Hauptpunkt zu spät im Bild.** Du planst mit 10 Tiles Blick voraus, die Kamera mit Drag zeigt 8. Der Ausgang erscheint später als gedacht, und dem Spieler bleibt weniger Zeit, sich zu entscheiden. + - **Linien ins Leere.** Ein Weg zeigt auf eine Wand, der Blick kommt an und findet nichts. + - **Blickführung erst in der Ausgestaltung.** Wer Kontrast erst mit der fertigen Grafik plant, testet im Blockout eine andere Hierarchie als die, die später im Spiel steht. + + ## Zusammenfassung + + - In der Draufsicht ist der Bildrand die Grenze des Blicks. Spieler schauen in Laufrichtung und folgen Kontrast in Helligkeit, Farbe, Form, Licht und Bewegung. + - Der Tonwert kommt vor der Farbe. Sättigung trennt, wenn die Umgebung blasser ist als das Wichtige. + - Licht, Bewegung und Linien führen den Blick. Eine Linie führt dorthin, wo sie endet. + - Ein Bildschirm braucht einen Hauptpunkt, höchstens zwei Nebenpunkte und Ruhe drumherum. Ein Lockvogel ist ein falscher Hinweis. + - Graustufen und Unschärfe zeigen die tatsächliche Hierarchie eines Standbilds. Ob Spieler ihr folgen, zeigt der Playtest. + - Drag-Ränder von 0,2 kürzen den Blick voraus von 160 auf 128 Pixel zur Seite und von 90 auf 72 nach oben. + - Im Blockout planst du Blickführung mit wenigen flachen Tonwerten. Die Ausgestaltung muss diese Hierarchie erhalten. +exercises: + - id: drei-regeln-draufsicht + type: choice + title: Was bleibt von den drei Regeln? + prompt: | + Das Level Design Book nennt drei Leitlinien für den Blick, abgeleitet aus Half-Life 2, einem Spiel in der Ich-Perspektive. Welche Aussagen über ihre Übertragung auf die Draufsicht stimmen? + options: + - text: „Players look in the direction they are moving“ gilt weiter. Der Blick voraus ist durch den Bildausschnitt begrenzt. + correct: true + why: Wer läuft, schaut in Laufrichtung. In der Draufsicht reicht der Blick dorthin nur bis zum Bildrand, bei mittiger Figur 160 Pixel zur Seite und 90 nach oben. + - text: „Players focus on contrast“ gilt unverändert, für Helligkeit, Farbe, Form, Licht und Bewegung. + correct: true + why: Kontrast wirkt in jeder Perspektive. Die Mittel dieses Moduls hängen alle an dieser Regel. + - text: „Players don’t look upwards“ gilt in der Draufsicht genauso, deshalb sehen Spieler die obere Bildhälfte kaum. + correct: false + why: In der Draufsicht gibt es kein Nach-oben-Schauen, die Kamera ist fest. Die obere Bildhälfte ist im Bild wie die untere. Die Grenze des Blicks ist der Bildrand. + - text: Die Regeln sagen voraus, dass Spieler dem stärksten Kontrast auch folgen. + correct: false + why: Die Regeln beschreiben, wohin der Blick geht. Ob der Spieler dorthin läuft, ist eine zweite Frage. Das Buch schätzt solche Hilfen auf 35 bis 40 Prozent und verweist auf den Playtest. + explanation: | + Die zweite und dritte Regel tragen in die Draufsicht, die erste verschiebt sich zum Bildrand. Alle drei beschreiben den Blick, nicht das Verhalten. Zwischen „hat es gesehen“ und „ist hingegangen“ liegt die Lücke, die du im Playtest misst. + hints: + - Zwei Aussagen sind richtig. + - Kann die Kamera in einem Top-down-Spiel nach oben kippen? + resources: + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding + + - id: rote-tuer + type: choice + title: Die rote Tür in der Wiese + prompt: | + Lehrbeispiel: Eine rote Tür steht in einer grünen Wiese. Auf der Neunerskala (1 hell, 9 fast schwarz) haben beide den Tonwert 5. Tester laufen an der Tür vorbei. Welche Änderung hilft am ehesten, ohne die Stelle direkter zu markieren? + options: + - text: Die Tür auf Tonwert 2 aufhellen oder die Wiese rund um die Tür auf 7 abdunkeln. + correct: true + why: Dann trennt sie der Tonwert, und sie fällt auch in Graustufen auf. Farbe verstärkt den Kontrast danach nur noch. + - text: Das Rot der Tür satter machen. + correct: false + why: Sättigung ändert den Tonwert nicht. In Graustufen bleibt die Tür so hell wie die Wiese, und auch farbig bleibt der Abstand klein. + - text: Mehr rote Blumen in der Wiese verteilen, damit Rot als Farbe des Abschnitts auffällt. + correct: false + why: Jede rote Blume ist ein weiterer Lockvogel. Die Tür verliert ihr einziges Merkmal. + - text: Einen leuchtenden Pfeil über die Tür setzen. + correct: false + why: Das ist eine stärkere, direktere Hilfe. Das Level Design Book rät, mit subtilen Mitteln zu beginnen und stärkere erst nach dem Playtest zu nehmen. Hier fehlt zuerst der Kontrast. + explanation: | + Gleich helle Farben verschmelzen in Graustufen und schwächen sich auch farbig gegenseitig. Die erste Frage ist deshalb, wie weit Tür und Umgebung auf der Skala auseinanderliegen. Erst wenn der Tonwert trägt und Tester die Tür trotzdem nicht finden, ist eine stärkere Markierung dran. + hints: + - Was sieht man von der Tür, wenn man die Farbe wegnimmt? + resources: + - title: The Level Design Book · Wayfinding aids + url: https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids + + - id: tonwerte-planen + type: order + title: Ein Bildschirm in Tonwerten + prompt: | + Du planst die Blickführung für einen Bildschirm im Blockout. Bring die Schritte in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Schreib die Absicht für diesen Bildschirm in einem Satz auf. + Leg fest, welche Stelle der Hauptpunkt ist. + Leg Boden und Wände in einen engen Tonwertbereich. + Gib dem Hauptpunkt den stärksten Kontrast im Bild. + Setz höchstens zwei Nebenpunkte mit schwächerem Kontrast. + Prüf das Standbild in Graustufen und mit zusammengekniffenen Augen. + Lass jemanden ohne Erklärung spielen und schau, wohin er geht. + alternatives: + - [1, 3, 2, 4, 5, 6, 7] + explanation: | + Der Hauptpunkt folgt aus der Absicht, deshalb steht der Satz am Anfang. Ob du zuerst den Hauptpunkt wählst oder zuerst den ruhigen Grund festlegst, ist gleichwertig. Der stärkste Kontrast hängt aber von beiden ab, und Nebenpunkte ordnest du dem Hauptpunkt unter. Die Proben am Standbild sind schnell und billig, deshalb kommen sie vor dem Playtest. Erst der Playtest zeigt, ob Spieler dem Blick auch folgen. + hints: + - Woraus folgt, welche Stelle der Hauptpunkt ist? + resources: + - title: The Level Design Book · Massing, Hierarchy + url: https://book.leveldesignbook.com/process/blockout/massing#hierarchy + + - id: lockvogel-modell + type: output + title: Wer gewinnt den Blick? + prompt: | + Lehrbeispiel: eine Tonwertkarte mit vier Zeilen zu je fünf Tiles, Neunerskala (1 hell, 9 fast schwarz). Die 3 in Zeile 2 ist der Ausgang, die 1 in Zeile 1 eine Laterne ohne Bedeutung, Zeilen und Spalten gezählt ab 0. Das Modell gibt für jedes Tile, das nicht Boden ist, Zeile, Spalte und den Abstand zum mittleren Tonwert der Karte aus. Was gibt es aus? + lang: python + code: | + # Neunerskala: 1 hell, 9 dunkel + karte = ["77777", + "71777", + "77737", + "77777"] + werte = [] + for zeile in karte: + werte += map(int, zeile) + mittel = sum(werte) / len(werte) + for i, w in enumerate(werte): + if w != 7: + d = abs(w - mittel) + print(i // 5, i % 5, d) + expected: | + 1 1 5.5 + 2 3 3.5 + hints: + - 18 Tiles mit 7, dazu eine 1 und eine 3. Die Summe ist 130, der Mittelwert 6,5. + - "`i // 5` ist die Zeile, `i % 5` die Spalte." + explanation: | + Der Mittelwert liegt bei 6,5. Die Laterne ist 5,5 Stufen davon entfernt, der Ausgang 3,5. Die Laterne ist der stärkste Kontrast. Es ist grob: Es vergleicht nur mit dem Durchschnitt und kennt weder Größe noch Licht, Bewegung oder Lage im Bild. Für einen ersten Blick reicht es aber. Liegt ein Lockvogel weiter vom Grund entfernt als dein Hauptpunkt, gewinnt er den Blick, und du dunkelst ihn ab oder hellst den Ausgang auf. + resources: + - title: The Level Design Book · Wayfinding, Psychology + url: https://book.leveldesignbook.com/process/blockout/wayfinding#psychology + + - id: vorlauf-drag + type: output + title: Breite Drag-Ränder + prompt: | + Die Kamera hat seitlich breitere Drag-Ränder als oben, rechts 0,5 und oben 0,2. Alle Werte sind Platzhalter. Was gibt das Modell aus? + lang: python + code: | + BREITE, HOEHE = 320, 180 + TILE = 16 + + def voraus(halb, drag): + return halb - drag * halb + + rechts = voraus(BREITE / 2, 0.5) + oben = voraus(HOEHE / 2, 0.2) + print(rechts, rechts / TILE) + print(oben, oben / TILE) + expected: | + 80.0 5.0 + 72.0 4.5 + hints: + - Ein Drag-Rand ist ein Anteil am halben Bild. Die Hälfte von 160 Pixeln ist 80. + explanation: | + Mit `drag_right_margin = 0.5` läuft die Figur 80 Pixel aus der Mitte, bevor die Kamera folgt. Beim Laufen nach rechts steht sie dann dort, und voraus bleiben 80 Pixel, 5 Tiles. Nach oben mit 0,2 bleiben 72 Pixel, viereinhalb Tiles. Breite Ränder beruhigen die Kamera bei kleinen Bewegungen, kosten aber Blick voraus. Ob dir Ruhe oder Vorlauf wichtiger ist, entscheidest du. + resources: + - title: Godot Docs · Camera2D, drag_right_margin + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-drag-right-margin + + - id: sekunden-voraus + type: output + title: Wie viel Zeit bleibt? + prompt: | + Mit den Standard-Drag-Rändern von 0,2 siehst du beim Laufen nach rechts 128 Pixel voraus. Die Figur läuft 90 Pixel pro Sekunde (Platzhalter). Wie viele Sekunden vergehen, bis sie die Stelle erreicht, die gerade am rechten Bildrand erscheint? Runde auf eine Nachkommastelle und antworte mit der Zahl. + lang: text + code: | + Sekunden = Pixel / (px/s) + Pixel 128 + px/s 90 + expected: | + 1.4 + accept: ["1,4", "1,4 s", "1.4 s", "1,4 Sekunden"] + explanation: | + 128 / 90 = 1,42 Sekunden. Ohne Drag wären es 160 / 90 = 1,78, also fast zwei Sekunden. Der Unterschied von gut einer Drittelsekunde klingt klein, aber er ist die Zeit, in der ein Spieler einen Abzweig bemerkt und sich entscheidet. Liegt ein Hauptpunkt an einer Stelle, an der er schnell reagieren soll, rechne mit dem kürzeren Wert. + + - id: begriffe-blick + type: gap + title: Fünf Begriffe zum Blick + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Die Helligkeit einer Fläche ohne Farbe heißt ⟦Tonwert⟧. Die Stelle eines Bildschirms, zu der der Blick zuerst gehen soll, ist der ⟦Hauptpunkt⟧. Ein auffälliger Punkt ohne Bedeutung, der den Blick abzieht, ist ein ⟦Lockvogel⟧. Viele kleine, gleich starke Kontraste ergeben visuelles ⟦Rauschen⟧. In Godot lassen die ⟦Drag-Ränder⟧ der Kamera die Figur aus der Bildmitte laufen, bevor die Kamera folgt. + gaps: + - label: Helligkeit + hint: Die Pixelart-Skala hat davon neun Stufen. + accept: ["Helligkeitswert", "Wert", "Value"] + - label: wichtigste Stelle + hint: Es gibt pro Bildschirm genau einen davon. + accept: ["Blickpunkt", "Fokuspunkt", "Blickziel", "Schwerpunkt", "Fokus"] + - label: falscher Hinweis + hint: Ein Wort aus der Jagd. + accept: ["Köder", "Ablenkung", "Decoy", "Störer"] + - label: zu viel von allem + hint: Ein Begriff aus der Bild- und Tontechnik. + accept: ["Bildrauschen", "Noise", "Unruhe"] + - label: Kamera-Einstellung + hint: Englisch heißen sie „drag margins“. + accept: ["Drag Ränder", "Drag-Margins", "Drag Margins", "drag margins", "Ränder", "Drag-Margin"] + explanation: | + Tonwert, Hauptpunkt und Ruhe bilden die Hierarchie eines Bildes. Lockvogel und Rauschen sind die beiden Arten, sie zu stören: ein einzelner falscher Punkt oder zu viele gleich laute. Die Drag-Ränder gehören dazu, weil sie bestimmen, wie viel vom Bild in Laufrichtung überhaupt zu sehen ist. + resources: + - title: Godot Docs · Camera2D + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html + + - id: laterne-zieht + type: bug + title: Der Blick geht woandershin + prompt: | + Lehrbeispiel: Tonwertkarte eines Bildschirms, 20 × 11 Tiles, Neunerskala (1 hell, 9 fast schwarz). Wände sind 9, der Boden 7. Absicht: Der Blick soll zuerst zum Ausgang am rechten Rand gehen, Tonwert 3 in Zeile 6. In Tests schauen fast alle zuerst woandershin. Eine Zeile enthält, was dem Ausgang den Blick stiehlt. Finde sie. + lang: text + code: | + 99999999999999999999 + 97777777777777777779 + 97777777777777777779 + 97717777777777777779 + 97777777777777777779 + 97777777777777777773 + 97777777777777777779 + 97777777777777777779 + 97777777777777777779 + 97777777777777777779 + 99999999999999999999 + lines: [4] + explanation: | + In Zeile 4 steht links eine 1, sechs Stufen heller als der Boden. Der Ausgang mit 3 ist nur vier Stufen heller. Die 1 ist der stärkste Kontrast im Bild und damit der Hauptpunkt, ob du willst oder nicht. Abhilfe ist eine von zwei Änderungen: die 1 abdunkeln, etwa auf 6, oder den Ausgang heller machen als alles andere. Welche du nimmst, hängt daran, ob die helle Stelle links etwas bedeuten soll. + hints: + - Such die Ziffer, die am weitesten von 7 entfernt ist. + + - id: wasser-am-rand + type: bug + title: Ein Blickplan mit einer Zeile zu viel + prompt: | + Lehrbeispiel: Blickplan für einen Bildschirm, Neunerskala (1 hell, 9 fast schwarz). Tester schauen zuerst nach unten statt zum Tor. Eine Zeile widerspricht der Hierarchie. Finde sie. + lang: prose + code: | + Absicht: Der Spieler soll den Ausgang oben links zuerst sehen. + Hauptpunkt: Tor oben links, Tonwert 2, einziges Licht im Bild. + Nebenpunkt: Truhe im Seitengang rechts, Tonwert 5. + Boden: Tonwerte 6 bis 8, ohne Muster. + Wände: Tonwert 9, ohne Fenster. + Wasser: Tonwert 2, animiert, über die ganze Unterkante. + lines: [6] + explanation: | + Das Wasser ist so hell wie das Tor, bewegt sich und läuft über die ganze Breite. Es hat damit zwei Mittel, die das Tor nicht hat: Bewegung und Fläche. Es konkurriert nicht nur mit dem Hauptpunkt, es schlägt ihn. Abhilfe ist ein dunklerer Tonwert für das Wasser, weniger Fläche oder weniger Bewegung. Die übrigen Zeilen passen zur Faustregel: ein Hauptpunkt, ein schwächerer Nebenpunkt, ruhiger Boden und Wände. + hints: + - Welche Zeile hat denselben Tonwert wie der Hauptpunkt? + resources: + - title: Jason Mitchell, „Connecting Visuals to Gameplay at Valve“ (Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf + + - id: zu-viel-kontrast + type: explain + title: Weniger helle Stellen + prompt: | + Hier stehen Texte nach den Folien von Jason Mitchells Vortrag über Left 4 Dead (MIGS 2008). Erkläre in drei bis fünf Sätzen, was Valve zwischen dem frühen und dem fertigen Bild geändert hat, warum das der Orientierung hilft und was daraus für einen Raum in der Draufsicht folgt. + lang: prose + code: | + Lighting for Darkness + • Aid navigation + • Players tend to follow the light + + Too many areas of contrast – Early production screenshot + Simplified lighting – Final look + points: + - Im frühen Bild gab es zu viele kontrastreiche Stellen, kein Punkt setzte sich durch. + - Das fertige Bild hat weniger helle Stellen, und jede davon hat einen Grund. + - Weil Spieler dem Licht folgen, ist jede helle Stelle ein Hinweis. Wenige Lichter heißen wenige, klare Hinweise. + - In der Draufsicht heißt das, einen Hauptpunkt zu beleuchten und den Rest ruhig zu halten, und dann im Playtest zu prüfen, ob Spieler folgen. + explanation: | + Valve hat Licht weggenommen, nicht hinzugefügt. Im frühen Bild konkurrierten viele helle Flächen, und der Blick fand kein Ziel. Im fertigen Bild ist Licht selten und deshalb bedeutsam. Weil Spieler laut Mitchell dem Licht folgen, wird jede helle Stelle zu einem Vorschlag, wohin es geht. Für einen Raum in der Draufsicht folgt daraus die Faustregel dieses Moduls: eine helle Stelle für den Hauptpunkt, wenige schwächere für Nebenpunkte, der Rest in einem engen, dunklen Bereich. Ob Spieler dem Licht auch hier folgen, misst du im Playtest. + hints: + - Hat Valve mehr Licht gesetzt oder weniger? + resources: + - title: Jason Mitchell, „Connecting Visuals to Gameplay at Valve“ (MIGS 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf + + - id: drag-erklaeren + type: explain + title: Warum sehe ich so wenig voraus? + prompt: | + Ein Tester sagt: „Beim Laufen tauchen Abzweige immer erst auf, wenn ich fast daran vorbei bin.“ Die Kamera hat diese Einstellungen. Erkläre in drei bis fünf Sätzen, was sie bewirken und welche Möglichkeiten du hast. + lang: text + code: | + anchor_mode = Drag Center + drag_horizontal_enabled = true + drag_left_margin = 0.2 + drag_right_margin = 0.2 + position_smoothing_enabled = true + points: + - Mit Drag folgt die Kamera erst, wenn die Figur 20 Prozent des halben Bildes aus der Mitte gelaufen ist. Beim Laufen steht die Figur vor der Mitte. + - Dadurch schrumpft der Blick voraus zur Seite von 160 auf 128 Pixel, die Glättung lässt die Kamera zusätzlich hinterherlaufen. + - Möglichkeiten sind Drag aus, kleinere Ränder, eine Vorlaufkamera per `offset` oder Abzweige, die früher ins Bild kommen. + - Welche Möglichkeit passt, ist eine Designentscheidung, die du mit einem neuen Test prüfst. + explanation: | + Die Drag-Ränder lassen die Figur 32 Pixel aus der Mitte laufen, bevor die Kamera folgt. Wer nach rechts läuft, steht deshalb rechts der Mitte und sieht 128 statt 160 Pixel voraus, mit der Glättung noch etwas weniger. Der Tester beschreibt genau das. Ich kann Drag abschalten, die Ränder verkleinern, ein Skript schreiben lassen, das die Kamera per `offset` in Laufrichtung schiebt, oder die Abzweige so legen, dass sie mit diesem Blick rechtzeitig erscheinen. Was davon passt, hängt davon ab, wie ruhig die Kamera sein soll. Ich ändere eine Sache und teste neu. + hints: + - Wo steht die Figur im Bild, während sie gleichmäßig nach rechts läuft? + resources: + - title: Godot Docs · Camera2D, drag_horizontal_enabled + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-drag-horizontal-enabled + - title: Godot Docs · Camera2D, offset + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-offset + + - id: screenshot-pruefen + type: practice + title: Ein fremdes Bild in Graustufen + prompt: | + Mach einen Screenshot aus einem veröffentlichten Top-down-Spiel, an der Stelle, an der ein neuer Raum ins Bild kommt. Stell ihn am Handy auf Graustufen und kneif die Augen zusammen. Notier in höchstens fünf Stichpunkten, was du findest. + lang: prose + starter: | + Spiel und Stelle: + Hauptpunkt (Mittel): + Nebenpunkte: + Lockvögel oder Rauschen: + Übersteht der Hauptpunkt Graustufen? + checklist: + - Spiel und Stelle sind genannt. + - Du nennst einen Hauptpunkt und das Mittel, das ihn trägt (Tonwert, Licht, Bewegung, Linie, Rahmung). + - Du nennst höchstens zwei Nebenpunkte. + - Du sagst, ob es einen Lockvogel oder Rauschen gibt, und wo. + - Du hast notiert, ob der Hauptpunkt in Graustufen der stärkste Kontrast bleibt. + explanation: | + Veröffentlichte Spiele sind gute Lehrer, weil ihre Hierarchie getestet ist. Bleibt der Hauptpunkt in Graustufen stark, trägt ihn der Tonwert. Verschwindet er, trägt ihn Farbe oder Bewegung, und das Standbild zeigt dir, wie viel davon abhängt. Was der Raum vermutlich will, liest du mit der Methode aus [Level lesen](/level-design/raum-lesen). + hints: + - Viele Handys haben den Graustufenmodus in den Bedienungshilfen, die Galerie-App einen Schwarz-Weiß-Filter. + resources: + - title: The Level Design Book · Massing, Readability + url: https://book.leveldesignbook.com/process/blockout/massing#readability + + - id: tonwertkarte-eigene + type: practice + title: Deine Tonwertkarte + prompt: | + Zeichne auf Karopapier eine Tonwertkarte für einen Bildschirm, 20 × 11 Kästchen, ein Kästchen pro Tile, eine Ziffer der Neunerskala pro Kästchen. Nimm einen Abschnitt, an dem du arbeitest, oder eine freie Übungsfläche; was dort steht und welche Stelle der Hauptpunkt ist, entscheidest du. Hier notierst du nur Absicht und Werte in wenigen Zeilen. + lang: prose + starter: | + Absicht (ein Satz): + Hauptpunkt (Ort, Tonwert): + Nebenpunkte (Ort, Tonwert): + Boden und Wände (Tonwerte): + Ergebnis der Graustufen- und Unschärfeprobe: + checklist: + - Die Absicht ist ein Satz, der sagt, was der Spieler zuerst sehen soll. + - Genau ein Hauptpunkt hat den größten Abstand zum Tonwert des Bodens. + - Es gibt höchstens zwei Nebenpunkte, beide mit kleinerem Abstand als der Hauptpunkt. + - Boden und Wände liegen in einem engeren Tonwertbereich, als der Abstand zwischen Hauptpunkt und Boden beträgt. + - Du hast die Skizze fotografiert, in Graustufen und mit zusammengekniffenen Augen angesehen und das Ergebnis notiert. + explanation: | + Die Karte ist ein Blockout auf Papier. Sie prüft die Hierarchie, bevor es Tiles gibt. Was sie nicht prüfen kann, ist der Weg: wann der Hauptpunkt beim Laufen ins Bild kommt und ob Spieler ihm folgen. Dafür baust du den Bildschirm später im [Blockout](/level-design/blockout) nach und lässt jemanden spielen. + hints: + - Fang mit Boden und Wänden an. Der Hauptpunkt fällt erst auf, wenn der Grund ruhig ist. + resources: + - title: The Level Design Book · Environment Art + url: https://book.leveldesignbook.com/process/env-art diff --git a/content/level-design/modules/blockout.yaml b/content/level-design/modules/blockout.yaml new file mode 100644 index 0000000..b317219 --- /dev/null +++ b/content/level-design/modules/blockout.yaml @@ -0,0 +1,558 @@ +id: blockout +title: "Blockout in Godot: graue Formen und Platzhalter-Tiles" +level: 2 +minutes: 150 +summary: Aus deiner Skizze einen begehbaren Abschnitt in Godot bauen – mit flachen Tonwerten statt Grafik, getrennten Ebenen für Boden, Wände, Hinweise und Notizen, einer Kamera mit Grenzen und einem Maßstabsraum, billig genug, um ihn nach jedem Test umzubauen. +place: pc +goals: + - Du erklärst, warum ein Blockout das Layout prüft und nicht die Grafik, und hältst ihn getrennt von der späteren Ausgestaltung. + - Du legst ein Platzhalter-TileSet an, in dem jede Kategorie deiner Blockout-Vokabel genau eine flache Tile hat, wo nötig mit einer einfachen Formmarke. + - Du baust einen Abschnitt aus den getrennten Ebenen `Ground`, `Walls` und `Cues` und hältst Notizen mit `Marker2D` und `Label` fest, die im Spiel ausgeblendet sind. + - Du setzt die Grenzen der Kamera aus der bemalten Fläche und rechnest aus, wie viele Bildschirme ein Abschnitt hat. + - Du läufst jeden Blockout selbst mit der Spielfigur ab und sicherst jede Runde in Git. +resources: + - title: The Level Design Book · Blockout + url: https://book.leveldesignbook.com/process/blockout + - title: Godot Docs · Using TileMaps + url: https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html + - title: Godot Docs · TileMapLayer + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html + - title: Godot Docs · Camera2D + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html + - title: Joel Burgess, Nate Purkeypile · Skyrim's Modular Level Design (Folien, GDC 2013) + url: https://www.slideshare.net/slideshow/gdc2013-kit-buildingfinal/17728576 +lesson: | + Lehrbeispiel: Auf deinem Karopapier steht ein Hof, 20 × 12 Kästchen, mit einem Tor rechts und einem Gang nach unten, ein Kästchen breit. Auf Papier sieht alles klar aus. In Godot läufst du los und merkst drei Dinge auf einmal: Der Hof passt fast ganz in ein Bild, also siehst du das Tor, das eine Entdeckung sein sollte, vom ersten Moment an. Der Gang, ein Kästchen breit, wirkt in Bewegung enger als auf Papier. Und die Fläche in der Mitte, die nach Platz aussah, durchquerst du in gut drei Sekunden. + + Das Level Design Book sagt es knapp: „You can't playtest a design document or a layout sketch, but you can playtest a blockout“ ([Blockout](https://book.leveldesignbook.com/process/blockout)). Ein **Blockout** ist die begehbare Rohfassung eines Levels aus einfachen Formen, ohne Details und ohne fertige Grafik. In diesem Modul baust du die Skizze aus [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze) in Godot nach, mit grauen Tiles. Du brauchst Godot 4.7 am PC und das Testgelände aus [Ein fremdes Projekt erkunden](/godot/projekt-erkunden). Die zwei Skripte hier sind technisches Gerüst, eine KI darf sie schreiben. Wo eine Wand steht, wie breit ein Gang ist und was ein Hinweis zeigt, entscheidest du. Alle Zahlen sind Platzhalter: Tiles 16 × 16, Spielbild 320 × 180, Figur mit 90 Pixeln pro Sekunde. + + ## Warum grau: billig ändern, Layout statt Grafik prüfen + + Das Level Design Book beschreibt den Blockout für 3D als „rough draft level built with simple 3D shapes, but without any details or polished art assets“. In der Draufsicht heißt das: flache Tiles in wenigen Tonwerten, dazu einfache Polygone für Formen, die nicht ins Raster passen. Der Grund steht im selben Abschnitt: Grobe Blockout-Geometrie zu löschen oder neu zu bauen ist „cheap“, fertige Grafik wegzuwerfen ist „expensive“ und verschwenderisch. + + Billig heißt hier zweierlei. Eine graue Wand verschiebst du in Sekunden, und es tut dir nicht leid um sie. Mit fertiger Pixelart zögerst du, und ein Gang, der zu schmal ist, bleibt schmal, weil das Umzeichnen Stunden kostet. Weiter unten steht ohne Umschweife: „99% of the time, your blockout will not survive a playtest.“ Räume fühlen sich falsch an, Türen sind zu eng, das Layout verwirrt. Genau dafür baust du ihn. + + Ein Blockout beantwortet Fragen zum Raum: Passt die Figur durch? Sieht der Spieler das Tor, bevor er davorsteht? Wie lange dauert der Weg? Welchen Weg nehmen Tester, die deine Absicht nicht kennen? Er beantwortet nicht, ob der Ort schön ist oder welche Stimmung er hat. Das kommt in [Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung), nachdem der Blockout einen Test bestanden hat. Fertige Pixelart brauchst du für dieses Modul nicht. + + > [!MERKE] + > Der Blockout klärt, ob Spieler tun, was du beabsichtigst. Die Ausgestaltung klärt, wie der Ort aussieht. Wer beides zugleich baut, weiß nach einem Test nicht, ob das Layout oder die Grafik gewirkt hat. + + ## Ein Platzhalter-TileSet aus flachen Tonwerten + + Wie du ein TileSet aus einem Bild anlegst, Tilegröße einstellst und Wand-Tiles eine Physik-Ebene gibst, zeigt [2D-Level aus Tiles](/godot/level-tilemap). Für den Blockout zeichnest du dir ein zweites, kleines Atlasbild mit einem Feld pro Kategorie deiner Blockout-Vokabel aus [Umgebung als Information](/level-design/umgebung-informiert): ein flacher Tonwert, wo die Vokabel es verlangt mit einer einfachen Formmarke wie einem Kreis oder einem Gitter. Das Level Design Book rät, Wände in einer anderen Farbe als den Boden zu zeigen, und fügt hinzu: „If you are afraid of colors affecting your blockout too much, then at least use textures with different shades of gray.“ + + Jede Kategorie bekommt genau eine Tile. Das Lehrbeispiel dieses Moduls benutzt die sechs Kategorien der Vorlage aus „Umgebung als Information“ mit diesen Platzhaltern: + + | Kategorie | Zeichen in der Rasterkarte | Platzhalter im Lehrbeispiel | Ebene | Kollision | + | --- | --- | --- | --- | --- | + | begehbar | `.` `+` `S` | mittleres Grau `#8c8c8c` | `Ground` | nein | + | blockiert hoch | `#` | dunkles Grau `#3c3c3c` | `Walls` | ja | + | blockiert tief | `o` `~` | Grau `#646464` | `Walls` | ja | + | gefährlich | – | fast Schwarz `#1e1e1e` mit hellem Gitter | `Walls`, wenn es den Weg sperrt, sonst `Ground` | nur auf `Walls` | + | benutzbar | – | mittleres Grau mit dunklem Kreis | `Walls`, wenn es den Weg sperrt, sonst `Ground` | nur auf `Walls` | + | Hinweis | `!` | helles Gelb `#f0d23c` | `Cues` | nein | + + Im Lehrbeispiel ist alles, was blockiert, dunkler als der Boden, gefährlich und benutzbar tragen zusätzlich eine Form, und der Hinweis ist die hellste Fläche. Ob dein Hinweis heraussticht, prüfst du mit einem Screenshot aller Tiles in Graustufen und mit zusammengekniffenen Augen, wie in [Komposition und Blickführung](/level-design/blickfuehrung). Warum der Tonwert vor der Farbe kommt, erklärt [Licht, Schatten und Tonwerte](/pixelart/licht-werte). Die Tabelle ist ein Lehrbeispiel; deine eigene Vokabel ersetzt sie. + + So sieht der Hof aus dem Einstieg als Rasterkarte aus, ein Zeichen pro Tile, 20 Zeichen sind ein Bildschirm breit: + + ```text + #################### + #..................# + #..oo.........~~~..# + #..oo.........~~~..# + #S.................+ + #.......!..........# + #..................# + ######.############# + ######.############# + ######.############# + ######!############# + ######+############# + ``` + + Legende: `#` Wand, `.` Boden, `o` niedriges Hindernis, `~` Wasser oder Abgrund, `+` Durchgang, `S` Start, `!` beabsichtigter Hinweis. In Godot wird daraus: Boden und Durchgänge auf `Ground`, `#`, `o` und `~` auf `Walls`, jedes `!` auf `Cues` über dem Boden. `S` ist die Position der Figur. + + ## Getrennte Ebenen: Ground, Walls, Cues und Notizen + + Ein `TileMapLayer` zeigt in jeder Zelle höchstens eine Tile. Mehrere Ebenen sind mehrere Nodes ([Multiple TileMapLayers and settings](https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html#multiple-tilemaplayers-and-settings)). Für den Blockout bekommt jede Aufgabe ihre eigene Ebene, mit englischen Node-Namen wie im Godot-Kurs: + + ```text + Main (Node2D) + ├── Ground (TileMapLayer) Boden, keine Kollision + ├── Cues (TileMapLayer) Hinweise, collision_enabled aus + ├── Objects (Node2D) y_sort_enabled + │ ├── Walls (TileMapLayer) Wände und Hindernisse, mit Kollision + │ └── Player Figur aus dem Testgelände + ├── Notes (Node2D) notes.gd, im Spiel aus + │ └── Note1 (Marker2D) + │ └── Label + └── CameraLimits (Node) camera_limits.gd + ``` + + Die Trennung hat drei Gründe. Erstens kollidiert nur `Walls`. `Cues` bekommt im Inspektor *Collision Enabled* aus ([collision_enabled](https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-property-collision-enabled)); ein Hinweis darf den Weg nicht verändern, sonst misst dein Test die Sperre statt des Hinweises. Zweitens blendest du mit dem Augensymbol im Szenen-Dock jede Ebene aus und siehst, was der Raum ohne Hinweise sagt. Drittens kommt später eine Ebene `Dressing` für die Ausgestaltung dazu, und `Ground` und `Walls` bleiben dabei, was sie sind. Warum `Walls` unter `Objects` hängt und Y-sortiert ist, steht in [2D-Level aus Tiles](/godot/level-tilemap). + + Nicht alles passt ins Raster. Eine schräge Kante, eine große Landmarke oder ein Platz, der kein Rechteck ist, entsteht als [`Polygon2D`](https://docs.godotengine.org/en/stable/classes/class_polygon2d.html) oder `ColorRect` in einem der Tonwerte. Soll die Form blockieren, braucht sie einen Körper mit Kollisionsform wie die Kiste im Testgelände ([Kollisionen und Trefferzonen](/godot/kollision-ebenen)). + + ### Notizen im Editor, aus im Spiel + + Für Notizen eignet sich der `Marker2D`. Die Doku nennt ihn „Generic 2D position hint for editing“, im Editor erscheint er immer als Kreuz ([Marker2D](https://docs.godotengine.org/en/stable/classes/class_marker2d.html)). Ein `Label` als Kind trägt den Text: Wegpunkte des erwarteten Wegs, „Hier soll das Tor zu sehen sein“, eine Frage für den Test. Eine verwandte Idee beschreibt Joel Burgess: Für das Projekt nach Skyrim führte Bethesda „Helper Markers“ für seine Baukästen ein, „editor-only markup that can help convey meaningful information about the kit“, etwa wie Teile zusammenpassen ([Transkript des GDC-Vortrags](http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html)). Dort tragen die Marker Wissen über Bauteile, bei dir Wissen über deine Absicht; in beiden Fällen sieht sie nur, wer im Editor baut. + + Tester sollen deine Notizen nicht sehen. Dieses Skript am Node `Notes` blendet sie beim Start aus und mit einer Taste wieder ein: + + ```gdscript title=notes.gd + extends Node2D + + ## Notizen im Blockout: im Editor sichtbar, im laufenden Spiel zuerst aus. + ## Die Aktion toggle_notes blendet sie ein und aus. Technisches Gerüst. + + + func _ready() -> void: + visible = false + + + func _unhandled_input(event: InputEvent) -> void: + if event.is_action_pressed(&"toggle_notes"): + visible = not visible + print("Notizen sichtbar: ", visible) + ``` + + Leg dafür in der Eingabe-Zuordnung die Aktion `toggle_notes` an, im Lehrbeispiel auf der Taste N. `_ready()` läuft nur im Spiel, also bleiben die Notizen im Editor sichtbar. `_unhandled_input()` bekommt Eingaben, die keine Oberfläche verbraucht hat ([Node._unhandled_input](https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-private-method-unhandled-input)). Kinder wie `Marker2D` und `Label` folgen der Sichtbarkeit ihres Elternknotens ([CanvasItem.visible](https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-visible)). Mit Godot 4.7.2 nachgeprüft: Nach dem Start ist `Notes` aus, ein Druck auf die Aktion schaltet es ein, und die Ausgabe zeigt `Notizen sichtbar: true`. + + > [!WARNING] Notiz oder Hinweis? + > Was der Spieler sehen soll, gehört auf `Cues`, nie in `Notes`. Eine Notiz, die beim Test sichtbar ist, erklärt den Raum, und du misst deine Erklärung statt deines Layouts. + + ## Die Kamera an der bemalten Fläche begrenzen + + Die Kamera des Testgeländes hängt an der Figur. Am Rand des Abschnitts zeigt sie sonst, was hinter dem Boden liegt, also nichts. `Camera2D` hat dafür Grenzen in Pixeln: `limit_left`, `limit_top`, `limit_right`, `limit_bottom` ([Camera2D.limit_left](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-limit-left)). Statt sie nach jeder Änderung von Hand nachzutragen, liest ein kleines Skript sie aus `Ground`: + + ```gdscript title=camera_limits.gd + extends Node + + ## Setzt die Grenzen der aktiven Kamera auf die bemalte Fläche von Ground. + ## Technisches Gerüst: Welche Fläche du bemalst, entscheidest du. + + @export var ground: TileMapLayer + + + func _ready() -> void: + var camera := get_viewport().get_camera_2d() + var rect := ground.get_used_rect() + var tile := ground.tile_set.tile_size + camera.limit_left = rect.position.x * tile.x + camera.limit_top = rect.position.y * tile.y + camera.limit_right = rect.end.x * tile.x + camera.limit_bottom = rect.end.y * tile.y + print("Kamera-Grenzen: ", camera.limit_left, " ", camera.limit_top, " ", camera.limit_right, " ", camera.limit_bottom) + ``` + + Hänge das Skript an einen `Node` namens `CameraLimits` und zieh `Ground` in das Feld *Ground* im Inspektor. Was die Zeilen tun: + + - `get_camera_2d()` liefert die aktive Kamera, hier die an der Figur ([Viewport.get_camera_2d](https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-method-get-camera-2d)). Mit Godot 4.7.2 nachgeprüft: Das klappt auch, wenn `CameraLimits` vor `Objects` im Baum steht, denn alle Nodes sind im Baum, bevor das erste `_ready()` läuft. + - `get_used_rect()` gibt das Rechteck um alle bemalten Zellen zurück, in Zellen, nicht in Pixeln ([TileMapLayer.get_used_rect](https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-method-get-used-rect)). + - `rect.end` ist `position + size`, die Ecke rechts unten, eine Zelle hinter der letzten bemalten ([Rect2i.end](https://docs.godotengine.org/en/stable/classes/class_rect2i.html#class-rect2i-property-end)). Mal Tilegröße ergibt Pixel. + - Das Skript setzt voraus, dass `Ground` bei (0, 0) liegt und nicht skaliert ist. So ist es im Testgelände. + + Gemessen mit Godot 4.7.2: Boden von Zelle (−2, −1) bis (37, 10) bemalt, Ausgabe `Kamera-Grenzen: -32 -16 608 176`. + + ### Wie viele Bildschirme hat ein Abschnitt? + + Das Spielbild ist 320 × 180 Pixel, also 20 × 11,25 Tiles. Ein Abschnitt von 40 × 12 Zellen ist 640 × 192 Pixel groß. Waagerecht hat die Kamera 320 Pixel Spielraum, genau ein zweiter Bildschirm. Senkrecht sind es nur 12 Pixel. Mit 11 Zeilen, also 176 Pixeln, ist die Fläche niedriger als das Bild. Dann zentriert Godot 4.7.2 die Kamera, nachgemessen: Sichtbar ist y = −2 bis 178, oben und unten bleiben je 2 Pixel ohne Boden. Plane deshalb mindestens 12 Zeilen Boden. Das Skript zählt nur Zellen auf `Ground`; bemalst du den Boden auch unter den Wänden, gehören deren Zeilen dazu. + + ## Der Maßstabsraum: Maße, die du ablaufen kannst + + Das Level Design Book unterscheidet bei Metriken die messbaren Werte der Figur: „Player metrics (or physics metrics) are factual numbers measured in-engine like player size, movement speed“ ([Metrics](https://book.leveldesignbook.com/process/blockout/metrics)). Es rät zu einer eigenen Testkarte, einem „metrics zoo“ oder „metrics playground“ ([Build a metrics zoo test map](https://book.leveldesignbook.com/process/blockout/metrics#build-a-metrics-zoo-test-map)), und warnt im selben Text: „metrics are not magic“. + + Bau dir dafür eine eigene Szene, den Maßstabsraum, mit demselben TileSet und derselben Figur. Darin stehen Gänge mit 1, 2 und 3 Tiles Breite, gerade und mit Ecke, Türen mit 1 und 2 Tiles, ein Rahmen aus 20 × 11 Tiles für einen Bildschirm und Markierungen für die Strecke, die die Figur in einer Sekunde läuft (90 Pixel, gut 5,6 Tiles), und für die Ausweichweite (66 Pixel, rund 4 Tiles, aus [Ausweichen, Risiko und Belohnung](/combat/ausweichen)). Mit Godot 4.7.2 nachgeprüft: Die Fußform des Testgeländes, 10 × 6 Pixel, läuft durch einen senkrechten Gang von einer Tile Breite. Dass sie durchpasst, heißt noch nicht, dass sich der Gang gut läuft. Das merkst du erst, wenn du schräg in die Ecken steuerst. Wie du aus diesen Werten Gang- und Arenabreiten ableitest, behandelt [Maßstab, Dichte und Freiflächen](/level-design/massstab-dichte). + + > [!TIP] + > Für Skyrim galt laut Burgess ein Minimum von „two character widths“ für den schmalsten begehbaren Raum, damit zwei computergesteuerte Figuren aneinander vorbeikommen. Das ist eine Regel für deren Spiel, keine für deins. Sie zeigt aber, wie man vorgeht: Eine Mindestbreite wird einmal festgelegt, begründet und im Maßstabsraum geprüft. + + ## Iteration: ablaufen, ändern, sichern + + Das Level Design Book verlangt für jeden Blockout zuerst einen eigenen Test: „walk around the space, within the game engine, with full player gravity, collision, and speed“, und ausdrücklich nicht nur im Editor herumschauen. Für dich heißt das: F5, mit der Figur jeden Gang ablaufen, jede Tür, jede Ecke schräg anlaufen und das Tor aus der Richtung suchen, aus der ein Tester kommt. + + Danach sicherst du den Stand. Die gemalten Zellen speichert Godot binär in `tile_map_data`; ein Diff davon sagt nichts ([2D-Level aus Tiles](/godot/level-tilemap)). Die Commit-Nachricht muss deshalb sagen, was du geändert hast und warum. Vor jedem Test setzt du einen Tag, damit du später weißt, welcher Stand getestet wurde. Wie Tags und Testversionen zusammenhängen, steht in [Testversionen exportieren](/godot/export-sichern). + + ```console + $ git add . + $ git commit -m "Blockout Runde 2: Gang nach unten 2 statt 1 Tile breit" + $ git tag blockout-r2 + ``` + + Leg zu jeder Runde einen Screenshot des Abschnitts in deine Notizen. Wie du Tests mit anderen Menschen führst und Wege aufzeichnest, zeigen [Beobachten, ohne zu erklären](/level-design/playtest-methode) und [Playtest am PC](/level-design/playtest-godot). + + > [!PRAXIS] „Functional-but-ugly“ bei Bethesda + > Joel Burgess und Nate Purkeypile beschreiben, wie Bethesda für Skyrim modulare Baukästen gebaut hat. Das Ziel war, sie so früh wie möglich in einen „functional-but-ugly“ Zustand zu bringen, damit das Level-Design arbeiten kann, während die Grafik ohne Eile ihre Richtung findet. Die ersten Teile, „proof pieces“, haben laut Transkript „almost no mesh detail and usually no textures at all“. Burgess betont auch, wie wichtig es ist, die eigene Arbeit oft zu spielen, „rather than staying editor-side for too long“ ([Transkript](http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html), [Folien](https://www.slideshare.net/slideshow/gdc2013-kit-buildingfinal/17728576)). + + > [!INTERVIEW] + > „Warum zeigst du uns graue Kästen statt eines fertigen Levels?“ Gute Antwort: Weil ich das Layout prüfen will, solange Änderungen billig sind. Grau trennt die Fragen: Passt die Figur durch, sehen Tester den Ausgang, stimmt die Reihenfolge? Hinweise liegen auf einer eigenen Ebene ohne Kollision, Notizen sind im Spiel aus. Hält der Blockout im Playtest, gestalte ich ihn aus und wiederhole denselben Test, um zu sehen, ob die Hinweise die Grafik überleben. + + ## Häufige Fehler + + - **Ausgestaltung im Blockout.** Gras mit drei Varianten, Deko an den Wänden. Der Test misst dann die Grafik mit, und jede Änderung wird teuer. Flache Tonwerte, bis der Blockout einen Test bestanden hat. + - **Hinweise mit Kollision.** Liegt ein Hinweis auf `Walls` oder hat `Cues` Kollision, ändert er den Weg. Nimmst du ihn später weg, ändert sich das Layout mit. + - **Notizen beim Test sichtbar.** Der Tester liest „Tor“ und geht zum Tor. Notizen gehören auf `Notes`, und `Notes` ist im Spiel aus. + - **Kamera ohne Grenzen.** Am Rand zeigt das Bild leere Fläche, die es im Abschnitt nicht gibt. + - **`size` statt `end`.** Beginnt der Boden nicht bei Zelle 0, verschiebt `rect.size` die rechte oder untere Grenze um genau diesen Versatz. + - **Abschnitt niedriger als das Bild.** 11 Zeilen sind 176 Pixel; das Bild ist 180 hoch. Godot zentriert, und oben und unten bleibt ein Streifen. + - **Nur im Editor schauen.** Im Editor siehst du den ganzen Abschnitt von oben. Im Spiel siehst du 20 × 11 Tiles um die Figur. Lauf ihn ab. + - **Kein Commit vor dem Test.** Nach drei Runden weißt du nicht mehr, welcher Stand welche Beobachtung erzeugt hat. + + ## Zusammenfassung + + - Ein Blockout ist die begehbare Rohfassung aus flachen Formen. Er prüft Wege, Breiten, Sicht und Reihenfolge, nicht die Grafik. + - Ein Platzhalter-TileSet hat eine Tile pro Kategorie der Blockout-Vokabel: flache Tonwerte, wo nötig mit einer einfachen Formmarke. Der Hinweis muss im Graustufen- und Unschärfetest herausstechen. + - `Ground`, `Walls` und `Cues` sind getrennte `TileMapLayer`. Nur `Walls` kollidiert. `Dressing` kommt erst nach dem Test dazu. + - Notizen sind `Marker2D` mit `Label` unter `Notes`; `notes.gd` blendet sie im Spiel aus und per Taste ein. + - `camera_limits.gd` setzt die Kameragrenzen aus `get_used_rect()` und `rect.end` mal Tilegröße. + - 320 × 180 sind 20 × 11,25 Tiles. Ein Abschnitt mit weniger als 12 Zeilen ist niedriger als das Bild. + - Der Maßstabsraum zeigt Gänge, Türen, Laufstrecke und Ausweichweite der Figur zum Ablaufen. + - Jede Runde: im Spiel ablaufen, ändern, committen, vor dem Test taggen. +exercises: + - id: was-gehoert-hinein + type: choice + title: Was gehört in den ersten Blockout? + prompt: | + Lehrbeispiel: Du baust den ersten Blockout eines Hofs mit einem Tor als Ausgang. Welche Dinge gehören hinein? + options: + - text: Flache Platzhalter-Tiles, eine pro Kategorie deiner Blockout-Vokabel, etwa begehbar, blockiert hoch und blockiert tief. + correct: true + why: Das ist der Kern eines Blockouts. Jede Fläche hat eine Bedeutung, und keine lenkt mit Details ab. + - text: Eine gelbe Platzhalter-Tile auf `Cues` an der Stelle, an der später eine Laterne das Tor zeigen soll. + correct: true + why: Der beabsichtigte Hinweis gehört schon in den Blockout, sonst testest du einen Raum ohne die Hilfe, die du geplant hast. Als flache Tile ohne Kollision ist er billig zu verschieben. + - text: Fertige Gras-Tiles mit drei Varianten, damit der Hof beim Test nicht so leer wirkt. + correct: false + why: Das ist Ausgestaltung. Der Test misst dann die Grafik mit, und jede Layoutänderung kostet Zeichenarbeit. + - text: Ein `Label` mit „Hier soll der Spieler zuerst das Tor sehen“, das die Tester während des Tests sehen. + correct: false + why: Notizen sind für dich. Sieht der Tester sie, erklärst du ihm den Raum und misst deine Erklärung statt des Layouts. + explanation: | + Ein Blockout enthält alles, was das Verhalten im Raum bestimmen soll: begehbare und blockierte Flächen und die geplanten Hinweise. Er enthält nichts, was nur gut aussehen soll, und nichts, was dem Tester die Absicht verrät. Notizen hältst du trotzdem fest, auf einer eigenen Ebene, die im Spiel aus ist. + hints: + - Frag bei jeder Option, ob sie das Verhalten des Testers prüft oder beeinflusst, ohne Teil des Raums zu sein. + - Zwei Optionen sind richtig. + resources: + - title: The Level Design Book · Blockout + url: https://book.leveldesignbook.com/process/blockout + + - id: erste-runde-ordnen + type: order + title: Von der Skizze zum ersten Test + prompt: | + Bring die Schritte für die erste Blockout-Runde in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Du legst ein TileSet mit den Platzhalter-Tonwerten deiner Blockout-Vokabel an. + Du malst Boden, Wände und Hinweise auf Ground, Walls und Cues. + Du verbindest CameraLimits mit Ground und startest das Spiel. + Du läufst mit der Figur jeden Gang und jede Tür ab, auch schräg in die Ecken. + Du änderst, was nicht passt, und läufst den Abschnitt erneut ab. + Du committest den Stand und markierst ihn mit einem Tag. + Du lässt eine andere Person den Abschnitt spielen und siehst zu. + explanation: | + Ohne Tiles gibt es nichts zu malen, ohne bemalten Boden keine Kameragrenzen. Der eigene Durchlauf kommt vor jedem fremden Test: Fehler, die du selbst findest, etwa ein Gang, in dem die Figur hängen bleibt, kosten keinen Tester. Der Tag vor dem Test sorgt dafür, dass du jede Beobachtung später genau einem Stand zuordnen kannst. + hints: + - Was muss es geben, bevor die Kamera Grenzen bekommen kann? + resources: + - title: The Level Design Book · Blockout, „How to blockout“ + url: https://book.leveldesignbook.com/process/blockout + + - id: zelle-vorhersagen + type: output + title: In welcher Zelle steht die Figur? + prompt: | + `walls` ist ein `TileMapLayer` bei (0, 0) mit Tiles von 16 × 16 Pixeln. Was gibt Godot 4.7 aus? + lang: gdscript + code: | + print(walls.local_to_map(Vector2(171.5, 94))) + print(walls.local_to_map(Vector2(-3, 47.9))) + expected: | + (10, 5) + (-1, 2) + accept: + - | + (10,5) + (-1,2) + hints: + - Teile jede Koordinate durch 16 und runde ab. + - Abrunden heißt auch bei negativen Zahlen zur kleineren Zahl hin. + explanation: | + 171,5 / 16 = 10,7, abgerundet 10; 94 / 16 = 5,9, abgerundet 5. −3 / 16 = −0,19, abgerundet −1; 47,9 / 16 = 2,99, abgerundet 2. Gemessen mit Godot 4.7.2. Mit dieser Rechnung findest du heraus, auf welcher Zelle ein Tester stehen geblieben ist, wenn du nur seine Position in Pixeln hast. + resources: + - title: Godot Docs · TileMapLayer.local_to_map + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-method-local-to-map + + - id: kamera-grenzen-vorhersagen + type: output + title: Wo bleibt die Kamera stehen? + prompt: | + Auf `Ground` (bei (0, 0), Tiles 16 × 16) sind alle Zellen von (−2, −1) bis einschließlich (37, 10) bemalt. Was gibt `camera_limits.gd` aus der Lektion beim Start aus? + lang: gdscript + code: | + var rect := ground.get_used_rect() + var tile := ground.tile_set.tile_size + camera.limit_left = rect.position.x * tile.x + camera.limit_top = rect.position.y * tile.y + camera.limit_right = rect.end.x * tile.x + camera.limit_bottom = rect.end.y * tile.y + print("Kamera-Grenzen: ", camera.limit_left, " ", camera.limit_top, " ", camera.limit_right, " ", camera.limit_bottom) + expected: | + Kamera-Grenzen: -32 -16 608 176 + hints: + - "`rect.position` ist (−2, −1), `rect.size` ist (40, 12)." + - "`rect.end` ist `position + size`, also eine Zelle hinter der letzten bemalten." + explanation: | + Das Rechteck beginnt bei (−2, −1) und ist 40 × 12 Zellen groß, `end` ist also (38, 11). Mal 16 ergibt links −32, oben −16, rechts 608, unten 176. Gemessen mit Godot 4.7.2. Rechts ist 608 und nicht 37 × 16 = 592: Die letzte bemalte Zelle reicht bis zum Pixel 608, und genau dort soll das Bild enden. + resources: + - title: Godot Docs · Rect2i.end + url: https://docs.godotengine.org/en/stable/classes/class_rect2i.html#class-rect2i-property-end + - title: Godot Docs · TileMapLayer.get_used_rect + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-method-get-used-rect + + - id: wie-viele-bildschirme + type: output + title: Wie viel Spielraum hat die Kamera? + prompt: | + Das Modell rechnet aus, um wie viele Pixel die Kamera in einem Abschnitt waagerecht und senkrecht wandern kann. Tiles 16 × 16, Spielbild 320 × 180, beides Platzhalter. Was gibt es aus? + lang: python + code: | + ZELLE = 16 + + def spielraum(spalten, zeilen, bild=(320, 180)): + return spalten * ZELLE - bild[0], zeilen * ZELLE - bild[1] + + for groesse in [(20, 12), (40, 12), (40, 11)]: + print(groesse, spielraum(*groesse)) + expected: | + (20, 12) (0, 12) + (40, 12) (320, 12) + (40, 11) (320, -4) + hints: + - 12 Zeilen sind 192 Pixel, 11 Zeilen sind 176 Pixel. + explanation: | + 20 Spalten sind genau ein Bildschirm breit, die Kamera steht waagerecht still. 40 Spalten geben 320 Pixel Spielraum, also einen zweiten Bildschirm. Senkrecht reichen 12 Zeilen für 12 Pixel Bewegung. Mit 11 Zeilen ist der Abschnitt 4 Pixel niedriger als das Bild; Godot 4.7.2 zentriert die Kamera dann, und oben und unten bleibt je ein Streifen von 2 Pixeln ohne Boden. Diese Rechnung machst du, bevor du malst, nicht nachdem der Rand im Test auffällt. + resources: + - title: Godot Docs · Camera2D.limit_bottom + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-limit-bottom + + - id: grenzen-ergaenzen + type: gap + title: Die Kameragrenzen aus dem Boden lesen + prompt: | + Ergänze die drei Lücken in `camera_limits.gd`. + lang: gdscript + code: | + func _ready() -> void: + var camera := get_viewport().⟦get_camera_2d⟧() + var rect := ground.⟦get_used_rect⟧() + var tile := ground.tile_set.tile_size + camera.limit_left = rect.position.x * tile.x + camera.limit_right = rect.⟦end⟧.x * tile.x + gaps: + - label: aktive Kamera + hint: Eine Methode des Viewports, die die aktive 2D-Kamera liefert. + - label: bemalte Fläche + hint: Eine Methode von `TileMapLayer`, die ein `Rect2i` um alle belegten Zellen liefert. + - label: rechte untere Ecke + hint: Die Eigenschaft von `Rect2i`, die `position + size` ist. + explanation: | + `get_camera_2d()` liefert die aktive Kamera, hier die an der Figur. `get_used_rect()` misst die bemalte Fläche in Zellen, `end` ist ihre Ecke rechts unten. Mit `size` statt `end` wäre die rechte Grenze nur dann richtig, wenn der Boden bei Spalte 0 beginnt. + resources: + - title: Godot Docs · Viewport.get_camera_2d + url: https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-method-get-camera-2d + + - id: notizen-ergaenzen + type: gap + title: Notizen per Taste + prompt: | + Ergänze `notes.gd` so, dass die Aktion `toggle_notes` die Notizen ein- und ausschaltet. + lang: gdscript + code: | + func _ready() -> void: + visible = false + + + func ⟦_unhandled_input⟧(event: InputEvent) -> void: + if event.⟦is_action_pressed⟧(&"toggle_notes"): + ⟦visible = not visible⟧ + gaps: + - label: Eingaben, die keine Oberfläche verbraucht hat + hint: Eine virtuelle Methode von `Node`, beginnt mit Unterstrich. + - label: Aktion gedrückt + hint: Eine Methode von `InputEvent`, die prüft, ob dieses Ereignis eine Aktion drückt. + - label: umschalten + hint: Sichtbarkeit auf das Gegenteil setzen. + accept: ["visible = !visible", "self.visible = not visible", "self.visible = not self.visible", "self.visible = !self.visible", "visible = not self.visible", "set_visible(not visible)"] + explanation: | + `_unhandled_input()` bekommt Tastendrücke, die keine Oberfläche verbraucht hat; für Eingaben im Spiel ist das laut Doku meist die passende Stelle. `is_action_pressed()` prüft das Ereignis gegen die Aktion aus der Eingabe-Zuordnung, nicht gegen eine Taste. `visible = not visible` schaltet um, und alle Kinder folgen. GDScript kennt für die Verneinung `not` und `!`; beide Schreibweisen und `set_visible()` sind mit Godot 4.7.2 nachgeprüft. + resources: + - title: Godot Docs · InputEvent.is_action_pressed + url: https://docs.godotengine.org/en/stable/classes/class_inputevent.html#class-inputevent-method-is-action-pressed + + - id: rechter-rand + type: bug + title: Zwei Tiles Leere am rechten Rand + prompt: | + Der Boden ist von Zelle (−2, −1) bis (37, 10) bemalt. Läufst du ganz nach rechts, zeigt die Kamera am rechten Bildrand einen Streifen von 32 Pixeln ohne Boden. Links, oben und unten stimmt alles. Finde die Zeile und korrigiere sie. + lang: gdscript + code: | + func _ready() -> void: + var camera := get_viewport().get_camera_2d() + var rect := ground.get_used_rect() + var tile := ground.tile_set.tile_size + camera.limit_left = rect.position.x * tile.x + camera.limit_top = rect.position.y * tile.y + camera.limit_right = rect.size.x * tile.x + camera.limit_bottom = rect.end.y * tile.y + lines: [7] + fix: + - line: 7 + answers: + - camera.limit_right = rect.end.x * tile.x + - camera.limit_right = tile.x * rect.end.x + - camera.limit_right = rect.end.x * ground.tile_set.tile_size.x + - camera.limit_right = (rect.position + rect.size).x * tile.x + - camera.limit_right = (rect.position.x + rect.size.x) * tile.x + explanation: | + `rect.size.x` ist die Breite, 40 Zellen, also 640 Pixel. Der Boden endet aber bei Zelle 38, also bei 608 Pixeln, weil er bei −2 beginnt. Die Kamera darf 32 Pixel zu weit. Mit Godot 4.7.2 nachgestellt: Mit `size` zeigt das Bild ganz rechts x = 320 bis 640, mit `end` x = 288 bis 608. Der Fehler fällt nur auf, wenn der Boden nicht bei Spalte 0 beginnt, und genau deshalb bleibt er oft lange unbemerkt. + resources: + - title: Godot Docs · Rect2i.end + url: https://docs.godotengine.org/en/stable/classes/class_rect2i.html#class-rect2i-property-end + + - id: ebenenplan + type: bug + title: Tester laufen um die Markierung herum + prompt: | + Im ersten Test laufen zwei von drei Testern auf die gelbe Markierung vor dem Tor zu, bleiben an ihr stehen und gehen außen herum. Die Markierung soll den Weg zeigen, nicht versperren. Finde die Zeile im Ebenenplan, die das verursacht. + lang: text + code: | + Ground Boden und Durchgänge, mittleres Grau, keine Kollision + Walls Wände, Hindernisse, Abgrund, dunkel, Kollision Ebene 1 + Cues Hinweise, helles Gelb, Kollision Ebene 1 + Notes Marker2D mit Label, im Spiel aus + Dressing kommt erst nach dem getesteten Blockout + lines: [3] + explanation: | + Der Hinweis hat Kollision und ist damit eine Sperre. Die Tester laufen nicht um ihn herum, weil sie ihn falsch lesen, sondern weil sie nicht durchkommen. Der Test misst also das Hindernis, nicht den Hinweis. `Cues` gehört ohne Kollision in den Plan: *Collision Enabled* aus am Layer und keine Physik-Polygone an den Hinweis-Tiles. + hints: + - Welche Ebene soll den Weg zeigen, und welche soll ihn begrenzen? + resources: + - title: Godot Docs · TileMapLayer.collision_enabled + url: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html#class-tilemaplayer-property-collision-enabled + + - id: notizen-erklaeren + type: explain + title: Warum die Notizen im Spiel aus sind + prompt: | + Erkläre in drei bis fünf Sätzen, was `notes.gd` im Editor und im laufenden Spiel bewirkt und warum Tester die Notizen nicht sehen sollen. + lang: gdscript + code: | + extends Node2D + + func _ready() -> void: + visible = false + + + func _unhandled_input(event: InputEvent) -> void: + if event.is_action_pressed(&"toggle_notes"): + visible = not visible + print("Notizen sichtbar: ", visible) + points: + - "`_ready()` läuft nur im Spiel. Im Editor bleiben die Notizen sichtbar, beim Start schaltet das Skript sie aus." + - "`Marker2D` und `Label` unter `Notes` folgen der Sichtbarkeit ihres Elternknotens, ein Schalter reicht für alle." + - Die Aktion `toggle_notes` schaltet die Notizen im laufenden Spiel ein und aus, etwa für deinen eigenen Durchlauf. + - Sähe ein Tester die Notizen, würde er deine Absicht lesen statt den Raum, und der Test misst die Erklärung statt des Layouts. + explanation: | + Das Skript sorgt dafür, dass Notizen dort sichtbar sind, wo du baust, und dort fehlen, wo andere testen. Im Editor läuft `_ready()` nicht, also siehst du Wegpunkte und Fragen beim Malen. Beim Start setzt das Skript `visible` auf `false`, und weil Kinder der Sichtbarkeit ihrer Eltern folgen, verschwinden alle Marker und Labels. Mit der Aktion holst du sie für deinen eigenen Durchlauf zurück. Für Tester bleiben sie aus, denn eine sichtbare Notiz wie „Tor zuerst“ ist eine Anweisung, und dann weißt du nach dem Test nicht, ob der Raum oder die Notiz gewirkt hat. Das Skript ist technisches Gerüst; was in den Notizen steht, entscheidest du. + resources: + - title: Godot Docs · CanvasItem.visible + url: https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-visible + + - id: vokabel-tileset + type: practice + title: Deine Blockout-Vokabel als TileSet + prompt: | + Leg deine Blockout-Vokabel als Platzhalter-TileSet an: eine Tile pro Kategorie, in deiner Tilegröße oder 16 × 16. Schreib zu jeder Tile ihre Kategorie, ihre Ebene und ob sie kollidiert. Welche Tonwerte und Formmarken es sind, entscheidest du; die Tabelle der Lektion ist nur ein Lehrbeispiel. + lang: prose + starter: | + Kategorie Tonwert / Form Ebene Kollision + begehbar + blockiert hoch + blockiert tief + gefährlich + benutzbar + Hinweis + checklist: + - Jede Kategorie deiner Blockout-Vokabel hat genau eine Tile, und jede Tile gehört zu genau einer Kategorie. + - Jede Tile ist ein flacher Tonwert, höchstens mit einer einfachen Formmarke wie Kreis oder Gitter. + - Zu jeder Tile stehen Kategorie, Ebene (`Ground`, `Walls` oder `Cues`) und Kollision ja oder nein. + - Begehbar und blockiert unterscheiden sich im Tonwert, gefährlich und blockiert auch in der Form. + - Du hast alle Tiles nebeneinander als Screenshot in Graustufen und mit zusammengekniffenen Augen angesehen, und die Hinweis-Tile fällt dabei zuerst auf. + - Das TileSet ist als `.tres` gespeichert, und nur Tiles für `Walls` haben ein Kollisionspolygon. + - Die Vokabel stimmt mit deiner Notiz aus „Umgebung als Information“ überein, oder du hast notiert, was du geändert hast und warum. + hints: + - Wenn dein Spiel eine Kategorie im Abschnitt nicht braucht, bekommt sie trotzdem eine Tile; dann ist die Vokabel für den nächsten Abschnitt fertig. + explanation: | + Die Vokabel ist ein Vertrag mit dir selbst: Eine Tile heißt im ganzen Abschnitt dasselbe. Dann kannst du nach einem Test sagen, ob ein Tester eine Wand als Wand gelesen hat, und musst nicht raten, ob ihn ein Detail abgelenkt hat. Der Graustufen- und Unschärfetest zeigt dir vor jedem Playtest, ob der Hinweis überhaupt die Chance hat, bemerkt zu werden. Wie du das TileSet technisch anlegst, steht in [2D-Level aus Tiles](/godot/level-tilemap). + resources: + - title: The Level Design Book · Blockout, „Sketch layout“ + url: https://book.leveldesignbook.com/process/blockout + - title: Godot Docs · Using TileSets · Adding collision + url: https://docs.godotengine.org/en/stable/tutorials/2d/using_tilesets.html#adding-collision-navigation-and-occlusion-to-the-tileset + + - id: massstabsraum + type: practice + title: Ein Maßstabsraum für deine Figur + prompt: | + Bau eine eigene Szene als Maßstabsraum, mit deinem Blockout-TileSet und deiner Figur. Lauf alles ab und notiere, was du misst. Welche Breiten du später verwendest, entscheidest du nach diesem Durchlauf. + lang: prose + starter: | + Gang 1 Tile: + Gang 2 Tiles: + Gang 3 Tiles: + Tür 1 / 2 Tiles: + Strecke in 1 s: + Ausweichweite: + Ein Bildschirm (20 × 11): + checklist: + - Die Szene ist getrennt vom Abschnitt und nutzt dasselbe TileSet und dieselbe Figur. + - Es gibt Gänge mit 1, 2 und 3 Tiles Breite, je einmal gerade und einmal mit Ecke. + - Es gibt Türöffnungen mit 1 und 2 Tiles Breite. + - Ein Rahmen aus 20 × 11 Tiles zeigt die Größe eines Bildschirms. + - Markierungen zeigen die Strecke der Figur in einer Sekunde und die Ausweichweite, mit deinen Werten oder den Platzhaltern. + - Du bist jeden Gang mit Tastatur und, falls vorhanden, mit Stick abgelaufen, auch schräg in die Ecken. + - Zu jedem Gang steht, ob und wo die Figur hängen bleibt, in Tiles oder Pixeln, nicht als Urteil. + hints: + - Leg die Gänge nebeneinander, dann vergleichst du sie in einem Bildausschnitt. + explanation: | + Der Maßstabsraum macht Zahlen begehbar. Statt „2 Tiles klingt eng“ läufst du durch 2 Tiles und siehst, wie die Figur an der Ecke reagiert. Die Notizen sind deine Grundlage für [Maßstab, Dichte und Freiflächen](/level-design/massstab-dichte) und für jede spätere Änderung an Tempo oder Fußform: Nach so einer Änderung läufst du den Raum erneut ab. + resources: + - title: The Level Design Book · Build a metrics zoo test map + url: https://book.leveldesignbook.com/process/blockout/metrics#build-a-metrics-zoo-test-map + + - id: eigener-blockout + type: practice + title: Deinen Abschnitt blocken + prompt: | + Bau den Abschnitt aus deiner Skizze als Blockout: Ebenen, Hinweise, Notizen, Kameragrenzen. Lauf ihn selbst ab, ändere, was nicht passt, und sichere den Stand. Jede Wand, jede Breite und jeder Hinweis ist deine Entscheidung; ein Agent darf dir nur die Skripte schreiben. + lang: prose + checklist: + - Der Abschnitt folgt deiner Skizze aus „Absicht notieren, Layout skizzieren“; Abweichungen stehen als Notiz in `Notes` oder in der Absichtsnotiz. + - "`Ground`, `Walls` und `Cues` sind getrennte `TileMapLayer`, und nur `Walls` kollidiert." + - Jeder Hinweis aus deiner Absichtsnotiz liegt auf `Cues`. + - Der erwartete Weg steht als nummerierte `Marker2D` in `Notes`; im Spiel ist `Notes` aus und per Taste einschaltbar. + - Die Kamera bleibt in der bemalten Fläche, und du hast die Ausgabe von `camera_limits.gd` notiert. + - Du bist den erwarteten Weg und jede Abzweigung im Spiel gelaufen, nicht nur im Editor angesehen. + - Der Stand ist committet und mit einem Tag markiert. + - Im Abschnitt liegt keine fertige Grafik, nur Platzhalter-Tiles und einfache Formen. + hints: + - Bleib bei 2 bis 4 Bildschirmen. Was nicht hineinpasst, kommt in einen zweiten Abschnitt. + explanation: | + Das ist der Stand, mit dem du in [Playtest am PC](/level-design/playtest-godot) Wege aufzeichnest. Je weniger du in diesen Stand investiert hast, desto leichter fällt es dir, ihn nach dem Test umzubauen. Das Level Design Book sagt es so: „Want to delete an entire room? Do it.“ + resources: + - title: The Level Design Book · Blockout, „Diverge and iterate“ + url: https://book.leveldesignbook.com/process/blockout + - title: Godot Docs · Using TileMaps + url: https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html diff --git a/content/level-design/modules/einfuehren-variieren.yaml b/content/level-design/modules/einfuehren-variieren.yaml new file mode 100644 index 0000000..8731cfe --- /dev/null +++ b/content/level-design/modules/einfuehren-variieren.yaml @@ -0,0 +1,459 @@ +id: einfuehren-variieren +title: Möglichkeiten einführen, sicher erproben, variieren +level: 2 +minutes: 100 +summary: Wie ein Level eine neue Möglichkeit lehrt, ohne sie zu erklären – einführen, sicher erproben lassen, prüfen, wenden und abschließen nach Koichi Hayashidas Kishōtenketsu und „Teach, test, twist“ –, und woran du erkennst, dass eine Abfolge zu viel auf einmal will oder eine Regel heimlich ändert. +place: unterwegs +goals: + - Du beschreibst die vier Schritte von Kishōtenketsu nach Koichi Hayashida und vergleichst sie mit „Teach, test, twist“. + - Du gestaltest eine sichere Erprobung mit niedrigem Preis für Fehler, ohne Zeitdruck und mit kurzem Rückweg. + - Du zählst in einer Abfolge von Räumen die Neuheiten pro Raum und den Abstand zwischen Einführung und Wendung. + - Du unterscheidest eine Wendung, die die Lage ändert, von einer Variation, die eine Regel stillschweigend bricht. + - Du planst für eine selbst gewählte Möglichkeit eine Abfolge, die ohne Text auskommt. +resources: + - title: Christian Nutt, „The Structure of Fun“, Interview mit Koichi Hayashida (Game Developer, 2012) + url: https://www.gamedeveloper.com/design/the-structure-of-fun-learning-from-i-super-mario-3d-land-i-s-director + - title: The Level Design Book · Pacing, Teach, test, twist + url: https://book.leveldesignbook.com/process/preproduction/pacing#teach-test-twist + - title: Kim Swift, Erik Wolpaw, „Integrating Narrative and Design – A Portal Post-Mortem“ (GDC 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf + - title: Dan Taylor, „Ten Principles of Good Level Design“, Teil 1 (Game Developer, 2013) + url: https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1- +lesson: | + Koichi Hayashida, Director von Super Mario 3D Land, beschreibt, wie ein Level eine einzelne Spielmechanik lehrt: „First, you have to learn how to use that gameplay mechanic, and then the stage will offer you a slightly more complicated scenario in which you have to use it. And then the next step is something crazy happens that makes you think about it in a way you weren't expecting. And then you get to demonstrate, finally, what sort of mastery you've gained over it.“ ([Game Developer, 2012](https://www.gamedeveloper.com/design/the-structure-of-fun-learning-from-i-super-mario-3d-land-i-s-director)) Kein Satz davon spricht von Text. Das Level selbst ist der Unterricht. + + Dieses Modul nennt alles, was ein Spieler tun kann oder womit er umgehen muss, eine **Möglichkeit**: eine Fähigkeit der Figur, ein Objekt wie eine Druckplatte, ein Hindernis wie brüchiger Boden, das Verhalten eines Gegners. Es zeigt, wie ein Level eine Möglichkeit einführt, sicher erproben lässt, prüft, wendet und abschließt, und woran du erkennst, dass eine Abfolge zu viel auf einmal will. Die Beispiele sind veröffentlichte Spiele oder neutrale Lehrbeispiele. Welche Möglichkeiten dein Spiel hat, entscheidest du. + + ## Kishōtenketsu: vier Schritte für eine Möglichkeit + + Hayashida vergleicht den Ablauf mit Vier-Bild-Comics. Im Manga spreche man von „kishoutenketsu, where you introduce a concept, and then in the next panel you develop the idea a little bit more; in the third panel there's something of a change-up, and then in the fourth panel you have your conclusion.“ Übertragen auf ein Level: + + | Schritt | bei Hayashida | im Level | + | --- | --- | --- | + | einführen | „introduce a concept“ | Die Möglichkeit erscheint und lässt sich ohne Risiko benutzen. | + | entwickeln | „develop the idea a little bit more“ | Eine etwas schwierigere Lage mit derselben Möglichkeit. | + | wenden | „something of a change-up“ | Dieselbe Möglichkeit, aber in einer Lage, die anders darüber denken lässt. | + | abschließen | „conclusion“ | Der Spieler zeigt, was er kann. | + + Den dritten Schritt nennt Hayashida „something of a doozy that throws them for a loop“. Er führt ihn auf Shigeru Miyamoto zurück, der als Kind Comics zeichnete: „That ten [twist] that really surprises people.“ + + Dazu gehört ein zweiter Gedanke aus demselben Interview, ein Kernkonzept pro Level: „I do think it's really important to decide on a core concept in level design.“ In Super Mario Galaxy hatte noch jeder Planet etwas Neues, „So you would end up with lots of different gameplay concepts in a single stage.“ Bei Super Mario 3D Land dagegen „you have a clear concept in the beginning, and that's carried through absolutely all the way.“ Vier Schritte brauchen Platz. Wer in einem Abschnitt fünf Möglichkeiten einführt, hat für keine davon eine Wendung übrig. + + ## Teach, test, twist + + Das Level Design Book beschreibt ein verwandtes Muster: „Teach, test, twist is a common 3-beat pattern in level design“ ([Pacing](https://book.leveldesignbook.com/process/preproduction/pacing#teach-test-twist)). Die drei Takte sind dort genau definiert: + + - **Teach**: „teach the player about a game activity“. + - **Test**: „test whether the player can repeat and recognize the activity, with prompting“. + - **Twist**: „twist the frame of the activity; with less prompting, can the player recall it?“ + + Der Unterschied zwischen Test und Twist liegt im Hinweis. Beim Test hilft der Raum noch beim Erkennen, bei der Wendung muss der Spieler sich selbst erinnern. Das Buch belegt das an Portal: In Kammer 10 lernt und übt der Spieler den „fling“, in Kammer 12 springt er von höher, in Kammer 15 schleudert er sich zweimal in der Luft, Kammer 18 endet mit einer „infinite fling“-Aufgabe. Dazu der Satz: „note how these "twist" beats are spaced out, and aren't immediately after the Test“. + + ```python run + # Fling in Portal 1, Kammern + # laut Level Design Book + teach = 10 + twists = [12, 15, 18] + print([k - teach for k in twists]) + ``` + + Die Wendungen kommen zwei, fünf und acht Kammern nach der Einführung. Dazwischen spielt der Spieler anderes. Wer sich nach fünf Kammern noch an den Fling erinnert, hat ihn gelernt. + + Hayashidas Entwickeln entspricht dem Test; dieser Kurs nennt den Schritt auch Prüfung. Kishōtenketsu hat einen vierten Schritt, den Abschluss, „Teach, test, twist“ nicht. Beide Muster sagen dasselbe Wesentliche: erst lehren, dann prüfen, dann die Lage ändern. Dan Taylor fasst es als Prinzip: „A good level should either introduce a new game mechanic, or put a spin on an old one to make the player re-evaluate his or her established paradigm.“ ([Ten Principles, Teil 1](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-)) + + > [!NOTE] Das Zelda-Muster, so wie Taylor es beschreibt + > Taylor schreibt in einer Bildunterschrift: „every dungeon in every Zelda game is a tutorial for the new piece of equipment you find in it... with the dungeon’s boss being the final test (always with a clever little twist).“ Das ist seine Beschreibung als Level-Designer, keine Aussage von Nintendo. Sie zeigt die vier Schritte über einen ganzen Dungeon gestreckt: Gegenstand finden, damit Rätsel lösen, am Boss abschließen. + + ## Sicher erproben: Preis, Zeitdruck, Rückweg + + Valve schreibt in den Folien zum Post-Mortem von Portal über einen Raum mit dem Titel „Incineration Station – Boss Battle Training“. Als Gründe, warum er funktionierte, stehen dort unter anderem „Perfect Training Location.“ und „Players Learn Better When Not Stressed.“ ([Portal Post-Mortem, GDC 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)) Auch das Level Design Book rät, ruhig anzufangen: „Even high action shooters like Doom or Quake begin with quiet rooms where players can test their controls and "warm up" before launching into combat.“ ([Start slow and quiet](https://book.leveldesignbook.com/process/preproduction/pacing#start-slow-and-quiet)) + + Ob eine Erprobung sicher ist, hängt an drei Dingen. Die Einteilung ist ein Werkzeug dieses Kurses: + + - **Preis für Fehler.** Was kostet ein Fehlversuch? Nichts, etwas Schaden, verlorener Fortschritt, der Tod? Beim ersten Kontakt sollte er klein sein. + - **Zeitdruck.** Gibt es Gegner, einen Countdown, eine Fläche, die einbricht? Beim ersten Kontakt sollte es keinen geben. + - **Rückweg.** Wie weit muss der Spieler nach einem Fehler zurück? Mit 90 Pixeln pro Sekunde, dem Platzhalter dieses Kurses, sind 30 Tiles über fünf Sekunden Laufen, bei jedem Versuch. + + Dazu kommt Platz zum Ausprobieren, also genug Fläche, um die Möglichkeit ohne Kante und ohne Gegner zu benutzen. Wie du Flächen bemisst, steht in [Maßstab, Dichte und Freiflächen](/level-design/massstab-dichte). + + Sicher heißt nicht beliebig leicht. Hayashida erzählt von einer Testerin, einer Büroangestellten aus dem Nachbargebäude, die „had a lot of trouble jumping across even a small gap“. Mit einem Hilfsmittel kam sie ans Ende des Levels, aber das Team wollte etwas anderes sehen: „what we really wanted to see was her being able to jump this gap.“ Das Team zog daraus den Schluss, den Tanooki-Anzug als Hilfe früher anzubieten, „if people are having a particular amount of trouble with a certain stage“. Der Test zeigte, für wen die Erprobung zu schwer war. + + > [!PRAXIS] Valve senkt den Preis für einen Fehler + > Für Portal plante Valve ein langes Level, in dem der Spieler einen Würfel mitnimmt und am Ende auf einen Knopf legt. Die Folien beschreiben die erste Fassung so: „Moving lift obstacle course over a goo-pit.“ „Players would destroy the box, and had to go back.“ „Frustrating and annoying.“ Die zweite Fassung: „Remove the lifts and the goo pit!“ und „Gameplay events where having the box is necessary.“ Als noch etwas fehlte, kam die Reihenfolge der Hilfen: „Try to hint using the environment. When all else fails great dialogue is an excellent hint.“ ([Portal Post-Mortem](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)) Valve nahm die Gefahr weg, die den Fortschritt zerstörte, und ließ den Würfel dort zählen, wo er gebraucht wird. Wie Ziele im Raum sichtbar bleiben, zeigt [Umgebung als Information](/level-design/umgebung-informiert). + + ## Eins nach dem anderen: Neuheiten zählen + + Die schnellste Prüfung einer Abfolge ist eine Zählung. Schreib für jeden Raum auf, welche Möglichkeiten darin vorkommen, und zähl, wie viele davon neu sind. Ein Lehrbeispiel: + + ```text + Raum 1: Druckplatte + Raum 2: Druckplatte, Druckplatte + Raum 3: Druckplatte, Kiste + Raum 4: Kiste + ``` + + Raum 3 führt die Kiste ein und verlangt sie zugleich zusammen mit der Druckplatte. Wer dort scheitert, weiß nicht, ob er die Kiste nicht versteht oder die Verbindung. Besser ist eine eigene Einführung der Kiste, erst danach die Verbindung. Eine Verbindung zweier bekannter Möglichkeiten ist selbst eine Neuheit. Sie kommt, wenn beide einzeln sitzen. + + Taylor beschreibt dieselbe Bauweise aus Sicht der Arbeit: „By applying simple modifiers to these modules you can create variation, building more levels with less work, and less risk.“ Die Module seien zugleich „a series of familiar encounters that the player can use to learn and master your mechanics, while the modifiers applied to these encounters keep them fresh by providing increased challenge and surprise“ ([Ten Principles, Teil 2](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-2-)). Ein bekannter Baustein mit einem Zusatz ist eine Neuheit, nicht fünf. + + > [!MERKE] Eine Neuheit pro Schritt + > Jeder Raum bringt höchstens eine neue Möglichkeit oder eine neue Verbindung. Die Prüfung kommt nach der Einführung, die Wendung mit Abstand nach der Prüfung. + + ## Wenden, ohne die Regel zu brechen + + Eine Wendung ändert die Lage, nicht die Regel. Das Level Design Book sagt „twist the frame of the activity“: Dieselbe Möglichkeit erscheint in einem neuen Rahmen, etwa eine Druckplatte, die hinter dem Tor liegt, das sie öffnet, und die man nur über einen Umweg erreicht. Der Spieler denkt anders über sie nach, aber sie funktioniert wie vorher. + + Gefährlich ist eine Variation, die die Regel ändert, ohne es zu zeigen. Brechen graue Platten in den ersten Räumen nach zwei Sekunden ein und in Raum vier sofort, ohne anders auszusehen, lernt der Spieler vor allem, seinem Wissen nicht zu trauen. Willst du eine Regel ändern, gib der neuen Regel ein neues Aussehen. Taylor verlangt eine „consistent visual language, through the use of colour and form, that the player can learn“. Wie du eine solche Sprache für deinen Blockout festlegst, behandelt [Umgebung als Information](/level-design/umgebung-informiert). + + Eine gute Wendung macht aus Wissen Verständnis. Andrew Shouldice beschreibt für Tunic drei Phasen des Lernens, vom Nichtwissen über das Wissen, „where you know something exists, but you don't understand it“, bis zum Verstehen: „Understanding is closure. That's where something 'clicks.'“ ([Game Developer, 2023](https://www.gamedeveloper.com/design/video-how-the-tunic-developers-built-a-mysterious-world)) Der Abschluss einer Abfolge ist die Stelle, an der es klickt. + + ## Lehren ohne Text + + Eine Texttafel ist das billigste Werkzeug, eine Möglichkeit zu erklären, und das bequemste. Heart Machine wollte in Hyper Light Drifter ganz ohne Text auskommen. Alex Preston sagt über die Entscheidung des Kernteams: „No text. Don’t do it. We don’t wanna do it.“ ([Unwinnable, 2015](https://unwinnable.com/2015/12/02/interview-with-alex-preston-the-creator-of-hyper-light-drifter/)) Was das für die Umgebung bedeutet, behandelt [Umgebung als Information](/level-design/umgebung-informiert). Hier geht es um die Abfolge. Ohne Text muss sie die Lehre übernehmen. + + Mittel dafür, als Sammlung dieses Kurses: + + - **Zeigen, bevor der Spieler handelt.** Die Möglichkeit wirkt einmal von selbst, etwa eine Platte, die unter einem Gegner einbricht, bevor die Figur sie betritt. + - **Ein Raum, der nur eine Lösung hat.** Wenn nur die neue Handlung weiterführt, probiert der Spieler sie aus. + - **Das Ziel sichtbar machen.** Wer sieht, wohin er will, sucht nach dem Mittel dorthin. + - **Erst ohne Preis, dann mit.** Der erste Kontakt kostet nichts, der zweite etwas. + - **Wiederholen mit einer kleinen Änderung.** So erkennt der Spieler, was gleich bleibt. + + Valves Reihenfolge aus Portal gilt hier auch: erst die Umgebung, dann, wenn nichts anderes hilft, ein Satz. Ob die Lehre trägt, zeigt nur das Verhalten von Testern, die das Spiel nicht kennen ([Playtests beobachten](/level-design/playtest-methode)). + + > [!WARNING] Prüfung vor Einführung + > Der häufigste Fehler in Abfolgen ist ein erster Kontakt, der schon eine Prüfung ist: eine neue Möglichkeit mitten im Kampf, unter Zeitdruck oder über einem Abgrund. Wer dort scheitert, lernt nur, dass er gescheitert ist. Zähl für jede Möglichkeit, wo sie zum ersten Mal vorkommt, und prüf, ob der Preis dort klein ist. + + > [!NOTE] Deine Möglichkeiten, deine Abfolge + > Welche Möglichkeiten dein Spiel hat und in welcher Reihenfolge sie kommen, entscheidest du. Eine KI darf dir ein Skript schreiben, das in einer Liste von Räumen die Neuheiten zählt. Die Liste selbst ist deine Arbeit. + + > [!INTERVIEW] „Wie bringst du Spielern eine neue Mechanik bei, ohne Tutorialtext?“ + > Ich lege für den Abschnitt eine Möglichkeit fest und plane vier Schritte: einführen, entwickeln, wenden, abschließen. Beim ersten Kontakt ist der Preis für Fehler klein, es gibt keinen Zeitdruck und der Rückweg ist kurz. Ich zähle pro Raum die Neuheiten, höchstens eine, und lege die Wendung mit Abstand nach der Prüfung, wie Portal es mit dem Fling macht. Ändere ich eine Regel, bekommt sie ein neues Aussehen. Dann beobachte ich Tester, die das Spiel nicht kennen, und schaue, wo sie scheitern. Erst wenn die Umgebung nicht reicht, kommt ein Satz. + + ## Häufige Fehler + + - **Zwei Neuheiten zugleich.** Wer scheitert, weiß nicht, woran. Eine Möglichkeit nach der anderen, die Verbindung danach. + - **Prüfung vor Einführung.** Der erste Kontakt findet unter Druck statt. + - **Hoher Preis beim ersten Versuch.** Ein langer Rückweg oder verlorener Fortschritt macht aus dem Lernen eine Strafe, wie bei Valves erster Fassung des Würfel-Levels. + - **Wendung direkt nach dem Test.** Ohne Abstand prüft sie das Kurzzeitgedächtnis, nicht das Gelernte. + - **Regel heimlich geändert.** Gleiches Aussehen, anderes Verhalten. + - **Einführung, die man verpassen kann.** Ein optionaler Seitenraum lehrt, was später Pflicht ist. + - **Texttafel als erstes Mittel.** Sie ist bequem, aber sie ersetzt keinen Raum, in dem man die Möglichkeit ausprobiert. + - **Kein Abschluss.** Die Abfolge endet mit der Wendung, und der Spieler zeigt nie, dass er die Möglichkeit beherrscht. + + ## Zusammenfassung + + - Kishōtenketsu nach Hayashida hat vier Schritte: einführen, entwickeln, wenden, abschließen. Ein Kernkonzept pro Abschnitt gibt ihnen Platz. + - „Teach, test, twist“ unterscheidet Test und Wendung über den Hinweis. Beim Test hilft der Raum, bei der Wendung erinnert sich der Spieler selbst. + - In Portal kommen die Wendungen zum Fling zwei, fünf und acht Kammern nach der Einführung. + - Sicher erproben heißt kleiner Preis für Fehler, kein Zeitdruck, kurzer Rückweg und genug Platz. + - Jeder Raum bringt höchstens eine Neuheit. Eine Verbindung zweier Möglichkeiten zählt als eigene. + - Eine Wendung ändert die Lage, nicht die Regel. Eine neue Regel bekommt ein neues Aussehen. + - Ohne Text übernimmt die Abfolge die Lehre. Erst die Umgebung, dann ein Satz. +exercises: + - id: dritter-schritt + type: choice + title: Der dritte Schritt + prompt: | + Lehrbeispiel: Eine Abfolge lehrt eine Druckplatte, die ein Tor öffnet. Welcher Raum entspricht dem dritten Schritt von Kishōtenketsu, der Wendung? + options: + - text: Die Druckplatte liegt hinter dem Tor, das sie öffnet. Man sieht sie durch das Gitter und muss einen Umweg zu ihr finden. + correct: true + why: Dieselbe Möglichkeit mit derselben Regel, aber in einer Lage, die anders über sie nachdenken lässt. Das meint Hayashida mit „change-up“. + - text: Eine einzelne Druckplatte liegt mitten im Raum, und das Tor gegenüber öffnet sich, sobald man sie betritt. + correct: false + why: Das ist die Einführung. Die Möglichkeit erscheint und lässt sich ohne Risiko benutzen. + - text: Zwei Druckplatten müssen beide betreten werden, bevor das Tor aufgeht. + correct: false + why: Das ist eine Entwicklung. Die Lage wird etwas schwieriger, aber man denkt auf dieselbe Weise über die Platte nach. + - text: Eine Druckplatte, die genauso aussieht wie die anderen, öffnet das Tor nur, solange man darauf steht. + correct: false + why: Hier ändert sich die Regel, ohne dass man es sieht. Das ist keine Wendung, sondern ein Bruch mit dem Gelernten. + explanation: | + Die Wendung behält die Regel und ändert den Rahmen. Der Spieler weiß, was die Platte tut, muss aber neu überlegen, wie er sie in dieser Lage nutzt. Eine heimlich geänderte Regel sieht aus wie eine Wendung, lehrt aber das Gegenteil, nämlich dass Gelerntes nicht gilt. + hints: + - Welcher Raum lässt die Regel gleich und ändert nur die Lage? + resources: + - title: Christian Nutt, „The Structure of Fun“ (Hayashida, Game Developer) + url: https://www.gamedeveloper.com/design/the-structure-of-fun-learning-from-i-super-mario-3d-land-i-s-director + + - id: sichere-erprobung + type: choice + title: Der erste brüchige Boden + prompt: | + Lehrbeispiel: Ein Abschnitt führt Boden ein, der einbricht, wenn man zu lange darauf steht. Welche erste Begegnung erfüllt Preis, Zeitdruck und Rückweg einer sicheren Erprobung? + options: + - text: Der erste brüchige Boden liegt in einem ruhigen Raum über einer flachen Grube. Wer einbricht, steht sofort am Rand wieder auf. + correct: true + why: Kleiner Preis, kein Zeitdruck, kurzer Rückweg. Der Spieler kann den Boden so oft ausprobieren, wie er will. + - text: Der erste brüchige Boden liegt mitten in einer Arena mit drei Gegnern. + correct: false + why: Die Gegner sind Zeitdruck und lenken ab. Wer einbricht, weiß nicht, ob er den Boden oder den Kampf falsch gelesen hat. + - text: Der erste brüchige Boden liegt am Ende eines langen Gangs. Wer einbricht, beginnt am Anfang des Abschnitts neu. + correct: false + why: Der Rückweg ist teuer. Jeder Fehlversuch kostet einen langen Weg durch Bekanntes, wie bei Valves erster Fassung des Würfel-Levels. + - text: Eine Texttafel erklärt den Boden, danach folgt eine Strecke aus brüchigen Tiles mit Zeitlimit. + correct: false + why: Der erste Kontakt ist schon eine Prüfung unter Zeitdruck. Die Tafel ersetzt den Raum, in dem man es ausprobiert. + explanation: | + Valve schreibt über Portal: „Players Learn Better When Not Stressed.“ Beim ersten Kontakt soll der Spieler herausfinden, was der Boden tut, nicht, ob er unter Druck damit zurechtkommt. Das kommt später, in der Entwicklung und der Wendung. + hints: + - Prüf jede Antwort auf drei Fragen. Was kostet ein Fehler, gibt es Zeitdruck, wie weit ist der Rückweg? + resources: + - title: Swift, Wolpaw, „A Portal Post-Mortem“ (GDC 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf + + - id: vier-raeume + type: order + title: Vier Räume, eine Druckplatte + prompt: | + Lehrbeispiel: vier Räume, die eine Druckplatte lehren. Bring sie in die Reihenfolge von Kishōtenketsu. + lang: prose + lines: | + Eine einzelne Druckplatte liegt mitten im Raum, und das Tor gegenüber öffnet sich, sobald man sie betritt. + Zwei Druckplatten an entgegengesetzten Enden des Raums müssen beide betreten werden, bevor das Tor aufgeht. + Die Druckplatte liegt hinter dem Tor, das sie öffnet, und man erreicht sie nur über einen Umweg. + Drei Druckplatten und drei Tore, deren Reihenfolge man ohne neue Elemente selbst herausfindet. + explanation: | + Die einzelne Platte führt ein, ohne Risiko. Zwei Platten entwickeln die Idee, die Lage wird etwas schwieriger. Die Platte hinter ihrem eigenen Tor ist die Wendung, die Regel bleibt, aber der Spieler muss anders denken. Der letzte Raum schließt ab: Er verlangt alles Gelernte und bringt nichts Neues. In einem echten Abschnitt stünden zwischen den Schritten oft andere Räume. + hints: + - Der letzte Raum bringt nichts Neues, er verlangt nur alles Gelernte. + resources: + - title: The Level Design Book · Teach, test, twist + url: https://book.leveldesignbook.com/process/preproduction/pacing#teach-test-twist + + - id: neuheiten-zaehlen + type: output + title: Wie viel ist neu? + prompt: | + Lehrbeispiel: vier Räume als Mengen von Möglichkeiten, „Platte“ steht für die Druckplatte. Das Modell zählt pro Raum, wie viele davon neu sind. Was gibt es aus? + lang: python + code: | + raeume = [ + {"Platte"}, + {"Platte"}, + {"Platte", "Kiste", "Falltür"}, + {"Kiste", "Falltür"}, + ] + bekannt = set() + for nr, r in enumerate(raeume, 1): + print(nr, len(r - bekannt)) + bekannt |= r + expected: | + 1 1 + 2 0 + 3 2 + 4 0 + hints: + - "`r - bekannt` ist alles, was im Raum vorkommt, aber vorher nirgends." + explanation: | + Raum 1 führt die Druckplatte ein, Raum 2 nichts Neues. Raum 3 bringt Kiste und Falltür zugleich, zwei Neuheiten, und das zusammen mit der Platte. Raum 4 ist danach nur noch Wiederholung. Die Zählung findet den Fehler sofort: Raum 3 sollte in zwei Räume zerfallen, je einen für Kiste und Falltür. Was das Modell nicht zählt, sind Verbindungen; dass Kiste und Falltür hier zum ersten Mal zusammen auftreten, ist eine weitere Neuheit. + resources: + - title: Python · set difference + url: https://docs.python.org/3/library/stdtypes.html#frozenset.difference + + - id: wendung-abstand + type: output + title: Wie weit liegt die Wendung entfernt? + prompt: | + Lehrbeispiel: die Schritte einer Abfolge, ein Eintrag pro Raum. Das Modell rechnet, wie viele Räume nach der Einführung jede Wendung und der Abschluss kommen. Was gibt es aus? + lang: python + code: | + folge = ["einführen", "prüfen", + "prüfen", "anderes", + "wenden", "anderes", + "anderes", "wenden", + "abschließen"] + start = folge.index("einführen") + w = [i - start + for i, s in enumerate(folge) + if s == "wenden"] + ende = folge.index("abschließen") + print(w, ende - start) + expected: | + [4, 7] 8 + hints: + - "`folge.index` liefert die erste Stelle, gezählt ab 0." + explanation: | + Die Einführung steht an Stelle 0, die Wendungen an 4 und 7, der Abschluss an 8. Zwischen Prüfung und erster Wendung liegt ein Raum mit anderem Inhalt, wie das Level Design Book es an Portal beschreibt: Wendungen kommen „spaced out“, nicht direkt nach dem Test. Ob dein Abstand zwei oder sechs Räume ist, entscheidest du. Die Zählung zeigt nur, ob es überhaupt einen gibt. + resources: + - title: The Level Design Book · Teach, test, twist + url: https://book.leveldesignbook.com/process/preproduction/pacing#teach-test-twist + + - id: rueckweg-sekunden + type: output + title: Was kostet ein Fehlversuch? + prompt: | + Lehrbeispiel: Wer an einer neuen Stelle scheitert, beginnt am Eingang des Raums, 30 Tiles entfernt. Tiles sind 16 Pixel, die Figur läuft 90 Pixel pro Sekunde (Platzhalter). Wie viele Sekunden läuft sie nach jedem Fehlversuch zurück? Runde auf eine Nachkommastelle und antworte mit der Zahl. + lang: text + code: | + Sekunden = Tiles × 16 / 90 + Rückweg 30 Tiles + expected: | + 5.3 + accept: ["5,3", "5,3 s", "5.3 s", "5,3 Sekunden"] + explanation: | + 30 × 16 = 480 Pixel, 480 / 90 = 5,33 Sekunden. Beginnt der Spieler stattdessen am Rand der Stelle, 3 Tiles entfernt, sind es 0,5 Sekunden. Bei zehn Versuchen läuft der Spieler vom Eingang aus zusammen fast eine Minute, vom Rand aus keine sechs Sekunden. Beim ersten Kontakt mit einer Möglichkeit ist der kurze Rückweg die bessere Wahl. Wo ein langer Rückweg Absicht ist, etwa bei einer Prüfung, entscheidest du. + + - id: begriffe-lehren + type: gap + title: Vier Begriffe zum Lehren + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Das Level Design Book nennt das Muster ⟦teach⟧, test, twist. Hayashida beschreibt vier Schritte nach dem Aufbau von Vier-Bild-Comics und nennt sie ⟦Kishōtenketsu⟧. Der dritte Schritt ist die ⟦Wendung⟧. Valve schreibt über Portal: Players learn better when not ⟦stressed⟧. + gaps: + - label: erster Takt + hint: Englisch für „lehren“. + accept: ["Teach"] + - label: vier Schritte + hint: Das Interview schreibt das Wort „kishoutenketsu“. + accept: ["kishoutenketsu", "Kishotenketsu", "kishotenketsu", "Kishoutenketsu"] + - label: dritter Schritt + hint: Englisch „twist“. + accept: ["Twist", "Wende", "Umschwung", "Überraschung", "ten", "Ten", "Change-up", "change-up"] + - label: Valve + hint: Englisch für „gestresst“. + accept: ["Stressed"] + explanation: | + Beide Muster beginnen mit dem Lehren und kommen über eine Prüfung zur Wendung. Kishōtenketsu ergänzt den Abschluss, an dem der Spieler zeigt, was er kann. Valves Satz aus Portal ist die Begründung für die sichere Erprobung am Anfang. + resources: + - title: The Level Design Book · Teach, test, twist + url: https://book.leveldesignbook.com/process/preproduction/pacing#teach-test-twist + + - id: zwei-neuheiten + type: bug + title: Ein Raum will zu viel + prompt: | + Lehrbeispiel: Abfolge für einen Abschnitt. Tester scheitern an einem Raum immer wieder und können nicht sagen, woran. Finde die Zeile. + lang: prose + code: | + Raum 1: Eine Kiste steht im Weg, man kann sie schieben. + Raum 2: Zwei Kisten, eine davon muss in eine Nische. + Raum 3: Eine Kiste muss auf eine Druckplatte, während der Boden um sie herum einbricht. + Raum 4: Eine Druckplatte öffnet ein Tor. + Raum 5: Kisten und Druckplatten, ohne brüchigen Boden. + lines: [3] + explanation: | + Raum 3 bringt zwei Neuheiten auf einmal, die Druckplatte und den brüchigen Boden, und verlangt beide zusammen mit der Kiste unter Zeitdruck. Die Druckplatte wird außerdem erst in Raum 4 eingeführt, also nach ihrer ersten Prüfung. Wer in Raum 3 scheitert, kann nicht wissen, ob er die Platte, den Boden oder die Verbindung nicht verstanden hat. Abhilfe: Raum 4 vor Raum 3 setzen und den brüchigen Boden in einem eigenen, ruhigen Raum einführen. + hints: + - Zähl in jeder Zeile, was dort zum ersten Mal vorkommt. + + - id: regel-heimlich + type: bug + title: Dieselben Platten, eine andere Regel + prompt: | + Lehrbeispiel: Abfolge mit brüchigen grauen Platten. Tester sagen nach Raum 4, das Spiel sei „unfair“. Finde die Zeile. + lang: prose + code: | + Raum 1: Graue Platten brechen ein, wenn man zwei Sekunden darauf steht. + Raum 2: Ein Gang aus grauen Platten, durch den man zügig gehen muss. + Raum 3: Graue Platten, dazwischen sichere Steine, die einen Umweg bilden. + Raum 4: Graue Platten, die sofort einbrechen, sobald man sie betritt. + Raum 5: Ein Raum mit grauen Platten und Steinen, der alles Gelernte verlangt. + lines: [4] + explanation: | + In Raum 4 ändert sich die Regel, nicht die Lage. Die Platten sehen aus wie vorher, brechen aber sofort ein. Was der Spieler in drei Räumen gelernt hat, gilt plötzlich nicht mehr, und er hatte keine Möglichkeit, das vorher zu sehen. Willst du solche Platten, gib ihnen ein eigenes Aussehen und führ sie wie eine neue Möglichkeit ein, mit kleinem Preis beim ersten Kontakt. + hints: + - In welchem Raum gilt die Regel aus Raum 1 nicht mehr? + resources: + - title: Dan Taylor, „Ten Principles of Good Level Design“, Teil 1 + url: https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1- + + - id: hayashida-konzept + type: explain + title: Ein Konzept pro Level + prompt: | + Koichi Hayashida im Interview mit Christian Nutt (2012), wörtlich. Erkläre in drei bis fünf Sätzen, was sich zwischen Super Mario Galaxy und Super Mario 3D Land geändert hat und warum das mit den vier Schritten von Kishōtenketsu zusammenhängt. + lang: prose + code: | + So you would be going through a galaxy, and every time you get to a new planet, there would be some new thing to play with there -- some new concept. So you would end up with lots of different gameplay concepts in a single stage. + + But it wasn't really until Super Mario 3D Land that I think I really became a lot more rigorous about enforcing that in level design, where you have a clear concept in the beginning, and that's carried through absolutely all the way. + points: + - In Galaxy brachte jeder Planet etwas Neues, ein Level hatte viele Konzepte. + - In 3D Land steht ein klares Konzept am Anfang und trägt durch das ganze Level. + - Vier Schritte brauchen Raum. Nur ein Konzept, das bleibt, kann eingeführt, entwickelt, gewendet und abgeschlossen werden. + - Für einen eigenen Abschnitt heißt das, eine Möglichkeit festzulegen und die anderen als Bekanntes zu nutzen. + explanation: | + In Super Mario Galaxy gab es auf jedem Planeten etwas Neues, ein Level war eine Folge von Einführungen. In Super Mario 3D Land hat Hayashida ein Konzept pro Level durchgesetzt, das vom Anfang bis zum Ende trägt. Das passt zu den vier Schritten: Eine Möglichkeit, die nach einem Raum wieder verschwindet, wird nur eingeführt, nie entwickelt, gewendet oder abgeschlossen. Erst ein Konzept, das bleibt, gibt dem Spieler die Chance, es zu beherrschen. Für meinen Abschnitt heißt das, eine Möglichkeit festzulegen und alles andere nur als Bekanntes einzusetzen. + hints: + - Wie viele der vier Schritte bekommt ein Konzept, das nur auf einem Planeten vorkommt? + resources: + - title: Christian Nutt, „The Structure of Fun“ (Game Developer, 2012) + url: https://www.gamedeveloper.com/design/the-structure-of-fun-learning-from-i-super-mario-3d-land-i-s-director + + - id: buero-testerin + type: explain + title: Die Lücke, über die sie nicht kam + prompt: | + Hayashida erzählt von einem Playtest für Super Mario 3D Land, wörtlich. Erkläre in drei bis fünf Sätzen, was das Team beobachtet hat, warum das Erreichen des Ziels nicht reichte und welche Antwort Nintendo gewählt hat. + lang: prose + code: | + But what we realized was that she had a lot of trouble jumping across even a small gap. [...] When we eventually had her use the P-wing to get to the end of the level, we thought, "Well, okay, she got through to the end of the level, but what we really wanted to see was her being able to jump this gap." And so that's the sort of thing that made us realize we need to put in some access to the Tanooki suit a little bit earlier, if people are having a particular amount of trouble with a certain stage. + points: + - Der Test zeigte eine Stelle, an der eine Testerin an einer Grundfähigkeit scheiterte, einem kleinen Sprung. + - Mit dem Hilfsmittel erreichte sie das Ziel, aber das Team wollte sehen, dass sie den Sprung schafft. Das Ziel war die Fähigkeit, nicht das Ende des Levels. + - Die Antwort des Teams war, den Tanooki-Anzug früher anzubieten, wenn Spieler in einem Level besonders viel Mühe haben. + - Für eine eigene Abfolge heißt das, beim Zusehen auf die Stelle des Scheiterns zu achten und Preis oder Hilfe dort anzupassen, ohne die Möglichkeit zu streichen. + explanation: | + Das Team sah, dass eine Testerin schon an einem kleinen Sprung scheiterte. Mit dem P-Flügel kam sie ans Ende, aber das war nicht die Absicht: Sie sollte den Sprung lernen. Die Antwort des Teams war, den Tanooki-Anzug als Hilfe früher anzubieten, wenn Spieler in einem Level besonders viel Mühe haben. Der Test hat so gezeigt, für wen die Erprobung zu schwer war. Für meine Abfolgen heißt das, die Stelle des Scheiterns genau zu notieren und dort Preis, Rückweg oder Hilfe zu ändern, statt die Möglichkeit selbst wegzunehmen. + hints: + - Was wollte das Team sehen, das Ende des Levels oder den Sprung? + resources: + - title: Christian Nutt, „The Structure of Fun“ (Game Developer, 2012) + url: https://www.gamedeveloper.com/design/the-structure-of-fun-learning-from-i-super-mario-3d-land-i-s-director + + - id: einfuehrung-analysieren + type: practice + title: Wie hat das Spiel es dir beigebracht? + prompt: | + Wähle ein veröffentlichtes Top-down-Spiel und darin eine Möglichkeit, die es dir ohne lange Erklärung beigebracht hat, etwa eine Fähigkeit, ein Hindernis oder ein Gegnerverhalten. Notier in höchstens fünf Stichpunkten, wie die Abfolge aufgebaut war. + lang: prose + starter: | + Spiel und Möglichkeit: + Erster Kontakt (Preis, Zeitdruck, Rückweg): + Prüfung: + Wendung: + Text oder Hinweise im Raum: + checklist: + - Spiel und Möglichkeit sind genannt. + - Beim ersten Kontakt sind Preis für Fehler, Zeitdruck und Rückweg beschrieben. + - Du nennst die Stelle, an der das Spiel die Möglichkeit zum ersten Mal geprüft hat. + - Du nennst eine Wendung oder schreibst, dass du keine gefunden hast. + - Du notierst, ob Text vorkam und wenn ja, wo. + explanation: | + Wer eine Abfolge in einem fremden Spiel zerlegt, sieht, welche Schritte dort wirklich vorkommen und welche fehlen. Fehlt die Wendung, endet das Lernen mit der Prüfung. Steht Text am Anfang, prüfe, ob der Raum ihn gebraucht hätte. Was du gesehen hast, trennst du von dem, was du vermutest, wie in [Level lesen](/level-design/raum-lesen). + hints: + - Erinnerst du dich nicht genau, sieh dir ein Video vom Anfang des Spiels an. + resources: + - title: The Level Design Book · Pacing + url: https://book.leveldesignbook.com/process/preproduction/pacing + + - id: eigene-abfolge + type: practice + title: Deine Abfolge für eine Möglichkeit + prompt: | + Wähle eine Möglichkeit, aus deinem eigenen Projekt oder als neutrales Übungsbeispiel; welche, entscheidest du. Schreib für sie eine Abfolge aus vier Schritten, je eine kurze Zeile pro Raum. Was in den Räumen steht, legst du fest. + lang: prose + starter: | + Möglichkeit: + Einführen: + Entwickeln (Prüfung): + Dazwischen: + Wenden: + Abschließen: + checklist: + - Jeder Raum bringt höchstens eine Neuheit, und du hast sie gezählt. + - Beim ersten Kontakt ist der Preis für Fehler klein, es gibt keinen Zeitdruck, und der Rückweg ist kurz. + - Die Wendung behält die Regel und ändert die Lage, oder eine geänderte Regel hat ein neues Aussehen. + - Zwischen Prüfung und Wendung liegt mindestens ein Raum mit anderem Inhalt, oder du begründest, warum nicht. + - Die Abfolge kommt ohne Text aus. + explanation: | + Die vier Zeilen sind ein Plan, kein Beweis. Ob Spieler die Möglichkeit so lernen, zeigt erst ein Playtest, in dem du nichts erklärst. Notier dir vorher, woran du merkst, dass ein Schritt scheitert, etwa an wiederholten Fehlversuchen an derselben Stelle. Die Vorlage dafür ist die Absichtsnotiz aus [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze). + hints: + - Fang mit dem Abschluss an. Was soll der Spieler am Ende können? + resources: + - title: The Level Design Book · Teach, test, twist + url: https://book.leveldesignbook.com/process/preproduction/pacing#teach-test-twist diff --git a/content/level-design/modules/massstab-dichte.yaml b/content/level-design/modules/massstab-dichte.yaml new file mode 100644 index 0000000..81a852c --- /dev/null +++ b/content/level-design/modules/massstab-dichte.yaml @@ -0,0 +1,549 @@ +id: massstab-dichte +title: Maßstab, Dichte und Freiflächen +level: 2 +minutes: 100 +summary: Maße aus der Spielfigur ableiten – Fußform, Tempo und Ausweichweite in Tiles –, daraus Gänge, Türen und Arenen bemessen, Hindernisse bewusst dosieren und Enge und Weite so setzen, dass Größe und Freifläche etwas bedeuten. +place: unterwegs +goals: + - Du rechnest Tempo, Ausweichweite und Fußform einer Figur in Tiles um und leitest daraus Gang- und Türbreiten ab. + - Du bemisst eine Arena in Ausweichweiten und Sekunden und prüfst, ob sie in einen Bildschirm passt. + - Du beschreibst, was die Dichte von Hindernissen bewirkt, und misst sie in einer Rasterkarte. + - Du erklärst, wie Bezugsobjekte, Raumgröße und Bildausschnitt Größe wirken lassen, ohne frei zu zoomen. + - Du setzt Enge und Weite bewusst ein und planst einen Maßstabsraum, in dem du deine Maße ausprobierst. +resources: + - title: The Level Design Book · Metrics + url: https://book.leveldesignbook.com/process/blockout/metrics + - title: Joel Burgess, Nate Purkeypile, „Skyrim's Modular Approach to Level Design“ (GDC 2013, Folien) + url: https://www.slideshare.net/JoelBurgess/gdc2013-kit-buildingfinal + - title: Christopher W. Totten, „Designing Better Levels Through Human Survival Instincts“ (Game Developer, 2011) + url: https://www.gamedeveloper.com/design/designing-better-levels-through-human-survival-instincts + - title: The Level Design Book · Prospect-refuge + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge +lesson: | + Koichi Hayashida, Director von Super Mario 3D Land, erzählt, wie sein Team Super Mario Galaxy 2 auf einem sehr kleinen Fernseher ausprobierte: „what we noticed, of course, was Mario was very, very tiny on the screen, so it was difficult to play the game when he's that small. We realized we have to make Mario a little bit bigger.“ ([Game Developer, 2012](https://www.gamedeveloper.com/design/the-structure-of-fun-learning-from-i-super-mario-3d-land-i-s-director)) Wie groß die Figur im Bild ist, bestimmt, wie groß sich alles um sie herum anfühlt und wie viel Platz sie braucht. + + Dieses Modul leitet Maße aus der Spielfigur ab: Gänge, Türen, Arenen, Hindernisfelder. Es rechnet mit den Platzhaltern dieses Kurses, wie sie die Testszenen aus dem Combat-Kurs nutzen. Deine Werte kommen aus deiner Figur, und welche das sind, entscheidest du. Wie der Bildschirm in Tiles aussieht und wie weit man darin voraussieht, steht in [Level lesen](/level-design/raum-lesen); was eine Freifläche vor einer Begegnung für den Ablauf eines Levels bedeutet, in [Rhythmus](/level-design/rhythmus). + + ## Metriken aus der Spielfigur + + Das Level Design Book definiert: „In level design, metrics are the sense of scale, distance, and measurements across the entire level / game.“ Es trennt zwei Arten. „Player metrics (or physics metrics) are factual numbers measured in-engine like player size, movement speed, maximum jump height, etc.“ Building metrics dagegen sind Maße für Böden und Wände, die du dir selbst festlegst, „based on your desired experience goals“ ([Metrics](https://book.leveldesignbook.com/process/blockout/metrics#what-are-metrics)). Die einen misst du, die anderen entscheidest du. Für Spiele gilt laut Buch: „build at the player's scale“. + + Die Platzhalter dieses Kurses als Tabelle: + + | Größe | Platzhalter | in Tiles | + | --- | --- | --- | + | Tile | 16 × 16 Pixel | 1 | + | Spielbild | 320 × 180 Pixel | 20 × 11 volle Tiles | + | Tempo (`move_speed`) | 90 Pixel pro Sekunde | 5,6 Tiles pro Sekunde | + | Ausweichen | 66 Pixel in 18 Frames | gut 4 Tiles | + | Fußform | 10 × 6 Pixel | ⅝ × ⅜ Tile | + + Bild und Tempo stammen aus [Godot-Start](/combat/godot-start), das Ausweichen aus [Ausweichen, Risiko und Belohnung](/combat/ausweichen). Die Fußform ist die flache Kollisionsform an den Füßen, mit der eine Figur in der Draufsicht an Wänden anstößt. Ihr Bild darf größer sein und über Kanten ragen. Wie das funktioniert, zeigt [Kollision und Ebenen](/godot/kollision-ebenen), aus dessen Testgelände die Fußform von 10 × 6 Pixeln stammt. Für Gänge zählt die Breite der Fußform, nicht die des Bildes. + + ```python run + # Platzhalter, Tempo in px/s + TILE = 16 + TEMPO = 90 + AUSWEICHEN = 66 + FUSS_B = 10 + + tiles_s = round(TEMPO / TILE, 1) + s_tile = round(TILE / TEMPO, 2) + print(tiles_s, s_tile) + print(round(AUSWEICHEN / TILE, 1)) + print(2 * FUSS_B) + ``` + + Die Figur läuft 5,6 Tiles pro Sekunde und braucht 0,18 Sekunden für ein Tile. Ein Ausweichen trägt sie 4,1 Tiles weit. Zwei Fußbreiten sind 20 Pixel. Diese Zahlen sind der Maßstab für alles, was folgt. Das Buch warnt zugleich, „metrics are not magic“. Ob ein Maß sich richtig anfühlt, weißt du erst, „when you're walking around inside your level and playtesting“. Deshalb gehören Maße in den Blockout, nicht erst in die fertige Grafik. + + > [!MERKE] Jedes Maß beginnt bei der Figur + > Gänge, Türen, Arenen und Abstände rechnest du aus Fußform, Tempo und Ausweichweite. Ändert sich eine dieser Zahlen, prüfst du die Maße neu. + + ## Gänge und Türen für Bewegung in alle Richtungen + + Für die Breite von Gängen gibt es zwei Quellen, die dasselbe sagen. Das Level Design Book: „The minimum hallway width should be at least double the player width. Even then, it will feel a bit narrow and uncomfortable.“ ([Basic metrics](https://book.leveldesignbook.com/process/blockout/metrics#common-modern-architecture-dimensions)) Joel Burgess über Skyrim, laut dem Transkript seines Vortrags mit Nate Purkeypile auf der GDC 2013, das auf Burgess' Blog steht: „We usually stick to a minimum of two character widths. This allows us to avoid pathing problems by ensuring there’s at least enough space for two AI characters to path around each other in any given space.“ Die Folien zum Vortrag liegen bei [Slideshare](https://www.slideshare.net/JoelBurgess/gdc2013-kit-buildingfinal). + + Übertragen auf das Raster: Zwei Fußbreiten sind 20 Pixel. Wände liegen im 16-Pixel-Raster, also ist der schmalste Gang nach dieser Regel 2 Tiles breit, 32 Pixel. Ein Gang von einem Tile, 16 Pixeln, lässt einer Fußform von 10 Pixeln 3 Pixel an jeder Seite. Mit Godot 4.7.2 nachgeprüft läuft sie durch einen senkrechten Gang dieser Breite ([Blockout in Godot](/level-design/blockout)). Ein Gegner kommt aber nicht an ihr vorbei, und wer schräg in die Öffnung läuft, hat wenig Spielraum. Wie sich das in deinem Spiel anfühlt, hängt an Kollisionsform und Bewegungscode; das prüfst du im Maßstabsraum. Ob die Regel aus Skyrim für dein Spiel gilt, entscheidest du. Sie gibt dir einen begründeten Startwert. + + Für Türen schreibt das Buch: „Modern doors should be narrower than hallways to allow space for a door frame.“ Im Raster heißt das, eine Tür von 2 Tiles in einem Gang von 3 Tiles zu planen, oder bewusst zu entscheiden, dass Türen so breit sind wie der Gang. In der 3/4-Ansicht kommt etwas hinzu: Zeichnest du Wände hoch, kann ihre Vorderseite im Bild einen Teil des Gangs dahinter verdecken. Der Gang wirkt dann schmaler, als er ist. + + Aus solchen Entscheidungen entsteht eine Tabelle von Gebäudemaßen, etwa „enger Gang 2, Standardgang 3, Tür 2, breiter Durchgang 4 Tiles“. Die Zahlen hier sind ein Lehrbeispiel. Deine Tabelle schreibst du nach dem Maßstabsraum. + + > [!PRAXIS] Bethesda misst den engsten Raum + > Burgess rät, früh den schmalsten begehbaren Raum des Spiels festzulegen: „It’s also worth figuring out the most narrow traversable space in the game.“ Der Grund ist praktisch: Zwei computergesteuerte Figuren müssen aneinander vorbeikommen. Bethesda bringt Baukästen dafür so früh wie möglich in einen Zustand, den das Team „functional-but-ugly“ nennt, damit das Design schon mit den echten Maßen arbeiten kann, während die Grafik ohne Eile ihre Richtung findet (Transkript; [Folien bei Slideshare](https://www.slideshare.net/JoelBurgess/gdc2013-kit-buildingfinal)). Für dich heißt das: Gangbreiten in grauen Tiles festlegen und ablaufen, lange bevor ein Tile gezeichnet ist. + + ## Arenen in Ausweichweiten + + Eine Arena ist eine Fläche für eine Begegnung. Wie Kämpfe darin ablaufen, behandelt der Combat-Kurs. Hier geht es um ihre Größe. Das Level Design Book stellt dafür eigene Fragen, „What is "close range" or "long range"? How big is a "big fight"?“ ([Combat metrics](https://book.leveldesignbook.com/process/blockout/metrics#combat-metrics)). In einem Spiel mit Ausweichrolle ist die Ausweichweite ein gutes Maß. Bei 66 Pixeln sind das gut 4 Tiles. + + Ein Lehrbeispiel: Eine Arena von 12 × 8 Tiles ist 192 × 128 Pixel groß. Quer passen zwei volle Ausweichrollen, die dritte endet an der Wand. Zu Fuß ist die Breite in 2,1 Sekunden durchquert. Die Arena passt in einen Bildschirm von 20 × 11 Tiles, der Spieler sieht also den ganzen Kampf. Ist sie größer als ein Bildschirm, entscheidet die Kamera mit, was er sieht; dazu [Große Kreaturen als Bosse](/combat/grosse-gegner). + + Ein großer Gegner nimmt Fläche weg. Das Level Design Book beschreibt einen Kampf in Elden Ring, einen großen Wolf in einem mittelgroßen Saal: „The medium-sized room makes the large wolf feel even larger. It will be difficult to dodge the wolf's attacks.“ Und weiter: „Furniture and clutter further limit the player's mobility and options. (Until the boss destroys the furniture, opening up more floor space, making the fight a bit easier.)“ ([Safety as game state](https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#safety-as-game-state)) Raumgröße, Gegnergröße und Einrichtung ergeben zusammen, wie viel Platz zum Ausweichen bleibt, und das kann sich im Kampf ändern. + + ## Freiflächen und Dichte + + Eine leere, weite Fläche kündigt etwas an. Das Level Design Book zählt es zu den subtilen Hinweisen, wenn „a room feels structured like a boss battle arena“ ([Subtle](https://book.leveldesignbook.com/process/blockout/wayfinding#subtle-1-20-certainty)). Christopher Totten beschreibt Bossräume als „typically wide-open places for staging elaborate encounters with strong enemies“ und die in Mega Man als Räume mit „little or no elaboration or places to hide“ ([Game Developer, 2011](https://www.gamedeveloper.com/design/designing-better-levels-through-human-survival-instincts)). Eine Freifläche ist damit ein Versprechen. Passiert dort nie etwas, lernt der Spieler, dass sie nichts bedeutet. + + **Dichte** ist der Anteil der Fläche, den Hindernisse belegen. Sie wirkt auf drei Arten: + + - **Reibung.** Hindernisse verlängern Wege und verlangen Lenken. Im Bericht von 4Gamer über einen Vortrag zu Breath of the Wild heißt es über kleine Felsen und Hügel, sie führten zu häufigen Eingaben am Stick und bestimmten so das Tempo der Erkundung (eigene Übersetzung, [4Gamer](https://www.4gamer.net/games/341/G034168/20170901120/)). + - **Deckung.** „Cover is any object that blocks a sightline and/or combat.“ (Level Design Book, [Enclosure](https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#enclosure)) In der Draufsicht sperren hohe Hindernisse Geschosse und Sicht, niedrige nur den Weg. + - **Rauschen.** Viele kleine Formen gleicher Stärke machen das Bild unruhig, siehe [Komposition und Blickführung](/level-design/blickfuehrung). + + Messen lässt sich Dichte in einer Rasterkarte, Hindernisse geteilt durch begehbare Fläche plus Hindernisse. Legende: `#` Wand, `.` Boden, `o` niedriges Hindernis. + + ```text + ############ + #..o....o..# + #....o.....# + #.o.....o..# + #.....o....# + ############ + ``` + + Hier sind es 6 von 40 Tiles, 15 Prozent. Die Zahl allein sagt nicht alles. Gleichmäßig verstreut steht in jeder Innenzeile ein Hindernis im Weg, wer waagerecht durch den Raum will, muss Haken schlagen. Dieselben sechs als zwei Gruppen lassen ganze Zeilen und eine zusammenhängende Fläche frei. Ob du Gassen willst oder Gestrüpp, folgt aus deiner Absicht. + + ## Größe wirken lassen: Bezugsobjekte und Bildausschnitt + + In einem Spiel mit pixelgenauer Darstellung kannst du nicht frei zoomen. `Camera2D.zoom` 2 macht aus jedem Weltpixel 2 × 2 Spielpixel und halbiert die sichtbare Welt auf 160 × 90 Pixel, eine Zoomstufe wie 1,5 macht manche Pixel ein, andere zwei Spielpixel breit ([Pixelraster und Skalierung](/godot/pixelraster), [Camera2D, zoom](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-zoom)). Größe muss also anders entstehen. + + Das Level Design Book fragt, was die Wahrnehmung von Größe und Tempo bestimmt, und antwortet: „Basically anything on the screen.“ ([Metrics of perception](https://book.leveldesignbook.com/process/blockout/metrics#metrics-of-perception)) In der Draufsicht sind das vor allem drei Dinge, eine Einteilung dieses Kurses: + + - **Bezugsobjekte.** Dinge, deren Größe der Spieler kennt, eine Tür, eine Kiste, die eigene Figur. Neben ihnen liest er ab, wie groß etwas Unbekanntes ist. Wie du Größen im Bild festhältst, zeigt die Maßstabstabelle in [Ansichten, Maßstab und große Kreaturen](/pixelart/ansichten-massstab). + - **Raumgröße.** Derselbe Gegner wirkt im engen Saal riesig und auf einer weiten Ebene klein, wie beim Wolf in Elden Ring. + - **Der Bildausschnitt.** Ein Objekt, das ein Drittel des Bildschirms füllt, wirkt anders als eines, das über den Bildrand ragt. + + Ungewöhnliche Größe braucht Gewöhnliches drumherum. Das Buch schreibt: „to make something feel unusual, you must contrast it with enough usual common elements first.“ + + > [!WARNING] Kein krummer Zoom für mehr Übersicht + > Wenn eine Arena nicht ins Bild passt, liegt die Lösung im Layout oder in der Kamera, nicht in einem Zoom von 0,75. Krumme Zoomstufen verzerren Pixelart. + + ## Enge und Weite + + In der Architektur gibt es dafür einen Namen. „In architecture, compression and expansion or compression and release is a technique in which small, narrow and sometimes dark spaces lead to ones that are large and bright.“ Die Technik lebe vom Kontrast und lasse große Räume größer wirken, als sie sind; bekannt gemacht hat sie Frank Lloyd Wright ([Wikipedia](https://en.wikipedia.org/wiki/Compression_and_expansion)). In einer Rasterkarte sieht das so aus, Legende wie oben: + + ```text + ######..###### + ######..###### + #............# + #............# + #............# + #............# + ######..###### + ``` + + Ein Gang von 2 Tiles öffnet sich in eine Fläche von 12 Tiles Breite, und am anderen Ende wird es wieder eng. + + Totten teilt Räume nach ihrer Größe im Verhältnis zur Figur in drei Gruppen: + + - **Narrow Space**, „A small enclosed space where the occupant feels confined and unable to move“. Er schreibt dazu: „In a narrow passage an enemy can literally become another wall of the space, diminishing the size of the space with each approaching step.“ + - **Intimate Space**, „neither confining nor overly large“. Alles darin soll „immediately accessible to the player and within reach of their avatar and their inherent abilities“ sein. Solche Räume wachsen mit den Fähigkeiten der Figur. + - **Prospect Space**, offen und ausgesetzt. Dazu zählt er die Bossräume. + + Dan Taylor beschreibt dieselbe Folge an Tomb Raider (2013): Lara gehe „from narrow, claustrophobic caves, through sprawling, epic jungles, to vertiginous mountain ascents“ ([Ten Principles, Teil 2](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-2-)). Enge und Weite wirken im Wechsel. Ein Abschnitt aus lauter gleich großen Räumen hat diesen Kontrast nicht. + + Totten beschreibt auch eine Folge aus Rückzugsort, offener Fläche und nächstem Rückzugsort, englisch Refuge, Prospect und „Secondary Refuge“, und schreibt: „Secondary Refuges can urge the occupant of a space forward“. Das Level Design Book hält diese Theorie für begrenzt nützlich, „This book argues that prospect-refuge, as traditionally understood, has limited application to level design“, und nennt Sicherheit im Spiel „a situation / game state, not a formal quality of architecture“ ([Prospect-refuge](https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge)). Es schlägt stattdessen die Begriffe Sichtlinie, Aussichtspunkt, Deckung und Umschließung vor. Für dieses Modul reicht: Enge und Weite misst du in Tiles. Was sie im Ablauf eines Levels bedeuten, behandelt [Rhythmus](/level-design/rhythmus). + + ## Der Maßstabsraum + + Das Level Design Book empfiehlt einen „metrics zoo“ oder „metrics playground“, eine Testkarte nur für dich, mit allen Bauteilen deines Spiels ([Build a metrics zoo test map](https://book.leveldesignbook.com/process/blockout/metrics#build-a-metrics-zoo-test-map)). Die Schritte dort: einen Blockout mit verschiedenen Räumen und Gängen bauen, auf Benutzbarkeit testen, auf Gefühl testen, ändern und wiederholen. Für ein Top-down-Spiel könnte ein Maßstabsraum zum Beispiel enthalten: + + - Gänge von 1, 2 und 3 Tiles Breite, gerade und mit Ecke, + - Türen in verschiedenen Breiten, die man auch schräg anläuft, + - eine Fläche in der Größe deiner Standardarena mit einer Linie in Ausweichweite, + - zwei Hindernisfelder mit verschiedener Dichte, + - Bezugsobjekte in der Größe deiner Maßstabstabelle. + + Burgess gibt dazu eine Rechenregel für Baukästen. Teilbaukästen sollen Grundflächen haben, die Vielfache voneinander sind: „a 512x512x512 room will always tile nicely with a 256x256x256 hallway, but a 384x384x384 room will eventually create gaps and/or overlaps.“ Im Tile-Raster heißt das: Ist dein Gangmodul 2 Tiles breit, gehen Räume von 8, 10 oder 12 Tiles auf, solche von 9 nicht. + + Auf Papier geht das unterwegs, ein Kästchen pro Tile. Den Maßstabsraum in Godot baust du in [Blockout in Godot](/level-design/blockout). Ein kleines Skript, das Abstände im Spiel anzeigt, darf dir eine KI schreiben. Welche Breiten und Größen bleiben, entscheidest du nach dem Ablaufen. + + > [!TIP] Erst ablaufen, dann festschreiben + > Schreib ein Maß erst in deine Tabelle, wenn du es im Maßstabsraum abgelaufen bist, auch schräg und mit Ausweichen. Ein Gang, der auf Papier reicht, kann sich mit 360°-Bewegung an jeder Ecke verhaken. + + > [!INTERVIEW] „Wie legst du fest, wie breit Gänge und wie groß Arenen werden?“ + > Ich fange bei der Figur an: Fußform, Tempo, Ausweichweite, gemessen im Spiel. Für Gänge nehme ich mindestens zwei Fußbreiten, auf das Raster aufgerundet, damit Figur und Gegner aneinander vorbeikommen. Arenen rechne ich in Ausweichweiten und in Sekunden zu Fuß und prüfe, ob sie in den Bildschirm passen. Dann baue ich einen Maßstabsraum, laufe alles ab, auch schräg, und schreibe erst danach eine Tabelle mit Gebäudemaßen. Ändert sich das Tempo der Figur, prüfe ich die Tabelle neu. + + ## Häufige Fehler + + - **Gang so breit wie die Figur.** Ein Tile für eine Fußform von 10 Pixeln. Die Figur kommt durch, ein Gegner nicht an ihr vorbei. + - **Maße nach Augenmaß im Editor.** Ohne Bezug zu Fußform, Tempo und Ausweichweite passt nichts zusammen, sobald sich eine Zahl ändert. + - **Arena ohne Rechnung.** Zu klein für zwei Ausweichrollen oder so groß, dass der Kampf über den Bildrand läuft, ohne dass es Absicht war. + - **Gleichmäßig verstreute Hindernisse.** Kein freier Weg, keine freie Fläche, viel Rauschen. + - **Freifläche ohne Folge.** Weite Räume kündigen etwas an. Bleiben sie leer, verliert das Signal seinen Wert. + - **Größe über Zoom.** Krumme Zoomstufen zerstören das Pixelraster. + - **Alles gleich groß.** Ohne Enge gibt es keine Weite. + - **Maße, die nicht aufgehen.** Räume, die keine Vielfachen des Gangmoduls sind, erzeugen Lücken und Sonderteile. + + ## Zusammenfassung + + - Player Metrics misst du im Spiel, Building Metrics legst du fest. Beide rechnest du in Tiles. + - Mit den Platzhaltern läuft die Figur 5,6 Tiles pro Sekunde, weicht gut 4 Tiles weit aus und hat eine Fußform von 10 Pixeln Breite. + - Gänge sind mindestens zwei Fußbreiten breit, auf das Raster aufgerundet. Bei 10 Pixeln sind das 20 Pixel, also 2 Tiles. + - Arenen misst du in Ausweichweiten und Sekunden und prüfst, ob sie in einen Bildschirm passen. Große Gegner und Einrichtung nehmen Fläche weg. + - Dichte wirkt als Reibung, Deckung und Rauschen. Ihre Verteilung zählt so viel wie ihre Menge. + - Größe entsteht über Bezugsobjekte, Raumgröße und Bildausschnitt, nicht über krummen Zoom. + - Enge und Weite wirken im Wechsel. Im Maßstabsraum probierst du Maße aus, bevor du sie festschreibst. +exercises: + - id: spieler-oder-bau + type: choice + title: Gemessen oder entschieden? + prompt: | + Das Level Design Book trennt Player Metrics, die man im Spiel misst, von Building Metrics, die man festlegt. Welche dieser Werte sind Player Metrics? + options: + - text: "`move_speed = 90` Pixel pro Sekunde" + correct: true + why: Das Tempo ist ein Wert der Figur, den du im Spiel messen und prüfen kannst. + - text: Das Ausweichen trägt die Figur 66 Pixel weit. + correct: true + why: Die Weite folgt aus Tempo und Dauer des Ausweichens und lässt sich im Log nachmessen. + - text: Die Fußform ist 10 × 6 Pixel groß. + correct: true + why: Sie ist die Kollisionsform der Figur, ein Fakt im Projekt. + - text: Ein Standardgang ist 3 Tiles breit. + correct: false + why: Das ist eine Building Metric. Du legst sie fest, abgeleitet aus den Player Metrics und deiner Absicht. + - text: Arenen für große Gegner sind 16 × 10 Tiles groß. + correct: false + why: Auch das ist eine Entscheidung, die du triffst, nicht ein Wert, den das Spiel misst. + explanation: | + Player Metrics beschreiben die Physik der Figur, Building Metrics schreiben vor, wie gebaut wird. Die zweiten leitest du aus den ersten ab. Ändert sich das Tempo oder die Ausweichweite, müssen die Gebäudemaße neu geprüft werden, nicht umgekehrt. + hints: + - Drei Werte sind richtig. + resources: + - title: The Level Design Book · Metrics, What are metrics? + url: https://book.leveldesignbook.com/process/blockout/metrics#what-are-metrics + + - id: gangbreite + type: choice + title: Der schmalste Gang + prompt: | + Die Fußform der Figur ist 10 Pixel breit (Platzhalter), Wände liegen im Raster von 16 Pixeln. Welche ist die schmalste Gangbreite, die Burgess' Regel von mindestens zwei Figurbreiten erfüllt? + options: + - text: 1 Tile, 16 Pixel + correct: false + why: Zwei Fußbreiten sind 20 Pixel. Die Figur passt durch ein Tile, ein Gegner kommt aber nicht an ihr vorbei. + - text: 1,25 Tiles, 20 Pixel + correct: false + why: Rechnerisch genau zwei Fußbreiten, aber Wände liegen im Raster. Einen Gang von 1,25 Tiles gibt es dort nicht. + - text: 2 Tiles, 32 Pixel + correct: true + why: Das erste Rastermaß über 20 Pixeln. Zwei Figuren kommen aneinander vorbei. + - text: 3 Tiles, 48 Pixel + correct: false + why: Erfüllt die Regel auch, ist aber nicht der schmalste Gang. Ob dein Standardgang 2 oder 3 Tiles breit ist, entscheidest du im Maßstabsraum. + explanation: | + Die Regel nennt eine Untergrenze, keine Wunschbreite. 20 Pixel auf das Raster aufgerundet ergibt 2 Tiles. Das Level Design Book fügt hinzu, dass sich die doppelte Breite noch eng anfühlt. Ein Standardgang darf deshalb breiter sein. Der engste Gang des Spiels ist aber eine Zahl, die du kennen solltest. + hints: + - Rechne erst in Pixeln, dann auf ganze Tiles aufrunden. + resources: + - title: Joel Burgess, Nate Purkeypile, Skyrim's Modular Approach (Folien) + url: https://www.slideshare.net/JoelBurgess/gdc2013-kit-buildingfinal + + - id: massstabsraum-schritte + type: order + title: Ein Maßstabsraum entsteht + prompt: | + Du willst die Maße für dein Spiel in einem Maßstabsraum finden. Bring die Schritte in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Schreib die Werte deiner Figur auf, Fußform, Tempo und Ausweichweite. + Bau einen Testraum mit Gängen, Türen und einer Fläche aus grauen Platzhalter-Tiles. + Lauf durch alle Gänge und Türen, auch schräg und mit Ausweichen. + Notier, welche Breiten sich zu eng oder zu weit anfühlen. + Ändere ein Maß und lauf denselben Weg noch einmal. + Schreib die Maße, die bleiben, in deine Tabelle der Gebäudemaße. + explanation: | + Das Level Design Book nennt für einen „metrics zoo“ dieselbe Folge: Blockout bauen, auf Benutzbarkeit und Gefühl testen, ändern, wiederholen. Die Werte der Figur stehen am Anfang, weil alle Maße davon abhängen. Die Tabelle steht am Ende, weil erst das Ablaufen zeigt, welche Maße tragen. Wer eine Zahl ändert, läuft denselben Weg, sonst vergleicht er zwei verschiedene Tests. + hints: + - Was muss feststehen, bevor du einen Gang bauen kannst? + resources: + - title: The Level Design Book · Build a metrics zoo test map + url: https://book.leveldesignbook.com/process/blockout/metrics#build-a-metrics-zoo-test-map + + - id: metriken-in-tiles + type: output + title: Eine andere Figur in Tiles + prompt: | + Lehrbeispiel: eine schnellere Figur mit anderen Platzhaltern. Was gibt das Modell aus? + lang: python + code: | + import math + + # Lehrbeispiel, Platzhalter + TILE = 16 + TEMPO = 120 + AUSWEICHEN = 80 + FUSS_B = 14 + + s_tile = round(TILE / TEMPO, 2) + print(TEMPO / TILE, s_tile) + print(AUSWEICHEN / TILE) + zwei = 2 * FUSS_B + print(math.ceil(zwei / TILE)) + expected: | + 7.5 0.13 + 5.0 + 2 + hints: + - 16 / 120 sind 0,1333 Sekunden. + - Zwei Fußbreiten sind 28 Pixel. Wie viele ganze Tiles braucht man dafür? + explanation: | + Die Figur läuft 7,5 Tiles pro Sekunde, ein Tile in 0,13 Sekunden. Ein Ausweichen trägt sie genau 5 Tiles weit. Zwei Fußbreiten sind 28 Pixel, aufgerundet 2 Tiles, also bleibt der schmalste Gang gleich, obwohl die Figur breiter ist. Eine Fußform über 16 Pixel würde 3 Tiles verlangen. `math.ceil` rundet auf: 28 / 16 sind 1,75 Tiles. Abgerundet wäre der Gang ein Tile breit, 16 Pixel, also 12 Pixel zu schmal. Aufgerundet ist er 32 Pixel breit, 4 Pixel mehr als nötig. + resources: + - title: Python · math.ceil + url: https://docs.python.org/3/library/math.html#math.ceil + + - id: ausweichen-quer + type: output + title: Wie viele Ausweichrollen passen quer? + prompt: | + Das Modell rechnet für drei Arenabreiten, wie viele volle Ausweichrollen quer hineinpassen und wie viele Sekunden die Figur zu Fuß hindurch braucht. Alle Werte sind Platzhalter. Was gibt es aus? + lang: python + code: | + # Platzhalter + TILE, TEMPO = 16, 90 + AUSWEICHEN = 66 + + def quer(breite): + px = breite * TILE + rollen = px // AUSWEICHEN + sek = round(px / TEMPO, 1) + return rollen, sek + + for breite in (8, 12, 20): + print(breite, quer(breite)) + expected: | + 8 (1, 1.4) + 12 (2, 2.1) + 20 (4, 3.6) + hints: + - "`//` teilt ganzzahlig: 192 // 66 ist 2." + - 20 Tiles sind 320 Pixel, ein ganzer Bildschirm. + explanation: | + 8 Tiles sind 128 Pixel, darin passt eine volle Ausweichrolle, zu Fuß 1,4 Sekunden. 12 Tiles sind 192 Pixel, zwei Rollen, 2,1 Sekunden. Ein ganzer Bildschirm, 320 Pixel, fasst vier Rollen und ist in 3,6 Sekunden durchquert. Damit hast du ein Maß für „groß“ und „klein“, das an deiner Figur hängt. Wie viele Rollen ein Kampf braucht, hängt an den Angriffen; das entscheidet der Combat-Teil deines Spiels. + resources: + - title: The Level Design Book · Combat metrics + url: https://book.leveldesignbook.com/process/blockout/metrics#combat-metrics + + - id: dichte-zaehlen + type: output + title: Wie dicht ist der Raum? + prompt: | + Das Modell zählt Boden und niedrige Hindernisse in einer Rasterkarte und gibt danach den Anteil der Hindernisse in Prozent aus. Legende: `#` Wand, `.` Boden, `o` niedriges Hindernis. Was gibt es aus? + lang: python + code: | + raum = [ + "############", + "#o...oo....#", + "#o...oo....#", + "#..........#", + "#....oo..oo#", + "############", + ] + text = "".join(raum) + boden = text.count(".") + hindernis = text.count("o") + alle = boden + hindernis + anteil = hindernis / alle + print(boden, hindernis) + print(round(100 * anteil)) + expected: | + 30 10 + 25 + hints: + - Jede Innenzeile hat 10 Tiles. Zähl die `o` Zeile für Zeile. + explanation: | + Die vier Innenzeilen haben 40 Tiles, davon 10 Hindernisse, also 25 Prozent. Anders als in der Lektion stehen die Hindernisse hier in Gruppen, und die vierte Zeile der Karte, `#..........#`, bleibt ganz frei. Dieselbe Dichte kann eine Gasse lassen oder ein Gestrüpp bilden. Die Zahl hilft beim Vergleichen zweier Felder, die Verteilung siehst du nur in der Karte. + resources: + - title: The Level Design Book · Prospect-refuge, Enclosure + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#enclosure + + - id: zoom-ausschnitt + type: output + title: Zoom 2 im kleinen Bild + prompt: | + Im Spielbild von 320 × 180 Pixeln steht `Camera2D.zoom` auf `(2, 2)`. Tiles sind 16 Pixel. Wie viele volle Tiles zeigt das Bild quer und hoch? Antworte in der Form „quer × hoch“. + lang: text + code: | + sichtbar = Bildgröße / zoom + Bild 320 × 180 + zoom 2 + Tile 16 + expected: | + 10 × 5 + accept: ["10 x 5", "10x5", "10×5", "10 mal 5", "10 × 5 Tiles", "10 x 5 Tiles", "10x5 Tiles", "10×5 Tiles"] + explanation: | + Zoom 2 zeigt 160 × 90 Pixel der Welt, also 10 Tiles quer und 5 volle Tiles hoch, ein Viertel der Fläche. Alles wirkt doppelt so groß, und der Spieler sieht nach oben nur noch 45 Pixel voraus. Zoom 2 hält das Pixelraster gleichmäßig, ändert aber den ganzen Maßstab des Spiels. Für einen einzelnen großen Raum ist es deshalb selten die richtige Antwort. + resources: + - title: Godot Docs · Camera2D, zoom + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-zoom + + - id: enge-weite-begriffe + type: gap + title: Eng, vertraut, offen + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Totten teilt Räume in drei Größen: den ⟦Narrow⟧ Space, in dem man sich eingeengt fühlt, den ⟦Intimate⟧ Space, in dem alles in Reichweite der Figur liegt, und den ⟦Prospect⟧ Space, offen und ausgesetzt. In der Architektur heißt eine Folge von eng zu weit compression and ⟦release⟧. Wie groß etwas ist, liest der Spieler an einem ⟦Bezugsobjekt⟧ ab, dessen Größe er kennt. + gaps: + - label: eng + hint: Englisch für „schmal“. + accept: ["narrow"] + - label: vertraut + hint: Englisch für „vertraut, nah“. + accept: ["intimate"] + - label: offen + hint: Englisch für „Aussicht“. + accept: ["prospect"] + - label: Freigabe + hint: Wikipedia nennt auch „compression and expansion“. + accept: ["expansion"] + - label: Vergleich + hint: Eine Tür oder Kiste neben dem großen Ding. + accept: ["Vergleichsobjekt", "Referenzobjekt", "Bezugsgegenstand", "Bezugspunkt"] + explanation: | + Tottens drei Größen messen Räume an der Figur, nicht in Metern. Compression and release beschreibt die Folge aus beiden. Bezugsobjekte sind das Werkzeug, mit dem Größe in einem Spiel ohne freien Zoom entsteht. + resources: + - title: Wikipedia · Compression and expansion + url: https://en.wikipedia.org/wiki/Compression_and_expansion + + - id: gang-zu-schmal + type: bug + title: Hier bleiben sie hängen + prompt: | + Lehrbeispiel: zwei Räume, verbunden durch einen Gang. Absicht: Der Gang ist überall mindestens zwei Fußbreiten breit, bei 10 Pixeln Fußbreite also 20 Pixel, im Raster 2 Tiles. Tester stoßen im Gang an eine Kante, und ein Gegner kommt nicht an der Figur vorbei. Finde die Zeile. + + Legende: `#` Wand, `.` Boden, `S` Start, `A` Ausgang + lang: text + code: | + ######################## + #......#########.......# + #..S................A..# + #...........####.......# + #......#########.......# + ######################## + lines: [4] + explanation: | + Der Gang liegt in Zeile 3 und 4 zwischen den Räumen. In Zeile 4 ragt ein Wandstück von vier Tiles hinein. Dort ist der Gang nur noch ein Tile breit, 16 Pixel für eine Fußform von 10. Die Figur passt hindurch, aber wer schräg anläuft, stößt an die Ecke des Wandstücks, und für zwei Figuren nebeneinander ist kein Platz. Abhilfe: das Wandstück entfernen oder den Gang an dieser Stelle nach oben verbreitern. + hints: + - Zähl in jeder Spalte des Gangs, wie viele Reihen Boden übereinanderliegen. + + - id: arena-notiz + type: bug + title: Eine Zeile rechnet falsch + prompt: | + Lehrbeispiel: Notiz zu einer Arena. Tile 16 Pixel, Platzhalter aus dem Kurs. Eine Zeile stimmt nicht. Finde sie und korrigiere sie. + lang: prose + code: | + Arena: 12 × 8 Tiles = 192 × 128 Pixel + Ausweichweite: 66 Pixel = gut 2 Tiles + Quer passen 2 volle Ausweichrollen. + Großer Gegner: 4 × 3 Tiles, belegt 12 von 96 Tiles. + Freie Fläche für die Figur: 84 Tiles. + lines: [2] + fix: + - line: 2 + answers: ["Ausweichweite: 66 Pixel = gut 4 Tiles", "Ausweichweite: 66 Pixel = 4 Tiles", "Ausweichweite: 66 Pixel = 4,1 Tiles", "Ausweichweite: 66 Pixel = etwa 4 Tiles", "Ausweichweite: 66 Pixel = rund 4 Tiles", "Ausweichweite: 66 Pixel = über 4 Tiles", "Ausweichweite: 66 Pixel = knapp über 4 Tiles"] + explanation: | + 66 / 16 = 4,1 Tiles, nicht gut 2. Die übrigen Zeilen stimmen: 192 / 66 ergibt zwei volle Rollen, der Gegner belegt 12 der 96 Tiles, und 84 bleiben frei. Ein Faktor zwei in der Ausweichweite verschiebt jede Entscheidung über die Arena. Mit „gut 2 Tiles“ würde die Arena doppelt so geräumig wirken, wie sie ist. + hints: + - Teil 66 durch 16. + + - id: elden-ring-saal + type: explain + title: Ein Wolf im Saal + prompt: | + Das Level Design Book beschreibt einen Bosskampf in Elden Ring. Hier zwei Sätze daraus, wörtlich. Erkläre in drei bis fünf Sätzen, wie Raumgröße und Einrichtung den Kampf und die Wirkung des Gegners verändern und was das für die Planung einer Arena heißt. + lang: prose + code: | + The medium-sized room makes the large wolf feel even larger. It will be difficult to dodge the wolf's attacks. + + Furniture and clutter further limit the player's mobility and options. (Until the boss destroys the furniture, opening up more floor space, making the fight a bit easier.) + points: + - Der Raum ist der Bezug für die Größe des Gegners. Ein mittelgroßer Saal lässt einen großen Gegner noch größer wirken. + - Weniger freie Fläche heißt weniger Platz zum Ausweichen. Raumgröße ist eine Kampfgröße. + - Möbel erhöhen die Dichte und schränken die Bewegung weiter ein. Werden sie zerstört, wächst die freie Fläche und der Kampf wird leichter. + - Für eine Arena heißt das, freie Fläche, Gegnergröße und Hindernisse zusammen zu rechnen und auch zu planen, wie sie sich im Kampf ändern. + explanation: | + Der Saal ist der Maßstab, an dem der Spieler den Wolf misst. Weil der Raum nur mittelgroß ist, füllt der Wolf viel davon, und das macht ihn groß und gefährlich zugleich, denn es bleibt wenig Platz zum Ausweichen. Die Möbel erhöhen die Dichte noch und nehmen Wege weg. Dass der Boss sie zerstört, ändert die Arena während des Kampfs: Mehr freie Fläche macht ihn leichter. Für eine eigene Arena rechne ich deshalb nicht nur ihre Größe, sondern die freie Fläche nach Abzug von Gegner und Einrichtung, und ich überlege, ob sich diese Fläche im Kampf ändern soll. + hints: + - Woran misst der Spieler, wie groß der Wolf ist? + resources: + - title: The Level Design Book · Prospect-refuge, Safety as game state + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#safety-as-game-state + + - id: zwei-breiten + type: explain + title: Warum zwei Figurbreiten? + prompt: | + Zwei Quellen zur Gangbreite, wörtlich. Erkläre in drei bis fünf Sätzen, was sie fordern, warum, und wie du die Regel auf ein Top-down-Spiel im 16-Pixel-Raster überträgst. + lang: prose + code: | + Level Design Book: „The minimum hallway width should be at least double the player width. Even then, it will feel a bit narrow and uncomfortable.“ + + Joel Burgess (Skyrim, GDC 2013, Transkript): „We usually stick to a minimum of two character widths. This allows us to avoid pathing problems by ensuring there’s at least enough space for two AI characters to path around each other in any given space.“ + points: + - Beide nennen zwei Figurbreiten als Untergrenze, nicht als Ziel. Auch das fühlt sich laut Buch noch eng an. + - Der Grund bei Burgess ist praktisch. Zwei computergesteuerte Figuren müssen aneinander vorbeikommen. + - In der Draufsicht zählt die Breite der Fußform, weil sie an Wänden anstößt, nicht das Bild der Figur. + - Im Raster rundest du auf ganze Tiles auf. Bei 10 Pixeln Fußbreite sind das 20 Pixel, also 2 Tiles. + explanation: | + Beide Quellen setzen die Untergrenze bei zwei Figurbreiten. Das Buch sagt dazu, dass sich selbst das noch eng anfühlt, Burgess begründet sie mit der Wegfindung: Zwei Figuren müssen aneinander vorbeikommen, sonst bleiben Gegner stecken. In einem Top-down-Spiel messe ich die Breite der Fußform, weil sie mit Wänden kollidiert. Bei 10 Pixeln sind zwei Breiten 20 Pixel, und weil Wände im 16-Pixel-Raster liegen, ist der engste Gang 2 Tiles breit. Wie breit der Standardgang wird, entscheide ich danach im Maßstabsraum. + hints: + - Wer muss in einem Gang aneinander vorbeikommen? + resources: + - title: The Level Design Book · Basic metrics + url: https://book.leveldesignbook.com/process/blockout/metrics#common-modern-architecture-dimensions + + - id: massstabsraum-skizze + type: practice + title: Dein Maßstabsraum auf Papier + prompt: | + Skizzier auf Karopapier einen Maßstabsraum, ein Kästchen pro Tile. Nimm die Werte deiner Figur, wenn du sie schon hast, sonst die Platzhalter des Kurses. Welche Gänge, Flächen und Hindernisse du hineinstellst und wie breit sie sind, entscheidest du. Hier notierst du die Werte und Maße in wenigen Zeilen. + lang: prose + starter: | + Figur (Fußform, Tempo, Ausweichweite): + Gänge (Breiten in Tiles): + Türen: + Fläche für eine Arena (Tiles, Ausweichrollen quer): + Hindernisfelder (Dichte in Prozent): + checklist: + - Die Werte der Figur stehen da und sind als eigene Werte oder Platzhalter gekennzeichnet. + - Es gibt Gänge in mindestens drei Breiten, darunter einen, der schmaler ist als zwei Fußbreiten. + - Die Arenafläche ist in Tiles, Ausweichrollen und Sekunden zu Fuß angegeben. + - Es gibt zwei Hindernisfelder mit verschiedener Dichte, beide in Prozent ausgerechnet. + - Die Raummaße sind Vielfache deiner Gangbreite. + explanation: | + Der Maßstabsraum ist der Ort, an dem aus Zahlen Gefühl wird. Der zu schmale Gang gehört absichtlich hinein: An ihm merkst du, wo deine Grenze liegt. Auf Papier prüfst du, ob die Maße zusammenpassen. Ob sie sich richtig anfühlen, zeigt erst das Ablaufen im [Blockout](/level-design/blockout). + hints: + - Fang mit der Arena an. Gänge und Räume rechnest du dann in Vielfachen deiner Gangbreite. + resources: + - title: The Level Design Book · Build a metrics zoo test map + url: https://book.leveldesignbook.com/process/blockout/metrics#build-a-metrics-zoo-test-map + + - id: enge-weite-beobachten + type: practice + title: Eng, dann weit, in einem fremden Spiel + prompt: | + Such in einem veröffentlichten Top-down-Spiel eine Stelle, an der ein enger Weg in eine weite Fläche führt. Schätz die Breiten in Tiles, etwa an der Größe der Figur oder einer Tür. Notier in höchstens fünf Stichpunkten, was du findest. + lang: prose + starter: | + Spiel und Stelle: + Breite eng / weit (geschätzt, Tiles): + Bezugsobjekt für die Schätzung: + Was in der weiten Fläche passiert: + Hindernisse in der Fläche (viele, wenige, Gruppen): + checklist: + - Spiel und Stelle sind genannt. + - Beide Breiten sind in Tiles geschätzt, und du nennst das Bezugsobjekt. + - Du beschreibst, was in der weiten Fläche passiert, ohne es zu werten. + - Du beschreibst, wie die Hindernisse in der Fläche verteilt sind. + explanation: | + Die Schätzung über ein Bezugsobjekt ist dieselbe Arbeit, die ein Spieler beim Ansehen macht. Passiert in der weiten Fläche eine Begegnung, hat das Spiel das Versprechen der Freifläche eingelöst. Passiert dort nichts, achte darauf, ob die Fläche einen anderen Zweck hat, etwa einen Ausblick. Was die Stelle im Ablauf leistet, ordnest du mit [Rhythmus](/level-design/rhythmus) ein. + hints: + - Die eigene Figur ist das zuverlässigste Bezugsobjekt. + resources: + - title: Christopher W. Totten, „Designing Better Levels Through Human Survival Instincts“ + url: https://www.gamedeveloper.com/design/designing-better-levels-through-human-survival-instincts diff --git a/content/level-design/modules/orientierung.yaml b/content/level-design/modules/orientierung.yaml new file mode 100644 index 0000000..5754c0d --- /dev/null +++ b/content/level-design/modules/orientierung.yaml @@ -0,0 +1,478 @@ +id: orientierung +title: Wege, Landmarken und Sichtlinien +level: 2 +minutes: 100 +summary: Wie Spieler eine Karte im Kopf bauen – Lynchs Wege, Kanten, Bereiche, Knoten und Landmarken in der Draufsicht –, wie du Landmarken und Sichtlinien mit Bildausschnitt, Kameragrenzen, hohen Verdeckern und Licht setzt und wann Verlaufen zum Spiel gehört. +place: unterwegs +goals: + - Du ordnest die Teile eines Top-down-Abschnitts Lynchs fünf Elementen zu und erkennst, wo die mentale Karte keinen Halt hat. + - Du unterscheidest ferne und nahe Landmarken und prüfst sie darauf, ob sie einzigartig, sichtbar und beständig sind. + - Du rechnest mit den Kameragrenzen von Godot aus, ob eine Landmarke von einer Stelle aus im Bild ist. + - Du setzt Sichtlinien, Verdecker, Schleifen und Abkürzungen zu Knoten bewusst ein. + - Du unterscheidest gewolltes von ungewolltem Verlaufen und wählst Hilfen von subtil bis direkt, Karte und Kompass zuletzt. +resources: + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding + - title: Wikipedia · The Image of the City (Kevin Lynch, 1960) + url: https://en.wikipedia.org/wiki/The_Image_of_the_City + - title: Push Square · Interview mit Jenova Chen zu Journey (2012) + url: https://www.pushsquare.com/news/2012/02/interview_thatgamecompany_journey + - title: 4Gamer · Bericht zum CEDEC-Vortrag über Breath of the Wild (2017, Japanisch) + url: https://www.4gamer.net/games/341/G034168/20170901120/ + - title: Godot Docs · Camera2D, limit_left + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-limit-left +lesson: | + Jenova Chen fasst das Ziel von Journey (thatgamecompany, 2012) in einem Satz: „The game’s goal is simple: go to the mountain.“ Im selben Interview erklärt er, warum sich Spieler in der weiten Wüste trotzdem nicht verlieren. Offene Flächen machen ratlos, „When you have open space it often feels like you don’t know where to go, you feel lost.“ Journey sei groß, aber geführt, „because there’s always a ‘doorway’, a giant ‘weenie’“. Das Wort stammt aus Disneys Parks und meint „something in the distance to guide you in the right direction“ ([Push Square, 2012](https://www.pushsquare.com/news/2012/02/interview_thatgamecompany_journey)). Welche Dinge im Spiel diese Rolle übernehmen, sagt Chen dort nicht im Einzelnen. + + In der Draufsicht gibt es keinen Horizont, an dem ein Ziel in der Ferne stehen könnte. Der Spieler sieht den Bildschirm, 20 × 11 Tiles im Platzhaltermaß dieses Kurses, und was er sich merkt. Orientierung muss aus diesem Rahmen und aus der Erinnerung kommen. Dieses Modul zeigt, aus welchen Elementen Spieler eine Karte im Kopf bauen, wie Landmarken in der Draufsicht funktionieren, wie du Sichtlinien setzt und wann Verlaufen zum Spiel gehört. Den Bildausschnitt und das Grundmodell aus Absicht, Hinweis und Verhalten kennst du aus [Level lesen](/level-design/raum-lesen), die Mittel, mit denen ein Bild den Blick lenkt, aus [Komposition und Blickführung](/level-design/blickfuehrung). + + ## Die mentale Karte: Lynchs fünf Elemente in der Draufsicht + + Das Level Design Book trennt zwei Fragen: „Wayfinding is when a player finds where they are in the level (orientation) and/or finds a route toward their destination (navigation).“ ([Wayfinding](https://book.leveldesignbook.com/process/blockout/wayfinding#what-is-wayfinding)) Für beide braucht der Spieler eine Vorstellung vom Raum, eine **mentale Karte**. + + Wie solche Karten aufgebaut sind, hat der Stadtplaner Kevin Lynch fünf Jahre lang in Boston, Jersey City und Los Angeles untersucht. Sein Buch „The Image of the City“ erschien 1960 bei MIT Press ([Verlagsseite](https://mitpress.mit.edu/9780262620017/the-image-of-the-city/)). Lynchs Kernsatz steht hier so, wie ihn ein Aufsatz der American Society of Appraisers zitiert, nicht nach dem Buch selbst: „The contents of the city images can conveniently be classified into five types of elements: paths, edges, districts, nodes, and landmarks.“ ([ASA, PDF](https://www.appraisers.org/docs/default-source/discipline_rp/site-analysis-part-9.pdf?sfvrsn=0)) Die Kurzbeschreibungen in der Mitte folgen der Zusammenfassung bei [Wikipedia](https://en.wikipedia.org/wiki/The_Image_of_the_City). Die rechte Spalte ist die Übertragung dieses Kurses. + + | Element | bei Lynch | in der Draufsicht | + | --- | --- | --- | + | Wege (paths) | Kanäle, in denen Menschen sich bewegen | Gänge, Pfade, Brücken, Treppen | + | Kanten (edges) | Mauern, Gebäude, Ufer | Wände, Klippen, Wasser, Zäune, die Grenze zwischen zwei Böden | + | Bereiche (districts) | größere Flächen, die man betritt und verlässt | Abschnitte mit eigenem Boden, Licht oder Material | + | Knoten (nodes) | Orte, die man betritt, wo Wege zusammenlaufen | Kreuzungen, Plätze, Räume mit mehreren Ausgängen | + | Landmarken (landmarks) | Bezugspunkte, die man nicht betritt | ein Turm, ein großer Baum, ein umgestürzter Pfeiler | + + Kanten sind nicht alle gleich. Das Level Design Book unterscheidet Barrieren, die Weg und Sicht sperren, etwa Wände, von solchen, die nur den Weg sperren, „deep pits, canyons, lava, rivers“ ([Direct](https://book.leveldesignbook.com/process/blockout/wayfinding#direct-95-98-certainty)). Die Rasterkarten dieses Kurses tragen den Unterschied in der Legende: `#` sperrt Weg und Sicht, `~` und `o` nur den Weg. Ein Fluss trennt zwei Bereiche und zeigt zugleich, was drüben liegt. + + Fehlt jeder Bezugspunkt, schätzen Menschen ihre Lage aus Richtung, Tempo und Zeit. Das Buch nennt das „dead reckoning“, eine Methode für Lagen, „when no landmarks are available“. Weil sich bei dieser Schätzung jeder Fehler zum nächsten addiert, wird sie mit jeder Abbiegung unsicherer. Wer durch drei gleiche Gänge gelaufen ist, weiß irgendwann nicht mehr, ob er zweimal oder dreimal links abgebogen ist. + + > [!TIP] Eine Karte aus dem Gedächtnis + > Das Level Design Book verweist auf Mapstalgia, eine Sammlung von Karten, die Spieler aus dem Gedächtnis gezeichnet haben, „often beautiful and wildly inaccurate“. Das Buch nennt sie „the closest thing we have to a player's mental map“ ([Further reading](https://book.leveldesignbook.com/process/blockout/wayfinding#further-reading)). Zeichne einen Abschnitt aus einem Spiel, das du kennst, ohne nachzusehen. Was du richtig erinnerst, hat deine Karte getragen. + + ## Landmarken: einzigartig, sichtbar, beständig + + Bei Lynch, wieder nach dem Zitat der ASA, sind Landmarken Bezugspunkte, die man von außen nutzt: „the observer does not enter within them, they are external“. Ihr Gebrauch bedeutet „the singling out of one element from a host of possibilities“. Lynch unterscheidet zwei Arten: + + - **Ferne Landmarken** sieht man „from many angles and distances“. Manche stehen so weit weg, dass sie „for all practical purposes“ eine Richtung anzeigen, „a constant direction“. Seine Beispiele sind einzelne Türme, goldene Kuppeln, große Hügel, sogar die Sonne, weil sie sich langsam und regelmäßig bewegt. + - **Nahe Landmarken** sind „visible only in restricted localities and from certain approaches“: Schilder, Schaufenster, Bäume, sogar Türknäufe. Auf sie verlassen sich Menschen umso mehr, je vertrauter ihnen ein Weg wird. + + Daraus leitet dieser Kurs drei Prüffragen ab: + + - **Einzigartig.** Gibt es das im Abschnitt nur einmal? Wikipedia fasst Lynch so zusammen, dass mindestens ein Merkmal „unique or memorable“ sein muss. Zwei gleiche Brunnen an zwei Kreuzungen sind keine Landmarken, sie machen die Kreuzungen verwechselbar. + - **Sichtbar.** Ist sie dort im Bild, wo der Spieler sich entscheidet? Nicht hinter einer hohen Wand, nicht unter einem Dach, nicht im Dunkeln, nicht außerhalb der Kameragrenzen. + - **Beständig.** Bleibt sie, wo sie ist, und sieht sie beim zweiten Besuch gleich aus? Ein patrouillierender Gegner, eine Truhe, die nach dem Öffnen verschwindet, oder ein Licht, das ausgeht, taugen schlecht. + + Lynch bemerkt auch über Knoten, die gelungensten schienen „both to be unique in some way and at the same time to intensify some surrounding characteristic“ (zitiert bei Wikipedia). Ein Knoten wird erkennbar, wenn er etwas Eigenes hat, das zum Bereich um ihn passt. + + In der Draufsicht ist die ferne Landmarke das schwierigste Element. Ein Turm am Horizont fehlt. Es gibt Ersatz, alles Übertragungen dieses Kurses: eine Kante, die über viele Bildschirme läuft und eine Richtung trägt, wie ein Fluss oder eine Mauer; ein Knoten, an dem der Spieler oft vorbeikommt; oder ein hohes Objekt in der 3/4-Ansicht. Dessen Bild ragt nach oben, sein oberes Ende ist deshalb noch zu sehen, wenn der Fuß schon unter dem unteren Bildrand liegt. Wie diese Ansicht gezeichnet wird, steht in [Grundkörper, Perspektive und Draufsicht](/pixelart/grundkoerper-raum). + + > [!MERKE] Drei Prüffragen für eine Landmarke + > Gibt es sie nur einmal? Ist sie am Entscheidungspunkt im Bild? Bleibt sie, wie sie ist? + + ## Sichtlinien in der Draufsicht: Bildausschnitt, Verdecker, Licht + + „A sightline is a line of empty space where one area can be seen from another area.“ So definiert es das Level Design Book. Als Nutzen von Aussichtspunkten nennt es, „preview landmarks, and offer layout information“ ([Instead of prospect](https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#instead-of-prospect)). In der Draufsicht entscheiden vier Dinge darüber, ob es eine Sichtlinie gibt: + + 1. **Bildausschnitt und Kameragrenzen.** Was nicht im Bild ist, sieht niemand. + 2. **Hohe Verdecker.** Wände, Dächer und hohe Bäume verdecken in der 3/4-Ansicht, was im Bild über ihnen liegt. Niedrige Hindernisse und Wasser verdecken nichts. + 3. **Licht und Dunkel.** Christopher Totten trennt Schatten, der versteckt, von Halbdunkel, das neugierig macht: „Where Shadow is primarily used to hide objects or the nature of spaces, Shade is used to obscure objects and evoke a sense of curiosity in players“ ([Game Developer, 2011](https://www.gamedeveloper.com/design/designing-better-levels-through-human-survival-instincts)). + 4. **Blickachsen.** Ein gerader Weg oder eine Öffnung, die auf die Landmarke zeigt, hält sie beim Gehen länger im Bild. + + Verdecken ist kein Fehler, sondern ein Werkzeug. Das zeigt ein Vortrag zu Breath of the Wild auf der japanischen Entwicklerkonferenz CEDEC 2017, über den das Fachmedium 4Gamer ausführlich berichtet hat. Die Sätze hier sind eigene Übersetzungen aus dem japanischen Bericht, keine Quelle von Nintendo ([4Gamer](https://www.4gamer.net/games/341/G034168/20170901120/)). Makoto Yonezu stellte dort eine Regel vor, die im Team „Regel der Felddreiecke“ hieß, englisch meist „Triangle Rule“. Das Gelände ist so gebaut, dass es aus Sicht des Spielers meist als Dreieck erscheint. Große Dreiecke wie Berge sind Landmarken, die man von weit her sieht. Mittlere verdecken Orte dahinter. Kleine Felsen und Hügel bestimmen das Tempo der Erkundung in der Nähe. Geht der Spieler weiter, erscheint, was das Dreieck verdeckt hat, und das weckt den Wunsch, als Nächstes dorthin zu gehen. Rechtecke verdecken vollständig und geben die Sicht plötzlich frei. Die englische Zusammenfassung bei [80 Level](https://80.lv/articles/the-design-secrets-of-breath-of-the-wild/) stützt sich auf Übersetzungen von Matt Walker und schreibt: „the team used them to surprise players, making them wonder what they’ll find on the other side.“ + + Die Übertragung auf die Draufsicht ist deine Arbeit. Die Verdecker sind dort der Bildrand, hohe Wände, Dächer und Dunkelheit. Eine Öffnung zeigt die Sicht frei, wenn die Kamera an einer Wandkante vorbeiscrollt. + + ### Kameragrenzen: was nie ins Bild kommt + + Godot begrenzt mit `limit_left`, `limit_top`, `limit_right` und `limit_bottom`, wie weit die Kamera scrollt: „The camera stops moving when reaching this value“ ([Camera2D, limit_right](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-limit-right)). Die Grenzen gelten für den Bildrand, nicht für die Bildmitte. Die Mitte bleibt deshalb einen halben Bildschirm von jeder Grenze entfernt. Nachgemessen mit Godot 4.7.2 in einem Bild von 320 × 180 Pixeln: Mit `limit_right = 640` bleibt die Bildmitte bei x = 480 stehen, auch wenn die Figur weiter nach rechts läuft. + + ```python run + # halbe Bildbreite, Platzhalter + HALB = 320 // 2 + + def mitte_x(fx, links, rechts): + m = max(fx, links + HALB) + return min(m, rechts - HALB) + + # Landmarke bei 900, Raum 960 + for rechts in (640, 960): + m = mitte_x(900, 0, rechts) + sicht = abs(900 - m) <= HALB + print(rechts, m, sicht) + ``` + + Mit einer Grenze bei 640 ist die Landmarke bei x = 900 nie im Bild, und die Figur läuft rechts aus dem Bild. Mit der Grenze am Rand des Raums, 960, steht die Mitte bei 800, und die Landmarke ist zu sehen. + + > [!WARNING] Grenzen schneiden auch Landmarken ab + > Eine Landmarke, die jenseits einer Kameragrenze steht, etwa im nächsten Raum hinter der Wand, sieht der Spieler von hier aus nie. Prüf bei jeder Landmarke, von welchen Bildmitten aus sie im Bild ist. `offset` kann die Kamera laut Doku über die Grenzen schieben; das ist eine eigene Entscheidung. + + ## Knoten, Schleifen und Abkürzungen + + Knoten sind die Stellen, an denen Spieler sich entscheiden. Dort zählt Orientierung am meisten, und dort gehören Landmarken hin. Kommt der Spieler an einen Knoten zurück, erkennt er ihn und weiß wieder, wo er ist. + + Eine **Schleife** führt zu einem bekannten Knoten zurück, ohne denselben Weg zu nehmen. Der Spieler kann seine Karte im Kopf prüfen: Er kommt dort an, wo er es erwartet. Eine **Abkürzung**, die sich am Ende eines Wegs zum Knoten öffnet, spart den langen Rückweg. Das Level Design Book zählt die Frage, „how much backtracking should be allowed?“, zu den Maßen, die du für dein Spiel festlegst ([Pacing metrics](https://book.leveldesignbook.com/process/blockout/metrics#pacing-metrics)). Dan Taylor verlangt für Wege, die man zweimal geht, „bi-directional gameplay, preferably with a key modifier on the second pass“ ([Ten Principles, Teil 2](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-2-)). Der Rückweg soll sich anders spielen als der Hinweg. + + **Brotkrumen** sind eine Reihe von Fundstücken, die einen Weg zeigen. Das Buch schätzt ihre Wirkung hoch ein, auf 80 Prozent, und nennt „lines of collectible items or powerups (Donkey Kong Country)“ und Dinge, die man aus der Ferne sieht, „weenies“, dasselbe Disney-Wort wie bei Chen ([Situational](https://book.leveldesignbook.com/process/blockout/wayfinding#situational-70-93-certainty)). + + **Sackgassen** sind erlaubt, wenn sie etwas bieten. Taylor beschreibt eine Truhe in Skyrim, die „clearly visible from the main path“ ist, „but has no obvious access“. Der Lohn ist sichtbar, der Weg dahin muss gefunden werden. Breath of the Wild nennt das, was Spieler vom Weg abzieht, laut 4Gamer 引力, „Anziehungskraft“. Hidemaro Fujibayashi definierte sie als eine Kraft, die den Spieler zu einem Ort zieht, weil es sich für ihn lohnt (eigene Übersetzung). Eine Sackgasse ohne Lohn und ohne Grund kostet den Weg hinein und den Weg zurück. + + ## Gewolltes und ungewolltes Verlaufen + + Nicht jedes Verlaufen ist ein Fehler. Taylor hält es für richtig, Bereiche zu verstecken, „as long as you provide the necessary visual or narrative clues“, und sogar „to create areas where the player feels lost or confused, to create a sense of dramatic tension“ ([Ten Principles, Teil 1](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-)). Das Level Design Book warnt vor dem Gegenteil: „Heavy use of landmarking, signposting, and breadcrumbing, will make a level feel like Disneyland.“ Wer eine echte Wildnis will, kann laut Buch eine Art „anti-wayfinding“ brauchen ([Against wayfinding](https://book.leveldesignbook.com/process/blockout/wayfinding#against-wayfinding)). + + Breath of the Wild zeigt beide Seiten in einem Test. Laut 4Gamer verteilte das Team zuerst Türme als Ziele über die Welt und legte Ereignisse auf die Wege dazwischen. Testspieler, die den Straßen folgten, empfanden die Welt als einen einzigen vorgegebenen Weg. Wer die Straßen verließ, hatte den Eindruck, kaum auf Ereignisse zu treffen. Fujibayashi nannte das Erlebnis „im schlechten Sinn zerstückelt“ (eigene Übersetzung). Laut Bericht antwortete das Team darauf mit der Anziehungskraft: Orte, die unterwegs ins Blickfeld kommen und zu einem Umweg locken, nach dem der Spieler auf seinen Weg zurückkehrt. + + Für deine Abschnitte hilft eine Unterscheidung, die dieser Kurs vorschlägt: + + | | gewollt | ungewollt | + | --- | --- | --- | + | Ziel | Der Spieler weiß, was er sucht, oder weiß, dass er erkundet. | Der Spieler weiß nicht, was er sucht. | + | Rückweg | Ein bekannter Knoten ist erreichbar. | Er findet nicht zurück. | + | Ende | Das Suchen endet in einem Fund oder einem Ausblick. | Er läuft dieselbe Runde noch einmal. | + + Andrew Shouldice beschreibt für Tunic Phasen, in denen man etwas lernt. Eine davon ist „knowledge [phase] where you know something exists, but you don't understand it“ ([Game Developer, 2023](https://www.gamedeveloper.com/design/video-how-the-tunic-developers-built-a-mysterious-world)). Ein sichtbarer, noch unerreichbarer Ort ist so eine offene Frage. Gewollt ist sie, wenn der Spieler sie als Frage erkennt. Woran du ungewolltes Verlaufen beim Zusehen erkennst, etwa am Stehenbleiben an Knoten oder am Hin und Her zwischen zwei Gängen, behandelt [Playtests beobachten](/level-design/playtest-methode). + + ## Hilfen von subtil bis direkt: Karte und Kompass zuletzt + + Das Level Design Book ordnet Hilfen zur Orientierung in vier Stufen nach geschätzter Sicherheit, „a non-scientific estimate“: subtil (1 bis 20 Prozent), grob (35 bis 60), situativ (70 bis 93) und direkt (95 bis 98). Einige Beispiele aus den Tabellen: + + | Hilfe | Stufe | Schätzung | + | --- | --- | --- | + | ungewöhnliches Detail, etwa ein feiner Riss | subtil | 10 % | + | Komposition, Sichtlinie auf eine Landmarke | grob | 35 % | + | Licht und Farbe | grob | 40 % | + | Brotkrumen aus Fundstücken | situativ | 80 % | + | dauerhafte Zielmarkierung, Minikarte im HUD | direkt | 97 % | + + Der Rat dazu lautet: „When possible, it's considered good practice to start at the top, and gradually incorporate less subtle methods in response to playtesting.“ ([Wayfinding aids](https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids)) Bei der direkten Stufe schreibt das Buch auch „sometimes it's OK to "give up"“. Eine Karte ist erlaubt. Sie ersetzt aber kein Layout, in dem man sich zurechtfindet, sie hilft nur, es zu lesen. Wie stark Markierungen im Raum sein dürfen, behandelt [Umgebung als Information](/level-design/umgebung-informiert). Auch Klang kann orientieren; das gehört in den späteren Sound-Kurs. + + > [!PRAXIS] Journey ohne Worte, Kompass und Karte + > Chen sagt über Journey: „We used the environment to guide the player without using words, or compass, or map.“ Für Spieler, die zu weit abweichen, gibt es eine unsichtbare Wand, die sagt, „hey, that’s probably not the direction you wanna go“. Geprüft hat das Team es an vielen Menschen: „we’ve tested the game on at least 200 people and they all managed to find their way out themselves“ ([Push Square](https://www.pushsquare.com/news/2012/02/interview_thatgamecompany_journey)). Die Hilfen bleiben subtil, die harte Grenze kommt erst am Rand, und ob es reicht, zeigt der Test. + + > [!INTERVIEW] „Tester verlaufen sich in deinem Abschnitt. Was tust du?“ + > Zuerst schaue ich, wo es passiert, meist an einem Knoten, und ob es gewollt ist. Dann prüfe ich die Landmarke dort: Ist sie einzigartig, ist sie am Entscheidungspunkt mit unserer Kamera im Bild, bleibt sie gleich? Ich prüfe auch, ob es von dort eine Schleife oder Abkürzung zu einem bekannten Knoten gibt. Ich ändere eine Sache, etwa eine Sichtlinie oder eine stärkere Landmarke, und teste mit neuen Leuten. Erst wenn subtile Mittel nicht reichen, nehme ich direktere wie Brotkrumen oder eine Markierung auf der Karte. + + ## Häufige Fehler + + - **Gleiche Knoten.** Zwei Kreuzungen mit demselben Brunnen und denselben Böden. Der Spieler hält die zweite für die erste. + - **Landmarke hinter einer hohen Wand.** In der 3/4-Ansicht verdeckt die Wand, was im Bild über ihr liegt, auch wenn es im Bildausschnitt ist. + - **Landmarke jenseits der Kameragrenze.** Sie steht im Level, aber nie im Bild. + - **Bewegliche Landmarken.** Ein Gegner oder ein Licht, das ausgeht, ist beim zweiten Besuch nicht mehr da. + - **Sackgassen ohne Grund.** Hinweg und Rückweg kosten Zeit, und am Ende steht nichts. Danach misstraut der Spieler jedem Seitengang. + - **Kein Rückweg zum Knoten.** Ein langer Weg ohne Schleife oder Abkürzung zwingt zum Zurücklaufen durch Bekanntes. + - **Alles markiert.** Jede Abzweigung hat ein Licht und ein Fundstück, und der Abschnitt wirkt wie ein Themenpark. + - **Karte statt Layout.** Die Minikarte zeigt den Weg, weil der Raum ihn nicht zeigt. + + ## Zusammenfassung + + - Spieler bauen eine mentale Karte aus Wegen, Kanten, Bereichen, Knoten und Landmarken. Ohne Bezugspunkte schätzen sie, und jede Abbiegung macht die Schätzung unsicherer. + - Kanten sperren Weg und Sicht oder nur den Weg. Die Legende dieses Kurses trennt `#` von `~` und `o`. + - Eine Landmarke ist einzigartig, am Entscheidungspunkt sichtbar und beständig. Ferne Landmarken zeigen eine Richtung, nahe tragen vertraute Wege. + - In der Draufsicht entscheiden Bildausschnitt, Kameragrenzen, hohe Verdecker, Licht und Blickachsen über Sichtlinien. Verdecken ist ein Werkzeug für Überraschung und Anreiz. + - Kameragrenzen gelten für den Bildrand. Die Bildmitte bleibt einen halben Bildschirm von jeder Grenze entfernt. + - Schleifen und Abkürzungen führen zu bekannten Knoten zurück. Sackgassen brauchen einen Lohn. + - Verlaufen ist gewollt, wenn der Spieler sein Ziel kennt und zurückfindet. Hilfen setzt du von subtil nach direkt, nach jedem Playtest eine Stufe, wenn nötig. +exercises: + - id: lynch-zuordnen + type: choice + title: Fünf Elemente in einem Abschnitt + prompt: | + Lehrbeispiel: ein Top-down-Abschnitt mit einem Fluss, einer Brücke, einem Platz und einem Viertel. Welche Zuordnungen zu Lynchs fünf Elementen stimmen? + options: + - text: Ein Fluss, der den Abschnitt teilt und nur an einer Brücke überquert werden kann, ist eine Kante. + correct: true + why: Er trennt zwei Bereiche und begrenzt die Bewegung. Lynch nennt Ufer ausdrücklich als Kante. Weil er die Sicht nicht sperrt, zeigt er zugleich, was drüben liegt. + - text: Ein Platz, auf den vier Gassen münden, ist ein Knoten. + correct: true + why: Man betritt ihn, und Wege laufen dort zusammen. Hier entscheidet sich der Spieler. + - text: Ein Viertel mit rotem Pflaster und Laternen an jeder Ecke ist ein Bereich. + correct: true + why: Es ist eine größere Fläche mit gemeinsamen Merkmalen, die man betritt und verlässt. + - text: Ein Hof, den man betritt und von dem drei Wege abgehen, ist eine Landmarke. + correct: false + why: Landmarken betritt man laut Lynch nicht, sie sind äußere Bezugspunkte. Ein Hof, an dem Wege zusammenlaufen, ist ein Knoten. Eine Statue in seiner Mitte könnte eine Landmarke sein. + explanation: | + Lynchs Elemente unterscheiden sich darin, was man mit ihnen tut. Auf Wegen bewegt man sich, Kanten begrenzen, Bereiche betritt man als Fläche, Knoten als Ort der Entscheidung, Landmarken nutzt man von außen. Ein Raum kann mehrere Rollen haben: Die Brücke ist ein Weg über eine Kante. + hints: + - Drei Aussagen sind richtig. + - Betritt man eine Landmarke? + resources: + - title: Wikipedia · The Image of the City + url: https://en.wikipedia.org/wiki/The_Image_of_the_City + + - id: landmarke-waehlen + type: choice + title: Woran erkennt man Kreuzung B? + prompt: | + Lehrbeispiel: Ein Abschnitt hat drei Kreuzungen, A, B und C, die der Spieler mehrmals passiert. An Kreuzung B soll er beim Zurückkommen sofort wissen, wo er ist. Welche Landmarke erfüllt die drei Prüffragen am besten? + options: + - text: Ein umgestürzter Pfeiler quer über der Kreuzung, der einzige im Abschnitt, von allen vier Zugängen aus im Bild. + correct: true + why: Er ist einzigartig, am Entscheidungspunkt sichtbar und bleibt liegen. Alle drei Prüffragen sind erfüllt. + - text: Ein Brunnen, wie er auch an Kreuzung A und C steht. + correct: false + why: Er ist nicht einzigartig. Drei gleiche Brunnen machen die Kreuzungen verwechselbar, statt sie zu unterscheiden. + - text: Ein auffällig gefärbter Gegner, der an der Kreuzung patrouilliert. + correct: false + why: Er bewegt sich und ist nach dem Kampf weg. Beim zweiten Besuch fehlt der Bezugspunkt. + - text: Eine große Statue in einem Seitenraum neben der Kreuzung, sichtbar, sobald man den Seitenraum betritt. + correct: false + why: Sie ist von der Kreuzung aus nicht im Bild. Am Entscheidungspunkt hilft sie nicht. + explanation: | + Eine Landmarke muss dort wirken, wo der Spieler sich entscheidet, und sie muss beim zweiten Besuch dieselbe sein. Lynch beschreibt Landmarken als das Herausgreifen eines Elements aus vielen Möglichkeiten. Was es mehrfach gibt, was sich bewegt oder was man vom Knoten aus nicht sieht, kann diese Aufgabe nicht übernehmen. + hints: + - Prüf jede Option mit drei Fragen. Gibt es sie nur einmal, ist sie im Bild, bleibt sie? + resources: + - title: American Society of Appraisers · Land/Site Analysis, Part 9 (zitiert Lynch, PDF) + url: https://www.appraisers.org/docs/default-source/discipline_rp/site-analysis-part-9.pdf?sfvrsn=0 + + - id: hilfen-stufen + type: order + title: Von subtil bis direkt + prompt: | + Das Level Design Book ordnet Hilfen zur Orientierung nach der geschätzten Sicherheit, mit der Spieler sie bemerken und nutzen. Bring diese sechs Hilfen in die Reihenfolge des Buchs, von der subtilsten zur direktesten. + lang: prose + lines: | + Eine Hommage an einen bekannten Ort erinnert nur Kenner an ein anderes Spiel. + Ein feiner Riss in der Wand fällt als ungewöhnliches Detail auf. + Eine Sichtlinie öffnet den Blick auf eine große Landmarke in der Ferne. + Ein beleuchteter Eingang hebt sich in einem dunklen Raum ab. + Eine Reihe Fundstücke führt zum Ziel. + Eine dauerhafte Markierung im HUD zeigt das Ziel. + explanation: | + Das Buch schätzt die Hommage auf 1 Prozent, das ungewöhnliche Detail auf 10, Komposition und Sichtlinien auf 35, Licht und Farbe auf 40, Brotkrumen auf 80 und eine dauerhafte Markierung im HUD auf 97. Die Zahlen sind ausdrücklich keine Messung. Die Reihenfolge ist trotzdem nützlich: Du fängst oben an und gehst nur dann eine Stufe weiter, wenn der Playtest zeigt, dass die subtilere Hilfe nicht reicht. + hints: + - Licht und Sichtlinie liegen nah beieinander. Das Buch stellt Komposition und Sichtlinien knapp vor Licht und Farbe. + resources: + - title: The Level Design Book · Wayfinding aids + url: https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids + + - id: landmarke-im-bild + type: output + title: Von wo sieht man die Landmarke? + prompt: | + Ein Raum ist 640 × 360 Pixel groß, die Kameragrenzen liegen an seinen Rändern. Die Landmarke steht bei (600, 40). Das Modell gibt für vier Positionen der Figur, (100, 300), (450, 300), (450, 200) und (620, 100), die Bildmitte aus und ob die Landmarke im Bild ist. Die Bildmitten stimmen mit Godot 4.7.2 überein, nachgemessen. Was gibt es aus? + lang: python + code: | + # halbes Bild, Platzhalter + HB, HH = 160, 90 + # limit_left/top/right/bottom + L, O, R, U = 0, 0, 640, 360 + # Landmarke + LX, LY = 600, 40 + + def klemme(w, a, b): + return min(max(w, a), b) + + wege = [(100, 300), (450, 300), + (450, 200), (620, 100)] + for fx, fy in wege: + mx = klemme(fx, L + HB, R - HB) + my = klemme(fy, O + HH, U - HH) + sx = abs(LX - mx) <= HB + sy = abs(LY - my) <= HH + print(mx, my, sx and sy) + expected: | + 160 270 False + 450 270 False + 450 200 False + 480 100 True + hints: + - Die Bildmitte liegt waagerecht zwischen 160 und 480, senkrecht zwischen 90 und 270. + - Senkrecht ist die Landmarke im Bild, wenn die Mitte höchstens 90 Pixel von y = 40 entfernt ist. + explanation: | + Bei (100, 300) klemmen beide Grenzen die Mitte auf (160, 270). Bei (450, 300) ist die Landmarke waagerecht nah genug, aber 230 Pixel zu weit oben. Bei (450, 200) sind es noch 160 Pixel, auch das ist mehr als ein halber Bildschirm hoch. Erst bei (620, 100) klemmt die rechte Grenze die Mitte auf x = 480, und die Landmarke ist 120 Pixel seitlich und 60 Pixel oben, also im Bild. Eine Landmarke in einer Ecke sieht man nur aus der Nähe dieser Ecke. Und weil das Bild nach oben nur 90 Pixel reicht, kostet jede Reihe Abstand nach oben mehr als zur Seite. + resources: + - title: Godot Docs · Camera2D, limit_bottom + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-limit-bottom + + - id: abkuerzung-sekunden + type: output + title: Was spart die Abkürzung? + prompt: | + Lehrbeispiel: Vom Ende eines Seitenwegs zurück zum Knoten sind es auf dem Hinweg 46 Tiles. Eine Abkürzung, die sich dort öffnet, ist 9 Tiles lang. Tiles sind 16 Pixel, die Figur läuft 90 Pixel pro Sekunde (Platzhalter). Wie viele Sekunden spart die Abkürzung? Runde auf eine Nachkommastelle und antworte mit der Zahl. + lang: text + code: | + Sekunden = Tiles × 16 / 90 + Hinweg 46 Tiles + Abkürzung 9 Tiles + expected: | + 6.6 + accept: ["6,6", "6,6 s", "6.6 s", "6,6 Sekunden"] + explanation: | + Der Hinweg dauert 46 × 16 / 90 = 8,2 Sekunden, die Abkürzung 9 × 16 / 90 = 1,6. Die Differenz sind 37 × 16 / 90 = 6,58, gerundet 6,6 Sekunden. Das klingt wenig, aber ein Spieler, der denselben Weg zum dritten Mal zurückläuft, spürt jede davon. Wie viel Rückweg dein Spiel verträgt, legst du als eigenes Maß fest, das Level Design Book zählt es zu den Pacing-Metriken. + resources: + - title: The Level Design Book · Metrics, Pacing metrics + url: https://book.leveldesignbook.com/process/blockout/metrics#pacing-metrics + + - id: lynch-begriffe + type: gap + title: Die Karte im Kopf + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Lynch teilt die mentale Karte einer Stadt in fünf Elemente: Wege, ⟦Kanten⟧, Bereiche, ⟦Knoten⟧ und ⟦Landmarken⟧. Eine Landmarke betritt man nicht, sie ist ein äußerer ⟦Bezugspunkt⟧. Ohne Landmarken schätzen Menschen ihre Lage aus Richtung, Tempo und Zeit. Das Level Design Book nennt das dead ⟦reckoning⟧. + gaps: + - label: Grenzen + hint: Mauern, Ufer und Klippen gehören dazu. + accept: ["Ränder", "Grenzen", "edges"] + - label: Entscheidungsorte + hint: Dort laufen Wege zusammen. + accept: ["nodes", "Knotenpunkte"] + - label: Bezugspunkte + hint: Ein Turm oder ein großer Baum. + accept: ["landmarks", "Wahrzeichen", "Landmarks"] + - label: was eine Landmarke ist + hint: Lynch spricht von „point-reference“. + accept: ["Orientierungspunkt", "Referenzpunkt", "point-reference", "Punkt", "Bezugspunkte"] + - label: Koppelnavigation + hint: Das englische Wort für die Rechnung der Seefahrer. + accept: ["Reckoning", "dead reckoning", "Dead Reckoning"] + explanation: | + Wege, Kanten, Bereiche, Knoten und Landmarken sind Lynchs Bausteine der mentalen Karte. Landmarken sind äußere Bezugspunkte, an Knoten entscheidet man sich. Dead reckoning ist die Notlösung ohne Bezugspunkte. Sie funktioniert, wird aber mit jeder Abbiegung ungenauer. + resources: + - title: The Level Design Book · Wayfinding, Psychology + url: https://book.leveldesignbook.com/process/blockout/wayfinding#psychology + + - id: landmarke-verdeckt + type: bug + title: Die Landmarke, die keiner sieht + prompt: | + Lehrbeispiel in der 3/4-Ansicht. Eine Mauer aus `#` ist im Bild zwei Tiles höher als ihr Fuß und verdeckt deshalb, was in den zwei Reihen direkt über ihr liegt. Der Spieler startet bei `S` und soll beim Hochlaufen die Landmarke `L` sehen. Kein Tester erwähnt sie. Finde die Zeile, die sie verdeckt. + + Legende: `#` hohe Wand, `.` Boden, `+` Durchgang, `S` Start, `L` Landmarke (ein Tile hoch gezeichnet) + lang: text + code: | + #################### + #..................# + #.......L..........# + #..................# + #..######+######...# + #..................# + #..................# + +.........S........# + #################### + lines: [5] + explanation: | + Die Mauer in Zeile 5 steht zwei Reihen unter der Landmarke, genau in derselben Spalte. In der 3/4-Ansicht reicht ihr Bild zwei Tiles nach oben und deckt Zeile 4 und 3 ab, also auch `L`. Der Durchgang liegt eine Spalte daneben, die Sichtlinie durch ihn trifft die Landmarke nicht. Abhilfe: die Landmarke über den Durchgang oder weiter nach oben setzen, die Mauer durch niedrige Hindernisse ersetzen oder die Landmarke höher zeichnen als die Mauer. Welche Lösung passt, hängt davon ab, ob der Spieler sie schon vor dem Durchgang sehen soll. + hints: + - Zähl von der Landmarke zwei Reihen nach unten. + + - id: grenze-schneidet + type: bug + title: Die Kamera bleibt stehen + prompt: | + Lehrbeispiel: Kameraeinstellungen für einen Raum. Läuft die Figur nach rechts, verschwindet sie ab x = 640 aus dem Bild, und die Landmarke taucht nie auf. Finde die Zeile und korrigiere sie. + lang: text + code: | + Raum: 960 × 360 Pixel + Landmarke: x = 900, y = 60 + limit_left = 0 + limit_right = 640 + limit_top = 0 + limit_bottom = 360 + lines: [4] + fix: + - line: 4 + answers: ["limit_right = 960", "limit_right=960"] + explanation: | + `limit_right` gilt für den rechten Bildrand. Mit 640 bleibt die Bildmitte bei 640 − 160 = 480 stehen, das Bild reicht bis x = 640. Was rechts davon liegt, auch die Figur und die Landmarke bei 900, ist nie im Bild. Mit 960, dem Rand des Raums, kann die Mitte bis 800 wandern, und die Landmarke ist zu sehen. Solche Werte stammen oft aus einer früheren, kleineren Fassung des Raums. + resources: + - title: Godot Docs · Camera2D, limit_right + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-limit-right + + - id: journey-weenie + type: explain + title: Etwas in der Ferne + prompt: | + Jenova Chen im Interview mit Push Square (2012) über Journey, wörtlich zitiert. Erkläre in drei bis fünf Sätzen, wie Journey laut Chen die Orientierung löst, welche Rolle die unsichtbare Wand spielt und was davon in der Draufsicht nicht direkt funktioniert. + lang: prose + code: | + When you have open space it often feels like you don’t know where to go, you feel lost. You don’t know how to navigate. Actually in Journey we can say it’s huge but the experience is rather guided, because there’s always a ‘doorway’, a giant ‘weenie’ — which is a Disney term, it’s something in the distance to guide you in the right direction. If you were to wander really far away from the map, we do have an invisible wall that tells you, “hey, that’s probably not the direction you wanna go.” So we’ve tested the game on at least 200 people and they all managed to find their way out themselves, so we’re pretty proud of that. We used the environment to guide the player without using words, or compass, or map. + points: + - Eine offene Fläche ohne Ziel macht ratlos. Ein sichtbares Ziel in der Ferne gibt die Richtung. + - Der „weenie“ ist immer da und zieht, die unsichtbare Wand fängt erst ab, wer sehr weit abweicht. + - Chen verzichtet auf Text, Kompass und Karte und belegt die Wirkung mit Tests an mindestens 200 Menschen. + - In der Draufsicht fehlt der Horizont. Ein Ziel in der Ferne muss in den Bildausschnitt passen oder als Kante, Richtung oder Erinnerung weitergetragen werden. + explanation: | + Chen beschreibt eine Stufenfolge. Zuerst zieht immer etwas Sichtbares in der Ferne in die richtige Richtung, ein „weenie“ im Sinn der Disney-Parks. Erst wer sehr weit abweicht, trifft auf eine unsichtbare Wand, die ihn zurückschickt. Text, Kompass oder Karte braucht es dabei nicht, und das Team hat an mindestens 200 Testern geprüft, dass es reicht. In der Draufsicht lässt sich das nicht eins zu eins übernehmen, weil es keinen Horizont gibt. Das Ziel in der Ferne wird dort zu etwas, das im Bildausschnitt erscheint, wenn der Spieler sich entscheidet, oder zu einer Kante, die über viele Bildschirme eine Richtung trägt. + hints: + - In welcher Reihenfolge greifen „weenie“ und unsichtbare Wand? + resources: + - title: Push Square · Interview mit Jenova Chen zu Journey + url: https://www.pushsquare.com/news/2012/02/interview_thatgamecompany_journey + + - id: dreiecksregel + type: explain + title: Dreiecke, die verdecken + prompt: | + Hier stehen zwei Berichte über einen CEDEC-Vortrag zu Breath of the Wild (2017): zwei Sätze aus 80 Level, das sich auf Übersetzungen von Matt Walker stützt, und eine Zusammenfassung aus dem japanischen Bericht von 4Gamer in eigener Übersetzung. Erkläre in drei bis fünf Sätzen, was die Regel bewirken soll, wozu die drei Größen dienen und wie sich die Idee auf die Draufsicht übertragen lässt. + lang: prose + code: | + 80 Level: „By using triangles they could give players a choice as to whether to go straight over the triangle, or around it.“ / „The triangles is also said obscure the player’s view, so the team used them to surprise players, making them wonder what they’ll find on the other side.“ + + 4Gamer (eigene Übersetzung): Große Dreiecke wie Berge sind Landmarken, die man von weit her sieht. Mittlere verdecken weiter entfernte Orte. Kleine, etwa Felsen, bestimmen das Tempo der Erkundung in der Nähe. Rechtecke verdecken ganz und geben die Sicht plötzlich frei. + points: + - Dreiecke lassen die Wahl zwischen drüber und drumherum und verdecken, was dahinter liegt. + - Das Verdecken ist Absicht. Beim Weitergehen öffnet sich die Sicht und zeigt ein neues Ziel. + - Die drei Größen haben drei Aufgaben, Landmarke, Verdecker und Tempo. + - In der Draufsicht verdecken Bildrand, hohe Wände in der 3/4-Ansicht, Dächer und Dunkelheit. Mit ihnen lässt sich dieselbe Folge aus Verdecken und Freigeben bauen. + - Es ist der Bericht über einen Vortrag, übersetzt. Eine Primärquelle von Nintendo gibt es dazu nicht. + explanation: | + Die Regel nutzt Gelände, um den Blick zu steuern. Ein Dreieck bietet zwei Wege an, drüber oder drumherum, und versteckt, was dahinter liegt. Geht der Spieler weiter, öffnet sich die Sicht, und das, was erscheint, wird zum nächsten Ziel. Große Dreiecke sind Landmarken, mittlere verdecken, kleine geben in der Nähe den Takt vor. In der Draufsicht gibt es keine Berge, die den Blick verstellen, aber den Bildrand, hohe Wände, Dächer und Dunkelheit. Mit ihnen kann ich dieselbe Folge bauen: verdecken, freigeben, neues Ziel. Weil die Quelle ein übersetzter Bericht ist, nenne ich sie auch so. + hints: + - Was passiert, wenn der Spieler um ein Dreieck herumgeht? + resources: + - title: 80 Level · The Design Secrets of Breath of the Wild + url: https://80.lv/articles/the-design-secrets-of-breath-of-the-wild/ + - title: 4Gamer · Bericht zum CEDEC-Vortrag (Japanisch) + url: https://www.4gamer.net/games/341/G034168/20170901120/ + + - id: karte-aus-dem-gedaechtnis + type: practice + title: Eine Karte aus dem Gedächtnis + prompt: | + Wähle einen Abschnitt aus einem Top-down-Spiel, das du länger gespielt hast, etwa ein Dorf oder einen Dungeon. Zeichne ihn auf Papier aus dem Gedächtnis, ohne nachzusehen. Vergleiche die Skizze danach mit einer Karte oder einem Video. Notiere in höchstens fünf Stichpunkten, was du findest. + lang: prose + starter: | + Spiel und Abschnitt: + Richtig erinnert: + Falsch oder vergessen: + Woran ich mich festgehalten habe (Element nach Lynch): + checklist: + - Die Skizze entstand, bevor du nachgesehen hast. + - Du nennst mindestens zwei Dinge, die du richtig erinnert hast, und zwei, die fehlten oder falsch waren. + - Jedes Erinnerte ist einem von Lynchs fünf Elementen zugeordnet. + - Du nennst mindestens eine Landmarke oder einen Knoten, an dem du dich orientiert hast. + explanation: | + Was du richtig erinnerst, hat deine mentale Karte getragen. Was fehlt oder falsch liegt, zeigt Stellen, an denen der Raum keinen Halt geboten hat. Die Sammlung Mapstalgia, auf die das Level Design Book verweist, besteht aus genau solchen Karten. Dieselbe Übung kannst du später mit Testern deiner eigenen Abschnitte machen. + hints: + - Fang mit dem Knoten an, an dem du am häufigsten warst. + resources: + - title: The Level Design Book · Wayfinding, Further reading + url: https://book.leveldesignbook.com/process/blockout/wayfinding#further-reading + + - id: landmarken-pruefen + type: practice + title: Drei Stellen, drei Prüffragen + prompt: | + Nimm einen Abschnitt, an dem du arbeitest, oder eine Skizze dazu. Welche Stellen das sind, an denen sich Spieler orientieren sollen, wählst du selbst, höchstens drei. Prüf für jede ihre Landmarke mit den drei Prüffragen und notier das Ergebnis kurz. Layout, Stellen und Landmarken entscheidest du; eine KI darf dir höchstens bei der Technik helfen, etwa mit einem Skript, das Bildmitten ausrechnet. + lang: prose + starter: | + Stelle 1 (Knoten, Entscheidung): + Landmarke: einzigartig? sichtbar? beständig? + Stelle 2: + Stelle 3: + Schleife oder Abkürzung zu einem Knoten: + checklist: + - Jede Stelle nennt einen Knoten oder eine Entscheidung des Spielers. + - Für jede Landmarke ist notiert, ob es sie im Abschnitt nur einmal gibt. + - Für jede ist geprüft, ob sie vom Entscheidungspunkt aus im Bildausschnitt liegt, mit deinen Werten für Bildgröße und Kameragrenzen, und nicht hinter einer hohen Wand oder unter einem Dach. + - Für jede ist notiert, ob sie sich bewegen, verschwinden oder verändern kann. + - Mindestens eine Stelle hat eine Schleife oder Abkürzung zurück zu einem bekannten Knoten. + explanation: | + Die Prüffragen ersetzen keinen Test, aber sie finden die häufigsten Fehler vorher: verwechselbare Knoten, verdeckte oder abgeschnittene Landmarken, Bezugspunkte, die beim zweiten Besuch fehlen. Was die Stellen sind und wie die Landmarken aussehen, entscheidest du. Ob Spieler sich daran orientieren, zeigt der Playtest in [Playtests beobachten](/level-design/playtest-methode). + hints: + - Für die Sichtbarkeit genügt ein Rahmen von 20 × 11 Kästchen um den Entscheidungspunkt auf deiner Skizze. + resources: + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding diff --git a/content/level-design/modules/playtest-godot.yaml b/content/level-design/modules/playtest-godot.yaml new file mode 100644 index 0000000..2f6c94d --- /dev/null +++ b/content/level-design/modules/playtest-godot.yaml @@ -0,0 +1,602 @@ +id: playtest-godot +title: "Playtest am PC: Wege aufzeichnen und vergleichen" +level: 2 +minutes: 140 +summary: Eine Testversion deines Blockouts so vorbereiten, dass sie Wege selbst aufzeichnet – Position als CSV, Zonen mit Zeit, eine Spur als Line2D und ein Übersichtsbild aller Sitzungen –, und die Spuren mit deinem erwarteten Weg vergleichen, ohne Daten über die Tester zu sammeln. +place: pc +goals: + - Du bereitest eine Testsitzung am PC vor, mit getaggtem Stand, Einverständnis und Sitzungsnummern statt Namen. + - Du baust einen Wegschreiber ein, der die Position alle 0,25 Sekunden als CSV nach `user://` schreibt und als Spur in eine `Line2D` hängt. + - Du legst Zonen als `Area2D` an und sagst vorher, welche Einträge im Zonen-Log stehen. + - Du erzeugst ein Übersichtsbild mit Wänden, erwartetem Weg und allen Spuren und liest daraus Halte, Umwege und Umkehrungen. + - Du trennst, was eine Spur zeigt, von dem, was nur Beobachtung und Protokoll erklären. +resources: + - title: Mike Ambinder · Valve's Approach to Playtesting (Folien, GDC 2009) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting + - title: Godot Docs · File paths in Godot projects + url: https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html + - title: Godot Docs · FileAccess + url: https://docs.godotengine.org/en/stable/classes/class_fileaccess.html + - title: Godot Docs · Area2D + url: https://docs.godotengine.org/en/stable/classes/class_area2d.html +lesson: | + Lehrbeispiel: Drei Tester haben deinen Hof gespielt, und du hast ihre Wege auf einer Papierkarte mitgezeichnet, wie in [Beobachten, ohne zu erklären](/level-design/playtest-methode). Beim Auswerten merkst du, wo das Papier ungenau ist. Stand T2 am Brunnen zwei Sekunden oder acht? Ging T3 an der Wand entlang oder eine Tile daneben? Und wann genau hat T1 den Seitengang betreten, vor oder nach dem Blick zum Tor? + + Am PC kann das Spiel selbst mitschreiben: wo die Figur ist, viermal pro Sekunde, und wann sie welche Zone betritt. Das ersetzt das Zusehen nicht. Valve fasst es in den Folien zu ihrem Playtest-Vortrag so: „Nothing beats direct gameplay observation“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Die Aufzeichnung macht dein Protokoll genauer und deine Spuren vergleichbar. Die zwei Skripte hier sind technisches Gerüst, eine KI darf sie schreiben. Welcher Weg der erwartete ist, wo die Zonen liegen und was du aus den Spuren schließt, entscheidest du. Grundlage ist der Blockout aus [Blockout in Godot](/level-design/blockout), mit `Notes` und `notes.gd`. + + ## Eine Testsitzung am PC vorbereiten + + Getestet wird ein fester Stand. Vor der Sitzung committest du, setzt einen Tag und exportierst eine Debug-Version, wie in [Testversionen exportieren und die Arbeit sichern](/godot/export-sichern) beschrieben. Debug, weil das Log bei einem Fehler die Zeile nennt. Spielt der Tester an deinem Rechner, kannst du das Projekt auch aus dem Editor starten; dann musst du aber darauf achten, dass er keine Docks und keinen Szenenbaum sieht. + + Vor dem Start liegen bereit: + + - die Absichtsnotiz des Abschnitts, mit den Zeichen, dass es klappt oder scheitert, + - das Beobachtungsprotokoll mit den Spalten `Zeit | Ort | Was der Spieler tut | Was er sagt`, + - eine Stoppuhr, die du startest, wenn das Spiel startet, damit Protokoll und Aufzeichnung dieselbe Zeit haben. + + Wie du ohne zu erklären beobachtest, steht in [Beobachten, ohne zu erklären](/level-design/playtest-methode) und allgemeiner in [Testlesen und Playtest](/narrative/testlesen-playtest). Das Level Design Book nennt den Kern: „Watching their behavior is more important than their feedback“ ([Playtesting](https://book.leveldesignbook.com/process/blockout/playtesting)). + + ### Daten über Wege, nicht über Menschen + + Der Wegschreiber zeichnet Position, Zeit und Zonen auf, keinen Namen, keinen Ton, kein Bild vom Gesicht. Sag dem Tester vor dem Start in einem Satz, was aufgezeichnet wird und wozu, und frag, ob das in Ordnung ist. Die Dateien bekommen Sitzungsnummern, im Protokoll heißt der Tester T1, T2, T3. Eine Liste, wer welche Nummer hatte, brauchst du nicht; wenn du sie doch führst, liegt sie getrennt von den Daten. Möchte jemand, dass seine Sitzung gelöscht wird, löschst du beide Dateien dieser Nummer. + + ## Der Wegschreiber: Position als CSV in user:// + + Im laufenden Spiel ist der Projektordner `res://` laut Doku meist schreibgeschützt. Für eigene Dateien gibt es `user://`, einen Ordner, der „guaranteed to be writable to, even in an exported project“ ist. Unter Linux liegt er standardmäßig in `~/.local/share/godot/app_userdata/[project_name]`, beim Start aus dem Editor und beim exportierten Spiel auf demselben Rechner im selben Ordner ([user://](https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html#accessing-persistent-user-data-user)). Das Skript hängt an einem `Node` namens `PathRecorder`, der im Baum **vor** `Objects` steht: + + ```gdscript title=path_recorder.gd + extends Node + + ## Wegschreiber für Playtests: schreibt alle 15 Physik-Frames (0,25 s) die Position + ## der Figur nach user://wege/, hängt sie an eine Line2D als Spur und notiert, + ## wann die Figur eine Zone der Gruppe "zones" betritt. Jede Sitzung bekommt + ## die nächste freie Nummer. Technisches Gerüst, keine Designentscheidung. + + @export var player: Node2D + @export var trail: Line2D + @export var every_frames := 15 + + var _frame := 0 + var _path: FileAccess + var _zones: FileAccess + + + func _ready() -> void: + DirAccess.make_dir_recursive_absolute("user://wege") + var n := 1 + while FileAccess.file_exists("user://wege/sitzung_%02d_weg.csv" % n): + n += 1 + _path = FileAccess.open("user://wege/sitzung_%02d_weg.csv" % n, FileAccess.WRITE) + _path.store_line("t,x,y") + _zones = FileAccess.open("user://wege/sitzung_%02d_zonen.csv" % n, FileAccess.WRITE) + _zones.store_line("t,zone") + for zone in get_tree().get_nodes_in_group(&"zones"): + zone.body_entered.connect(_on_zone_entered.bind(zone.name)) + print("Wegschreiber: Sitzung ", n) + + + func _physics_process(_delta: float) -> void: + if _frame % every_frames == 0: + var p := player.global_position + _path.store_line("%.2f,%.1f,%.1f" % [_seconds(), p.x, p.y]) + _path.flush() + trail.add_point(p) + _frame += 1 + + + func _on_zone_entered(body: Node2D, zone_name: StringName) -> void: + if body == player: + _zones.store_line("%.2f,%s" % [_seconds(), zone_name]) + _zones.flush() + + + func _seconds() -> float: + return _frame / float(Engine.physics_ticks_per_second) + ``` + + Was die Teile tun: + + - **Sitzungsnummer.** Das Skript sucht die erste Nummer, für die es noch keine Datei gibt. So überschreibt keine Sitzung eine andere, auch im exportierten Spiel, wo du im Inspektor nichts ändern kannst. Der Ordner muss vorher existieren; die Doku zu `FileAccess.WRITE` sagt dazu: „When creating a file it must be in an already existing directory.“ + - **Takt.** `_physics_process` läuft 60-mal pro Sekunde ([physics_ticks_per_second](https://docs.godotengine.org/en/stable/classes/class_engine.html#class-engine-property-physics-ticks-per-second)). Jeder 15. Frame ergibt vier Messpunkte pro Sekunde, mit genauen Zeiten 0.00, 0.25, 0.50. Ein Zähler statt eines Timers hält die Zeiten auf diesem Raster. Mit Godot 4.7.2 nachgeprüft: Nach 3600 Physik-Frames, also 60 Sekunden, hat die Spur 240 Punkte. + - **CSV.** `store_line()` hängt einen Zeilenumbruch an ([store_line](https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-store-line)). `%.2f` schreibt die Zeit mit zwei Stellen, `%.1f` die Pixel mit einer. + - **`flush()`.** Ohne diese Zeile hält Godot geschriebenen Text in einem Puffer und schreibt ihn in Blöcken auf die Platte, nachgemessen in Blöcken von 4096 Byte. Bei diesem Format sind das gut 220 Messpunkte, knapp eine Minute. Die Doku: „calling flush() can be used to ensure the data is safe even if the project crashes instead of being closed gracefully“ ([flush](https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-flush)). Mit Godot 4.7.2 nachgeprüft, das Spiel jeweils hart beendet: Ohne `flush()` war die Datei nach 200 Frames leer; nach 250 Sekunden standen 16384 von 18292 Byte darin, die letzten gut 25 Sekunden fehlten, und die letzte Zeile war abgeschnitten. Mit `flush()` waren beide Dateien vollständig. Bei regulärem Beenden ist die Datei auch ohne `flush()` vollständig. + - **Reihenfolge im Baum.** `PathRecorder` vor `Objects` misst, bevor sich die Figur im selben Frame bewegt. Dann ist der Punkt bei 0.50 genau der Stand nach 30 Bewegungsschritten. + + Gemessen mit Godot 4.7.2, Figur ab (40, 100) mit 90 Pixeln pro Sekunde nach rechts, ohne Beschleunigung: + + ```csv title=sitzung_01_weg.csv + t,x,y + 0.00,40.0,100.0 + 0.25,62.5,100.0 + 0.50,85.0,100.0 + 0.75,107.5,100.0 + 1.00,130.0,100.0 + ``` + + > [!TIP] Die Sitzungsnummer steht in der Ausgabe + > Beim Start schreibt der Wegschreiber `Wegschreiber: Sitzung 3` in die Ausgabe, im exportierten Spiel ins Log unter `user://logs/`. Trag die Nummer nach dem Beenden ins Protokoll ein, bevor die nächste Sitzung startet; dann gehören `sitzung_03_weg.csv` und `sitzung_03_zonen.csv` eindeutig zu dieser Seite. Während der Sitzung bleibt dein Blick beim Tester. + + Vier Punkte pro Sekunde sind 240 Zeilen pro Minute. Für Abschnitte von 2 bis 4 Bildschirmen reicht das; ein Halt von einer Sekunde sind vier Punkte auf einer Stelle. Willst du gröber messen, stellst du `every_frames` im Inspektor auf 30. + + ## Die Spur und der erwartete Weg als Line2D + + `trail.add_point(p)` hängt jeden Messpunkt an eine `Line2D` an ([add_point](https://docs.godotengine.org/en/stable/classes/class_line2d.html#class-line2d-method-add-point)). Daneben zeichnest du einen zweiten `Line2D`, `ExpectedPath`, mit den Punkten des Wegs, den deine Absichtsnotiz erwartet; die Punkte setzt du im 2D-Editor oder trägst sie im Inspektor unter *Points* ein ([points](https://docs.godotengine.org/en/stable/classes/class_line2d.html#class-line2d-property-points)). Beide hängen unter `Notes`: + + ```text + Main (Node2D) + ├── PathRecorder (Node) path_recorder.gd, vor Objects + ├── Ground, Cues, Objects … aus dem Blockout + ├── Gang (Area2D) Gruppe zones + │ └── Shape (CollisionShape2D) + ├── Tor (Area2D) Gruppe zones + │ └── Shape (CollisionShape2D) + └── Notes (Node2D) notes.gd, im Spiel aus, liegt bei (0, 0) + ├── ExpectedPath (Line2D) erwarteter Weg, von dir gezeichnet + └── Trail (Line2D) Spur, vom Wegschreiber gefüllt + ``` + + So sieht der Tester weder seine Spur noch deinen erwarteten Weg; beides würde ihn lenken. Nach der Sitzung drückst du die Taste für `toggle_notes` und siehst die Spur im laufenden Spiel über dem Blockout. Mit Godot 4.7.2 nachgeprüft: Unter `Notes` ist `Trail` nach dem Start unsichtbar und nach der Aktion sichtbar. Stell bei beiden `width` auf 1; der Standard ist 10 Pixel, in einem Bild von 320 × 180 ein breiter Balken ([width](https://docs.godotengine.org/en/stable/classes/class_line2d.html#class-line2d-property-width)). `add_point()` erwartet Koordinaten der `Line2D`, der Wegschreiber übergibt globale Positionen. Deshalb liegen `Notes`, `Trail` und `ExpectedPath` bei (0, 0); auch das Übersichtsbild weiter unten liest die Punkte von `ExpectedPath` als Positionen im Spiel. + + ## Zonen: wann betritt der Spieler welchen Ort? + + Eine Zone ist eine `Area2D` mit einer `CollisionShape2D`, deren Namen der Ort ist, den deine Absichtsnotiz nennt. Leg sie in die Gruppe `zones` ([Groups](https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html)). Der Wegschreiber holt sich alle Zonen der Gruppe und verbindet ihr Signal `body_entered`. Das Signal kommt, wenn ein Körper die Fläche betritt, und verlangt `monitoring = true`, den Standard ([body_entered](https://docs.godotengine.org/en/stable/classes/class_area2d.html#class-area2d-signal-body-entered)). Mit `bind(zone.name)` bekommt die Funktion den Namen der Zone mit. + + Damit die Zone die Figur bemerkt, muss ihre Maske den Layer der Figur enthalten. Im Testgelände liegt die Figur auf Layer 2 „player“. Die Zone selbst braucht keinen Layer. Ausschnitt aus `main.tscn`, ohne die `unique_id`, die Godot 4.7.2 in jede Node-Zeile schreibt: + + ```ini title=main.tscn + [node name="Tor" type="Area2D" parent="." groups=["zones"]] + position = Vector2(208, 100) + collision_layer = 0 + collision_mask = 2 + ``` + + Warum Layer und Maske so zusammenhängen, erklärt [Kollisionen und Trefferzonen](/godot/kollision-ebenen). Das Log hält nur das Betreten fest. Wer in einer Zone steht, erzeugt keine neuen Zeilen; wer sie verlässt und wieder betritt, eine neue. Gemessen mit Godot 4.7.2: Zone `Gang` von x = 96 bis 144, `Tor` von 192 bis 224, die Figur läuft 2 Sekunden nach rechts, 1 Sekunde zurück und 1 Sekunde wieder nach rechts: + + ```csv title=sitzung_01_zonen.csv + t,zone + 0.58,Gang + 1.65,Tor + 2.82,Gang + 3.65,Tor + ``` + + Welche Orte Zonen werden, folgt aus deiner Absichtsnotiz. Steht dort „Der Spieler soll das Tor erreichen, bevor er den Seitengang betritt“, brauchst du genau diese zwei Zonen, und das Log beantwortet die Frage für jeden Tester mit einer Zeile. + + ## Ein Übersichtsbild aller Sitzungen + + Die Spur im Spiel zeigt nur den Bildausschnitt um die Figur. Für die Auswertung, auch unterwegs am Handy, brauchst du ein Bild des ganzen Abschnitts mit allen Sitzungen. Dieses Skript läuft ohne Fenster aus dem Terminal. Es lädt deine Hauptszene, zeichnet die Zellen von `Walls`, den erwarteten Weg in Grün und jede Datei `*_weg.csv` in einer eigenen Farbe: + + ```gdscript title=trail_overview.gd + extends SceneTree + + ## Übersichtsbild für die Auswertung: zeichnet die Wände, den erwarteten Weg (grün) + ## und jeden Weg aus user://wege/ in ein PNG, 1 Bildpixel = 1 Spielpixel. + ## Aufruf im Projektordner: godot --headless --path . -s trail_overview.gd + ## Technisches Gerüst, keine Designentscheidung. + + const COLORS := [Color.RED, Color.ORANGE, Color.MAGENTA, Color.CYAN, Color.YELLOW] + + + func _initialize() -> void: + var level: Node = load("res://main.tscn").instantiate() + var ground: TileMapLayer = level.get_node("Ground") + var walls: TileMapLayer = level.get_node("Objects/Walls") + var tile := ground.tile_set.tile_size + var rect := ground.get_used_rect() + var image := Image.create_empty(rect.size.x * tile.x, rect.size.y * tile.y, false, Image.FORMAT_RGB8) + image.fill(Color(0.55, 0.55, 0.55)) + for cell in walls.get_used_cells(): + image.fill_rect(Rect2i((cell - rect.position) * tile, tile), Color(0.24, 0.24, 0.24)) + var origin := Vector2(rect.position * tile) + _draw(image, level.get_node("Notes/ExpectedPath").points, origin, Color.GREEN) + var files := Array(DirAccess.get_files_at("user://wege")).filter(func(f): return f.ends_with("_weg.csv")) + for i in files.size(): + var points := PackedVector2Array() + var csv := FileAccess.open("user://wege/" + files[i], FileAccess.READ) + csv.get_csv_line() # Kopfzeile t,x,y + while csv.get_position() < csv.get_length(): + var row := csv.get_csv_line() + points.append(Vector2(float(row[1]), float(row[2]))) + _draw(image, points, origin, COLORS[i % COLORS.size()]) + print(files[i], ": ", points.size(), " Punkte, Farbe ", COLORS[i % COLORS.size()].to_html(false)) + image.save_png("user://wege/uebersicht.png") + print("gespeichert: ", ProjectSettings.globalize_path("user://wege/uebersicht.png")) + level.free() + quit() + + + func _draw(image: Image, points: PackedVector2Array, origin: Vector2, color: Color) -> void: + for i in points.size() - 1: + var a := points[i] - origin + var b := points[i + 1] - origin + for s in int(a.distance_to(b)) + 1: + var p := Vector2i(a.move_toward(b, s)) + if p.x >= 0 and p.y >= 0 and p.x < image.get_width() and p.y < image.get_height(): + image.set_pixelv(p, color) + ``` + + Ein Skript, das von `SceneTree` erbt, startet Godot mit `-s` ohne Hauptszene ([Running a script](https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html#running-a-script)). `get_files_at()` liefert die Dateien „sorted alphabetically“ ([DirAccess.get_files_at](https://docs.godotengine.org/en/stable/classes/class_diraccess.html#class-diraccess-method-get-files-at)), also bekommt Sitzung 01 immer Rot, 02 Orange und so weiter. Heißt deine Hauptszene anders oder liegen die Nodes woanders, passt du die drei Pfade an. Ausgabe nach drei Lehrbeispiel-Sitzungen, mit Godot 4.7.2, Pfad gekürzt: + + ```console + $ godot --headless --path . -s trail_overview.gd + sitzung_01_weg.csv: 18 Punkte, Farbe ff0000 + sitzung_02_weg.csv: 18 Punkte, Farbe ffa500 + sitzung_03_weg.csv: 22 Punkte, Farbe ff00ff + gespeichert: /home/…/.local/share/godot/app_userdata/Playtest-Pruefung/wege/uebersicht.png + ``` + + Das Bild ist so groß wie der Abschnitt in Spielpixeln, bei 24 × 12 Tiles also 384 × 192. Spielt jemand auf einem anderen Rechner, kopierst du dessen Ordner `wege` vorher in deinen `user://`-Ordner. Bei mehr als fünf Sitzungen wiederholen sich die Farben; erzeug dann ein Bild pro Runde. + + ## Spuren lesen: was sie zeigen und was nicht + + Im Übersichtsbild suchst du Muster, die du zählen kannst: + + - **Halt.** Viele Punkte auf einer Stelle. Acht Punkte sind zwei Sekunden. + - **Umkehr.** Die Spur läuft ein Stück zurück. Zähl, wo und wie oft. + - **Umweg.** Die Spur weicht vom grünen Weg ab und kommt später zurück, oder sie kommt nicht zurück. + - **Reihenfolge.** Das Zonen-Log zeigt, ob der Tester die Orte in der erwarteten Folge betreten hat. + - **Lücke.** Ein Ort ohne jede Spur. Niemand war dort, auch nicht zufällig. + + > [!MERKE] + > Die Spur zählt Ort, Dauer und Reihenfolge. Den Grund für einen Halt oder Umweg liefert nur das Protokoll. Deutung kommt erst, wenn beides zusammenpasst. + + Was die Spur nicht zeigt, ist der Grund. Acht Punkte vor einer Abzweigung können Unsicherheit sein, ein Blick auf etwas Interessantes oder ein Tester, der kurz mit dir spricht. Das klärst du mit dem Protokoll: Die Stoppuhrzeit im Protokoll und die Zeit in der CSV gehören zusammen. Erst wenn beides zusammenpasst, schreibst du eine Deutung auf, getrennt von der Beobachtung. Wie du daraus eine Änderung ableitest, zeigt [Überarbeiten: von der Beobachtung zur Änderung](/level-design/ueberarbeiten). + + > [!PRAXIS] Heatmaps bei Valve + > In Valves Folien zum Playtesting von 2009 steht die Aufzeichnung neben der direkten Beobachtung: „Record of gameplay behaviors“, etwa „Deaths, level times, friendly fire“, dazu eine „Heatmap of Death Concentrations“ der Karte Dustbowl aus Team Fortress 2. Die Folien nennen die Grenzen gleich mit: „Averages hide extreme examples“, „Miss nuance (lacking context)“ und „Can see ‘illusory’ patterns“. Valve nutzt beides, Zahlen und Zusehen, und behandelt jede Designidee als Hypothese: „Game designs are hypotheses“, „Playtests are experiments“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). + + > [!INTERVIEW] + > „Wir haben Wegdaten aus vielen Sitzungen. Warum noch zusehen?“ Gute Antwort: Die Daten zeigen, wo und wie lange jemand war, nicht warum. Ein Halt vor einer Abzweigung kann Verwirrung sein oder Neugier. Ich nutze die Spuren, um Stellen zu finden und zu zählen, und das Protokoll aus der Beobachtung, um sie zu erklären. Dazu achte ich darauf, dass die Daten nichts über die Person enthalten: Sitzungsnummern, keine Namen, nur Position, Zeit und Zonen. + + ## Häufige Fehler + + - **Eine Zeile pro Datei.** Wer die Datei bei jedem Messpunkt mit `FileAccess.WRITE` neu öffnet, leert sie jedes Mal. Öffne sie einmal in `_ready()`. + - **Leeres Zonen-Log.** Die Maske der Zone enthält den Layer der Figur nicht, die Zone ist nicht in der Gruppe `zones`, oder `monitoring` ist aus. + - **Unvollständige Datei nach einem Absturz.** `flush()` fehlt. Am Ende fehlt bis zu knapp eine Minute, eine kurze Sitzung geht ganz verloren. Bei regulärem Beenden fällt das nicht auf. + - **Sitzungen überschrieben.** Ein fester Dateiname für alle Sitzungen. Die Nummer muss das Skript selbst finden. + - **Spur für den Tester sichtbar.** `Trail` oder `ExpectedPath` hängen nicht unter `Notes`. Der Tester folgt dann der grünen Linie. + - **Namen in Dateien.** Ein Dateiname wie `sitzung_anna.csv` sammelt Daten über eine Person, die du nicht brauchst. + - **Spuren ohne Protokoll.** Das Bild zeigt eine Abweichung, aber niemand weiß, was in dem Moment passiert ist. + + ## Zusammenfassung + + - Getestet wird ein getaggter Stand als Debug-Export. Absichtsnotiz, Protokoll und Stoppuhr liegen bereit. + - Aufgezeichnet werden Position, Zeit und Zonen unter einer Sitzungsnummer, mit Einverständnis und ohne Namen. + - `path_recorder.gd` schreibt alle 15 Physik-Frames eine CSV-Zeile nach `user://wege/`, 240 pro Minute, mit `flush()` nach jeder Zeile. + - Zonen sind `Area2D` in der Gruppe `zones`, deren Maske den Layer der Figur enthält. Das Log hält nur das Betreten fest. + - `Trail` und `ExpectedPath` hängen unter `Notes` und sind im Spiel aus. + - `trail_overview.gd` zeichnet Wände, erwarteten Weg und alle Sitzungen in ein PNG, 1 Bildpixel pro Spielpixel. + - Spuren zeigen Halte, Umkehrungen, Umwege und Lücken. Den Grund liefert das Protokoll. +exercises: + - id: was-aufzeichnen + type: choice + title: Was gehört in die Aufzeichnung? + prompt: | + Du bereitest eine Sitzung am PC vor. Welche Daten zeichnest du auf? + options: + - text: Position und Zeit alle 0,25 Sekunden unter einer Sitzungsnummer. + correct: true + why: Das ist der Weg, ohne etwas über die Person. Die Nummer reicht, um Datei und Protokoll zusammenzubringen. + - text: Den Zeitpunkt, an dem die Figur eine Zone betritt. + correct: true + why: Damit beantwortest du Reihenfolge-Fragen aus der Absichtsnotiz mit einer Zeile pro Tester. + - text: Den Vornamen des Testers im Dateinamen, damit du Sitzungen später zuordnen kannst. + correct: false + why: Für die Auswertung brauchst du nur die Sitzungsnummer. Ein Name in den Daten ist eine Information über eine Person, die du nicht brauchst. + - text: Eine Tonaufnahme der ganzen Sitzung, damit dir nichts entgeht, ohne vorher zu fragen. + correct: false + why: Was aufgezeichnet wird, sagst du vorher und fragst nach dem Einverständnis. Für Wege reichen Position, Zeit und Zonen; das Gesagte steht in deinem Protokoll. + explanation: | + Die Aufzeichnung dient der Frage, ob der Raum funktioniert, nicht der Person, die ihn testet. Daraus folgt die Auswahl: Position, Zeit und Zonen unter einer Nummer. Alles Weitere fragst du vorher ab oder lässt es weg. Wer vorher erklärt, was gespeichert wird, bekommt außerdem entspanntere Tester. + resources: + - title: Godot Docs · Accessing persistent user data (user://) + url: https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html#accessing-persistent-user-data-user + + - id: spur-deuten + type: choice + title: Was sagen die Daten von T2? + prompt: | + Im Übersichtsbild liegen an einer Abzweigung 12 Punkte der Spur von T2 auf einer Stelle. Das Zonen-Log von T2 enthält `12.25,Gabelung` und `16.50,Seitengang`, danach endet die Sitzung, ein Eintrag `Tor` fehlt. Welche Aussagen stützen die Daten? + options: + - text: T2 stand an der Abzweigung ungefähr drei Sekunden. + correct: true + why: 12 Punkte mal 0,25 Sekunden sind 3 Sekunden. Das ist gezählt. + - text: T2 hat in dieser Sitzung den Seitengang betreten und das Tor nicht. + correct: true + why: Das steht im Zonen-Log, mit Zeit. + - text: T2 war an der Abzweigung unsicher, wohin. + correct: false + why: Das ist eine Deutung. T2 kann sich umgesehen, etwas betrachtet oder mit dir gesprochen haben. Ob er unsicher war, sagt dir das Protokoll, nicht die Spur. + - text: T2 hat die Markierung am Tor nicht gesehen. + correct: false + why: Die Spur zeigt, wo die Figur war, nicht wohin der Tester geschaut hat. Gesehen haben kann er sie und sich trotzdem anders entschieden haben. + explanation: | + Spuren und Zonen-Logs zählen Ort, Dauer und Reihenfolge. Alles, was im Kopf des Testers passiert, liegt außerhalb. Für die Frage, ob die Markierung am Tor gewirkt hat, brauchst du das Protokoll: Was hat T2 in den drei Sekunden getan und gesagt? Erst dann ordnest du die Stelle einer der vier Arten aus [Überarbeiten](/level-design/ueberarbeiten) zu: „nicht bemerkt“, „falsch gelesen“, „nicht befolgt“ oder „unbeabsichtigte Folge“. + hints: + - Frag bei jeder Aussage, ob eine Zahl oder Zeile in den Daten sie belegt. + resources: + - title: Mike Ambinder · Valve's Approach to Playtesting, Folien „Stat Collection/Analysis“ + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + + - id: sitzung-ordnen + type: order + title: Eine Sitzung am PC + prompt: | + Bring die Schritte einer Testsitzung in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Du committest den Stand, setzt einen Tag und exportierst eine Debug-Version. + Du legst Absichtsnotiz, Protokoll und Stoppuhr bereit und prüfst, dass Notes im Spiel aus ist. + Wenn Version und Unterlagen bereitliegen, sagst du dem Tester, was aufgezeichnet wird, und fragst nach seinem Einverständnis. + Der Tester spielt, du startest die Stoppuhr mit dem Spiel und schreibst mit, ohne zu erklären. + Nach dem regulären Beenden notierst du die neue Sitzungsnummer im Protokoll. + Du erzeugst das Übersichtsbild und vergleichst die Spur mit dem erwarteten Weg. + alternatives: + - [2, 1, 3, 4, 5, 6] + explanation: | + Ob du zuerst exportierst oder zuerst die Unterlagen bereitlegst, ist gleich. Fest ist: Einverständnis vor dem Start, Mitschreiben während des Spiels, die Nummer nach dem Beenden und vor der nächsten Sitzung, damit Protokoll und Datei zusammengehören. Die Auswertung kommt zuletzt, mit allen Daten der Sitzung. + resources: + - title: The Level Design Book · Playtesting, „How to run a playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#how-to-run-a-playtest + + - id: csv-zeile + type: output + title: Welche Zeile steht bei 1,50 Sekunden? + prompt: | + Die Figur startet bei (40, 100) und läuft ab dem ersten Physik-Frame mit konstant 90 Pixeln pro Sekunde nach rechts (Platzhalter, ohne Beschleunigung). `PathRecorder` steht im Baum vor `Objects` und misst, bevor sich die Figur im selben Frame bewegt. Welche Zeile schreibt der Wegschreiber für t = 1,50? + lang: gdscript + code: | + func _physics_process(_delta: float) -> void: + if _frame % every_frames == 0: + var p := player.global_position + _path.store_line("%.2f,%.1f,%.1f" % [_seconds(), p.x, p.y]) + _path.flush() + trail.add_point(p) + _frame += 1 + expected: | + 1.50,175.0,100.0 + hints: + - 1,5 Sekunden sind 90 Physik-Frames. + - Pro Frame läuft die Figur 1,5 Pixel. + explanation: | + Bei t = 1,50 ist `_frame` 90. Weil der Wegschreiber vor der Figur läuft, hat sie sich bis dahin 90-mal bewegt: 90 × 1,5 = 135 Pixel, also x = 175. y bleibt 100. Das Format schreibt die Zeit mit zwei Nachkommastellen und die Pixel mit einer. Gemessen mit Godot 4.7.2. Stünde `PathRecorder` hinter `Objects`, wäre jeder Punkt einen Schritt weiter, hier 176.5. + resources: + - title: Godot Docs · FileAccess.store_line + url: https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-store-line + + - id: zonen-folge + type: output + title: Was steht im Zonen-Log? + prompt: | + Zone `Gang` reicht von x = 96 bis 144, Zone `Tor` von x = 192 bis 224, beide über die ganze Höhe des Wegs. Die Figur startet bei x = 40, läuft 2 Sekunden nach rechts (bis x = 220), dann 1 Sekunde nach links (bis x = 130), dann 1 Sekunde nach rechts. Welche Zonen stehen in `zonen.csv`? Schreib nur die Namen, einen pro Zeile, in der Reihenfolge des Logs. + lang: gdscript + code: | + func _on_zone_entered(body: Node2D, zone_name: StringName) -> void: + if body == player: + _zones.store_line("%.2f,%s" % [_seconds(), zone_name]) + _zones.flush() + expected: | + Gang + Tor + Gang + Tor + hints: + - "`body_entered` kommt nur beim Betreten, nicht beim Verweilen." + - Wo steht die Figur bei x = 130? + explanation: | + Auf dem Hinweg betritt die Figur `Gang` und dann `Tor`. Auf dem Rückweg verlässt sie `Tor` und betritt `Gang` ein zweites Mal. Bei x = 130 steht sie in `Gang`; auf dem zweiten Weg nach rechts gibt es deshalb keinen neuen Eintrag für `Gang`, erst wieder für `Tor`. Gemessen mit Godot 4.7.2: Einträge bei 0.58, 1.65, 2.82 und 3.65 Sekunden. Ein zweiter Eintrag derselben Zone heißt also immer: Der Tester war draußen und ist zurückgekommen. + resources: + - title: Godot Docs · Area2D.body_entered + url: https://docs.godotengine.org/en/stable/classes/class_area2d.html#class-area2d-signal-body-entered + + - id: zellen-zaehlen + type: output + title: Wo stand T2 am längsten? + prompt: | + Das Modell zählt, wie viele Messpunkte eines Wegs in jede Zelle von 16 × 16 Pixeln fallen. Was gibt es aus? + lang: python + code: | + from collections import Counter + + # (t, x, y) aus sitzung_02_weg.csv, gekürzt + weg = [(0.00, 40.0, 100.0), (0.25, 62.5, 100.0), (0.50, 85.0, 100.0), + (0.75, 99.0, 96.5), (1.00, 99.0, 96.5), (1.25, 99.0, 96.5), + (1.50, 99.0, 96.5), (1.75, 100.5, 95.0), (2.00, 121.0, 88.0)] + + zellen = Counter((int(x // 16), int(y // 16)) for t, x, y in weg) + zelle, anzahl = zellen.most_common(1)[0] + print(zelle, anzahl * 0.25, "s") + print(len(zellen), "Zellen besucht") + expected: | + (6, 6) 1.0 s + 6 Zellen besucht + hints: + - 99 // 16 ist 6, 96.5 // 16 ist 6, 95 // 16 ist 5. + - Jeder Punkt steht für 0,25 Sekunden. + explanation: | + Vier Punkte liegen bei (99, 96.5), also in Zelle (6, 6): eine Sekunde. Der Punkt bei (100.5, 95) liegt schon in Zelle (6, 5), obwohl er nur 1,5 Pixel daneben ist; Zellgrenzen schneiden Halte manchmal in zwei Teile. Besucht wurden (2, 6), (3, 6), (5, 6), (6, 6), (6, 5) und (7, 5). Zelle (4, 6) fehlt, weil die Figur sie zwischen zwei Messpunkten durchquert hat. So eine Zählung ist eine kleine Heatmap auf Tile-Ebene; `//` rundet wie `local_to_map()` ab. + resources: + - title: Python · collections.Counter + url: https://docs.python.org/3/library/collections.html#collections.Counter + + - id: wegschreiber-luecken + type: gap + title: Datei öffnen und Zonen verbinden + prompt: | + Ergänze den Anfang des Wegschreibers. Die Datei soll neu angelegt werden, die Kopfzeile bekommen, und jede Zone der Gruppe `zones` soll beim Betreten `_on_zone_entered` aufrufen. + lang: gdscript + code: | + func _ready() -> void: + DirAccess.make_dir_recursive_absolute("user://wege") + _path = FileAccess.open("user://wege/sitzung_01_weg.csv", FileAccess.⟦WRITE⟧) + _path.⟦store_line⟧("t,x,y") + for zone in get_tree().⟦get_nodes_in_group⟧(&"zones"): + zone.⟦body_entered⟧.connect(_on_zone_entered.bind(zone.name)) + gaps: + - label: Modus zum Schreiben + hint: Die Konstante von `FileAccess`, die eine Datei neu anlegt oder leert. + accept: ["WRITE_READ"] + - label: eine Zeile schreiben + hint: Schreibt Text und hängt einen Zeilenumbruch an. + - label: alle Nodes einer Gruppe + hint: Eine Methode von `SceneTree`. + - label: Signal beim Betreten + hint: Das Signal von `Area2D` für Körper, nicht für andere Areas. + explanation: | + `FileAccess.WRITE` legt die Datei an oder leert sie, deshalb öffnest du sie genau einmal. `WRITE_READ` tut beim Öffnen dasselbe und erlaubt zusätzlich Lesen; mit Godot 4.7.2 nachgeprüft, der Wegschreiber läuft mit beiden gleich. `store_line()` schreibt die Kopfzeile mit Zeilenumbruch. `get_nodes_in_group()` liefert alle Zonen, egal wo sie im Baum hängen. `body_entered` meldet Körper wie die Figur; `area_entered` würde nur andere Areas melden. Mit `bind()` hängt der Name der Zone als zusätzliches Argument an. + resources: + - title: Godot Docs · SceneTree.get_nodes_in_group + url: https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-get-nodes-in-group + - title: Godot Docs · FileAccess.open + url: https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-open + + - id: nur-eine-zeile + type: bug + title: Die CSV hat nur eine Zeile + prompt: | + Nach einer Sitzung von zwei Sekunden enthält `sitzung_01_weg.csv` nur eine Zeile, `1.75,197.5,100.0`. Die Kopfzeile fehlt, die Spur im Spiel ist vollständig. Finde die Zeile, die das verursacht. + lang: gdscript + code: | + func _physics_process(_delta: float) -> void: + if _frame % every_frames == 0: + var p := player.global_position + _path = FileAccess.open("user://wege/sitzung_01_weg.csv", FileAccess.WRITE) + _path.store_line("%.2f,%.1f,%.1f" % [_seconds(), p.x, p.y]) + _path.flush() + trail.add_point(p) + _frame += 1 + lines: [4] + explanation: | + `FileAccess.WRITE` legt die Datei neu an oder kürzt sie auf null. Jeder Messpunkt öffnet sie neu und löscht damit alles davor, auch die Kopfzeile aus `_ready()`. Übrig bleibt der letzte Punkt. Mit Godot 4.7.2 nachgestellt: genau die Zeile `1.75,197.5,100.0`. Die Zeile gehört gestrichen; die Datei öffnet `_ready()` einmal. Die Spur ist vollständig, weil `add_point()` mit der Datei nichts zu tun hat, deshalb fällt der Fehler im Spiel nicht auf. + hints: + - Was macht der Modus `WRITE` mit einer Datei, die schon existiert? + resources: + - title: Godot Docs · FileAccess, Konstante WRITE + url: https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-constant-write + + - id: leere-zonen + type: bug + title: Das Zonen-Log bleibt leer + prompt: | + Nach jeder Sitzung enthält `zonen.csv` nur die Kopfzeile. Mit *Sichtbare Kollisionsformen* siehst du, dass die Figur durch die Zone `Tor` läuft. Die Figur des Testgeländes liegt auf Layer 2 „player“, Layer 3 heißt „pickups“. Finde die Zeile und korrigiere sie. + lang: ini + code: | + [node name="Tor" type="Area2D" parent="." groups=["zones"]] + position = Vector2(208, 100) + collision_layer = 0 + collision_mask = 4 + + [node name="Shape" type="CollisionShape2D" parent="Tor"] + shape = SubResource("tor") + lines: [4] + fix: + - line: 4 + answers: + - collision_mask = 2 + - collision_mask = 3 + - collision_mask = 6 + - collision_mask = 7 + explanation: | + 4 ist der Bitwert für Layer 3 „pickups“. Die Zone sucht also nur Sammelstücke, die Figur auf Layer 2 meldet `body_entered` nicht, obwohl sich die Formen überlappen. Mit Maske 2, dem Bitwert für Layer 2, sieht die Zone die Figur. Jede Maske, die Layer 2 enthält, geht auch, etwa 3 oder 6; die Zone meldet dann zusätzlich Wände oder Sammelstücke, und der Wegschreiber sortiert sie über `body == player` aus. Mit Godot 4.7.2 nachgestellt: Mit Maske 4 bleibt das Log leer, mit 2, 3, 6 oder 7 stehen `Gang` und `Tor` darin. Die Standardmaske 1 schreibt Godot gar nicht in die `.tscn`; steht dort keine Zeile `collision_mask`, sucht die Zone nur Layer 1. + resources: + - title: Godot Docs · Using Area2D + url: https://docs.godotengine.org/en/stable/tutorials/physics/using_area_2d.html + + - id: wegschreiber-erklaeren + type: explain + title: Takt, Zeit und flush + prompt: | + Erkläre in drei bis fünf Sätzen, wann diese Funktionen eine Zeile schreiben, woher die Zeit kommt und wozu `flush()` dient. + lang: gdscript + code: | + func _physics_process(_delta: float) -> void: + if _frame % every_frames == 0: + var p := player.global_position + _path.store_line("%.2f,%.1f,%.1f" % [_seconds(), p.x, p.y]) + _path.flush() + trail.add_point(p) + _frame += 1 + + + func _seconds() -> float: + return _frame / float(Engine.physics_ticks_per_second) + points: + - "Bei `every_frames = 15` und 60 Physik-Frames pro Sekunde schreibt die Funktion vier Zeilen pro Sekunde, in den Frames 0, 15, 30 …" + - Die Zeit kommt aus dem Frame-Zähler geteilt durch die Physik-Frames pro Sekunde, nicht aus der Uhr; sie liegt immer auf dem Raster 0.00, 0.25, 0.50. + - "`flush()` schreibt jede Zeile sofort auf die Platte; stürzt das Spiel ab, fehlt höchstens die letzte Viertelsekunde. Ohne `flush()` fehlt alles, was noch im Puffer lag, bis zu knapp einer Minute, bei kurzen Sitzungen alles." + - "`add_point()` hängt denselben Punkt an die Spur, Datei und Spur zeigen also dieselben Messpunkte." + explanation: | + Die Funktion läuft in jedem Physik-Frame, schreibt aber nur, wenn der Zähler ein Vielfaches von 15 ist, bei 60 Physik-Frames pro Sekunde also viermal pro Sekunde. Die Zeit rechnet `_seconds()` aus dem Zähler, deshalb stehen in der Datei glatte Werte wie 0.25 und 0.50, egal wie schnell der Rechner zeichnet. `flush()` schreibt den Puffer sofort auf die Platte. Mit Godot 4.7.2 nachgeprüft: Ohne `flush()` fehlte nach einem harten Abbruch alles, was noch im Puffer von 4096 Byte lag, nach einer kurzen Sitzung die ganze Datei; mit `flush()` enthielt sie alle Punkte bis zum Abbruch. `add_point()` hängt denselben Punkt an die Spur, Bild im Spiel und Datei passen zusammen. + resources: + - title: Godot Docs · FileAccess.flush + url: https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-flush + + - id: wegschreiber-einbauen + type: practice + title: Den Wegschreiber in deinen Blockout bauen + prompt: | + Bau Wegschreiber, Zonen, erwarteten Weg und Spur in deinen Blockout ein und teste alles mit einem eigenen Durchlauf. Welche Orte Zonen werden und wie der erwartete Weg verläuft, entscheidest du aus deiner Absichtsnotiz; die Skripte darf dir ein Agent schreiben. + lang: prose + checklist: + - "`PathRecorder` steht im Baum vor `Objects`, `player` und `trail` sind im Inspektor gesetzt." + - Jede Zone ist eine `Area2D` in der Gruppe `zones`, ihre Maske enthält den Layer deiner Figur, und ihr Name ist ein Ort aus deiner Absichtsnotiz. + - "`ExpectedPath` und `Trail` hängen unter `Notes`, liegen wie `Notes` bei (0, 0), haben `width` 1 und sind im Spiel aus." + - Nach deinem Durchlauf gibt es eine neue Weg-Datei mit vier Zeilen pro Sekunde und ein Zonen-Log mit deinen Zonen in der gelaufenen Reihenfolge. + - Das Übersichtsbild zeigt Wände, erwarteten Weg und deine Spur deckungsgleich mit dem Abschnitt. + - Du hast das Spiel einmal hart beendet und geprüft, dass die Datei bis kurz davor gefüllt ist. + hints: + - Lauf beim ersten Durchlauf absichtlich einmal zurück, dann siehst du im Zonen-Log, ob ein zweiter Eintrag kommt. + explanation: | + Ein eigener Durchlauf prüft die Technik, bevor ein Tester seine Zeit investiert. Dass das Zonen-Log deine Reihenfolge wiedergibt und das Übersichtsbild auf den Abschnitt passt, sind die zwei Proben, die du brauchst. Der harte Abbruch zeigt dir, dass `flush()` wirkt; unter Linux beendet `kill -9` mit der Prozessnummer das Spiel ohne Aufräumen. + resources: + - title: Godot Docs · Groups + url: https://docs.godotengine.org/en/stable/tutorials/scripting/groups.html + - title: Godot Docs · Line2D.add_point + url: https://docs.godotengine.org/en/stable/classes/class_line2d.html#class-line2d-method-add-point + + - id: sitzung-mit-tester + type: practice + title: Eine Sitzung mit einem Tester + prompt: | + Führ eine Sitzung mit einer Person durch, die deinen Abschnitt nicht kennt. Wer das ist, entscheidest du. Bereite sie vor wie in der Lektion, sieh zu, ohne zu erklären, und halte Protokoll und Aufzeichnung zusammen. + lang: prose + checklist: + - Der getestete Stand hat einen Tag, und das Protokoll nennt ihn. + - Der Tester wusste vor dem Start, was aufgezeichnet wird, und hat zugestimmt. + - Weder Dateinamen noch Protokoll enthalten seinen Namen; er heißt T1 oder trägt die Sitzungsnummer. + - Notizen, Spur und erwarteter Weg waren während der Sitzung aus. + - Du hast nichts erklärt; jeder Eingriff steht mit Zeit im Protokoll. + - Die Sitzungsnummer der neuen Dateien steht im Protokoll. + hints: + - Sag vorher einen Satz wie „Das Spiel speichert, wo die Figur langläuft, keinen Namen und keinen Ton. In Ordnung?“ und dann nichts mehr zum Abschnitt. + explanation: | + Eine einzige Sitzung reicht, um den Ablauf zu üben: Einverständnis, Stoppuhr, Protokoll, Nummer. Für Aussagen über deinen Abschnitt brauchst du mehrere Tester, das ist Teil der [Werkstatt](/level-design/werkstatt-abschnitt). Jeder Eingriff mit Zeit im Protokoll erklärt dir später Halte in der Spur, die sonst wie Verwirrung aussehen. + resources: + - title: The Level Design Book · Playtesting, „Playtest formats“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#playtest-formats + - title: Nielsen Norman Group · Talking with Users in a Usability Test + url: https://www.nngroup.com/articles/talking-to-users/ + + - id: spuren-auswerten + type: practice + title: Spur und Absicht vergleichen + prompt: | + Erzeuge das Übersichtsbild für deine Sitzungen und leg es neben Absichtsnotiz und Protokoll. Schreib drei bis fünf Beobachtungen auf. Welche Stellen du auswählst und was du daraus schließt, entscheidest du. + lang: prose + starter: | + Ort (Zone oder Zelle) | Zeit | Spur zeigt | Protokoll sagt | meine Deutung + checklist: + - Jede Beobachtung nennt einen Ort und eine Zeit. + - Jede Beobachtung trennt, was Spur und Protokoll zeigen, von deiner Deutung. + - Mindestens eine Beobachtung vergleicht die Spur mit dem erwarteten Weg. + - Halte von mehr als zwei Sekunden und Umkehrungen sind gezählt, nicht geschätzt. + - Du hast notiert, welche Frage die Daten nicht beantworten und wie du sie beim nächsten Test klärst. + hints: + - Acht Punkte auf einer Stelle sind zwei Sekunden. + explanation: | + Die Tabelle zwingt dich, Ort, Zeit und Quelle zu nennen, bevor du deutest. Dann kannst du später prüfen, ob eine Änderung das beobachtete Verhalten getroffen hat. Wie du aus solchen Beobachtungen eine Änderung ableitest, zeigt [Überarbeiten](/level-design/ueberarbeiten). + resources: + - title: Mike Ambinder · Valve's Approach to Playtesting (Folien, GDC 2009) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf diff --git a/content/level-design/modules/playtest-methode.yaml b/content/level-design/modules/playtest-methode.yaml new file mode 100644 index 0000000..5ecd042 --- /dev/null +++ b/content/level-design/modules/playtest-methode.yaml @@ -0,0 +1,507 @@ +id: playtest-methode +title: "Beobachten, ohne zu erklären: Playtests für Level" +level: 2 +minutes: 100 +summary: Was du bei einem Level-Playtest beobachtest – Weg, Halt, Blickrichtung, Umkehr, Wände entlang, Kanten testen, übersehene Hinweise –, wie du den Weg auf einer Papierkarte mitschreibst, wann du eingreifst, wen du testen lässt und wie du anonyme Notizen unterwegs in die Arten einordnest, mit denen du danach überarbeitest. +place: unterwegs +goals: + - Du bereitest einen Level-Playtest aus deiner Absichtsnotiz vor, mit Testfragen, einer Karte ohne erwarteten Weg und einer Abbruchregel. + - Du beobachtest Weg, Halt, Blickrichtung, Umkehr, Laufen an Wänden, Kantentests und übersehene Hinweise und protokollierst sie als Zeit, Ort, Tun und Sagen. + - Du unterscheidest gewollte Erkundung von Verwirrung anhand deiner Absicht und des Wegs, nicht nach Eindruck. + - Du entscheidest nach einer vorher festgelegten Regel, wann du eingreifst, und protokollierst den Eingriff so, dass die Daten danach getrennt bleiben. + - Du wählst frische oder wiederkehrende Tester passend zur Frage, testest in kleinen Runden und notierst anonym. + - Du ordnest Beobachtungen den Codes „Absicht erfüllt“, „nicht bemerkt“, „falsch gelesen“, „nicht befolgt“ und „unbeabsichtigte Folge“ zu und sortierst sie nach Häufigkeit und Schwere. +resources: + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + - title: Jakob Nielsen, „Why You Only Need to Test with 5 Users“ (NN/g, 2000) + url: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ + - title: Amy Schade, „Avoid Leading Questions to Get Better Insights from Participants“ (NN/g, 2017) + url: https://www.nngroup.com/articles/leading-questions/ + - title: Kim Swift, Erik Wolpaw, „A Portal Post-Mortem“ (GDC 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf +lesson: | + Lehrbeispiel: Eine Freundin spielt deinen Blockout, den Lagerhof aus [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze). Nach 14 Sekunden läuft sie an der Öffnung zur Kammer vorbei. Nach 30 Sekunden steht sie am Tor und läuft gegen die Wand daneben. Nach einer Minute fragt sie: „Muss ich hier irgendwas finden?“ Du willst „rechts!“ sagen. Sagst du es, weißt du nie, ob sie die Kammer allein gefunden hätte. + + Wie man zusieht, ohne zu helfen, steht allgemein in [Testlesen und Playtest: Verständlichkeit beobachten](/narrative/testlesen-playtest): lautes Denken anleiten, Fragen zurückgeben, danach neutral fragen, Beobachtung und Deutung trennen. Lies das zuerst, hier wird es nicht wiederholt. Dieses Modul behandelt, was bei Leveln dazukommt: worauf du achtest, wie du einen Weg auf Papier mitschreibst, wann du eingreifst, wen du testen lässt und wie du deine Notizen unterwegs einordnest, damit du in [Überarbeiten](/level-design/ueberarbeiten) damit arbeiten kannst. + + ## Was du bei einem Level beobachtest + + Das Level Design Book beginnt sein Kapitel mit „A playtest is when someone plays your level, and you watch whether your level works or not.“ Für Tests mit Menschen, die keine Entwickler sind, schreibt es: „Watching their behavior is more important than their feedback“ ([Playtest formats](https://book.leveldesignbook.com/process/blockout/playtesting#playtest-formats)). Verhalten heißt bei einem Level vor allem Bewegung im Raum. Sieben Dinge kannst du sehen: + + - **Weg.** Welche Wegpunkte der Tester in welcher Reihenfolge erreicht. + - **Halt.** Wo die Figur stehen bleibt und wie lange. + - **Blickrichtung und Kamera.** Augen siehst du nicht. Du siehst, wohin die Figur schaut und was die Kamera gerade zeigt. Das Level Design Book nennt als Regel: „Players look in the direction they are moving.“ ([Wayfinding, Psychology](https://book.leveldesignbook.com/process/blockout/wayfinding#psychology)). Dreht die Figur kurz zu einer Öffnung, spricht das dafür, dass sie bemerkt wurde. Ein Beweis ist es nicht. + - **Umkehr.** Der Tester geht zu einem Wegpunkt zurück, an dem er schon war. + - **An Wänden entlang.** Die Figur läuft dicht an einer Wand entlang. Das Buch nennt Spieler, die so nach Geheimnissen suchen: „wallhugging to try to find secrets“. Es kann auch heißen, dass der Tester keinen Ausgang sieht. + - **Kanten testen.** Der Tester läuft gegen Wände, Wasser oder Abgründe, um zu prüfen, ob sie wirklich sperren. Dann traut er deinen Zeichen für „blockiert“ nicht ganz ([Umgebung als Information](/level-design/umgebung-informiert)). + - **Hinweis übersehen.** In der Nähe eines Hinweises hält der Tester nicht, ändert nicht die Richtung und sagt nichts dazu. Ob der Hinweis dabei im Bild war oder im Rest unterging, kannst du nur mit der Skizze und ihren Wegpunkten sagen. + + Dazu kommt, was der Tester sagt. Valve beschreibt lautes Denken mit drei Wörtern: „Unprompted and uncorrected“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Du schreibst es wörtlich und kurz auf. + + ## Der Weg auf der Papierkarte + + Nimm zum Test eine Kopie deiner Skizze mit, eine Karte je Tester. Die Nummern der Wegpunkte brauchst du für die Ortsangaben, die Linie deines erwarteten Wegs nicht. Steht sie auf der Karte, zeichnest du leicht nach, was du erwartest, statt was passiert. Mit dem Stift ziehst du den Weg des Testers nach. Wo er hält, setzt du eine kleine Nummer an die Linie, am Rand stehen Nummer und Zeit. Die Zeit nimmst du mit der Stoppuhr des Handys, wie es die Checkliste des Level Design Book vorschlägt: „use stopwatch app to time how long it takes“ ([Prepare for playtest](https://book.leveldesignbook.com/process/blockout/playtesting#id-1.-prepare-for-playtest)). + + Daneben führst du das Beobachtungsprotokoll. Jeder Eintrag hat vier Angaben: Zeit, Ort, was der Spieler tut, was er sagt. Am Handy schreibst du es als kurze Zeilen: + + ```text + 0:05 S betritt den Hof + 0:09 1 hält 3 s, schaut hoch + 0:14 3 läuft vorbei + 0:22 2 hält 8 s am Tor + 0:30 2 läuft gegen Wand links + 0:40 1 zurück zur Hofmitte + 1:02 1 „Muss ich was finden?“ + ``` + + Der Ort ist eine Wegpunktnummer oder ein Zeichen aus der Skizze. Das Tun ist ein Verb mit Ort oder Richtung. Gesagtes steht wörtlich in Anführungszeichen. Deutungen wie „verwirrt“ gehören nicht in diese Zeilen; warum, steht im Narrative-Modul. + + Valve nennt drei Schwächen des direkten Beobachtens: „Presence of observers can bias results“, „Salient event can slant interpretation“ und „Behavior requires interpretation“. Für einen Level-Playtest folgen daraus drei Regeln: + + - **Setz dich schräg hinter den Tester.** Das Level Design Book: „watch from a short distance behind the playtester(s), don’t just breathe over their shoulder.“ + - **Notier auch das Unauffällige.** Jeden Wegpunkt und jeden Halt, nicht nur den Moment, in dem etwas schiefgeht. Sonst hängt deine Auswertung am lautesten Ereignis. + - **Zeig nicht auf den Bildschirm und frag nicht nach einem Hinweis, solange gespielt wird.** Die Nielsen Norman Group beschreibt eine Sitzung, in der die Frage „What do you think this button does?“ der Testperson erst verriet, dass der Text ein Link war ([Avoid Leading Questions](https://www.nngroup.com/articles/leading-questions/)). Im Level gilt dasselbe: Fragst du nach dem Licht in der Kammer, hat ab dann nicht mehr der Raum es gezeigt, sondern du. + + Am PC kannst du den Weg auch aufzeichnen lassen. In [Playtest am PC: Wege aufzeichnen und vergleichen](/level-design/playtest-godot) schreibt ein Skript alle 0,25 Sekunden die Position der Figur in eine Datei mit der Kopfzeile `t,x,y`, 240 Punkte pro Minute, und zeichnet die Spuren. Das Skript darf dir eine KI schreiben; was du beobachtest und wie du es einordnest, entscheidest du. Die Papierkarte bleibt trotzdem nützlich, denn sie hält fest, was eine Spur allein nicht zeigt: wohin die Figur schaute und was der Tester sagte. + + > [!MERKE] Zeit, Ort, Tun, Sagen + > Jede Zeile im Protokoll hat diese vier Teile. Gedeutet wird später, und zwar gegen die Absichtsnotiz. + + ## Verwirrung oder gewollte Erkundung? + + Dasselbe Verhalten kann zweierlei bedeuten. Ein Tester, der 40 Sekunden in einer Nische steht und die Wände abläuft, kann verloren sein oder genau das tun, was du wolltest. Die Nielsen Norman Group warnt vor dieser Verwechslung: Was für den Beobachter wie Mühe aussah, kann auch heißen, dass die Person gerade entschied, was wichtig ist, oder dass sie „exploring various areas of the site“ war ([Avoid Leading Questions](https://www.nngroup.com/articles/leading-questions/)). Dan Taylor erinnert daran, dass sogar Verlorensein gewollt sein kann. Es sei in Ordnung, „to create areas where the player feels lost or confused, to create a sense of dramatic tension“ ([Ten Principles, Teil 1](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-)). + + Entscheide deshalb nicht nach Eindruck, sondern nach deiner Absichtsnotiz. Schreib vor dem Test hinein, wo Erkundung erwünscht ist, etwa „Nische West: Nebenweg zum Suchen“. Läuft ein Tester dort herum und kommt danach auf den Weg zurück, ist das kein Befund gegen den Raum. Läuft er auf dem Pflichtweg im Kreis, schon. + + Ein paar Anhaltspunkte helfen. Keiner davon ist ein Beweis. + + - **Neue Orte oder alte Schleifen?** Wer erkundet, kommt oft an Stellen, an denen er noch nicht war. Wer verloren ist, wiederholt oft dieselbe Folge von Wegpunkten. + - **Zurück zum Bekannten.** Kehrt der Tester immer wieder zum Start oder zum letzten Knoten zurück, sucht er einen neuen Anfang. + - **Kanten testen nahe am Ziel.** Läuft er dort gegen Wände, wo es für ihn weitergehen soll, hat er das Ziel gesehen, aber keinen Weg dorthin. + - **Gesagtes.** „Was ist da hinten?“ klingt nach Neugier, „Wo war ich schon?“ nach fehlender Orientierung. Du schreibst beides wörtlich auf und deutest es erst danach. + + Umkehrungen je Wegpunkt und Verweildauer je Ort kannst du aus dem Protokoll auszählen. Wie das geht, zeigen die Übungen. + + ## Eingreifen: wann und wie du es notierst + + Das Level Design Book rät, „resist the urge to interrupt the playtest to apologize or explain“, und setzt eine Grenze: „However, if the playtester is definitely stuck or if the level is clearly just broken, then go ahead and intervene.“ ([Observe playtest](https://book.leveldesignbook.com/process/blockout/playtesting#id-3.-observe-playtest-collect-telemetry)) + + Leg vor dem Test eine **Abbruchregel** fest, damit du nicht im Moment entscheidest, etwa „kein neuer Wegpunkt seit zwei Minuten“. Die Zahl wählst du selbst. Ohne Regel sitzt du im Zweifel sehr lange daneben. In der Debatte um gelbe Markierungen erzählte Joseph Hunter, Entwickler von Sucker for Love, dass ein Entwickler 20 Minuten schweigend zusehen musste, wie ein Tester einen Weg nach oben suchte ([GamesRadar+](https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/)). + + Greifst du ein, dann in drei Schritten: + + 1. Zuerst die kleinste Hilfe: Gib eine Frage zurück, wie in [Testlesen und Playtest](/narrative/testlesen-playtest) beschrieben. + 2. Reicht das nicht, zeig auf einen Bereich, nicht auf die Lösung, etwa „Schau dich im Hof noch einmal um“. + 3. Notier den Eingriff als eigene Zeile, mit Zeit, Ort und deinem Wortlaut, und zieh auf der Karte einen Querstrich. Alles danach ist „nach Eingriff“. + + ```text + 2:40 1 EINGRIFF „Schau im Hof“ + 2:47 3 geht in die Kammer + ``` + + Die Stelle, an der der Tester festhing, wertest du aus. Was er nach dem Eingriff findet, zählt nicht als gefunden, denn gezeigt hast du es. Technische Fehler sind etwas anderes: Die Figur steckt in der Kollision fest, die Kamera springt, das Spiel stürzt ab. Dann hilfst du sofort und notierst „Technik“. Das sagt nichts über die Lesbarkeit deines Raums und kommt auf die Fehlerliste ([Fehler eingrenzen](/godot/fehler-eingrenzen)). + + ## Wer testet: frische und wiederkehrende Tester + + **Frische Tester** haben den Abschnitt noch nie gespielt. Nur sie können zeigen, ob man einen Hinweis bemerkt. Das Level Design Book nennt einen Test mit möglichst wenig Anleitung einen „blind“ Playtest. **Wiederkehrende Tester** kennen den Grundriss. Ihr Weg zeigt Erinnerung, nicht Lesbarkeit. Sie sind gut für andere Fragen: Stört eine Änderung den Fluss? Ist irgendwo etwas kaputt? Wie spielt sich der nächste Abschnitt, wenn der erste bekannt ist? **Du selbst** findest beim eigenen Durchspielen, was das Buch „obvious problems“ nennt: „does the level load? is the doorway wide enough?“. Notier zu jedem Tester, ob er neu ist und welche Fassung er gespielt hat. + + **Wenige pro Runde.** Jakob Nielsen hat für Usability-Tests gezeigt, dass jeder weitere Tester weniger Neues bringt. Er schreibt: „Even 3 users are enough to get an idea of the diversity in user behavior and insight into what's unique and what can be generalized.“ Zugleich warnt er vor „the spurious behavior of a single person“ ([NN/g, 2000](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)). Für Level heißt das: drei bis fünf Tester, dann ändern, dann eine neue Runde mit neuen Testern. Was ein einzelner Tester Ungewöhnliches tut, ist eine Notiz, noch kein Befund. + + **Kurz einweisen.** Das Buch rät, Erwartungen zu setzen, „But keep it brief.“ Sag, was der Tester tun soll, wie lange es dauert und dass alles graue Platzhalter sind. Erkläre nicht das Level. Ein Satz wie „Du musst den Hebel finden“ beendet den Test, bevor er beginnt. Das Level Design Book warnt allerdings: „But normies have a hard time playtesting blockouts, you'll likely have to art pass first“. Spielt jemand selten, erklärst du deshalb in der Einweisung kurz die Steuerung und deine Blockout-Vokabel ([Umgebung als Information](/level-design/umgebung-informiert)), also welche Form und welcher Tonwert was bedeutet, aber nie den Weg. Reicht das nicht, testest du mit dieser Person erst nach einer kurzen Ausgestaltung ([Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung)). + + **Anonym notieren.** Schreib keine Namen in Karte und Protokoll, sondern „T1“, „T2“, „T3“, dazu Datum, Fassung und ob neu oder wiederkehrend. Notizen am Handy landen oft in einem Cloud-Speicher; Namen haben dort nichts zu suchen. Nimmst du den Bildschirm auf, dann nur das Spielbild, mit Einverständnis, und lösch die Aufnahme, wenn du sie ausgewertet hast. + + > [!PRAXIS] Valves Freitags-Playtest + > Bei Valve testen Level-Designer jeden Freitag mit Menschen außerhalb des Teams. Phil Co beschreibt, was das für die Woche bedeutet: „Everything we do during the week is focused on that Friday playtest.“ (zitiert im [Level Design Book](https://book.leveldesignbook.com/process/blockout/playtesting#playtesting-at-valve)). Im Post-Mortem zu Portal steht unter „Playtesting“: „Keeps you objective“ und „Watching a playtest exposes what isn’t working.“ ([Swift und Wolpaw, GDC 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)). Feste, kleine Runden halten das Zusehen im Arbeitsablauf, statt es ans Ende zu schieben. + + ## Notizen auswerten: einordnen, zählen, ordnen + + Nach der Sitzung, etwa auf dem Heimweg, gehst du das Protokoll Zeile für Zeile durch und gibst jeder Zeile, die etwas über deinen Raum sagt, einen von fünf Codes: + + | Code | Bedeutung | Beispiel | + | --- | --- | --- | + | Absicht erfüllt | Verhalten passt zum Zeichen „klappt“ | geht zuerst zu 2, dann zu 3 | + | nicht bemerkt | Hinweis war nicht im Bild oder ging im Rest unter | kein Halt, kein Richtungswechsel, kein Wort an 3 | + | falsch gelesen | bemerkt, aber anders verstanden | hält den Durchgang für Wand | + | nicht befolgt | verstanden, aber nicht gefolgt | schaut zur Kammer, sagt „später“ | + | unbeabsichtigte Folge | befolgt, aber anders als gedacht | erreicht A durch eine Lücke | + + Die Kette dahinter, bemerken, lesen, befolgen, Folge, und die Hebel für jede Art behandelt [Überarbeiten](/level-design/ueberarbeiten). Hier zählt der Beleg: Zu jedem Code gehören Zeit und Ort aus dem Protokoll. Kannst du zwischen „nicht bemerkt“ und „falsch gelesen“ nicht entscheiden, schreib „unklar“ und achte in der nächsten Runde an dieser Stelle auf Blickrichtung und Halt. + + Danach fasst du über alle Tester zusammen, je Ort und Code, etwa „3, nicht bemerkt, 3 von 4“. Geordnet wird nach Häufigkeit und Schwere. Eine Skala als Vorschlag: Schwere 3 blockiert den Pflichtweg, Schwere 2 kostet deutlich Zeit oder dreht die Reihenfolge um, Schwere 1 betrifft einen Nebenweg. Valve warnt bei Statistiken: „Averages hide extreme examples“. Halte deshalb den einen Tester, der festhing, neben den Zahlen sichtbar. + + ```text + Runde 1 · 4 Tester, alle neu + 3 nicht bemerkt 3/4 Schwere 3 + 2 falsch gelesen 2/4 Schwere 2 + 4 Absicht erfüllt 4/4 + T3: 2 min an 1, Eingriff + ``` + + Diese Liste ist der Anfang für [Überarbeiten](/level-design/ueberarbeiten). Dort wählst du eine Stelle aus und änderst genau eine Sache. + + > [!INTERVIEW] „Ein Tester läuft im Kreis. Was tust du?“ + > Ich schaue zuerst in die Absichtsnotiz, ob dort Erkundung vorgesehen ist. Wenn nicht, schreibe ich weiter mit: Zeit, Wegpunkt, Blickrichtung, Gesagtes, damit ich später sehe, welche Schleife er läuft und an welchem Hinweis er vorbeigeht. Eingreifen tue ich erst nach der Regel, die ich vorher festgelegt habe, mit der kleinsten Hilfe, und ich protokolliere den Eingriff. Danach ordne ich die Stelle ein, meist als „nicht bemerkt“ oder „falsch gelesen“, und prüfe in der nächsten Runde mit neuen Testern, ob es ein Muster ist. + + ## Häufige Fehler + + - **Nur das Spannende notieren.** Im Protokoll stehen drei dramatische Momente und keine Zeit dazwischen. Schreib jeden Wegpunkt und jeden Halt auf. + - **Den erwarteten Weg auf der Karte.** Du zeichnest den Weg des Testers an deinem entlang. Nimm eine Karte ohne deine Linie. + - **Eingriff ohne Notiz.** Später zählst du einen Fund, den du selbst gezeigt hast. Jeder Eingriff bekommt eine Zeile und einen Strich. + - **Mit wiederkehrenden Testern prüfen, ob etwas auffällt.** Wer die Kammer kennt, findet sie immer. Für Fragen des Bemerkens brauchst du neue Tester. + - **Jede Umkehr als Problem werten.** In einem Bereich, der zum Suchen da ist, ist Umkehr erwünscht. Prüf gegen die Notiz. + - **Namen in den Notizen.** Schreib T1, T2, T3. + - **Eine große Runde.** Zehn Tester auf einmal zeigen dir oft dieselben Stellen. Teil sie auf mehrere Runden mit Änderungen dazwischen auf. + + ## Zusammenfassung + + - Bei Leveln beobachtest du Weg, Halt, Blickrichtung, Umkehr, Laufen an Wänden, Kantentests und übersehene Hinweise, dazu wörtlich das Gesagte. + - Der Weg kommt auf eine Kopie der Skizze ohne deinen erwarteten Weg, mit Nummern und Zeiten. Das Protokoll hat je Zeile Zeit, Ort, Tun und Sagen. + - Sitz schräg dahinter, notier auch Unauffälliges und zeig nicht auf den Bildschirm. + - Ob Erkundung oder Verwirrung, entscheidet die Absichtsnotiz, nicht dein Eindruck. + - Eingreifen nach einer vorher festgelegten Regel, mit der kleinsten Hilfe, als eigene Zeile im Protokoll. + - Frische Tester für Fragen des Bemerkens, wiederkehrende für Fluss und Technik. Drei bis fünf pro Runde, anonym notiert. + - Jede Zeile bekommt einen Code mit Beleg. Zusammengefasst wird je Ort und Code, geordnet nach Häufigkeit und Schwere. +exercises: + - id: erkundung-oder-verwirrung + type: choice + title: 40 Sekunden in der Nische + prompt: | + Lehrbeispiel: In der Absichtsnotiz steht „Nische West: Nebenweg zum Suchen, Fundstück hinter Kisten“. Ein Tester geht in die Nische, läuft 40 Sekunden an den Wänden und Kisten entlang, findet nichts, geht zurück zur Hofmitte und von dort zum Tor. Wie ordnest du die 40 Sekunden ein? + options: + - text: Absicht erfüllt. Die Nische ist zum Suchen da, der Tester hat gesucht und ist danach auf den Weg zurückgekehrt. + correct: true + why: Die Notiz sieht Erkundung genau dort vor. Dass er das Fundstück nicht gefunden hat, ist eine eigene Beobachtung, kein Zeichen für Verwirrung. + - text: Nicht bemerkt, weil er das Fundstück nicht gefunden hat. + correct: false + why: Das Suchen selbst war erwünscht. Ob das Fundstück zu gut versteckt ist, notierst du getrennt und prüfst es über mehrere Tester. + - text: Verwirrung, weil er lange an Wänden entlanggelaufen ist. + correct: false + why: An Wänden entlanglaufen kann Suche nach Geheimnissen sein. Ohne Bezug zur Notiz ist „Verwirrung“ nur ein Eindruck. + - text: Unbeabsichtigte Folge, weil er nicht direkt zum Tor ging. + correct: false + why: Er hat die Reihenfolge nicht umgangen, sondern einen erlaubten Umweg gemacht und ist zurückgekehrt. + explanation: | + Dasselbe Verhalten kann Erkundung oder Verwirrung sein. Entscheidend ist, was die Absichtsnotiz für diesen Ort vorsieht. Hier ist Suchen gewollt, und der Tester kehrt danach auf den Weg zurück. Dass er nichts gefunden hat, ist eine zweite Frage: Wenn drei von vier Testern suchen und keiner etwas findet, ist das Fundstück vielleicht nicht bemerkt worden. + hints: + - Lies zuerst, was die Notiz über die Nische sagt. + resources: + - title: NN/g · Avoid Leading Questions + url: https://www.nngroup.com/articles/leading-questions/ + + - id: wann-eingreifen + type: choice + title: Jetzt helfen oder nicht? + prompt: | + Deine Abbruchregel lautet „kein neuer Wegpunkt seit zwei Minuten“. In welchen Fällen greifst du ein? + options: + - text: Die Figur steckt zwischen zwei Kisten in der Kollision fest und kommt nicht mehr heraus. + correct: true + why: Ein technischer Fehler. Du hilfst sofort und notierst „Technik“. Über die Lesbarkeit sagt das nichts. + - text: Der Tester hat seit drei Minuten keinen neuen Wegpunkt erreicht und läuft zwischen Hofmitte und Tor hin und her. + correct: true + why: Die Regel ist erfüllt. Du gibst die kleinste Hilfe und protokollierst den Eingriff. + - text: Der Tester bleibt 20 Sekunden an der Abzweigung stehen und schaut sich um. + correct: false + why: Ein Halt ist eine Beobachtung. Er kann gerade das tun, was du willst, nämlich den Raum lesen. + - text: Der Tester fragt „Bin ich hier richtig?“ + correct: false + why: Eine Frage ist kein Festhängen. Gib sie zurück, etwa mit „Was meinst du?“, und notier sie wörtlich. + explanation: | + Das Level Design Book erlaubt den Eingriff, wenn der Tester „definitely stuck“ ist oder das Level „clearly just broken“. Die Abbruchregel macht „definitely stuck“ zu einer Zahl, die du vorher festlegst. Technik hilfst du sofort. Halte und Fragen sind Material für deine Auswertung und kein Grund zu helfen. + hints: + - Zwei Fälle sind richtig. + resources: + - title: The Level Design Book · Playtesting, „Observe playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#id-3.-observe-playtest-collect-telemetry + + - id: frisch-oder-wiederkehrend + type: choice + title: Wer kann das beantworten? + prompt: | + Du hast im Lagerhof eine Änderung gemacht. Ein Tester aus der letzten Runde hat Zeit. Welche Fragen kann er dir sinnvoll beantworten? + options: + - text: Stören die neuen Kisten den Weg zum Tor? + correct: true + why: Eine Frage zum Fluss. Dafür muss der Tester den Raum nicht neu sehen. + - text: Läuft die Figur nach der Änderung irgendwo fest? + correct: true + why: Technik prüft jeder, auch du selbst. + - text: Bemerkt man die Öffnung zur Kammer jetzt? + correct: false + why: Er weiß schon, dass es die Kammer gibt. Ob die Öffnung auffällt, zeigt nur jemand, der sie noch nie gesehen hat. + - text: Geht man jetzt zuerst zum Tor? + correct: false + why: Seine Reihenfolge folgt der Erinnerung an die letzte Runde, nicht dem Raum. + explanation: | + Wiederkehrende Tester kennen den Grundriss. Ihr Verhalten zeigt Erinnerung, deshalb taugen sie nicht für Fragen des Bemerkens und der ersten Reihenfolge. Für Fluss, Technik und spätere Abschnitte sind sie gut. Für die Frage, ob die Änderung wirkt, brauchst du neue Tester. + hints: + - Welche Fragen hängen davon ab, dass man den Raum zum ersten Mal sieht? + resources: + - title: The Level Design Book · Playtesting, „Playtest formats“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#playtest-formats + + - id: sitzung-ablauf + type: order + title: Eine Sitzung von vorn bis hinten + prompt: | + Bring die Schritte eines Level-Playtests in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Leite aus der Absichtsnotiz die Testfragen und die Abbruchregel ab. + Kopier die Skizze ohne deinen erwarteten Weg, eine Karte je Tester. + Weise den Tester kurz ein, ohne das Level zu erklären. + Sieh zu, zeichne den Weg mit und protokolliere Zeit, Ort, Tun und Sagen. + Stell nach dem Spiel deine offenen Fragen. + Ordne jede Protokollzeile einem der fünf Codes zu. + Zähl nach Ort und Code und ordne nach Häufigkeit und Schwere. + alternatives: + - [2, 1, 3, 4, 5, 6, 7] + explanation: | + Testfragen, Regel und Karte bereitest du vor, ihre Reihenfolge ist gleich. Die Einweisung kommt vor dem Spiel und bleibt kurz. Während des Spiels beobachtest du nur, Fragen kommen danach, damit sie das Verhalten nicht ändern. Das Einordnen braucht das ganze Protokoll, das Zählen alle Codes. + hints: + - Fragen stellst du erst, wenn nicht mehr gespielt wird. + resources: + - title: The Level Design Book · Playtesting, „How to run a playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#how-to-run-a-playtest + + - id: umkehr-zaehlen + type: output + title: Wie oft zurück? + prompt: | + Ein Weglog aus einem Playtest: Sekunde und Wegpunkt, an dem der Tester ankommt. Das Modell zählt Ankünfte an Wegpunkten, an denen er schon war. Was gibt es aus? + lang: python + code: | + # (Sekunde, Wegpunkt) + log = [(0, "S"), (4, "1"), + (9, "2"), (15, "3"), + (22, "2"), (30, "3"), + (41, "4")] + gesehen = set() + umkehr = [] + for zeit, wp in log: + if wp in gesehen: + umkehr.append((wp, zeit)) + gesehen.add(wp) + print(len(umkehr), umkehr) + expected: | + 2 [('2', 22), ('3', 30)] + hints: + - Bis Sekunde 15 ist jeder Wegpunkt neu. + explanation: | + Der Tester kommt bei Sekunde 22 zum zweiten Mal an Wegpunkt 2 an und bei Sekunde 30 zum zweiten Mal an 3. Zwischen Tor und Öffnung pendelt er also einmal hin und her, bevor er zum Hebel geht. Ob das ein Problem ist, sagt die Zahl nicht. Liegt dort laut Notiz der Pflichtweg, ist es ein Befund; vielleicht wurde die Öffnung beim ersten Mal nicht bemerkt. + resources: + - title: Python · set + url: https://docs.python.org/3/library/stdtypes.html#set + + - id: verweildauer + type: output + title: Wo blieb er am längsten? + prompt: | + Dasselbe Weglog. Das Modell rechnet für jeden Wegpunkt die Zeit vom Ankommen bis zum nächsten Wegpunkt zusammen, also Halten plus Weg. Was gibt es aus? + lang: python + code: | + log = [(0, "S"), (4, "1"), + (9, "2"), (15, "3"), + (22, "2"), (30, "3"), + (41, "4")] + dauer = {} + for a, b in zip(log, log[1:]): + t1, wp = a + t2 = b[0] + dauer[wp] = dauer.get(wp, 0) + dauer[wp] += t2 - t1 + top = max(dauer, key=dauer.get) + print(top, dauer[top]) + print(dauer["2"]) + expected: | + 3 18 + 14 + hints: + - "Wegpunkt 3 kommt zweimal vor: 22 − 15 und 41 − 30." + - Wegpunkt 2 ebenso, 15 − 9 und 30 − 22. + explanation: | + An Wegpunkt 3 kommen 7 und 11 Sekunden zusammen, an 2 sind es 6 und 8. Der letzte Eintrag hat keinen Nachfolger und zählt nicht. Das Modell trennt Halten und Gehen nicht. Ziehst du die Gehzeit ab, die du aus Weglänge und Tempo kennst ([Rhythmus](/level-design/rhythmus)), bleibt die Zeit, in der der Tester stand oder suchte. Bei 3 ist das vermutlich der größte Teil, und genau dort lohnt der Blick ins Protokoll. + resources: + - title: Python · zip() + url: https://docs.python.org/3/library/functions.html#zip + + - id: begriffe-playtest + type: gap + title: Fünf Begriffe für den Playtest + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Einen Test mit möglichst wenig Anleitung nennt das Level Design Book einen ⟦blind⟧ Playtest. Geht ein Tester zu einem Wegpunkt zurück, an dem er schon war, ist das eine ⟦Umkehr⟧. Wann du eingreifst, legst du vorher in einer ⟦Abbruchregel⟧ fest. Ob man einen Hinweis bemerkt, zeigen nur ⟦frische⟧ Tester. War ein Hinweis nicht im Bild oder ging er im Rest unter, lautet der Code ⟦nicht bemerkt⟧. + gaps: + - label: Testform + hint: Englisch, in Anführungszeichen, wie „ohne zu sehen“. + accept: ["blinden", "Blind-"] + - label: zurück zum Bekannten + hint: Das Gegenteil von „weitergehen“. + accept: ["Umkehrung", "Rückkehr", "Backtracking"] + - label: vorher festgelegt + hint: Eine Regel, nach der du den Test unterbrichst. + accept: ["Eingriffsregel", "Regel"] + - label: wer den Abschnitt nicht kennt + hint: Gegenteil von „wiederkehrend“. + accept: ["neue", "frischen", "neuen"] + - label: erste der vier Fehlerarten + hint: Zwei Wörter. Der Hinweis wurde nicht wahrgenommen. + accept: ["übersehen", "nicht gesehen", "nicht wahrgenommen"] + explanation: | + Ein blinder Playtest kommt dem Spielen ohne dich am nächsten. Umkehr und Verweildauer kannst du zählen. Die Abbruchregel schützt dich vor spontanen Eingriffen, frische Tester schützen deine Ergebnisse vor Erinnerung. „Nicht bemerkt“ ist die erste der vier Fehlerarten, mit denen du in [Überarbeiten](/level-design/ueberarbeiten) weiterarbeitest; der fünfte Code, „Absicht erfüllt“, hält fest, was funktioniert hat. + resources: + - title: The Level Design Book · Playtesting, „Playtest formats“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#playtest-formats + + - id: vorbereitung-fehler + type: bug + title: Ein Schritt verdirbt den Test + prompt: | + Lehrbeispiel: deine Notizen zur Vorbereitung eines Playtests. Eine Zeile macht den Test wertlos für die Frage, ob Tester den Weg allein finden. Finde sie. + lang: prose + code: | + Ich setze mich schräg hinter den Tester. + Ich notiere die Tester als T1, T2 und T3. + Ich zeige dem Tester vor dem Start die Skizze, damit er weiß, wo er ist. + Ich lege fest, dass ich nach zwei Minuten ohne neuen Wegpunkt helfe. + Ich starte die Stoppuhr, sobald der Tester die Figur bewegt. + lines: [3] + explanation: | + Die Skizze zeigt Wege, Durchgänge und Hinweise. Wer sie vorher gesehen hat, spielt mit einer Karte im Kopf, und du misst, ob er sich an die Skizze erinnert, nicht, ob der Raum ihm den Weg zeigt. Die anderen Zeilen schützen den Test: Abstand, anonyme Notizen, eine feste Abbruchregel und Zeiten ab einem klaren Startpunkt. + hints: + - Welche Zeile gibt dem Tester eine Information, die das Level geben soll? + resources: + - title: The Level Design Book · Playtesting, „Brief playtester“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#id-2.-brief-playtester + + - id: eingriff-gezaehlt + type: bug + title: Ein Fund, der keiner war + prompt: | + Ein ausgewertetes Protokoll, jede Zeile mit Code. Eine Zeile ist falsch eingeordnet. Finde sie. + lang: text + code: | + 0:14 3 vorbei: nicht bemerkt + 1:02 1 hält 30 s: unklar + 2:40 1 EINGRIFF „Schau im Hof“ + 2:47 3 Kammer: Absicht erfüllt + 3:20 A hinaus: nach Eingriff + lines: [4] + explanation: | + Der Tester geht in die Kammer, sieben Sekunden nachdem du ihn auf den Hof hingewiesen hast. Das ist kein Beleg dafür, dass der Raum die Kammer zeigt. Die Zeile gehört zu „nach Eingriff“ wie die letzte. Ausgewertet wird die Stelle davor: An Wegpunkt 3 ist er vorbeigelaufen, an 1 hat er 30 Sekunden gestanden. Diese Stelle geht als Befund in die Zählung. + hints: + - Was passiert direkt vor der falschen Zeile? + + - id: beobachter-wirkung + type: explain + title: Drei Schwächen des Zusehens + prompt: | + Auszug aus Valves Folien zum Playtesting. Erkläre in drei bis fünf Sätzen, was die drei Minuspunkte bei einem Level-Playtest bedeuten und was du jeweils dagegen tust. + lang: prose + code: | + Direct Observation + + Get a feel for player interaction with game + + Importance of what people do—not what they say + – Presence of observers can bias results + – Salient event can slant interpretation + – Behavior requires interpretation + points: + - Wer zusieht, verändert das Verhalten. Du sitzt schräg dahinter, zeigst nicht auf den Bildschirm und fragst während des Spiels nicht nach Hinweisen. + - Ein auffälliges Ereignis färbt die Auswertung. Du notierst jeden Wegpunkt und jeden Halt mit Zeit, nicht nur das Dramatische. + - Verhalten muss gedeutet werden. Du trennst die Zeilen des Protokolls von den Codes und deutest gegen die Absichtsnotiz. + - Über mehrere Tester zählen schützt davor, eine einzelne Deutung für ein Muster zu halten. + explanation: | + Valve hält das direkte Beobachten für unverzichtbar und nennt trotzdem drei Fallen. Erstens verändert ein Beobachter, was der Tester tut, deshalb sitzt du schräg dahinter und zeigst auf nichts. Zweitens bleibt das auffälligste Ereignis am stärksten hängen; ein Protokoll mit jeder Ankunft und jedem Halt hält dagegen. Drittens sagt ein Halt an einer Abzweigung allein nicht, warum der Tester hält. Darum stehen im Protokoll nur Zeit, Ort, Tun und Sagen, und gedeutet wird danach, mit der Absichtsnotiz daneben und über mehrere Tester. + hints: + - Nimm dir die drei Minuspunkte einzeln vor. + resources: + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + + - id: protokoll-einordnen + type: explain + title: T2 im Lagerhof + prompt: | + Lehrbeispiel: das Protokoll von T2 im Lagerhof, dem Abschnitt aus der Lektion. Absicht: „Der Spieler soll das Tor im Norden sehen, bevor er den Weg über die Kammer findet.“ Erkundung ist in der Notiz nicht vorgesehen. Erkläre in drei bis fünf Sätzen, welche Codes du für die Wegpunkte 2 und 3 vergibst und ob die Umkehrungen nach Erkundung oder nach Suche aussehen. + lang: prose + code: | + 0:05 S betritt den Hof. + 0:09 1 hält 2 s. + 0:16 2 hält 6 s am Tor, Figur zum Licht. + 0:25 2 läuft gegen die Wand rechts vom Tor. + 0:31 2 sagt: „Geht das nicht auf?“ + 0:38 1 zurück zur Hofmitte. + 0:44 3 läuft an der Öffnung vorbei, die Kamera zeigt die Kammer 1 s lang. + 0:52 1 zurück zur Hofmitte, hält 10 s. + 1:05 3 dreht zur Öffnung, geht in die Kammer. + 1:12 4 zieht den Hebel. + points: + - An Wegpunkt 2 ist die Absicht erfüllt, denn der Tester geht zuerst zum Tor; der Kantentest und die Frage zeigen, dass er das Tor als geschlossen gelesen hat. + - An Wegpunkt 3 lautet der Code beim ersten Vorbeigehen „nicht bemerkt“, denn der Tester hält nicht, ändert die Richtung nicht und sagt nichts, obwohl die Kammer kurz im Bild war. + - Beim zweiten Mal bemerkt er die Öffnung, nach zwei Umkehrungen zur Hofmitte und 10 Sekunden Halt. + - Weil die Notiz hier keine Erkundung vorsieht und er zum Bekannten zurückkehrt, sieht das nach Suche aus, nicht nach gewollter Erkundung. + - Ein Tester ist kein Muster; die Codes werden über alle Tester gezählt. + explanation: | + T2 geht zuerst zum Tor und hält dort, die Figur zeigt zum Licht. Die Reihenfolge stimmt, an Wegpunkt 2 ist die Absicht erfüllt. Dass er gegen die Wand daneben läuft und fragt, ob das Tor nicht aufgeht, zeigt, dass er es als geschlossen gelesen hat und einen anderen Weg sucht. An Wegpunkt 3 läuft er zuerst vorbei, ohne Halt, Richtungswechsel oder ein Wort, obwohl die Kammer eine Sekunde im Bild war. Sie ging also im Rest unter: „nicht bemerkt“, belegt mit 0:44. Erst nach zwei Rückkehren zur Hofmitte und zehn Sekunden Stillstand dreht er zur Öffnung. Da die Notiz dort keine Erkundung vorsieht und er immer wieder zum Knoten zurückgeht, spricht das für Suche. Ob die Öffnung zu leise ist, entscheidest du erst, wenn du dieselbe Stelle bei den anderen Testern gezählt hast. + hints: + - Geh die Zeilen nach Wegpunkt sortiert durch, erst alle zu 2, dann alle zu 3. + resources: + - title: The Level Design Book · Playtesting, „Analyze playtest data“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#id-5.-analyze-playtest-data + + - id: video-weg + type: practice + title: Einen fremden Weg mitzeichnen + prompt: | + Wähle ein Video, in dem jemand ein Top-down-Spiel zum ersten Mal spielt. Nimm zwei bis drei Minuten in einem Bereich. Skizzier den Bereich grob auf Papier, setz eigene Nummern als Wegpunkte und zeichne den Weg mit Zeiten mit. Schreib hier fünf Protokollzeilen und zähl die Umkehrungen. + lang: prose + starter: | + Video, Spiel, Stelle: + Protokoll (Zeit, Ort, Tun, Sagen): + Umkehrungen: + Stelle, die du einordnen würdest: + checklist: + - Jede der fünf Zeilen hat Zeit, Ort als Wegpunkt, Tun und, falls gesprochen wurde, das Gesagte wörtlich. + - Keine Zeile enthält ein Gefühlswort oder ein „weil“. + - Mindestens eine Zeile beschreibt Blickrichtung, Halt, Laufen an einer Wand oder einen Kantentest. + - Die Zahl der Umkehrungen passt zu den Wegpunkten im Protokoll. + - Du nennst eine Stelle, die du einordnen würdest, und schreibst dazu, welche Information dir für den Code fehlt. + explanation: | + Ein Video ist kein echter Test, denn die Person spielt für ein Publikum und du kennst die Absicht des Spiels nicht. Zum Üben reicht es: Du lernst, schnell Zeit und Ort zu notieren und den Weg auf Papier mitzuzeichnen. Die fehlende Information für den Code ist meist die Absicht. Genau deshalb schreibst du sie für deine eigenen Abschnitte vorher auf. + hints: + - Halte das Video an, wenn ein neuer Bereich ins Bild kommt, und skizzier zuerst die Ränder. + resources: + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting + + - id: eigener-test-planen + type: practice + title: Dein erster Level-Playtest + prompt: | + Plane den ersten Playtest deines eigenen Abschnitts. Nimm die Absichtsnotiz aus [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze). Stichpunkte genügen. + lang: prose + starter: | + Testfragen (mit Ort): + Abbruchregel: + Einweisung (ein bis zwei Sätze): + Tester (wie viele, neu?): + So bleiben die Notizen anonym: + checklist: + - Jede Testfrage nennt einen Wegpunkt und lässt sich durch Zusehen beantworten. + - Die Abbruchregel enthält eine Zahl, etwa eine Zeit ohne neuen Wegpunkt. + - Die Einweisung erklärt nicht, wohin der Tester gehen oder was er finden soll. + - Du planst drei bis fünf Tester und notierst, ob sie den Abschnitt schon kennen. + - Die Notizen enthalten keine Namen, und du hast festgelegt, was mit Aufnahmen geschieht. + explanation: | + Mit diesem Plan kannst du den Test ohne Vorbereitung im Moment durchführen. Die Testfragen bestimmen, worauf du achtest, die Abbruchregel, wann du eingreifst, und die Einweisung schützt den Test davor, dass du das Level erklärst. Den ganzen Ablauf mit mehreren Runden übst du in der [Werkstatt](/level-design/werkstatt-abschnitt). + hints: + - Nimm die Zeichen für „klappt“ und „scheitert“ aus deiner Notiz und mach aus jedem eine Frage. + resources: + - title: The Level Design Book · Playtesting, „Prepare for playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#id-1.-prepare-for-playtest diff --git a/content/level-design/modules/raum-lesen.yaml b/content/level-design/modules/raum-lesen.yaml new file mode 100644 index 0000000..a48683d --- /dev/null +++ b/content/level-design/modules/raum-lesen.yaml @@ -0,0 +1,443 @@ +id: raum-lesen +title: "Level lesen: Absicht, Hinweis, Verhalten" +level: 1 +minutes: 80 +summary: Das Denkmodell des Kurses – ein Level ist eine Absicht, die über Hinweise im Raum Verhalten auslösen soll – und eine Methode, Abschnitte veröffentlichter Top-down-Spiele zu lesen, Gesehenes von Gedeutetem zu trennen und eine eigene Absicht prüfbar aufzuschreiben. +place: unterwegs +goals: + - Du unterscheidest Absicht, Hinweis und Verhalten und sagst, welche Ebene du gestaltest und welche du beobachtest. + - Du rechnest aus, wie viele Tiles ein Bildschirm zeigt und wie früh der Spieler in der Draufsicht sieht, was kommt. + - Du liest einen Abschnitt eines veröffentlichten Top-down-Spiels in sechs Schritten und formulierst die vermutete Absicht in einem Satz. + - Du trennst in Notizen, was zu sehen war, von dem, was du daraus geschlossen hast. + - Du schreibst eine Absichtsnotiz mit beobachtbaren Zeichen für Erfolg und Scheitern. +resources: + - title: The Level Design Book · Critical path + url: https://book.leveldesignbook.com/process/layout/criticalpath + - title: Dan Taylor, „Ten Principles of Good Level Design“, Teil 1 (Game Developer, 2013) + url: https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1- + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + - title: Iwata Asks · A Link Between Worlds, Teil 3 „Direct Top-down View“ + url: https://www.nintendo.com/en-gb/Iwata-Asks/Iwata-Asks-The-Legend-of-Zelda-A-Link-Between-Worlds/The-Legend-of-Zelda-A-Link-Between-Worlds/3-Direct-Top-down-View/3-Direct-Top-down-View-831979.html +lesson: | + Lehrbeispiel: Du betrittst in einem Top-down-Spiel einen Hof. Links und rechts gibt es Durchgänge, oben einen weiteren, in der Mitte steht ein Brunnen. Neben dem rechten unteren Durchgang hängt eine Laterne, sonst ist alles dunkel. Du gehst zur Laterne. Hat das jemand so gewollt? Und wenn ja, hat dich die Laterne dorthin gebracht, oder war es der Brunnen, der den Weg geradeaus versperrt? + + Level-Design beginnt mit solchen Fragen. Ein Level ist kein Bild, das man betrachtet, sondern ein Raum, in dem jemand Entscheidungen trifft: wohin er geht, wo er stehen bleibt, was er ausprobiert und was er übersieht. Dieses Modul führt das Denkmodell ein, mit dem der ganze Kurs arbeitet, und eine Methode, mit der du veröffentlichte Level liest, bevor du eigene baust. Du brauchst dafür ein Spiel, ein Video oder deine Erinnerung, Papier und einen Stift. + + ## Ein Level ist ein Raum mit Absicht + + Ein Raum wird zum Level, sobald jemand mit einer Absicht entschieden hat, wie er aussieht. Die Absicht ist das, was der Spieler an dieser Stelle tun, bemerken oder verstehen soll: den Ausgang finden, einen Seitengang bemerken, eine neue Fähigkeit ohne Risiko ausprobieren, vor einer Begegnung einen Überblick bekommen. Sie ist nicht dasselbe wie „schön“ oder „stimmig“. Ein schöner Raum, in dem niemand den Ausgang findet, verfehlt seine Absicht. Ein karger grauer Raum aus Kästen, in dem alle sofort richtig gehen, erfüllt sie. + + Dan Taylor hat das 2013 auf der GDC als zehn Prinzipien formuliert. Zum ersten, „Good level design is fun to navigate“, schreibt er: „Careful layout, lighting, signage and other visual cues should create a natural “flow” to the level that guides the player instinctively through it.“ Das dritte lautet: „Good level design tells the player what to do, but not how to do it“ ([Game Developer, Teil 1](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-)). Das Ziel soll klar sein, der Weg dorthin bleibt beim Spieler. The Level Design Book sagt es knapper: „the best flow is whatever supports the intended experience design goals“ ([Flow](https://book.leveldesignbook.com/process/layout/flow)). Gut ist, was der Absicht dient. + + Für dich heißt das: Jeder Abschnitt, den du in diesem Kurs baust, beginnt mit einem Satz. Welcher Satz das ist, entscheidest du. Der Kurs gibt dir Werkzeuge, ihn umzusetzen und zu prüfen, keine Orte und keine Begegnungen für dein Spiel. + + ## Absicht, Hinweis, Verhalten: das Grundmodell + + Jede Stelle eines Levels hat drei Ebenen, und sie liegen an drei verschiedenen Orten. + + | Ebene | Wo sie liegt | Was du damit tust | + | --- | --- | --- | + | Absicht | in deinem Kopf, als Satz notiert | festlegen, bevor du baust | + | Hinweis | im Raum: Licht, Weg, Kontrast, Form, Landmarke | bauen und ändern | + | Verhalten | beim Spieler: Weg, Halt, Umkehr, Gesagtes | beobachten und notieren | + + Nur die mittlere Ebene kannst du gestalten. Die Absicht siehst du in keinem Spiel, und Verhalten kannst du nicht anordnen, nur beobachten. Das Level Design Book nennt den beabsichtigten Hauptweg „critical path“ und schränkt sofort ein: „Most players will wander, explore, linger, or even just get confused.“ ([Critical path](https://book.leveldesignbook.com/process/layout/criticalpath)). Level-Design arbeitet deshalb in einer Schleife: Absicht notieren, Hinweise bauen, Spieler beobachten, die Lücke zwischen Absicht und Verhalten ansehen und dann entweder die Hinweise oder die Absicht ändern. + + Im Hof aus dem Einstieg sieht das so aus. Absicht: „Der Spieler soll zuerst rechts unten hinausgehen.“ Hinweise: die Laterne als einziges Licht, der Brunnen in der Achse vom Eingang. Verhalten: Drei von vier Testern gehen zur Laterne, einer geht zuerst oben links hinaus. Ob die Laterne gewirkt hat oder der Brunnen, verrät dieses Ergebnis nicht. Dafür müsstest du eine Sache ändern und neu beobachten. + + > [!MERKE] Drei Ebenen + > Die Absicht steht in deiner Notiz, der Hinweis im Raum, das Verhalten beim Spieler. Gestalten kannst du nur Hinweise, prüfen nur am Verhalten. + + ## Die Draufsicht: was der Bildschirm zeigt und was er verbirgt + + In einem Spiel mit Kamera hinter der Figur sieht der Spieler einen Turm am Horizont, auch wenn er weit weg ist. In der Draufsicht gibt es keinen Horizont. Was der Spieler sieht, ist der Bildschirm, und der ist klein. Bei 320 × 180 Pixeln Spielgrafik und Tiles von 16 Pixeln, wie in der Testszene aus [Godot-Start](/combat/godot-start), passen 20 Tiles nebeneinander und 11 volle übereinander. Beide Werte sind Platzhalter; deine Auflösung und deine Tilegröße legst du mit deiner Grafik fest ([Pixelraster und Skalierung](/godot/pixelraster)). + + Daraus folgen drei Dinge, die den ganzen Kurs begleiten: + + - **Der Bildschirm ist die Einheit.** Ein Hinweis, der nicht im Bild ist, existiert für den Spieler nur als Erinnerung. Ein Abschnitt aus drei Bildschirmen ist bei 90 Pixeln pro Sekunde in elf Sekunden durchquert. + - **Der Blick voraus ist kurz und ungleich.** Hält die Kamera die Figur in der Mitte, sieht der Spieler nach rechts 160 Pixel voraus, nach oben nur 90. Wer im Breitbild nach oben läuft, sieht Hindernisse also später. Mit Drag-Rändern und Glättung läuft die Kamera in Godot der Figur sogar etwas hinterher; soll sie vorausschauen, verschiebt ein kleines Skript ihren `offset` in Laufrichtung ([Camera2D, offset](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-offset)). Welche Kamera du willst, ist eine Designentscheidung. + - **Die 3/4-Ansicht verdeckt.** Die meisten Top-down-Spiele zeigen Wände von vorn und Dächer von oben. Was hinter einer hohen Wand oder unter einem Dach liegt, ist unsichtbar, obwohl es im Bildausschnitt liegt. Wie diese Ansicht gezeichnet wird, steht in [Grundkörper, Perspektive und Draufsicht](/pixelart/grundkoerper-raum). + + > [!NOTE] Rechnen, um zu sehen + > Die kleinen Rechnungen in den Übungen sind keine Mathematik um ihrer selbst willen. Sie zeigen dir, wie viel ein Bildschirm fasst und wie lange ein Weg dauert, bevor du auch nur ein Tile setzt. + + ## Ein veröffentlichtes Level lesen: die Methode + + Du lernst Level-Design schneller, wenn du fremde Level liest, bevor du eigene baust. Lesen heißt dabei nicht, einen Eindruck zu haben, sondern eine Stelle so genau zu beschreiben, dass ein anderer sie nachvollziehen kann. Die Methode hat sechs Schritte: + + 1. **Einmal unvorbereitet spielen.** Danach sofort notieren, wo du entlanggegangen bist. Das geht nur einmal: Beim zweiten Mal kennst du die Stelle. + 2. **Noch einmal ansehen und skizzieren.** Auf Karopapier, ein Kästchen pro Tile, mit einem Rahmen von 20 × 11 Kästchen für einen Bildschirm. Videos darfst du anhalten. + 3. **Hinweise markieren.** Alles, was den Blick oder den Weg gelenkt hat: Licht, Kontrast, Wege, Öffnungen, Bewegung, Gegenstände. + 4. **Gesehenes und Gedeutetes trennen.** Mehr dazu im nächsten Abschnitt. + 5. **Die vermutete Absicht in einem Satz.** Was soll der Spieler hier tun oder bemerken? + 6. **Gegenprüfen.** Mit einer Entwicklerquelle, etwa einem Vortrag im [GDC Vault](https://gdcvault.com/) oder einem Postmortem, oder mit dem Weg eines zweiten Spielers, dem du nichts erklärst. + + Gute Stellen für den Anfang sind kurze Abschnitte von einem bis drei Bildschirmen: der erste Raum eines Dungeons, eine Kreuzung in einem Dorf, ein Raum vor einer Begegnung. Ganze Level sind für den Anfang zu groß. + + > [!PRAXIS] Nintendo baut auf einem bekannten Level auf + > Für A Link Between Worlds (2013) suchte das Zelda-Team eine Ansicht, in der das neue Eintreten der Figur in Wände wirkt. Eiji Aonuma erzählt: „we considered placing the camera directly overhead and fixing it there, and we made a test version.“ Als das passte, schlug er vor, „that we should use the landforms from A Link to the Past instead of starting from scratch“, und übertrug das Gelände des Vorgängers selbst in 3D ([Iwata Asks, Teil 3](https://www.nintendo.com/en-gb/Iwata-Asks/Iwata-Asks-The-Legend-of-Zelda-A-Link-Between-Worlds/The-Legend-of-Zelda-A-Link-Between-Worlds/3-Direct-Top-down-View/3-Direct-Top-down-View-831979.html)). Zuerst prüfte eine spielbare Testfassung die Idee, dann diente ein Level, das alle kannten, als Grundlage. + + ## Gesehenes und Gedeutetes trennen + + „Die Laterne lockt den Spieler zum Tor“ klingt wie eine Beobachtung, ist aber eine Deutung. Beobachtet hast du zweierlei: Die Laterne ist das hellste Objekt im Bild, und du bist zum Tor gegangen. Dass das eine das andere bewirkt hat, ist eine Vermutung. Sie kann stimmen. Aber solange du sie nicht als Vermutung notierst, prüfst du sie nie. + + Dieselbe Trennung brauchst du beim Zusehen. „Der Spieler war verwirrt“ ist eine Deutung. „Er blieb zwölf Sekunden am Brunnen stehen und ging dann zurück“ ist eine Beobachtung. Eine Kamera könnte sie aufnehmen. Valve hat das 2009 in seinen Folien zum Playtesting so zusammengefasst: „Importance of what people do—not what they say“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Was jemand sagt, hilft trotzdem. Die Nielsen Norman Group beschreibt das laute Denken, bei dem Testpersonen „continuously thinking out loud“ spielen oder arbeiten, als billiges und robustes Werkzeug ([Thinking Aloud](https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/)). Auch dort ist das Gesagte eine Beobachtung und die Ursache eine Deutung. Wie man solche Protokolle führt, behandelt [Testlesen und Playtest](/narrative/testlesen-playtest); was speziell bei Leveln wichtig ist, [Playtests beobachten](/level-design/playtest-methode). + + Ein Prüfsatz hilft: Könnte eine Kamera das aufnehmen? Wenn nein, gehört es in die Spalte „gedeutet“. + + ## Die Absichtsnotiz + + Für eigene Abschnitte drehst du die Methode um. Statt eine Absicht zu vermuten, schreibst du sie vorher auf, zusammen mit dem, woran du beim Zusehen merkst, ob sie eintritt. Die Notiz hat in diesem Kurs immer dieselbe Form: + + ```text + Abschnitt: + Absicht (ein Satz): + Der Spieler soll … + Erwarteter Weg: + Hinweise (wo, was, wofür): + Zeichen, dass es klappt: + Zeichen, dass es scheitert: + ``` + + Die letzten beiden Zeilen sind die wichtigsten. „Der Gang soll geheimnisvoll wirken“ ist ein Ziel, aber kein Zeichen. „Der Spieler wird am Seitengang langsamer oder schaut hinein“ kannst du auf einem Video abhaken. Ausführlich übst du die Notiz in [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze). Eine Skizze ersetzt dabei nie den Test. Das Level Design Book warnt: „A layout is NOT a level, the player never plays your drawing.“ ([Layout](https://book.leveldesignbook.com/process/layout)) + + > [!NOTE] Deine Absicht, deine Entscheidung + > Was in der Notiz steht, entscheidest du. Eine KI darf dir später Skripte schreiben, etwa einen Wegschreiber für Playtests. Layouts, Orte und Absichten für dein Spiel lässt du dir nicht erzeugen: Dann würdest du die Lücke zwischen Absicht und Verhalten an einem fremden Entwurf studieren. + + > [!INTERVIEW] „Wie analysierst du ein Level?“ + > Ich spiele die Stelle einmal unvorbereitet und notiere sofort meinen Weg. Dann skizziere ich sie im Raster, markiere jeden Hinweis und trenne, was zu sehen war, von dem, was ich daraus geschlossen habe. Am Ende steht die vermutete Absicht in einem Satz, und den prüfe ich gegen eine Entwicklerquelle oder gegen den Weg eines zweiten Spielers. + + ## Häufige Fehler + + - **Ein Gefühl als Absicht.** „Soll spannend sein“ lässt sich nicht beobachten. Schreib dazu, woran du Spannung beim Zusehen erkennen würdest, oder wähl eine andere Absicht. + - **Hinweis gleich Wirkung.** „Ich habe eine Laterne hingestellt, also gehen sie hin.“ Ob sie hingehen, zeigt erst der Test. + - **Nach dem eigenen Spielen urteilen.** Du kennst jeden Weg und jede Absicht. Dein eigener Durchgang zeigt dir Fehler in der Technik, nicht ob andere die Hinweise lesen. + - **Ein Standbild statt eines Wegs.** Ein Screenshot zeigt Komposition, aber nicht, wann der Spieler was sieht. Ein Level wird über die Zeit gespielt. + - **Kopieren statt verstehen.** Wer einen gelungenen Raum nachbaut, ohne die Absicht dahinter zu kennen, übernimmt die Form und verliert den Grund. + + ## Zusammenfassung + + - Ein Level ist ein Raum mit Absicht. Gut ist er, wenn das Verhalten der Spieler zur Absicht passt, nicht wenn er schön ist. + - Absicht (Kopf), Hinweis (Raum), Verhalten (Spieler): Gestalten kannst du nur Hinweise, prüfen nur am Verhalten. + - In der Draufsicht ist der Bildschirm die Einheit: 20 × 11 Tiles bei 320 × 180 Pixeln und 16-Pixel-Tiles, als Platzhalter. + - Der Blick voraus ist kurz, nach oben und unten kürzer als zur Seite. Hohe Wände und Dächer verdecken auch im Bildausschnitt. + - Fremde Level liest du in sechs Schritten: unvorbereitet spielen, skizzieren, Hinweise markieren, Gesehenes und Gedeutetes trennen, Absicht vermuten, gegenprüfen. + - Eine Absichtsnotiz nennt die Absicht in einem Satz und beobachtbare Zeichen für Erfolg und Scheitern. +exercises: + - id: was-ist-verhalten + type: choice + title: Was hast du beobachtet? + prompt: | + Lehrbeispiel: Ein Hof mit drei Ausgängen. Welche Aussagen beschreiben **Verhalten**, also etwas, das du beim Zusehen beobachten kannst? + options: + - text: Drei von vier Testern gingen zuerst zum Tor mit der Laterne. + correct: true + why: Das ist gezählt, was Spieler getan haben. Ob die Laterne der Grund war, sagt die Aussage nicht, und das ist richtig so. + - text: Ein Tester blieb zwölf Sekunden am Brunnen stehen und lief dann zurück zum Eingang. + correct: true + why: Ort, Dauer und Richtung sind beobachtbar. Was er dabei dachte, steht nicht drin. + - text: Die Laterne am Tor ist das hellste Objekt im Bild. + correct: false + why: Das beschreibt den Raum, also einen Hinweis. Ob jemand darauf reagiert, ist eine andere Frage. + - text: Die Spieler sollen das Tor als Weg nach draußen erkennen. + correct: false + why: Das ist die Absicht. Sie steht im Kopf des Designers, nicht im Spiel, und lässt sich nur über Verhalten prüfen. + - text: Der Tester war am Brunnen verwirrt. + correct: false + why: Verwirrung ist eine Deutung. Beobachtet hast du, dass er stehen blieb und umkehrte. Er kann auch gesucht, gelesen oder sich umgesehen haben. + explanation: | + Absicht, Hinweis und Verhalten liegen an drei verschiedenen Orten: im Kopf, im Raum und beim Spieler. Nur Hinweise kannst du direkt bauen, nur Verhalten kannst du beobachten. Wer Deutungen wie „verwirrt“ als Beobachtung notiert, legt sich auf eine Ursache fest, bevor er sie geprüft hat. + hints: + - Frag bei jeder Aussage, ob eine Kamera sie aufnehmen könnte. + - Zwei Aussagen sind richtig. + resources: + - title: "Nielsen Norman Group, „Thinking Aloud: The #1 Usability Tool“" + url: https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/ + + - id: hinweis-oder-absicht + type: choice + title: Die Laterne am Tor + prompt: | + Lehrbeispiel: In deinem Hof hängt am Tor eine Laterne, sonst ist es dunkel. Vier von vier Testern gehen zuerst zum Tor. Was darfst du daraus schließen? + options: + - text: Die Absicht „zuerst zum Tor“ ist in diesem Test erreicht. Ob die Laterne der Grund war, weißt du noch nicht. + correct: true + why: Das Verhalten passt zur Absicht. Für die Ursache kommen auch der Weg vom Eingang, die Form des Hofs oder Gewohnheit infrage. + - text: Die Laterne funktioniert. Sie zieht Spieler zum Tor. + correct: false + why: Das ist eine Deutung. Liegt das Tor direkt gegenüber dem Eingang, wären die Tester vielleicht auch ohne Laterne hingegangen. + - text: Die Absicht ist bewiesen und gilt für alle Spieler. + correct: false + why: Vier Tester sind vier Beobachtungen. Sie zeigen, dass die Stelle nicht offensichtlich scheitert, aber keine Regel für alle. + - text: Nichts, weil die Tester nicht gesagt haben, warum sie zum Tor gegangen sind. + correct: false + why: Verhalten ist eine Beobachtung, auch ohne Begründung. Was Spieler sagen, ergänzt das Verhalten, ersetzt es aber nicht. + explanation: | + Ein Test prüft zuerst, ob das Verhalten zur Absicht passt. Welcher Hinweis es ausgelöst hat, ist eine zweite Frage. Die beantwortest du, indem du eine Sache änderst, etwa die Laterne an einen anderen Ausgang hängst, und mit neuen Testern wieder zusiehst. Wie das geht, zeigt [Überarbeiten](/level-design/ueberarbeiten). + hints: + - Welche anderen Gründe könnte es geben, zum Tor zu gehen? + resources: + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + + - id: level-lesen-schritte + type: order + title: Einen fremden Abschnitt lesen + prompt: | + Du willst einen kurzen Abschnitt eines veröffentlichten Top-down-Spiels lesen. Bring die Schritte in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Spiel den Abschnitt einmal ohne Vorsatz und notier danach aus dem Gedächtnis, wo du entlanggegangen bist. + Sieh dir die Stelle noch einmal an und skizzier sie auf Karopapier, ein Kästchen pro Tile. + Markier in der Skizze alles, was deinen Blick oder deinen Weg gelenkt hat. + Trenn deine Notizen in das, was zu sehen war, und das, was du daraus geschlossen hast. + Schreib die vermutete Absicht des Abschnitts in einem Satz auf. + Vergleich den Satz mit einer Entwicklerquelle oder mit dem Weg eines zweiten Spielers. + explanation: | + Der erste Durchgang ist der einzige, in dem du den Abschnitt nicht kennst. Deshalb notierst du deinen Weg sofort und vor jeder Analyse. Die Skizze macht aus Bildern einen Raum mit Maßen. Erst danach suchst du Hinweise, trennst Beobachtung von Deutung und formulierst die Absicht. Der Vergleich am Ende zeigt, ob deine Deutung mehr ist als dein eigener Eindruck. + hints: + - Was geht nur ein einziges Mal? + resources: + - title: The Level Design Book · Critical path + url: https://book.leveldesignbook.com/process/layout/criticalpath + + - id: bildschirm-in-tiles + type: output + title: Ein Bildschirm in Tiles + prompt: | + Spielbild 320 × 180 Pixel, Tiles 16 × 16 (beides Platzhalter). Was gibt das Modell aus? + lang: python + code: | + BILD_B, BILD_H = 320, 180 + TILE = 16 + + quer = BILD_B // TILE + hoch = BILD_H // TILE + rest = BILD_H % TILE + print(quer, hoch, rest) + expected: | + 20 11 4 + hints: + - "`//` teilt ganzzahlig, `%` liefert den Rest." + - 11 × 16 = 176. + explanation: | + Quer passen genau 20 Tiles, hoch 11 volle und ein Streifen von 4 Pixeln. Ein Bildschirm ist also 20 × 11 Tiles groß, und je nach Kameraposition schaut oben oder unten ein Viertel einer zwölften Reihe herein. Für Skizzen auf Karopapier heißt das: Ein Rahmen von 20 × 11 Kästchen ist ein Bildschirm. + resources: + - title: Godot Docs · Multiple resolutions + url: https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html + + - id: quer-ueber-den-bildschirm + type: output + title: Wie lange ist ein Bildschirm? + prompt: | + Die Figur läuft mit 90 Pixeln pro Sekunde (Platzhalter aus [Godot-Start](/combat/godot-start)). Was gibt das Modell aus? Das erste Ergebnis ist ein Bildschirm quer, das zweite ein Abschnitt aus drei Bildschirmen nebeneinander. + lang: python + code: | + BILD_B = 320 + TEMPO = 90 # Pixel pro Sekunde + + eins = BILD_B / TEMPO + drei = 3 * eins + print(round(eins, 1), + round(drei, 1)) + expected: | + 3.6 10.7 + hints: + - 320 / 90 ist etwas mehr als 3,5. + explanation: | + Ein Bildschirm quer dauert gut dreieinhalb Sekunden, drei Bildschirme knapp elf. Ein „kurzer Abschnitt“ ist im Spiel also wirklich kurz. Diese Zahlen helfen dir später beim Rhythmus: Was in elf Sekunden passieren soll, muss auf drei Bildschirme passen. Mit deinem eigenen Tempo kommen andere Werte heraus. + resources: + - title: Python · round() + url: https://docs.python.org/3/library/functions.html#round + + - id: vorlauf-nach-oben + type: output + title: Wie früh siehst du, was kommt? + prompt: | + Die Kamera hält die Figur in der Bildmitte, Spielbild 320 × 180, Tempo 90 Pixel pro Sekunde (Platzhalter). Etwas erscheint am Bildrand, sobald es einen halben Bildschirm entfernt ist. Wie viele Sekunden vorher siehst du es, wenn du nach rechts und wenn du nach oben läufst? Was gibt das Modell aus? + lang: python + code: | + BILD_B, BILD_H = 320, 180 + TEMPO = 90 # px/s, Platzhalter + + rechts = (BILD_B / 2) / TEMPO + oben = (BILD_H / 2) / TEMPO + print(round(rechts, 1), + round(oben, 1)) + expected: | + 1.8 1.0 + hints: + - Ein halber Bildschirm ist 160 Pixel breit und 90 Pixel hoch. + explanation: | + Nach rechts reicht der Blick 160 Pixel, das sind knapp zwei Sekunden Vorlauf. Nach oben sind es 90 Pixel und genau eine Sekunde. Im Breitbild siehst du beim Laufen nach oben oder unten also deutlich weniger voraus. Was dort hinter dem Bildrand wartet, braucht mehr Ankündigung, eine langsamere Annäherung oder eine Kamera, die in Laufrichtung vorausschaut. In Godot verschiebt dafür ein kleines Skript den `offset` der Kamera ([Camera2D, offset](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-offset)). + resources: + - title: Godot Docs · Camera2D, offset + url: https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-offset + + - id: begriffe-grundmodell + type: gap + title: Drei Ebenen und ein Rahmen + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Was der Designer erreichen will, ist die ⟦Absicht⟧. Was im Raum steht, um das zu bewirken, etwa Licht, ein Weg oder eine Landmarke, ist ein ⟦Hinweis⟧. Was Spieler tatsächlich tun, ist ihr ⟦Verhalten⟧. In der Draufsicht begrenzt der ⟦Bildschirm⟧ alles, was der Spieler gerade sehen kann. + gaps: + - label: im Kopf + hint: Das Ziel des Designers, in einem Satz. + accept: ["Designabsicht", "Ziel"] + - label: im Raum + hint: Englisch oft „cue“. + accept: ["Cue", "Signal", "Hinweise"] + - label: beim Spieler + hint: Das, was du beim Zusehen beobachtest. + accept: ["Spielerverhalten"] + - label: der Rahmen + hint: Bei 320 × 180 Pixeln sind es 20 × 11 Tiles. + accept: ["Bildausschnitt", "Ausschnitt", "Kamerabild"] + explanation: | + Absicht, Hinweis und Verhalten sind das Grundmodell dieses Kurses. Gestalten kannst du nur die Hinweise, prüfen nur am Verhalten. Der Bildschirm ist in der Draufsicht der Rahmen, in dem jeder Hinweis wirken muss: Was nicht im Bild ist, kennt der Spieler nur aus der Erinnerung. + + - id: deutung-im-protokoll + type: bug + title: Eine Zeile zu viel gewusst + prompt: | + Lehrbeispiel: Notizen, nachdem du einen Freund den Hof aus dem Lehrbeispiel hast spielen sehen. Eine Zeile notiert eine Deutung, als wäre sie beobachtet. Finde sie. + lang: prose + code: | + 0:05 betritt den Hof von unten + 0:09 läuft geradeaus bis zum Brunnen + 0:11 bleibt am Brunnen stehen, die Figur zeigt nach links + 0:23 ist unsicher, wohin es weitergeht + 0:24 läuft zum Durchgang rechts oben + 0:31 kommt zurück und geht zum Tor + lines: [4] + explanation: | + „Unsicher“ steht nirgends im Bild. Beobachtet hast du nur zwölf Sekunden ohne Bewegung am Brunnen. Er kann unsicher gewesen sein, aber auch den Brunnen betrachtet, eine Nachricht auf dem Handy gelesen oder überlegt haben, welchen Durchgang er zuerst nimmt. Schreib „0:11–0:23 steht still am Brunnen“ und die Deutung, wenn du willst, getrennt daneben. Wie man Beobachtung und Deutung in Protokollen trennt, zeigt [Testlesen und Playtest](/narrative/testlesen-playtest). + hints: + - Welche Zeile könnte eine Kamera nicht aufnehmen? + + - id: absicht-nicht-pruefbar + type: bug + title: Woran merkst du das? + prompt: | + Lehrbeispiel: eine Absichtsnotiz für einen kurzen Gang mit einer Abzweigung. Eine Zeile lässt sich beim Zusehen nicht prüfen. Finde sie. + lang: prose + code: | + Abschnitt: Gang mit Abzweigung, zwei Bildschirme + Absicht (ein Satz): Der Spieler soll den Seitengang bemerken, aber zuerst geradeaus gehen. + Erwarteter Weg: geradeaus bis zur Tür, danach zurück in den Seitengang + Hinweise (wo, was, wofür): Licht am Ende des Gangs, Fundstück halb sichtbar im Seitengang + Zeichen, dass es klappt: Der Gang soll sich geheimnisvoll anfühlen. + Zeichen, dass es scheitert: Der Spieler läuft am Seitengang vorbei und kommt nicht zurück. + lines: [5] + explanation: | + „Geheimnisvoll anfühlen“ ist ein Gefühl, kein Zeichen. Beobachten könntest du etwa, dass der Spieler am Seitengang langsamer wird, kurz hineinschaut oder später zurückkommt. Ein Gefühl darfst du als Ziel haben; in die Notiz gehört, woran du beim Zusehen merkst, dass es eintritt. Zeile 6 dagegen ist beobachtbar und deshalb brauchbar. + hints: + - Vergleich die Zeilen 5 und 6. Welche könntest du auf einem Video abhaken? + + - id: hof-lesen + type: explain + title: Vier Durchgänge, ein Hof + prompt: | + Lehrbeispiel: ein Hof als Rasterkarte, ein Zeichen pro Tile. Der Spieler kommt bei `S` herein. Erkläre in drei bis fünf Sätzen, welcher Durchgang die meisten Spieler zuerst anziehen dürfte, welche Hinweise dafür sprechen und was du beobachten müsstest, um deine Vermutung zu prüfen. + + Legende: `#` Wand, `.` Boden, `o` Brunnen (niedrig), `+` Durchgang, `!` Laterne, `S` Start + lang: text + code: | + ####+############### + #..................# + #..................+ + #........o.........# + #..................# + #.................!# + +..................+ + #..................# + #..................# + #########S########## + points: + - Der Hof hat vier Durchgänge, oben links, links unten und zwei rechts. + - Die Laterne steht neben dem unteren rechten Durchgang und macht ihn zum auffälligsten Punkt im Bild. + - Der Brunnen steht genau auf der Linie vom Eingang nach oben und nimmt dem Weg geradeaus das Ziel. + - Prüfen würdest du das am ersten Durchgang, den Tester ohne Erklärung nehmen, und an Halten oder Umkehren unterwegs. + explanation: | + Der Hof hat vier Durchgänge: einen oben links, einen links unten und zwei rechts. Am unteren rechten hängt die Laterne, das einzige Licht im Bild, und vermutlich gehen die meisten Spieler dorthin. Der Brunnen steht genau in der Achse vom Eingang nach oben. Er nimmt dem Weg geradeaus die Richtung und macht die Laterne als nächsten Punkt noch auffälliger. Prüfen kannst du das nur im Test: welchen Durchgang Tester zuerst nehmen, ob sie am Brunnen halten und ob jemand nach dem ersten Durchgang umkehrt. Ob dieser Hof gut ist, hängt an der Absicht. Soll der Spieler oben links hinaus, arbeitet die Laterne gegen dich. + hints: + - Zähl zuerst die Ausgänge und such dann das Einzige, das anders ist als alles andere. + + - id: was-nicht-wie + type: explain + title: Was, aber nicht wie + prompt: | + Dan Taylor, Level-Designer bei Square Enix Montreal, hat 2013 zehn Prinzipien guten Level-Designs vorgestellt. Hier der Titel des dritten Prinzips, ein Satz aus seiner Erläuterung zum ersten und einer aus der zum dritten. Erkläre in drei bis fünf Sätzen, was er meint, wie das zu Absicht, Hinweis und Verhalten passt und wo die Grenze liegt. + lang: prose + code: | + Good level design tells the player what to do, but not how to do it. + + Careful layout, lighting, signage and other visual cues should create a natural “flow” to the level that guides the player instinctively through it. + + the player must never be in any doubt as to what their objective is. + points: + - Das Ziel („what“) soll klar sein, der Weg dorthin („how“) bleibt die Entscheidung des Spielers. + - Layout, Licht und Zeichen sind Hinweise. Sie führen, ohne den Weg vorzuschreiben. + - Ob die Führung „instinctively“ wirkt, zeigt nur das Verhalten der Spieler, nicht der Entwurf. + - Die Grenze ist das Ziel selbst. Über das Ziel darf kein Zweifel bestehen, über den Weg schon. + explanation: | + Taylor trennt Ziel und Weg. Der Spieler soll wissen, was er erreichen will, etwa „hinaus aus dem Hof“, aber selbst herausfinden, wie. Das passt zum Grundmodell: Die Absicht legt das Ziel fest, die Hinweise im Raum machen es lesbar, und das Verhalten zeigt, ob die Führung so selbstverständlich wirkt, wie er es fordert. Die Grenze steht im letzten Satz. Unklarheit über den Weg kann Entdecken sein, Unklarheit über das Ziel ist ein Fehler im Level. Das schließt Geheimnisse nicht aus: Taylor hält versteckte Bereiche ausdrücklich für richtig, solange es Hinweise darauf gibt. + hints: + - Lies „what“ als Ziel und „how“ als Weg. + - Welche Ebene des Grundmodells beschreibt „instinctively“? + resources: + - title: Dan Taylor, „Ten Principles of Good Level Design“, Teil 1 (Game Developer, 2013) + url: https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1- + - title: Dan Taylor, „Ten Principles for Good Level Design“ (GDC 2013, Video) + url: https://www.youtube.com/watch?v=iNEe3KhMvXM + + - id: abschnitt-lesen + type: practice + title: Ein Abschnitt auf Karopapier + prompt: | + Nimm einen kurzen Abschnitt aus einem veröffentlichten Top-down-Spiel, das du spielst. Skizzier ihn auf Karopapier, ein Kästchen pro Tile, und füll die Notiz aus. Das Foto der Skizze bleibt bei dir; hier schreibst du nur die Notiz. + lang: prose + starter: | + Spiel und Stelle: + Mein Weg beim ersten Spielen: + Hinweise (Ort, Art): + Gesehen: + Gedeutet: + Vermutete Absicht (ein Satz): + checklist: + - Die Skizze hat einen Rahmen, der zeigt, wie viel davon auf einen Bildschirm passt. + - Dein Weg beim ersten Spielen steht drin, aus dem Gedächtnis notiert. + - Mindestens drei Hinweise sind mit Ort und Art genannt. + - Unter „Gesehen“ steht nur, was eine Kamera aufnehmen könnte. + - Die vermutete Absicht ist ein Satz und nennt ein beobachtbares Verhalten. + explanation: | + Diese Notiz ist die Grundform jeder Analyse in diesem Kurs. Später schreibst du dieselbe Notiz vor dem Bauen für deine eigenen Abschnitte, nur heißt die letzte Zeile dann „Absicht“ statt „vermutete Absicht“. Wenn du dieselbe Stelle in ein paar Wochen noch einmal liest, siehst du, wie sich dein Blick verändert hat. + hints: + - Für Maße zählst du Schritte oder vergleichst mit der Größe der Figur. Genau muss es nicht sein. + resources: + - title: The Level Design Book · Layout + url: https://book.leveldesignbook.com/process/layout + + - id: erster-blick + type: practice + title: Wohin ging dein Blick? + prompt: | + Öffne ein Top-down-Spiel, das du noch nicht kennst, oder ein Video davon, das du noch nicht gesehen hast. Halt das erste Bild an, das einen neuen Raum zeigt. Notier, wohin dein Blick zuerst ging, dann zweitens, dann drittens, und vermute je einen Grund. + lang: prose + starter: | + Spiel, Stelle: + 1. Blick: + 2. Blick: + 3. Blick: + Wohin würde ich zuerst gehen: + checklist: + - Drei Blickpunkte in der Reihenfolge, in der du sie bemerkt hast. + - Zu jedem Punkt steht ein möglicher Grund (Helligkeit, Farbe, Bewegung, Form, Lage im Bild). + - Du nennst den Ort, zu dem du zuerst gehen würdest, und ob er einer deiner Blickpunkte ist. + explanation: | + Der erste Blick ist schnell und lässt sich nicht wiederholen. Deshalb hältst du ihn sofort fest. Die Gründe sind Vermutungen; welche Mittel den Blick wirklich lenken, behandelt [Komposition und Blickführung](/level-design/blickfuehrung). Liegt der Ort, zu dem du gehen würdest, nicht unter deinen Blickpunkten, hat dich etwas anderes gelenkt, etwa ein Weg oder eine Gewohnheit aus anderen Spielen. + hints: + - Video anhalten genügt. Der Rest geht ohne Spiel. diff --git a/content/level-design/modules/rhythmus.yaml b/content/level-design/modules/rhythmus.yaml new file mode 100644 index 0000000..c81d427 --- /dev/null +++ b/content/level-design/modules/rhythmus.yaml @@ -0,0 +1,495 @@ +id: rhythmus +title: Rhythmus aus Bewegung, Beobachtung, Entdeckung und Begegnung +level: 2 +minutes: 90 +summary: Wie ein Abschnitt zwischen Anspannung und Ruhe wechselt – Takte benennen und als Taktplan in Textform notieren, ihre Mindestdauer aus Weglänge und Tempo rechnen, Aussicht vor der Freifläche und Ruhe danach setzen und Monotonie erkennen, am AI Director von Left 4 Dead, an Portal und am Level Design Book. +place: unterwegs +goals: + - Du zerlegst einen Abschnitt in Takte der Arten Bewegung, Beobachtung, Entdeckung, Begegnung und Ruhe und notierst sie als Taktplan in Textform. + - Du rechnest die Mindestdauer eines Takts aus Weglänge in Tiles und Tempo und findest die längste Strecke ohne Ruhe. + - Du nennst die vier Phasen des AI Director von Left 4 Dead und erklärst, was ein handgebauter Abschnitt davon übernehmen kann und was nicht. + - Du setzt einen Aussichtspunkt vor eine Freifläche und begründest ihn mit Sichtlinie und Bildausschnitt, nicht mit einem angeborenen Sicherheitsgefühl. + - Du erkennst Monotonie in einem Taktplan und benennst, wo ein Kontrast in Art oder Intensität fehlt, ohne den Inhalt vorzugeben. +resources: + - title: Michael Booth, „The AI Systems of Left 4 Dead“ (Valve, 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf + - title: The Level Design Book · Pacing + url: https://book.leveldesignbook.com/process/preproduction/pacing + - title: The Level Design Book · Prospect-refuge + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge + - title: Kim Swift, Erik Wolpaw, „Integrating Narrative and Design – A Portal Post-Mortem“ (GDC 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf + - title: Christopher W. Totten, „Designing Better Levels Through Human Survival Instincts“ (Game Developer, 2011) + url: https://www.gamedeveloper.com/design/designing-better-levels-through-human-survival-instincts +lesson: | + Lehrbeispiel: Ein Abschnitt aus drei Bildschirmen. Ein Gang, ein Raum mit Gegnern, ein Gang, ein Raum mit Gegnern, ein Gang, ein Raum mit Gegnern. Im Test funktioniert jeder Raum für sich: Die Tester finden den Eingang, nutzen die Fläche und finden den Ausgang. Trotzdem werden sie im dritten Raum schneller und nachlässiger, und einer sagt: „Schon wieder.“ Kein Raum ist kaputt. Die Folge ist es. + + Rhythmus ist die Ordnung eines Abschnitts in der Zeit: was nacheinander passiert, wie lange es dauert und wo der Spieler Luft holt. Dieses Modul zeigt, wie du einen Abschnitt in Takte zerlegst, sie als Taktplan in Textform notierst, ihre Dauer aus Weglänge und Tempo abschätzt und Aussicht, Ruhe und Kontrast bewusst setzt. Begegnungen kommen hier nur als Raum und als Takt vor. Was in ihnen passiert, ist Combat Design ([Gegnermuster](/combat/gegnermuster), [Große Kreaturen als Bosse](/combat/grosse-gegner)). + + ## Takte: woraus ein Abschnitt in der Zeit besteht + + Das Level Design Book definiert: „Pacing is the general order and rhythm of activities and events in a level.“ Die kleinste Einheit nennt es Beat: „A beat is a small self-contained chunk of a level. A single area, event, activity, or element.“ ([Pacing](https://book.leveldesignbook.com/process/preproduction/pacing#beats-and-variation)). In diesem Kurs heißt ein Beat **Takt**. + + Valve hat für Half-Life 2: Episode Two und Left 4 Dead Takte in vier Arten sortiert: Explore, Combat, Choreo und Puzzle. Das Buch fügt hinzu: „For each project, you must devise your own categories and metrics.“ ([Pacing, Graph](https://book.leveldesignbook.com/process/preproduction/pacing#graph)). Für ein Top-down-Spiel mit Erkundung arbeitet dieser Kurs mit fünf Arten: + + | Art | Was der Spieler tut | Lehrbeispiel | + | --- | --- | --- | + | Bewegung | geht von A nach B, ohne neue Aufgabe | Gang zwischen zwei Höfen | + | Beobachtung | bekommt einen Überblick oder sieht ein Ziel | Treppenabsatz über einem Hof | + | Entdeckung | findet etwas abseits des Hauptwegs | Nische mit Fundstück | + | Begegnung | muss mit einer Gefahr umgehen | Freifläche mit Gegnern | + | Ruhe | nichts verlangt etwas von ihm | Raum ohne Gefahr am Ende eines Wegs | + + Die Arten sind ein Werkzeug, keine Vorschrift. Brauchst du für dein Spiel andere, leg sie fest und bleib dabei. + + Zu jedem Takt gehört eine **Intensität**, also wie viel Aufmerksamkeit er verlangt. Unter den Fragen, die ein Plan beantworten soll, nennt das Buch: „When should the player pay more attention, and when do they rest and recover?“ Zugleich warnt es: „The intensity score is just a gut feeling that emerges from knowing the game and observing playtests. It's not a hard science.“ Eine Intensität von 0 bis 5 ist also eine Schätzung, die du im Playtest prüfst. + + ## Der Taktplan als Text + + Das Buch nennt mehrere Formen, Takte festzuhalten, darunter eine Liste („Beat sheet, simple text list of beats“) und ein Balkendiagramm der Intensität über die Zeit ([Plotting and documentation](https://book.leveldesignbook.com/process/preproduction/pacing#plotting-and-documentation)). In diesem Kurs heißt so eine Liste **Taktplan** (englisch oft beat chart oder, im Level Design Book, beat sheet). Am Handy passt beides in einen Textblock: eine Zeile pro Takt, die Weglänge in Tiles, die geschätzte Intensität als Zahl und als Balken. + + ```text + Nr Art Tiles Int. + 1 Bewegung 30 1 = + 2 Beobachtung 6 2 == + 3 Begegnung 12 4 ==== + 4 Ruhe 8 0 + 5 Entdeckung 14 2 == + 6 Bewegung 25 1 = + ``` + + Lies den Plan von oben nach unten wie eine Melodie. Wo stehen die Spitzen? Wie viele Takte liegen zwischen zwei Spitzen? Folgen zwei gleiche Arten aufeinander? Wo ist die längste Strecke ohne Ruhe? Diese Fragen beantwortest du, bevor du ein Tile gesetzt hast. Ob die Antworten stimmen, zeigt erst der Test. + + > [!NOTE] Dein Plan + > Welche Takte dein Abschnitt hat und in welcher Reihenfolge, entscheidest du. Eine KI darf dir ein kleines Skript schreiben, das aus deinem Plan Zeiten rechnet. Den Plan selbst lässt du dir nicht vorschlagen. + + ## Dauer aus Weglänge und Tempo + + In der Draufsicht kannst du die Dauer eines Bewegungstakts aus der Skizze ablesen. Die Platzhalter der Testszene aus [Godot-Start](/combat/godot-start) sind Tiles mit 16 Pixeln und ein Tempo von 90 Pixeln pro Sekunde. Ein Tile dauert dann 0,18 Sekunden, ein Bildschirm quer (20 Tiles) 3,6 Sekunden. Deine echten Werte legst du selbst fest. + + ```python run + TILE = 16 # px, Platzhalter + TEMPO = 90 # px/s, Platzhalter + + def sekunden(tiles): + s = tiles * TILE / TEMPO + return round(s, 1) + + takte = [("Bewegung", 30), + ("Beobachtung", 6), + ("Begegnung", 12), + ("Ruhe", 8)] + for art, tiles in takte: + print(art, sekunden(tiles)) + ``` + + Der Gang mit 30 Tiles, anderthalb Bildschirme lang, dauert 5,3 Sekunden. Ein Weg, der auf dem Karopapier lang aussieht, ist im Spiel oft nach wenigen Sekunden vorbei. + + Für die anderen Arten liefert die Rechnung nur eine Untergrenze: die Zeit, die ein Spieler ohne Halt für den Weg braucht. Eine Begegnung auf 12 Tiles dauert nicht 2,1 Sekunden, und eine Nische mit Fundstück hält den Spieler länger, als der Weg hinein dauert. Diese Verweildauer misst du im Playtest ([Playtests beobachten](/level-design/playtest-methode)). Der Unterschied ist selbst ein Befund: Dauert ein Takt im Test viel länger als sein Weg, ist dort etwas passiert. + + > [!WARNING] Weglänge ist nicht Dauer + > Die Rechnung aus Tiles und Tempo stimmt nur für Bewegung ohne Halt. Für Beobachtung, Entdeckung, Begegnung und Ruhe ist sie die kürzeste mögliche Zeit. + + ## Anspannung und Ruhe: der AI Director von Left 4 Dead + + Michael Booth hat 2009 beschrieben, wie Left 4 Dead (Valve) Anspannung und Ruhe abwechselt ([The AI Systems of Left 4 Dead](https://cdn.akamai.steamstatic.com/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf)). Vorbild war Counter-Strike, dessen Pacing er „spiky“ nennt, „with periods of quiet tension punctuated by unpredictable moments of intense combat“. Zwei Zeilen seiner Folien fassen das Problem zusammen: „Constant, unchanging combat is fatiguing“ und „Long periods of inactivity are boring“. + + Das System, das Valve AI Director nennt, schätzt für jeden Spieler eine „Survivor Intensity“. Sie steigt, wenn der Spieler Schaden nimmt, kampfunfähig wird, von einer Kante gezogen wird oder wenn in seiner Nähe Gegner sterben. Mit der Zeit klingt sie ab. Daraus steuert der Director vier Phasen: + + - **Build Up:** volle Bedrohung, bis die Intensität die Spitze überschreitet. + - **Sustain Peak:** volle Bedrohung noch 3 bis 5 Sekunden nach der Spitze. + - **Peak Fade:** minimale Bedrohung, bis die Intensität aus dem Spitzenbereich abklingt. + - **Relax:** minimale Bedrohung für 30 bis 45 Sekunden oder bis die Spieler weit genug zum nächsten Safe Room gelaufen sind, dann wieder Build Up. + + Zwei Punkte aus den Folien zählen für handgebaute Abschnitte. Erstens: „Algorithm adjusts pacing, not difficulty“. Der Director macht die Spitzen nicht höher, er verteilt sie. Rhythmus und Schwierigkeit sind zwei verschiedene Größen. Zweitens hängt die Ruhe am Raum. Sie endet nach einer Zeit oder nach einer Strecke Richtung nächster sicherer Raum. + + Dein Abschnitt hat keinen Director. Du legst die Täler fest an Orte, und du kannst nicht messen, wie angespannt ein Spieler gerade ist. Übernehmen kannst du das Muster: Aufbau, Spitze, Abklingen, Ruhe, und die Ruhe an einen Ort gebunden. Booths 30 Sekunden Ruhe wären bei 90 Pixeln pro Sekunde über acht Bildschirme Weg. In einem Abschnitt von zwei bis vier Bildschirmen entsteht Ruhe deshalb selten durch Weglänge allein. Sie braucht einen Ort, an dem der Spieler stehen bleibt. + + Das Level Design Book gibt dieselbe Richtung als Rat: „Start slow and quiet.“ und „Alternate highs and lows.“ Wer zu lange auf hoher Intensität bleibt, stumpft ab, „otherwise the player will simply go numb“ ([Pacing advice](https://book.leveldesignbook.com/process/preproduction/pacing#pacing-advice)). + + > [!MERKE] Rhythmus ist Wechsel + > Ein Takt wirkt durch seine Nachbarn. Eine Spitze braucht ein Tal davor und danach, eine Ruhe braucht etwas, wovon sie ausruht. + + ## Aussicht vor der Freifläche, Ruhe danach + + Christopher W. Totten überträgt die Prospect-Refuge-Theorie aus der Architektur auf Level ([Game Developer, 2011](https://www.gamedeveloper.com/design/designing-better-levels-through-human-survival-instincts)). Prospect ist bei ihm „an open space where the player is exposed to threats and feels vulnerable“. Refuges sind geschützte Orte, von denen aus frühe Menschen in die offene Fläche schauen und Gefahren einschätzen konnten. Totten beschreibt Folgen aus Zuflucht, Freifläche und nächster Zuflucht. Die nächste Zuflucht zieht den Spieler voran: „Secondary Refuges can urge the occupant of a space forward“. Bossräume nennt er als Beispiel für Prospect-Räume. + + Das Level Design Book widerspricht: „This book argues that prospect-refuge, as traditionally understood, has limited application to level design.“ ([Prospect-refuge](https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge)). Es schlägt vor, statt von prospect von sightline und vista zu sprechen, statt von refuge von cover, enclosure oder safe house. Eine vista ist ein Aussichtspunkt mit vielen Sichtlinien, nützlich „especially for an arena layout before an encounter begins“. Sicherheit ist für das Buch kein Merkmal einer Form: „No shape or layout is intrinsically safe.“ Ein Raum wirkt sicher, weil das Spiel dort bisher nicht angegriffen hat, weil dort ein Speicherpunkt steht oder weil die Begegnung vorbei ist. + + Für deinen Taktplan folgen daraus zwei Bausteine, ohne Theorie über Instinkte: + + - **Aussicht vor der Freifläche.** Ein Beobachtungstakt direkt vor einer Begegnung zeigt dem Spieler die Fläche, bevor er sie betritt. In der Draufsicht ist das eine Kamerafrage. Steht die Figur am unteren Rand einer Freifläche und hält die Kamera sie mittig, sieht der Spieler nach oben nur gut 5 Tiles weit. Passt die Fläche ins Bild, solange er noch am Eingang steht? Was die Kamera zeigt, behandelt [Wege, Landmarken und Sichtlinien](/level-design/orientierung), wie groß eine Freifläche sein muss, [Maßstab, Dichte und Freiflächen](/level-design/massstab-dichte). + - **Ruhe nach der Spitze.** Ein Ort nach der Begegnung, an dem nichts verlangt wird. Ob er sich sicher anfühlt, hängt daran, was das Spiel dort bisher getan hat, nicht an seiner Form. + + Entdeckungen haben einen eigenen Rhythmus. Andrew Shouldice, Entwickler von Tunic, teilt das Lernen über ein Geheimnis in drei Phasen: „You start not knowing [something], that's the ignorance phase. And there's [the] knowledge [phase] where you know something exists, but you don't understand it.“ Danach folgt: „Understanding is closure.“ Laut dem Bericht von Game Developer interessiert ihn die mittlere Phase am meisten ([Game Developer, 2023](https://www.gamedeveloper.com/design/video-how-the-tunic-developers-built-a-mysterious-world)). Für den Taktplan heißt das: Eine Entdeckung kann über mehrere Takte reichen. Der Spieler sieht etwas in einem Beobachtungstakt und erreicht es erst Takte später. Dazwischen trägt die offene Frage den Abschnitt. + + ## Monotonie und Kontrast + + Monotonie hat zwei Formen. Die eine ist eine zu lange Spitze, Booths „fatiguing“. Das Level Design Book schreibt, auch ein intensiver Bosskampf werde nach zehn Minuten zur Plackerei: „Any intense boss fight will feel like a slog after 10+ minutes.“ Die andere ist zu viel Gleiches auf mittlerer Höhe, wie im Lehrbeispiel am Anfang: drei gleiche Räume hintereinander, keiner davon ein Ereignis. + + Im Taktplan erkennst du beides an zwei Zeichen. Mehrere Takte derselben Art folgen aufeinander, oder die Balken bleiben über viele Zeilen gleich lang. Die Gegenmittel sind Kontrast in der Art, etwa eine Entdeckung nach einer Begegnung, und Kontrast in der Intensität: ein Tal nach einer Spitze oder eine Spitze nach langer gleicher Mitte. Welches Mittel du wählst und was in dem neuen Takt passiert, entscheidest du. + + > [!PRAXIS] Valve ändert den Rhythmus nach Playtests + > Valve testete jeden Freitag mit Menschen außerhalb des Teams. Der Level-Designer Phil Co beschreibt, wie sich dabei Monotonie zeigte: „we might have too much of one particular gameplay and the playtester suffers from fatigue.“ In Half-Life 2: Episode Two bestand der Teil vor dem Auto fast nur aus Kämpfen „with just a few enemies at a time“. Das Team fügte deshalb eine Spitze ein, „a combat high moment“: ein Gebäude, in dem Alyx den Spieler mit dem Scharfschützengewehr unterstützt (zitiert im [Level Design Book](https://book.leveldesignbook.com/process/blockout/playtesting#playtesting-at-valve)). Die Antwort auf Ermüdung war dort keine Pause, sondern ein Kontrast. + + ## Begegnungen als Raum und Takt + + In diesem Kurs ist eine Begegnung ein Platz im Taktplan: ein Ort mit einer Größe, ein Weg hinein und hinaus, eine Aussicht davor oder keine, und ein Takt danach. Was die Gegner tun, wie viele es sind und wie sie sich ankündigen, gehört nicht in den Taktplan des Level-Designs. Booth hat Bossbegegnungen sogar aus dem Director herausgenommen: „Boss Encounters NOT affected by adaptive pacing“, denn „Boss encounters are intended to change up the pacing anyhow“. Eine große Begegnung ist selbst ein Wechsel im Rhythmus. + + Für den Taktplan reichen drei Fragen. Was sieht der Spieler, bevor die Begegnung beginnt? Wie lang ist der Weg hinein und hinaus? Was kommt danach? Wie Gegnermuster eine Begegnung füllen, zeigt [Gegnermuster](/combat/gegnermuster), Arena und Kamera für große Gegner [Große Kreaturen als Bosse](/combat/grosse-gegner). Musik und Klang tragen den Rhythmus mit; das behandelt der spätere Sound-Kurs. + + > [!INTERVIEW] „Wie planst du den Rhythmus eines Abschnitts?“ + > Ich schreibe die Takte als Liste mit Art, geschätzter Intensität und Weglänge in Tiles und rechne die Mindestdauer aus dem Tempo. Dann suche ich die längste Strecke ohne Ruhe und Stellen, an denen zwei gleiche Takte aufeinanderfolgen. Vor jeder Freifläche prüfe ich, ob der Spieler sie überblickt, bevor die Begegnung beginnt. Im Playtest messe ich, wie lange jeder Takt wirklich dauert, und vergleiche das mit dem Plan. + + ## Häufige Fehler + + - **Gleiche Takte hintereinander.** Drei Begegnungen ähnlicher Größe mit kurzen Gängen dazwischen: Im Taktplan steht dreimal dieselbe Zeile. Setz einen Takt anderer Art oder anderer Intensität dazwischen. + - **Ein Gang als Ruhe.** 20 Tiles Gang sind 3,6 Sekunden. Ruhe braucht einen Ort, an dem der Spieler stehen bleibt, nicht nur Weg. + - **Die höchste Spitze ganz am Ende.** Das Level Design Book rät: „Avoid maximum intensity final bosses / encounters.“ Valve hat das bei Portal im Test erfahren. Über eine verworfene, sehr intensive Fassung des Endkampfs steht im Post-Mortem „High Intensity = Bad“ ([Swift und Wolpaw, GDC 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)). + - **Intensität mit Schwierigkeit verwechseln.** Booths Director verändert die Verteilung der Spitzen, nicht ihre Höhe. Ein Takt kann intensiv und leicht sein. + - **Den Plan für das Ergebnis halten.** „You can't playtest a document“, schreibt das Level Design Book über Pacing-Pläne ([Against pacing](https://book.leveldesignbook.com/process/preproduction/pacing#against-pacing)). Die geschätzte Intensität ersetzt den Test nicht. + - **Kampfinhalte im Taktplan.** Gegnertypen und Muster gehören ins Combat Design. Im Taktplan stehen Ort, Größe, Weg und Dauer. + + ## Zusammenfassung + + - Pacing ist Reihenfolge und Rhythmus der Tätigkeiten in einem Level. Die Einheit ist der Takt (Beat). + - Dieser Kurs nutzt fünf Arten: Bewegung, Beobachtung, Entdeckung, Begegnung, Ruhe. Die Intensität von 0 bis 5 ist eine Schätzung, die der Playtest prüft. + - Ein Taktplan in Textform zeigt Spitzen, Täler, Wiederholungen und die längste Strecke ohne Ruhe. + - Tiles mal 16 durch 90 ergibt die Mindestdauer in Sekunden (Platzhalter). Außer bei Bewegung kommt Verweildauer dazu. + - Der AI Director von Left 4 Dead wechselt zwischen Build Up, Sustain Peak, Peak Fade und Relax. Er verteilt die Spitzen, die Schwierigkeit ändert er nicht. + - Eine Aussicht vor einer Freifläche zeigt die Fläche, bevor die Begegnung beginnt. Sicherheit ist ein Zustand des Spiels, keine Form. + - Monotonie entsteht durch zu lange Spitzen oder zu viel Gleiches. Kontrast in Art oder Intensität hilft. +exercises: + - id: director-phasen + type: choice + title: Was der Director tut + prompt: | + Welche Aussagen geben Michael Booths Folien zum AI Director von Left 4 Dead richtig wieder? + options: + - text: In der Phase Relax hält der Director die Bedrohung 30 bis 45 Sekunden lang minimal oder bis die Spieler weit genug zum nächsten Safe Room gelaufen sind. + correct: true + why: So steht es auf der Folie zu Relax. Die Ruhe endet nach Zeit oder nach Weg. + - text: Sustain Peak hält die volle Bedrohung noch 3 bis 5 Sekunden, nachdem die Intensität ihre Spitze erreicht hat. + correct: true + why: Auf der Folie steht „Continue full threat population for 3-5 seconds after Survivor Intensity has peaked“. Die volle Bedrohung läuft also nach der Spitze noch kurz weiter. + - text: Spielen die Survivors gut, erhöht der Director die Schwierigkeit der Spitzen. + correct: false + why: Booth schreibt „Algorithm adjusts pacing, not difficulty“. Verändert wird die Verteilung der Spitzen, nicht ihre Höhe. + - text: Bossbegegnungen verschiebt der Director in die Phase Build Up. + correct: false + why: Bossbegegnungen sind ausgenommen, „NOT affected by adaptive pacing“. Sie sollen den Rhythmus ohnehin wechseln. + explanation: | + Der Director schätzt eine Intensität pro Spieler und schaltet zwischen voller und minimaler Bedrohung. Er verändert, wann Spitzen kommen, nicht wie hoch sie sind. Für handgebaute Abschnitte ist das die wichtigste Lehre: Rhythmus und Schwierigkeit sind zwei getrennte Größen. + hints: + - Zwei Aussagen sind richtig. + - Achte auf die Folie mit dem Satz über „difficulty“. + resources: + - title: Michael Booth, „The AI Systems of Left 4 Dead“ (Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf + + - id: phasen-ordnen + type: order + title: Ein Zyklus des Directors + prompt: | + Bring die Phasen des AI Director in die Reihenfolge, in der sie aufeinander folgen. Der Zyklus beginnt mit Build Up. + lang: prose + lines: | + Build Up: volle Bedrohung, bis die Intensität der Spieler die Spitze überschreitet. + Sustain Peak: volle Bedrohung noch 3 bis 5 Sekunden nach der Spitze. + Peak Fade: minimale Bedrohung, bis die Intensität aus dem Spitzenbereich abklingt. + Relax: minimale Bedrohung für 30 bis 45 Sekunden oder bis die Spieler weit genug zum nächsten Safe Room gelaufen sind. + Danach beginnt der Zyklus wieder mit Build Up. + explanation: | + Aufbau, Spitze halten, Abklingen, Ruhe. Peak Fade steht zwischen Spitze und Ruhe, damit ein laufender Kampf zu Ende gehen kann, bevor die Ruhe zählt. Für deinen Taktplan heißt das: Nach einer Begegnung kommt nicht sofort die Ruhe, sondern erst der Ausklang. + hints: + - Zweimal volle Bedrohung, zweimal minimale. + resources: + - title: Michael Booth, „The AI Systems of Left 4 Dead“ (Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf + + - id: ruhe-ist-zustand + type: choice + title: Was einen Ort ruhig macht + prompt: | + Lehrbeispiel: Nach einer Begegnung auf einer Freifläche soll der Spieler einen Ort zum Durchatmen haben. Welche Aussage entspricht der Haltung des Level Design Book? + options: + - text: Ob ein Ort sicher wirkt, hängt am Zustand des Spiels, etwa daran, ob dort bisher angegriffen wurde. Keine Form ist von sich aus sicher. + correct: true + why: „No shape or layout is intrinsically safe.“ Das Buch nennt refuge einen Zustand, keine Eigenschaft der Architektur. + - text: Eine enge Nische mit niedrigem Dach ist nach der Prospect-Refuge-Theorie immer ein Ruheort, also reicht sie. + correct: false + why: Das ist die Lesart, gegen die sich das Buch wendet. Eine Nische, in der schon einmal ein Hinterhalt lag, wirkt nicht ruhig. + - text: Eine Aussicht ist vor allem nach einer Begegnung nützlich, damit der Spieler sieht, was er geschafft hat. + correct: false + why: Das Buch nennt die vista nützlich „especially for an arena layout before an encounter begins“, also davor. + - text: Ruhe entsteht durch einen langen Gang, weil dort nichts passiert. + correct: false + why: Ein Gang mit 20 Tiles dauert bei den Platzhaltern 3,6 Sekunden. Ruhe braucht einen Ort zum Stehenbleiben. + explanation: | + Das Level Design Book ersetzt refuge durch Begriffe wie cover, enclosure oder safe house und macht Sicherheit zu einer Frage des Spielzustands. Ein Ort wird ruhig, weil das Spiel ihn ruhig hält, und der Spieler lernt das über die Zeit. Deshalb kann derselbe Raum vor der Begegnung bedrohlich und danach ruhig sein. + hints: + - Lies die Option, die von Form spricht, und die, die von Zustand spricht. + resources: + - title: The Level Design Book · Prospect-refuge, „Safety as game state“ + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#safety-as-game-state + + - id: takt-dauer + type: output + title: Drei Wege in Sekunden + prompt: | + Tiles mit 16 Pixeln, Tempo 90 Pixel pro Sekunde, beides Platzhalter. Was gibt das Modell aus? + lang: python + code: | + TILE = 16 # px, Platzhalter + TEMPO = 90 # px/s, Platzhalter + + def sekunden(tiles): + s = tiles * TILE / TEMPO + return round(s, 1) + + print(sekunden(20)) + print(sekunden(45)) + print(sekunden(9)) + expected: | + 3.6 + 8.0 + 1.6 + hints: + - Ein Tile dauert 16 / 90 Sekunden, also etwa 0,18. + - 45 × 16 = 720, und 720 / 90 ist glatt. + explanation: | + 20 Tiles sind ein Bildschirm quer, 3,6 Sekunden. 45 Tiles ergeben genau 8 Sekunden, 9 Tiles 1,6. Diese Zeiten gelten nur, wenn der Spieler ohne Halt geht. Für einen Bewegungstakt ist das die Dauer, für alle anderen Arten die Untergrenze. + resources: + - title: Python · round() + url: https://docs.python.org/3/library/functions.html#round + + - id: laengste-strecke + type: output + title: Wie lange ohne Ruhe? + prompt: | + Der Taktplan lautet: Bewegung 30 Tiles, Begegnung 12, Ruhe, Entdeckung 14, Bewegung 25, Begegnung 15, Ruhe. Das Modell sucht die längste Strecke ohne Ruhe, zuerst in Tiles, dann als Mindestdauer in Sekunden. Was gibt es aus? + lang: python + code: | + TILE = 16 # px, Platzhalter + TEMPO = 90 # px/s, Platzhalter + # Tiles je Takt, "R" heißt Ruhe + takte = [30, 12, "R", 14, 25, + 15, "R"] + lauf = rekord = 0 + for t in takte: + if t == "R": + lauf = 0 + else: + lauf += t + rekord = max(rekord, lauf) + s = rekord * TILE / TEMPO + print(rekord, round(s, 1)) + expected: | + 54 9.6 + hints: + - Vor der ersten Ruhe liegen 30 + 12 Tiles, zwischen den beiden Ruhen 14 + 25 + 15. + - 54 × 16 / 90 = 9,6. + explanation: | + Die erste Strecke hat 42 Tiles, die zweite 54. Die längste Strecke ohne Ruhe liegt also zwischen den beiden Ruhetakten und dauert mindestens 9,6 Sekunden. In Wirklichkeit dauert sie länger, denn Entdeckung und Begegnung halten den Spieler auf. Das Modell misst Weg, der Playtest misst Zeit. Beides nebeneinander zeigt dir, wo die Verweildauer liegt. + resources: + - title: Python · max() + url: https://docs.python.org/3/library/functions.html#max + + - id: ruhe-in-bildschirmen + type: output + title: 30 Sekunden Weg + prompt: | + Booths Phase Relax dauert mindestens 30 Sekunden. Wie viele Bildschirme quer (je 20 Tiles) läuft die Figur in dieser Zeit ohne Halt, bei 90 Pixeln pro Sekunde und 16-Pixel-Tiles (Platzhalter)? Eine Nachkommastelle. + lang: text + code: | + Pixel = Sekunden × Tempo + Tiles = Pixel / 16 + Bildschirme = Tiles / 20 + expected: | + 8,4 + accept: ["8.4", "8,4 Bildschirme", "8,4 Bildschirmbreiten"] + explanation: | + 30 × 90 = 2700 Pixel, durch 16 sind das 168,75 Tiles, durch 20 rund 8,4 Bildschirme. Ein Abschnitt von zwei bis vier Bildschirmen kann die Ruhe von Left 4 Dead also nicht über Weg allein herstellen. Ruhe braucht dort einen Ort, an dem der Spieler stehen bleibt, oder sie ist kürzer als bei Booth. Wie lang sie in deinem Spiel sein soll, entscheidest du. + resources: + - title: Michael Booth, „The AI Systems of Left 4 Dead“ (Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf + + - id: begriffe-rhythmus + type: gap + title: Fünf Begriffe zum Rhythmus + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Reihenfolge und Rhythmus der Tätigkeiten in einem Level nennt das Level Design Book ⟦Pacing⟧. Einen kleinen, abgeschlossenen Teil davon nennt es ⟦Beat⟧, dieser Kurs sagt Takt. Im AI Director von Left 4 Dead folgt auf Sustain Peak die Phase ⟦Peak Fade⟧, danach ⟦Relax⟧. Statt prospect empfiehlt das Buch für einen Aussichtspunkt vor einer Begegnung den Begriff ⟦vista⟧. + gaps: + - label: Fachbegriff für Rhythmus + hint: Englisch, von „pace“, Schritt oder Tempo. + - label: Einheit + hint: Englisch wie in der Musik, vier Buchstaben. + accept: ["Takt", "Beats"] + - label: dritte Phase + hint: Die Spitze klingt ab, zwei Wörter. + accept: ["Peak-Fade"] + - label: vierte Phase + hint: Englisch für „entspannen“. + accept: ["Relax period", "Ruhe"] + - label: Aussichtspunkt + hint: Englisch, fünf Buchstaben, wie in „Panorama“. + accept: ["Aussicht", "Aussichtspunkt", "sightline"] + explanation: | + Pacing und Beat stammen aus dem Level Design Book, die Phasen aus Booths Folien. Peak Fade lässt einen laufenden Kampf ausklingen, Relax hält die Bedrohung danach minimal. Vista und sightline sind die Begriffe, die das Buch statt prospect vorschlägt, weil sie beschreiben, was der Spieler sieht, statt ein Gefühl zu behaupten. + resources: + - title: The Level Design Book · Prospect-refuge, „Instead of prospect“ + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#instead-of-prospect + + - id: dauer-falsch + type: bug + title: Ein Takt ist zu kurz gerechnet + prompt: | + Ein Taktplan mit Mindestdauern. Eine Zeile ist falsch gerechnet. Tippe sie an und korrigiere sie. + lang: text + code: | + Tile 16 px, Tempo 90 px/s + Takt 1 Bewegung: 45 Tiles, 8,0 s + Takt 2 Beobachtung: 9 Tiles, 1,6 s + Takt 3 Begegnung: 18 Tiles, 2,0 s + Takt 4 Ruhe: 10 Tiles, 1,8 s + lines: [4] + fix: + - line: 4 + answers: ["Takt 3 Begegnung: 18 Tiles, 3,2 s", "Takt 3 Begegnung: 18 Tiles, 3.2 s"] + explanation: | + 18 × 16 = 288 Pixel, durch 90 sind das 3,2 Sekunden. Mit 2,0 wirkt die Begegnung im Plan kürzer als ihre eigene Durchquerung. Die anderen Zeilen stimmen: 720 / 90 = 8,0, 144 / 90 = 1,6 und 160 / 90 ≈ 1,8. Eine falsche Untergrenze ist tückisch, weil du im Playtest dann eine Verweildauer siehst, die gar keine ist. + hints: + - Rechne jede Zeile nach. Tiles × 16 / 90. + + - id: sicht-verdeckt + type: bug + title: Die Brüstung ist eine Wand + prompt: | + Lehrbeispiel: Der Spieler kommt bei `S` in einen Vorraum. Von dort soll er über eine niedrige Brüstung die Freifläche mit der Begegnung `B` überblicken, bevor er sie durch den Durchgang betritt. Der Raum passt auf einen Bildschirm. Eine Zeile widerspricht dieser Absicht. Finde sie. + + Legende: `#` Wand, blockiert Weg und Sicht nach dahinter · `o` niedriges Hindernis, blockiert Weg, nicht Sicht · `.` Boden · `+` Durchgang · `S` Start · `B` Begegnung + lang: text + code: | + #################### + #..................# + #..................# + #.........B........# + #..................# + #..................# + #########+########## + #..................# + #.....S............# + #################### + lines: [7] + explanation: | + Zeile 7 trennt Vorraum und Freifläche mit hohen Wänden. Nach der Legende verdecken sie die Sicht auf das, was dahinter liegt, und der Spieler sieht die Freifläche erst, wenn er durch den Durchgang tritt. Für die Absicht müsste die Zeile aus niedrigen Hindernissen bestehen, etwa `#oooooooo+ooooooooo#`. Dann ist der Vorraum ein Beobachtungstakt vor der Begegnung. Ob die Brüstung auch in der Ausgestaltung niedrig aussieht, prüfst du später noch einmal. + hints: + - Welche Zeile liegt zwischen `S` und `B`? + - Vergleich die Bedeutung von `#` und `o` in der Legende. + resources: + - title: The Level Design Book · Prospect-refuge, „Instead of prospect“ + url: https://book.leveldesignbook.com/process/blockout/massing/prospect-refuge#instead-of-prospect + + - id: glados-takt + type: explain + title: Der letzte Takt von Portal + prompt: | + Auszüge aus den Folien des Portal-Post-Mortems von Kim Swift und Erik Wolpaw (Valve, GDC 2008) zum Endkampf. Erkläre in drei bis fünf Sätzen, was Valve über den letzten Takt gelernt hat und was daraus für den letzten Takt eines eigenen Abschnitts folgt. + lang: prose + code: | + Conclusion: High Intensity = Bad. No one paid attention to GLaDOS. Alienated people who liked the slower-paced, cerebral nature of Portal. + Complex Boss Battle: Nope. The more complex, the longer players would take, resulting in bad pacing. + What made the Fire Pit climactic? Time Pressure. Visual Impact. High Drama. Easy Puzzle. + points: + - Eine sehr intensive Fassung lenkte von der Figur ab und passte nicht zum ruhigeren Rhythmus des restlichen Spiels. + - Komplexität verlängert die Dauer eines Takts, und die längere Dauer verschlechterte das Pacing. + - Die gewählte Fassung wirkte als Höhepunkt durch Zeitdruck und Wirkung, nicht durch Schwierigkeit („Easy Puzzle“). + - Gefunden hat Valve das über mehrere getestete Fassungen, nicht über den Plan. + explanation: | + Valve hat mehrere Fassungen des Endkampfs gebaut und verworfen. Die sehr intensive Fassung zog die Aufmerksamkeit von GLaDOS weg und vergraulte Spieler, die das langsame, nachdenkliche Portal mochten. Ein komplexes Rätsel scheiterte an der Dauer, denn je komplexer, desto länger brauchten die Spieler. Der Höhepunkt kam aus Zeitdruck, Wirkung und Drama bei einem leichten Rätsel. Für einen eigenen Abschnitt heißt das: Der letzte Takt muss zum Rhythmus des Ganzen passen, und Höhepunkt heißt nicht höchste Schwierigkeit. Das Level Design Book rät ebenso, die letzte Begegnung nicht auf maximale Intensität zu setzen. Was dein letzter Takt ist, entscheidest du und prüfst es im Test. + hints: + - Lies die drei Auszüge als drei Versuche mit je einem Ergebnis. + - Was steht beim Fire Pit zur Schwierigkeit? + resources: + - title: Swift, Wolpaw, „A Portal Post-Mortem“ (GDC 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf + - title: The Level Design Book · Pacing, „Avoid maximum intensity final bosses“ + url: https://book.leveldesignbook.com/process/preproduction/pacing#avoid-maximum-intensity-final-bosses-encounters + + - id: director-uebertragen + type: explain + title: Ein Director ohne Director + prompt: | + Dein Abschnitt hat kein System, das die Anspannung der Spieler misst. Erkläre in drei bis fünf Sätzen, was du vom AI Director für einen handgebauten Abschnitt übernehmen kannst und was nicht. Die Auszüge stammen aus Booths Folien. + lang: prose + code: | + Estimate the “emotional intensity” of each Survivor. Track the max intensity of all 4 Survivors. If intensity is too high, remove major threats for awhile. Otherwise, create an interesting population of threats. + Relax: Maintain minimal threat population for 30-45 seconds, or until Survivors have traveled far enough toward the next safe room, then resume Build Up. + Algorithm adjusts pacing, not difficulty. + points: + - Übernehmen lässt sich das Muster aus Aufbau, Spitze, Abklingen und Ruhe. + - Die Ruhe wird an einen Ort gebunden, wie bei Booth an den Weg zum nächsten Safe Room. + - Rhythmus und Schwierigkeit bleiben getrennt; der Director verteilt Spitzen, er macht sie nicht höher. + - Nicht übernehmen lässt sich die Messung in Echtzeit. Die Intensität ist im Plan geschätzt und wird im Playtest geprüft. + explanation: | + Der Director misst für jeden Spieler eine Intensität und schaltet danach zwischen voller und minimaler Bedrohung. Ein handgebauter Abschnitt kann das Muster übernehmen: Aufbau, Spitze, Ausklang und Ruhe, die Ruhe an einen Ort gebunden, so wie in Left 4 Dead an den Safe Room. Ebenso lässt sich die Trennung übernehmen, dass Rhythmus nicht Schwierigkeit ist. Was fehlt, ist die Messung. Wann ein Spieler wirklich angespannt ist, weißt du nicht vorher, deshalb schätzt du die Intensität im Taktplan und prüfst sie im Playtest an Verweildauer, Umkehr und Gesagtem. + hints: + - Trenne das Muster vom Messen. + resources: + - title: Michael Booth, „The AI Systems of Left 4 Dead“ (Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf + + - id: taktplan-veroeffentlicht + type: practice + title: Taktplan eines fremden Abschnitts + prompt: | + Wähle zwei bis fünf Minuten aus einem veröffentlichten Top-down-Spiel, das du kennst, oder aus einem Video davon. Schreib einen Taktplan mit höchstens acht Takten. Je Takt: Art, geschätzte Intensität von 0 bis 5 und Dauer (geschätzt oder mit Zeitangaben aus dem Video). Markiere zum Schluss die längste Strecke ohne Ruhe. + lang: prose + starter: | + Spiel, Stelle: + 1 Art / Int. / Dauer: + 2 Art / Int. / Dauer: + 3 Art / Int. / Dauer: + Längste Strecke ohne Ruhe: + checklist: + - Spiel und Stelle sind so genannt, dass jemand sie wiederfindet. + - Jeder Takt hat eine der fünf Arten oder eine Art, die du vorher selbst festgelegt hast. + - Jeder Takt hat eine Intensität von 0 bis 5 und eine Dauer. + - Die längste Strecke ohne Ruhe ist mit ihren Takten benannt. + - Du notierst, ob vor einer Begegnung ein Beobachtungstakt liegt. + explanation: | + Ein fremder Abschnitt zeigt dir, wie veröffentlichte Spiele Spitzen und Täler setzen, ohne dass du selbst etwas bauen musst. Die Intensität bleibt deine Schätzung. Wenn du denselben Abschnitt später mit jemand anderem vergleichst, siehst du, wie unterschiedlich zwei Menschen dieselbe Stelle einordnen, und genau deshalb gehört die Schätzung in den Playtest. + hints: + - Ein Takt endet, wenn sich ändert, was der Spieler tut. + resources: + - title: The Level Design Book · Pacing, „Plotting and documentation“ + url: https://book.leveldesignbook.com/process/preproduction/pacing#plotting-and-documentation + + - id: taktplan-eigen + type: practice + title: Dein eigener Taktplan + prompt: | + Für einen eigenen Abschnitt von zwei bis vier Bildschirmen: Welche Takte er hat, entscheidest du. Schreib den Taktplan mit Art, Weglänge in Tiles, Mindestdauer in Sekunden und geschätzter Intensität. Notiere darunter, welcher Takt im Test vermutlich viel länger dauert als sein Weg, und warum. + lang: prose + starter: | + Abschnitt (Bildschirme): + Tempo, Tilegröße: + Takte (Art, Tiles, s, Int.): + Längste Strecke ohne Ruhe: + Takt, der länger dauern wird: + checklist: + - Der Plan hat höchstens acht Takte, jeder mit Art, Tiles, Sekunden und Intensität. + - Die Sekunden sind aus Tiles und deinem Tempo gerechnet, und du hast notiert, welche Werte Platzhalter sind. + - Die längste Strecke ohne Ruhe ist benannt. + - Begegnungen stehen nur mit Ort, Größe, Weg und Dauer im Plan, ohne Gegnertypen. + - Du hast eine Vermutung notiert, die du im Playtest prüfen kannst. + explanation: | + Dieser Plan ist eine Hypothese über die Zeit. Die gerechneten Sekunden sind die Untergrenze, die Vermutung zum längeren Takt ist deine erste Testfrage. Im Playtest misst du, wie lange die Takte wirklich dauern ([Playtests beobachten](/level-design/playtest-methode)), und vergleichst die Zahlen mit diesem Plan. + hints: + - Fang mit der Skizze an und miss die Wege in Kästchen. + resources: + - title: The Level Design Book · Pacing + url: https://book.leveldesignbook.com/process/preproduction/pacing diff --git a/content/level-design/modules/ueberarbeiten.yaml b/content/level-design/modules/ueberarbeiten.yaml new file mode 100644 index 0000000..208ca9e --- /dev/null +++ b/content/level-design/modules/ueberarbeiten.yaml @@ -0,0 +1,436 @@ +id: ueberarbeiten +title: "Überarbeiten: von der Beobachtung zur Änderung" +level: 3 +minutes: 100 +summary: Aus Playtest-Notizen eine Änderung ableiten, die eine bestimmte Ursache trifft – bestimmen, wo die Kette aus Bemerken, Lesen, Befolgen und Folge reißt, die Absicht prüfen, den kleinsten passenden Hebel wählen, eine Änderung pro Runde mit frischen Testern prüfen und dabei nicht übermarkieren. +place: unterwegs +goals: + - Du ordnest eine beobachtete Stelle einer von vier Arten zu – nicht bemerkt, falsch gelesen, nicht befolgt, unbeabsichtigte Folge – und nennst den Beleg. + - Du entscheidest begründet, ob du das Level änderst oder bewusst die Absicht. + - Du wählst zu jeder Art einen passenden Hebel und fängst mit dem kleinsten an. + - Du planst eine Runde mit genau einer Änderung, einer zählbaren Erwartung und neuen Testern. + - Du erkennst, wann stärkere Markierungen das Finden kosten, und hältst eine Rangfolge der Hinweise. +resources: + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding + - title: Jakob Nielsen, „Why You Only Need to Test with 5 Users“ (NN/g, 2000) + url: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ + - title: GamesRadar+, Debatte um gelbe Markierungen (2023) + url: https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/ +lesson: | + Lehrbeispiel: Du hast einen Gang mit einer Abzweigung gebaut. Im Seitengang liegt ein Fundstück, und deine Absicht lautet: „Der Spieler soll den Seitengang bemerken, aber zuerst geradeaus gehen.“ Vier Tester haben gespielt. Drei sind am Seitengang vorbeigelaufen und nicht zurückgekommen. Der erste Reflex ist ein Pfeil an der Abzweigung. Er würde vermutlich helfen, und du wüsstest danach trotzdem nicht, warum drei von vier Testern den Gang übersehen haben. + + Überarbeiten heißt, aus Beobachtungen eine Änderung abzuleiten, die eine bestimmte Ursache trifft. Dieses Modul zeigt, wie du eine Stelle diagnostizierst, den passenden Hebel wählst, eine Änderung pro Runde testest und dabei deine Absicht im Blick behältst. Du arbeitest unterwegs mit deinen Notizen. Die Änderung selbst baust du am PC in den Blockout ein ([Blockout in Godot](/level-design/blockout)). Welche Änderung du wählst, ist eine Designentscheidung und bleibt deine; eine KI kann dir höchstens beim Auszählen und Sortieren der Notizen helfen. + + ## Wo die Kette reißt: vier Arten, einen Hinweis zu verfehlen + + Ein Hinweis wirkt nur, wenn vier Dinge nacheinander klappen. Er muss im Bild sein und bemerkt werden. Er muss richtig gelesen werden. Der Spieler muss ihm folgen wollen. Und das, was dann passiert, muss das sein, was du wolltest. An jeder Stelle kann die Kette reißen, und jede Stelle braucht eine andere Reparatur. + + | Art | Was passiert | Woran du es erkennst | + | --- | --- | --- | + | Nicht bemerkt | Der Hinweis war nicht im Bild oder ging im Rest unter. | Kein Halt, kein Richtungswechsel in seiner Nähe, beim lauten Denken kein Wort dazu. | + | Falsch gelesen | Bemerkt, aber anders verstanden: Der Durchgang sah aus wie Wand, das Fundstück wie Dekoration. | Der Spieler geht hin, versucht etwas anderes oder dreht ab; er sagt etwa „ach, da geht's nicht weiter“. | + | Nicht befolgt | Verstanden, aber etwas anderes war wichtiger oder der Weg zu teuer. | Er schaut hin, sagt „später“ oder folgt einem stärkeren Ziel. | + | Unbeabsichtigte Folge | Befolgt, aber anders als gedacht: Abkürzung, festgefahren, Reihenfolge umgangen. | Der Weg im Protokoll weicht von deinem erwarteten Weg ab, obwohl der Hinweis gewirkt hat. | + + Die Spalte rechts ist der Grund, warum du in [Playtests beobachten](/level-design/playtest-methode) Ort, Zeit, Blickrichtung und Gesagtes getrennt notierst. Aus „hat den Gang übersehen“ kannst du keine Art ablesen. Aus „läuft bei 0:14 ohne Halt an der Abzweigung vorbei, die Kamera zeigt den Seitengang 1,5 Sekunden lang am linken Bildrand“ schon: Der Gang war im Bild, aber vermutlich nicht auffällig genug. + + > [!MERKE] Erst die Art, dann die Änderung + > Bestimme für jede Stelle zuerst, an welcher Stelle der Kette sie reißt. Eine Änderung, die eine andere Stelle repariert, hilft zufällig oder gar nicht. + + ## Die Absicht prüfen, bevor du das Level änderst + + Manchmal ist nicht der Raum falsch, sondern die Absicht. Zwei Tester gehen zuerst in den Seitengang statt geradeaus, finden das Fundstück und gehen danach zufrieden weiter. Das widerspricht deiner Notiz, aber vielleicht ist der Ablauf besser als dein Plan. Dann änderst du die Absicht bewusst, schreibst die neue Fassung in die Notiz und testest gegen sie weiter. Was du nicht tun solltest: die Absicht still an das anpassen, was gerade passiert ist. Dann kann dein nächster Test nichts mehr widerlegen. + + Die Gegenfrage gehört dazu: Ist das Verhalten ein Problem für dein Spiel oder nur eine Abweichung von deinem Plan? Ein Tester, der eine Stelle anders löst, als du gedacht hast, hat nicht zwingend etwas falsch gemacht. Ein Tester, der festhängt, umkehrt und aufgibt, schon eher. Das entscheidest du, nicht der Tester. + + ## Hebel: was du an einer Stelle ändern kannst + + Zu jeder Art gehören andere Hebel. Die Tabelle verweist auf die Module, in denen sie erklärt sind. + + | Art | Mögliche Hebel | + | --- | --- | + | Nicht bemerkt | Hinweis früher oder länger ins Bild bringen, Tonwertkontrast erhöhen, konkurrierende Reize daneben entfernen, Rahmung durch eine Öffnung ([Blickführung](/level-design/blickfuehrung)), eine Sichtlinie öffnen ([Orientierung](/level-design/orientierung)) | + | Falsch gelesen | Form und Farbe an deine visuelle Sprache angleichen, Durchgänge breiter und klarer abgrenzen, Zustand sichtbar machen ([Umgebung als Information](/level-design/umgebung-informiert)) | + | Nicht befolgt | Kosten senken (kürzerer Weg, kein Risiko), Belohnung vorher zeigen, Konkurrenz später auftauchen lassen, Reihenfolge ändern ([Einführen und variieren](/level-design/einfuehren-variieren)) | + | Unbeabsichtigte Folge | Kante oder Kollision schließen, Abkürzung bewusst erlauben oder sperren, Weg breiter oder enger ([Maßstab und Dichte](/level-design/massstab-dichte)) | + + Fang mit dem kleinsten Hebel an, der die Ursache trifft. Ein stärkerer Kontrast am Seitengang ist kleiner als ein Pfeil, und ein Pfeil ist kleiner als ein neuer Grundriss. Das Level Design Book ordnet Hilfen zur Orientierung nach geschätzter Sicherheit, von subtil (1–20 %) bis direkt (95–98 %), und rät: „start at the top, and gradually incorporate less subtle methods in response to playtesting“ ([Wayfinding](https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids)). Der Pfeil bleibt erlaubt. Er kostet nur etwas: Was überall markiert ist, muss niemand mehr finden. + + ## Eine Änderung pro Runde, mit frischen Testern + + Combat Design stimmt Werte als Experiment ab: Hypothese vorher, genau eine Größe ändern, vergleichen ([Tuning als Experiment](/combat/tuning)). Für Räume gilt dasselbe. Änderst du am Seitengang Kontrast, Breite und Lage des Fundstücks zugleich, und jetzt finden ihn alle, weißt du nicht, welche Änderung es war. Beim nächsten Abschnitt fängst du wieder bei null an. + + Schreib die Hypothese vor dem Umbau auf, in dieser Form: + + ```text + Stelle: Abzweigung, WP 3 + Gesehen: 3/4 ohne Halt vorbei + Art: nicht bemerkt + Änderung: Boden im Seitengang + einen Tonwert heller + Erwartung: mind. 3/4 halten + an WP 3 + ``` + + Für den nächsten Test brauchst du neue Tester. Wer den Abschnitt schon gespielt hat, weiß, dass es den Seitengang gibt. Er kann dir sagen, ob die Änderung stört, aber nicht, ob man den Gang jetzt bemerkt. Das Level Design Book nennt einen Test mit möglichst wenig Anleitung einen „blind“ Playtest: „pretend they are playing the level by themselves, alone, and see what they do“ ([Playtesting](https://book.leveldesignbook.com/process/blockout/playtesting#playtest-formats)). Valve fasst diese Haltung in zwei Zeilen: „Game designs are hypotheses“, „Playtests are experiments“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Viele kleine Runden zeigen dir dabei mehr als eine große. Jakob Nielsen hat das für Usability-Tests so formuliert: „The best results come from testing no more than 5 users and running as many small tests as you can afford.“ ([NN/g, 2000](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)). Sein Grund passt auch zu Leveln: Nach jeder kleinen Runde änderst du etwas, und die nächste Runde prüft die Änderung. + + > [!TIP] Eine Runde, ein kurzer Block + > Passt die Hypothese nicht in diese sieben kurzen Zeilen, änderst du zu viel auf einmal. Teil sie auf mehrere Runden auf. + + ## Übermarkieren: wenn jeder Hinweis lauter wird + + Jede Runde verführt dazu, die Stelle mit den meisten Problemen deutlicher zu machen. Nach fünf Runden leuchtet jeder Durchgang, jedes Fundstück blinkt, und der Raum hat keine Rangfolge mehr. Die Debatte um gelbe Farbe an kletterbaren Kanten, die 2023 um das Remake von Resident Evil 4 aufkam, dreht sich um genau diese Abwägung. Der Entwickler David Szymanski erklärte dort, warum detaillierte Grafik das Problem verschärft: „As environments get more detailed and realistic, materials get more complex and noisy, etc, it becomes increasingly difficult to direct players in unobtrusive ways“ ([GamesRadar+](https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/)). Starke Markierungen machen sicher, dass niemand festhängt, und nehmen dem Spieler das Finden. Für dich folgt daraus noch etwas: Ein Hinweis, der im grauen Blockout trägt, kann in der fertigen Grafik untergehen. Deshalb testest du nach der Ausgestaltung noch einmal ([Ausgestaltung](/level-design/ausgestaltung)). + + Zwei Fragen helfen. Muss der Spieler diesen Hinweis finden, um weiterzukommen, oder ist er eine Belohnung für Aufmerksamkeit? Pflichtwege dürfen deutlich sein, Nebenwege leiser. Und: Welchen Hinweis machst du leiser, wenn du diesen lauter machst? Eine Rangfolge bleibt nur erhalten, wenn nicht alles gleichzeitig steigt. + + ## Das Iterationsprotokoll + + Halte jede Runde in einem kurzen Block fest. Das Protokoll ist für dich, aber es ist auch das, was du später im Vergleich zwischen Absicht und Verhalten zeigst ([Werkstatt](/level-design/werkstatt-abschnitt)). + + ```text + Runde 1 · 4 Tester + Stelle: WP 3 + Gesehen: 3/4 ohne Halt vorbei + Art: nicht bemerkt + Änderung: Boden heller + Erwartung: mind. 3/4 halten + Ergebnis: Runde 2: 3/4 halten + + Runde 2 · 4 neue Tester + Stelle: WP 3 + Gesehen: 3/4 halten, 1/4 vorbei + Art: Absicht erfüllt + Änderung: keine + Erwartung: – + Ergebnis: – + ``` + + Die Zeile „Ergebnis“ füllst du erst nach der nächsten Runde aus. Bleibt sie leer, weil kein Test mehr kam, steht da „nicht geprüft“. Auch das ist eine ehrliche Angabe. + + > [!PRAXIS] Zusehen, dann ändern + > Joseph Hunter, Entwickler von Sucker for Love, schrieb in derselben Debatte: „I promise the yellow paint was added in after a dev was forced to watch in silence as a playtester got stuck for 20 minutes looking for a way up“ ([GamesRadar+](https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/)). Valve beschreibt in seinem Post-Mortem zu Portal dieselbe Reihenfolge: „Watch your playtests“ und „Adjust gameplay to what players look like they need.“ ([Swift und Wolpaw, GDC 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)). Die Änderung folgt dem, was Spieler tun, nicht dem, was der Designer vorher befürchtet hat. + + > [!INTERVIEW] „Tester verstehen deinen Raum nicht. Was tust du?“ + > Ich schaue zuerst, an welcher Stelle es reißt: nicht bemerkt, falsch gelesen, nicht befolgt oder eine Folge, die ich nicht wollte. Dazu nehme ich Ort, Zeit und Gesagtes aus dem Protokoll, nicht den Eindruck. Dann prüfe ich, ob meine Absicht noch stimmt, ändere eine Sache mit einer schriftlichen Erwartung und teste mit Leuten, die den Raum noch nicht kennen. + + ## Häufige Fehler + + - **Mehrere Änderungen auf einmal.** Du weißt danach nicht, was gewirkt hat. Eine Änderung pro Runde, die anderen auf die Liste. + - **Den Vorschlag des Testers bauen.** „Mach den Gang rot“ ist eine Beobachtung, dass er den Gang nicht als Weg gelesen hat. Ob Rot die Antwort ist, entscheidest du ([Testlesen und Playtest](/narrative/testlesen-playtest)). + - **Mit denselben Testern prüfen, ob etwas auffällt.** Wer es schon kennt, bemerkt es immer. Für Fragen des Bemerkens brauchst du frische Tester. + - **Ein Ausreißer, ein Umbau.** Ein Tester von fünf hängt fest. Notier es, prüf es in der nächsten Runde, aber bau nicht den Grundriss um. + - **Ein Layoutproblem mit Grafik lösen.** Liest niemand den Durchgang als Weg, weil er nur ein Tile breit ist, hilft keine schönere Tür. Erst das Layout, dann die Ausgestaltung ([Ausgestaltung](/level-design/ausgestaltung)). + - **Die Absicht still ändern.** Schreib jede neue Fassung mit Datum in die Notiz. + + ## Zusammenfassung + + - Ein Hinweis kann auf vier Arten verfehlen: nicht bemerkt, falsch gelesen, nicht befolgt, unbeabsichtigte Folge. + - Die Art liest du aus Ort, Zeit, Blickrichtung und Gesagtem, nicht aus einem Eindruck. + - Prüf vor jeder Änderung, ob die Absicht noch stimmt. Änderst du sie, dann bewusst und schriftlich. + - Jede Art hat eigene Hebel. Fang mit dem kleinsten an, der die Ursache trifft. + - Eine Änderung pro Runde, mit schriftlicher Erwartung und neuen Testern. + - Starke Markierungen kosten das Finden. Wenn du einen Hinweis lauter machst, frag, welcher leiser wird. + - Das Iterationsprotokoll hält Beobachtung, Art, Änderung und Ergebnis jeder Runde fest. +exercises: + - id: art-bestimmen + type: choice + title: Nur Deko? + prompt: | + Lehrbeispiel, Notiz aus einem Playtest: „0:31 WP 4. Geht auf den schmalen Durchgang zu, bleibt davor stehen, sagt: ‚Ah, da ist nur Deko.‘ Geht weiter nach rechts.“ Der Durchgang ist begehbar und führt zum Fundstück. An welcher Stelle reißt die Kette? + options: + - text: Falsch gelesen + correct: true + why: Der Tester hat den Durchgang bemerkt und ist hingegangen, hat ihn aber als Dekoration gedeutet. Das Bemerken hat geklappt, das Lesen nicht. + - text: Nicht bemerkt + correct: false + why: Er ist auf den Durchgang zugegangen und hat darüber gesprochen. Bemerkt hat er ihn also. + - text: Nicht befolgt + correct: false + why: Nicht befolgt hieße, er hätte den Weg erkannt und sich trotzdem für etwas anderes entschieden. Er hielt ihn aber gar nicht für einen Weg. + - text: Unbeabsichtigte Folge + correct: false + why: Eine unbeabsichtigte Folge setzt voraus, dass der Hinweis gewirkt hat und etwas anderes passiert ist als geplant. Hier hat der Hinweis nicht gewirkt. + explanation: | + Der Satz „da ist nur Deko“ ist der wichtigste Beleg im Protokoll. Er zeigt, dass der Durchgang im Bild war und angesehen wurde, aber nicht wie ein Weg aussah. Die passenden Hebel betreffen deshalb Form und visuelle Sprache, etwa eine klarere Öffnung oder denselben Boden wie im Hauptweg, nicht mehr Licht oder eine größere Belohnung. + hints: + - Hat er den Durchgang gesehen? Hat er ihn als Weg verstanden? + resources: + - title: Don Norman, „Signifiers, not affordances“ (2008) + url: https://jnd.org/signifiers-not-affordances/ + + - id: passender-hebel + type: choice + title: Am Bildrand vorbei + prompt: | + Lehrbeispiel: Der Seitengang war beim Vorbeilaufen 1,5 Sekunden am linken Bildrand zu sehen. Drei von vier Testern liefen ohne Halt vorbei und sagten nichts dazu. Du hast die Stelle als „nicht bemerkt“ eingeordnet. Welche Änderungen setzen an dieser Ursache an? + options: + - text: Den Hauptweg vor der Abzweigung leicht auf den Seitengang zu biegen, damit er länger und näher an der Bildmitte im Bild ist. + correct: true + why: Mehr Zeit im Bild und eine bessere Lage im Bildausschnitt erhöhen die Chance, dass der Gang bemerkt wird. Das trifft die Ursache. + - text: Den Boden im Seitengang einen Tonwert heller machen als den Hauptweg. + correct: true + why: Kontrast zieht den Blick. Das ist ein kleiner Hebel an der richtigen Stelle der Kette. + - text: Das Fundstück im Seitengang wertvoller machen. + correct: false + why: Eine größere Belohnung hilft, wenn Spieler den Gang sehen und sich trotzdem dagegen entscheiden. Wer ihn nicht bemerkt, weiß nichts von der Belohnung. + - text: Den Seitengang breiter machen, ohne an Lage oder Kontrast etwas zu ändern. + correct: false + why: Breite hilft beim Lesen als Weg. Ob der Gang bemerkt wird, hängt hier vor allem an Lage und Kontrast; die Breite allein ändert daran wenig. + explanation: | + Für „nicht bemerkt“ sind Lage im Bild, Dauer im Bild und Kontrast die passenden Hebel. Eine wertvollere Belohnung oder ein breiterer Gang reparieren andere Stellen der Kette. Ändere in der nächsten Runde nur eines der beiden richtigen Mittel, sonst weißt du nicht, welches gewirkt hat. + hints: + - Zwei Antworten sind richtig. Frag bei jeder, ob sie dem Spieler hilft, den Gang überhaupt zu sehen. + resources: + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding + + - id: eine-runde + type: order + title: Eine Überarbeitungsrunde + prompt: | + Bring die Schritte einer Überarbeitungsrunde in eine sinnvolle Reihenfolge. + lang: prose + lines: | + Lies das Protokoll und such die Stellen, an denen Verhalten und Absicht auseinandergehen. + Bestimm für jede Stelle, an welcher Stelle der Kette sie reißt, und notier den Beleg. + Prüf, ob die Absicht noch stimmt oder ob du sie bewusst ändern willst. + Wähl für eine Stelle den kleinsten Hebel, der die Ursache trifft. + Schreib Änderung und Erwartung auf, bevor du im Blockout etwas umbaust. + Bau die Änderung ein und teste mit Leuten, die den Abschnitt noch nicht kennen. + explanation: | + Die Diagnose kommt vor der Absicht, weil du erst wissen musst, was passiert ist, bevor du entscheidest, ob es ein Problem ist. Die Erwartung steht vor dem Umbau, damit das Ergebnis sie widerlegen kann. Neue Tester stehen am Ende, weil nur sie zeigen, ob jemand die Stelle ohne Vorwissen jetzt anders spielt. + hints: + - Was muss feststehen, bevor du einen Hebel wählen kannst? + resources: + - title: Mike Ambinder, „Valve's Approach to Playtesting“ (GDC 2009, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + + - id: notizen-zaehlen + type: output + title: Was kam am häufigsten vor? + prompt: | + Du hast die Stellen aus einem Playtest mit drei Testern eingeordnet. Was gibt das Modell aus? + lang: python + code: | + from collections import Counter + + notizen = [ + "nicht bemerkt", + "falsch gelesen", + "nicht bemerkt", + "Absicht erfüllt", + "nicht bemerkt", + "falsch gelesen", + ] + zaehlung = Counter(notizen) + top = zaehlung.most_common(2) + for art, n in top: + print(art, n) + expected: | + nicht bemerkt 3 + falsch gelesen 2 + hints: + - "`most_common(2)` liefert die zwei häufigsten Einträge, der häufigste zuerst." + explanation: | + „Nicht bemerkt“ kommt dreimal vor, „falsch gelesen“ zweimal, „Absicht erfüllt“ einmal. Die Zählung sagt dir, womit du anfängst: mit der Art, die am häufigsten auftritt und am meisten stört. Sie sagt dir nicht, ob alle drei „nicht bemerkt“ an derselben Stelle lagen. Ordne deshalb immer nach Stelle und Art, nicht nur nach Art. + resources: + - title: Python · collections.Counter.most_common + url: https://docs.python.org/3/library/collections.html#collections.Counter.most_common + + - id: vorher-nachher + type: output + title: Vorher und nachher + prompt: | + Runde 1 mit vier Testern, Runde 2 nach einer Änderung mit fünf neuen. `True` heißt: hat an der Abzweigung angehalten. Was gibt das Modell aus? + lang: python + code: | + r1 = [False, False, True, False] + r2 = [True, True, False, + True, True] + + def bruch(runde): + n = sum(runde) + return f"{n}/{len(runde)}" + + print(bruch(r1), bruch(r2)) + expected: | + 1/4 4/5 + hints: + - "`sum` zählt `True` als 1 und `False` als 0." + explanation: | + In Runde 1 hielt einer von vier an, in Runde 2 vier von fünf. Das spricht für die Änderung, beweist bei neun Menschen aber keine Regel. Schreib deshalb beide Brüche ins Protokoll statt Prozentzahlen: „80 %“ klingt nach mehr Gewissheit, als fünf Tester liefern. Ob die Erwartung „mindestens 3 von 4“ erfüllt ist, entscheidest du mit der Zahl und mit dem, was die Tester an der Stelle getan haben. + resources: + - title: Jakob Nielsen, „Why You Only Need to Test with 5 Users“ (NN/g, 2000) + url: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ + + - id: begriffe-ueberarbeiten + type: gap + title: Vier Wörter für eine Runde + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Bevor du etwas änderst, stellst du eine ⟦Diagnose⟧: An welcher Stelle reißt die Kette? Dann schreibst du eine ⟦Erwartung⟧ auf, was nach der Änderung anders sein soll. Du änderst pro Runde genau ⟦eine⟧ Sache. Ob man die Stelle jetzt bemerkt, zeigen nur ⟦frische⟧ Tester, die den Abschnitt noch nicht kennen. + gaps: + - label: vor der Änderung + hint: Wie beim Arzt, bevor er behandelt. + accept: ["Ursachenanalyse", "Analyse"] + - label: schriftlich vor dem Umbau + hint: Englisch oft „hypothesis“. + accept: ["Hypothese", "Vorhersage"] + - label: wie viele + hint: Mehr als das, und du weißt nicht, was gewirkt hat. + accept: ["1", "einzige"] + - label: welche Tester + hint: Das Gegenteil von „wiederkehrend“. + accept: ["neue", "unvoreingenommene", "unbeteiligte"] + explanation: | + Diagnose, Erwartung, eine Änderung und neue Tester sind die vier Bestandteile jeder Runde. Ohne Diagnose triffst du die Ursache zufällig, ohne Erwartung kann das Ergebnis nichts widerlegen, mit mehreren Änderungen weißt du nicht, was gewirkt hat, und mit bekannten Testern misst du Erinnerung statt Bemerken. + + - id: runde-zu-voll + type: bug + title: Diese Runde beweist nichts + prompt: | + Lehrbeispiel: der Plan für Runde 2 an einer Abzweigung. Zwei Zeilen machen das Ergebnis der Runde unbrauchbar. Finde beide. + lang: prose + code: | + Stelle: Abzweigung, WP 3 + Gesehen: 3 von 4 laufen ohne Halt vorbei + Art: nicht bemerkt + Änderung: Boden heller, Gang zwei Tiles breiter und Fundstück näher an die Abzweigung + Erwartung: mindestens 3 von 4 halten an WP 3 + Tester: dieselben vier wie in Runde 1 + lines: [4, 6] + explanation: | + Zeile 4 ändert drei Dinge zugleich. Halten danach alle an, weißt du nicht, ob es der Boden, die Breite oder das Fundstück war. Zeile 6 nimmt dieselben Tester. Die wissen schon, dass es den Seitengang gibt, und halten vermutlich an, auch wenn die Änderung nichts bewirkt. Die übrigen Zeilen sind in Ordnung: Stelle, Beobachtung, Art und eine prüfbare Erwartung. + hints: + - Eine Zeile betrifft, was geändert wird, die andere, wer testet. + resources: + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting#playtest-formats + + - id: falsche-art + type: bug + title: Die Art passt nicht zum Beleg + prompt: | + Lehrbeispiel: drei eingeordnete Stellen aus einem Protokoll. Bei einer passt die Art nicht zu dem, was beobachtet wurde. Finde sie. + lang: prose + code: | + WP 2: läuft ohne Halt am Hebel vorbei, sagt nichts → nicht bemerkt + WP 4: geht zur Tür, drückt dagegen, sagt „zu“, geht weiter → nicht bemerkt + WP 6: sieht das Fundstück, sagt „hol ich später“, geht zum Ausgang → nicht befolgt + lines: [2] + explanation: | + An WP 4 ist der Tester zur Tür gegangen und hat sie angefasst, bemerkt hat er sie also. Er hielt sie für verschlossen. Ist sie offen, hat er sie falsch gelesen; ist sie wirklich verschlossen und soll es sein, ist das Verhalten vielleicht sogar beabsichtigt. Die Art „nicht bemerkt“ würde dich zu Hebeln wie Kontrast oder Licht führen, die hier nichts helfen. + hints: + - Wo hat der Tester den Hinweis angefasst oder angesprochen? + + - id: protokoll-diagnose + type: explain + title: Zweimal um den Brunnen + prompt: | + Lehrbeispiel: Ausschnitt aus einem Protokoll. Absicht des Abschnitts: „Der Spieler soll vom Hof aus den Durchgang rechts unten nehmen.“ Erkläre in drei bis fünf Sätzen, an welcher Stelle die Kette vermutlich reißt, welche Zeilen das belegen und welche einzelne Änderung du für die nächste Runde vorschlagen würdest. + lang: prose + code: | + 0:05 betritt den Hof von unten + 0:08 läuft zum Brunnen in der Mitte + 0:10 umrundet den Brunnen einmal + 0:16 umrundet ihn ein zweites Mal + 0:22 sagt „Hier muss doch was sein“ + 0:25 geht nach links oben hinaus + points: + - Das Verhalten weicht von der Absicht ab, der Tester nimmt den falschen Durchgang. + - Der Brunnen zieht den Blick und wird für ein Ziel gehalten; das zeigen das Umrunden und der Satz bei 0:22. + - Über den Durchgang rechts unten gibt es keinen Beleg, dass er bemerkt wurde. Die Kette reißt vermutlich beim Bemerken, weil der Brunnen die Aufmerksamkeit bindet. + - Eine Änderung genügt für die nächste Runde, etwa den Brunnen unauffälliger machen oder den Durchgang heller, nicht beides. + explanation: | + Der Tester hält den Brunnen für das Ziel: Er läuft direkt hin, umrundet ihn zweimal und sagt „Hier muss doch was sein“. Der Durchgang rechts unten taucht im Protokoll gar nicht auf, also gibt es keinen Beleg, dass er bemerkt wurde. Ich ordne die Stelle als „nicht bemerkt“ ein, mit dem Brunnen als konkurrierendem Reiz. Für die nächste Runde rücke ich den Brunnen im Tonwert näher an den Boden. Ein hellerer Durchgang ginge auch, aber nicht beides zugleich. + hints: + - Was sucht der Tester am Brunnen, und was erwähnt er gar nicht? + + - id: gelbe-farbe + type: explain + title: Warum Realismus mehr Farbe braucht + prompt: | + Zwei Entwickler zur Debatte um gelbe Markierungen, 2023 in GamesRadar+ zitiert. Erkläre in drei bis fünf Sätzen, was beide meinen und was daraus für einen Blockout aus grauen Formen und für seine spätere Ausgestaltung folgt. + lang: prose + code: | + David Szymanski: „As environments get more detailed and realistic, materials get more complex and noisy, etc, it becomes increasingly difficult to direct players in unobtrusive ways“ + + Damion Schubert: „the push towards more realistic art increases the need for more unrealistic visual cues.“ + points: + - Detaillierte Grafik erzeugt visuelles Rauschen, in dem leise Hinweise untergehen. + - Je mehr Rauschen, desto stärker müssen Hinweise sein, bis hin zu unrealistischen Markierungen. + - Ein grauer Blockout hat kaum Rauschen, deshalb können Hinweise dort stärker wirken als später. + - Nach der Ausgestaltung musst du deshalb erneut testen, ob die Hinweise noch tragen. + explanation: | + Beide beschreiben denselben Zusammenhang. Je mehr Details, Materialien und Texturen ein Raum hat, desto lauter ist der Hintergrund, gegen den ein Hinweis ankommen muss. Leise Mittel wie ein etwas hellerer Boden verschwinden darin, und Studios greifen zu deutlichen, oft unrealistischen Markierungen wie gelber Farbe. Für deinen Ablauf heißt das: Im grauen Blockout gibt es kaum Rauschen, ein Hinweis kann dort tragen und in der fertigen Grafik untergehen. Deshalb gehört nach der Ausgestaltung derselbe Test noch einmal auf den Plan, und ein Hinweis, der dann scheitert, ist ein Fall für diese Abwägung, kein Grund für Gelb überall. + hints: + - Was passiert mit einem leisen Signal in einem lauten Raum? + resources: + - title: GamesRadar+, Debatte um gelbe Markierungen (2023) + url: https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/ + + - id: drei-stellen-einordnen + type: practice + title: Drei Stellen, drei Diagnosen + prompt: | + Lehrbeispiel: Notizen aus einem Playtest mit drei Testern in einem Abschnitt aus zwei Bildschirmen. Die Absicht lautet: „Der Spieler soll den Schalter finden, das Tor öffnen und den Abschnitt nach oben verlassen.“ Ordne die drei Stellen ein und schreib für eine davon Änderung und Erwartung auf. + + ```text + A 0:12 WP 2 läuft am Schalter + vorbei, sagt nichts (3 von 3) + B 0:40 WP 5 steht vor dem Tor, + sagt „zu?“, kehrt um (2 von 3) + C 1:05 WP 6 läuft am Tor vorbei + über die Wiese hinaus (1 von 3) + ``` + lang: prose + starter: | + A – Art, Beleg: + B – Art, Beleg: + C – Art, Beleg: + Gewählte Stelle: + Änderung (eine): + Erwartung: + checklist: + - Jede der drei Stellen hat eine Art und einen Beleg aus der Notiz. + - Du hast eine Stelle gewählt und begründest kurz, warum diese zuerst. + - Die Änderung ist genau eine und passt zur Art der gewählten Stelle. + - Die Erwartung nennt ein Verhalten, das du in der nächsten Runde zählen kannst. + explanation: | + Hier gibt es keine einzige richtige Lösung, aber eine prüfbare Begründung. Stelle A betrifft alle drei Tester und steht am Anfang der Kette: Ohne Schalter kein Tor. Viele würden deshalb dort anfangen. Stelle C betrifft einen von drei und ist vielleicht eine unbeabsichtigte Folge, eine Lücke, durch die man das Tor umgehen kann. Ob das ein Fehler ist, hängt an deiner Absicht. + hints: + - Welche Stelle müsste zuerst klappen, damit die anderen überhaupt vorkommen? + + - id: eigene-runde + type: practice + title: Deine nächste Runde + prompt: | + Nimm die Notizen aus deinem letzten eigenen Playtest. Hast du noch keinen gemacht, nimm die Notizen aus [Playtests beobachten](/level-design/playtest-methode). Schreib den Block für die nächste Runde. + lang: prose + starter: | + Runde · Tester (neu?): + Stelle: + Gesehen: + Art: + Änderung: + Erwartung: + Ergebnis: (nach dem Test) + checklist: + - Die Stelle ist so genau benannt, dass du sie im Blockout wiederfindest. + - Unter „Gesehen“ steht ein Beleg mit Häufigkeit, etwa „3 von 4“. + - Die Art ist eine der vier und passt zum Beleg. + - Es gibt genau eine Änderung. + - Die Erwartung ist zählbar und steht vor dem Test fest. + - Du hast notiert, ob die Tester der nächsten Runde den Abschnitt schon kennen. + explanation: | + Dieser Block ist eine Runde deines Iterationsprotokolls. Mit der Zeit zeigt er dir, welche Hebel bei dir oft wirken und welche selten. In der [Werkstatt](/level-design/werkstatt-abschnitt) legst du mehrere solche Blöcke neben die Absicht deines Abschnitts. + hints: + - Passt der Block nicht auf sieben Zeilen, änderst du zu viel auf einmal. + resources: + - title: "Kim Swift, Erik Wolpaw, „Integrating Narrative and Design: A Portal Post-Mortem“ (GDC 2008, Folien)" + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf diff --git a/content/level-design/modules/umgebung-informiert.yaml b/content/level-design/modules/umgebung-informiert.yaml new file mode 100644 index 0000000..c22ff2b --- /dev/null +++ b/content/level-design/modules/umgebung-informiert.yaml @@ -0,0 +1,485 @@ +id: umgebung-informiert +title: Umgebung als Information und visuelles Erzählen +level: 2 +minutes: 90 +summary: Wie ein Raum sagt, was man hier tun kann – Affordanz und Signifikant nach Don Norman, eine feste visuelle Sprache für begehbar, blockiert, gefährlich und benutzbar, die Stärke von Markierungen, sichtbare Zustände und Vorschau, kurz das Erzählen über Spuren und am Ende deine eigene Blockout-Vokabel. +place: unterwegs +goals: + - Du unterscheidest Affordanz und Signifikant nach Don Norman und findest in einem Raum Möglichkeiten ohne Zeichen und Zeichen ohne Möglichkeit. + - Du prüfst eine visuelle Sprache auf Konsistenz, sodass begehbar, blockiert, gefährlich, benutzbar und Hinweis je ein eigenes, gleichbleibendes Zeichen haben. + - Du ordnest Markierungen nach ihrer Sicherheit von subtil bis direkt und begründest, wie stark ein Pflichtweg und ein Nebenweg markiert sein sollen. + - Du machst Zustände und Ziele sichtbar und trennst Information („Was kann ich hier tun?“) von Erzählung („Was ist hier passiert?“). + - Du legst deine eigene Blockout-Vokabel aus Formen und Tonwerten fest, als Vorbereitung für den Blockout. +resources: + - title: Don Norman, „Signifiers, not affordances“ (2008) + url: https://jnd.org/signifiers-not-affordances/ + - title: The Level Design Book · Wayfinding + url: https://book.leveldesignbook.com/process/blockout/wayfinding + - title: The Level Design Book · Environment Art, „Readability“ + url: https://book.leveldesignbook.com/process/env-art#readability + - title: Jason Mitchell, „Connecting Visuals to Gameplay at Valve“ (MIGS 2008, Folien) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf + - title: GamesRadar+, Debatte um gelbe Markierungen (2023) + url: https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/ +lesson: | + Lehrbeispiel: Ein Lagerraum mit drei gleichen Türen. Zwei sind Kulisse und gehen nicht auf, eine führt weiter. Im Test läuft jeder Tester die Türen der Reihe nach an. Der erste erwischt zufällig gleich die richtige, der zweite probiert alle drei. Damion Schubert, Creative Director bei Boss Fight, hat genau das in der Debatte um gelbe Markierungen beschrieben: „Trying to open 30 doors to find one we can go through breaks immersion, because the tedium of the experience calls attention to the faults of the simulation.“ ([GamesRadar+](https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/)) + + Jeder Raum beantwortet die Frage „Was kann ich hier tun?“, ob du das planst oder nicht. Dieses Modul zeigt, wie eine Umgebung informiert: wie sich das, was möglich ist, von dem unterscheidet, was man sieht, wie eine feste visuelle Sprache aussieht, wie stark Markierungen sein sollen und wie Zustände und Ziele sichtbar werden. Kurz geht es auch darum, wie Spuren zugleich führen und erzählen. Am Ende legst du deine eigene Blockout-Vokabel fest. + + ## Affordanz und Signifikant: was möglich ist und was man sieht + + Der Psychologe J. J. Gibson hat den Begriff Affordanz (affordance) geprägt. Don Norman fasst ihn so zusammen: „the actions possible by a specific agent on a specific environment. To Gibson, affordances did not have to be perceivable or even knowable — they simply existed.“ Norman hat den Begriff 1988 ins Design gebracht und dabei wahrnehmbare Affordanzen gemeint. 2008 setzt er einen zweiten Begriff daneben, den Signifikanten (signifier): „A “signifier” is some sort of indicator, some signal in the physical or social world that can be interpreted meaningfully.“ Sein Schluss: „Forget affordances: what people need, and what design must provide, are signifiers.“ ([Signifiers, not affordances](https://jnd.org/signifiers-not-affordances/)) + + Im Spiel lassen sich beide sauber trennen. Die Affordanz steckt in den Regeln: Kollision, Tiefe des Wassers, ob eine Tür aufgeht. Der Signifikant ist das, was der Spieler davon sieht: Tonwert, Form, Kante, Licht. Was die Figur kann, steht im Code. Was der Spieler glaubt, dass sie kann, steht auf dem Bildschirm. Daraus ergeben sich vier Fälle: + + | Möglich? | Sichtbar? | Folge | + | --- | --- | --- | + | ja | ja | Der Spieler sieht die Möglichkeit und nutzt sie. | + | ja | nein | Versteckt: gut für ein Geheimnis, schlecht für den Pflichtweg. | + | nein | ja | Kulisse, die benutzbar aussieht: Der Spieler probiert und wird enttäuscht. | + | nein | nein | Wand, die wie eine Wand aussieht: kein Problem. | + + Der dritte Fall kostet Zeit und Vertrauen. Der Entwickler Pedro Braga nennt in derselben Debatte, was ihm erst im Playtest auffiel: „I have [to make] holes impossible to jump through twice as large otherwise people will be trying to make the jump for hours and get bored of the game.“ In der Draufsicht gilt das für Lücken und Abgründe. Das Ausweichen der Testszene trägt 66 Pixel, gut vier Tiles (Platzhalter, siehe [Ausweichen](/combat/ausweichen)). Ein Abgrund von drei Tiles kann dann überwindbar aussehen, ob er es ist oder nicht. Welche Breite was bedeutet, legen deine Regeln fest, und die Grafik muss es zeigen. + + Norman ergänzt zwei Dinge. Auch Fehlendes ist ein Zeichen, etwa ein leerer Bahnsteig, an dem der Zug schon weg ist. Und Zeichen entstehen auch ungewollt, als „accidental byproduct of the world“. Ein Muster im Boden, das wie ein Weg aussieht, ist ein Signifikant, auch wenn du es nur als Schmuck gezeichnet hast. + + > [!MERKE] Regel und Zeichen + > Die Kollision entscheidet, was möglich ist. Die Grafik entscheidet, was der Spieler für möglich hält. Prüf beides getrennt. + + ## Eine visuelle Sprache: eine Bedeutung, ein Zeichen + + Vor jedem Raum stellt der Spieler dieselben Fragen. Kann ich hier gehen? Sperrt das den Weg, die Sicht oder beides? Ist das gefährlich? Kann ich das benutzen? Soll ich hierhin? Eine visuelle Sprache gibt auf jede Frage im ganzen Spiel dieselbe Antwort. + + Valve hat für Team Fortress 2 eine Rangfolge solcher Fragen aufgeschrieben, die „Read Hierarchy“ ([Jason Mitchell, MIGS 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf)). Die erste Frage, „Team – Friend or Foe?“, beantwortet die Farbe. Die zweite, „Class – Run or Attack?“, beantworten unter anderem „Distinctive silhouettes“. Jede Frage hat ihren eigenen Kanal. Valve spricht dort über Figuren, nicht über Räume. Übertragen auf einen Blockout heißt das: Gib jeder Frage einen eigenen Kanal, etwa den Tonwert für begehbar und blockiert und die Form für Gefahr, und benutze keinen Kanal für zwei Fragen. + + Das Level Design Book fragt bei der Lesbarkeit eines Levels: „Can the player understand where they can go vs. can't go, should vs. shouldn't go?“ ([Readability](https://book.leveldesignbook.com/process/env-art#readability)). Als Mittel nennt es, Farben für eine Bedeutung zu reservieren, etwa „only explosive barrels are red!“. Ein Beispiel aus dem Buch: In The Last of Us Part II steht Efeu für geschlossene Gebäude, Gebäude zum Betreten sind frei davon. Das funktioniert laut Buch nur, „As long as all the designers and artists maintain consistency in how they use ivy“. + + Bedeutung entsteht dabei durch Wiederholung, nicht durch die Form an sich. Das Buch rät ausdrücklich ab: „shape and color psychology are not effective for level design“ ([Avoid shape and color psychology](https://book.leveldesignbook.com/process/env-art#avoid-shape-and-color-psychology)). Ein Dreieck ist nicht von sich aus gefährlich. Es wird gefährlich, wenn es im ganzen Spiel Gefahr bedeutet und der Spieler das gelernt hat. Wie du so etwas einführst, zeigt [Möglichkeiten einführen, sicher erproben, variieren](/level-design/einfuehren-variieren). + + Die Legende der Rasterkarten in diesem Kurs ist schon eine kleine visuelle Sprache. `#` sperrt Weg und Sicht nach dahinter, `o` und `~` sperren den Weg, aber nicht die Sicht. Das Level Design Book trennt genauso zwischen Abgründen und Flüssen, die „physically block movement without blocking line of sight“, und Wänden, die Bewegung und Sicht sperren. + + Eine Ausnahme ist erlaubt, wenn sie ein eigenes Zeichen hat. Eine Wand, durch die man gehen kann, braucht einen Hinweis, sonst bricht sie die Sprache. Das Buch nennt als subtiles Zeichen „subtle crack in ground or wall (Zelda)“. + + ## Wie stark markieren: von subtil bis direkt + + Das Level Design Book ordnet Hilfen zur Orientierung nach geschätzter Sicherheit, „a non-scientific estimate of the proportion of players will likely perceive and use the aid“ ([Wayfinding aids](https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids)). Einige Einträge aus seiner Tabelle: + + | Stufe | Sicherheit | Beispiele | + | --- | --- | --- | + | Subtle | 1–20 % | ungewöhnliches Detail wie ein Riss (10 %) | + | Coarse | 35–60 % | Licht und Farbe (40 %), Schilder in der Welt (40 %), Spuren (50 %) | + | Situational | 70–93 % | Reihen von Fundstücken, sichtbare Belohnungen in der Ferne (80 %) | + | Direct | 95–98 % | tiefe, breite Abgründe (95 %), feste Wände (98 %) | + + Zwei Dinge fallen auf. Schilder in der Welt stehen nur bei 40 %, mit dem Zusatz „easily mistaken for irrelevant set dressing“. Und selbst eine feste Wand überzeugt nicht jeden. Das Buch nennt Speedrunner und Spieler, die „wallhugging to try to find secrets“ jede Wand abtasten. + + Daraus folgt eine Faustregel: Ein Pflichtweg braucht mehr Sicherheit als ein Nebenweg. Was den Abschnitt beendet, darf nicht nur an einem Riss hängen. Was eine Belohnung für Aufmerksamkeit ist, darf leise sein. Zu viele laute Zeichen nehmen dem Spieler das Finden; wie du beim Überarbeiten nicht übermarkierst, zeigt [Überarbeiten](/level-design/ueberarbeiten). + + Licht ist ein starkes Mittel. Für Left 4 Dead notiert Valve: „Players tend to follow the light“. Dieselben Folien zeigen eine frühe Fassung mit „Too many areas of contrast“ und daneben die vereinfachte Beleuchtung der fertigen Fassung ([Mitchell, MIGS 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf)). Ein Hinweis wirkt nur, wenn wenig anderes mit ihm konkurriert. Im grauen Blockout ist das leicht, mit der Ausgestaltung wird es schwer. Schubert nennt das „one of those counterintuitive cases where realism is less immersive“. Halte deine Sprache deshalb auch, wenn Grafik dazukommt ([Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung)). + + > [!PRAXIS] Was im Playtest nicht offensichtlich war + > In der Debatte um gelbe Markierungen 2023 listete Pedro Braga auf, welche „things that seemed obvious to me but weren't during playtests“ er nachbessern musste. Eines davon: „Players won't pick up a necessary item even though it's on a pedestal... So I make it [floating and glowing] instead.“ Palle Hoffstein, Artist bei The Division, erzählt halb im Scherz, er habe einmal gedacht: „we don't need the signs and breadcrumbs. Players aren't stupid. Let them explore.“ Nach Playtests hieß es: „put it back and let's never speak of this again.“ ([GamesRadar+](https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/)) Beide haben die Stärke ihrer Zeichen am Verhalten der Tester eingestellt, nicht an der eigenen Erwartung. + + ## Zustände und Ziele sichtbar machen + + Norman schreibt, Menschen brauchen „some sign of what it is for, what is happening, and what the alternative actions are“. Im Raum heißt das: Ein Ding mit Zuständen zeigt, in welchem Zustand es ist. Eine Tür kann offen sein, geschlossen, verschlossen bis zu einer Bedingung oder Kulisse, die nie aufgeht. Jeder dieser Zustände braucht ein eigenes Zeichen, und die Kulisse sollte nicht wie eine Tür aussehen, die gerade nur zu ist. + + Eine Änderung des Zustands muss der Spieler sehen, wenn sie passiert. In der Draufsicht heißt das: Ursache und Wirkung liegen auf einem Bildschirm, oder die Wirkung wird auf andere Weise gezeigt. Hält die Kamera die Figur am Schalter mittig, sieht der Spieler rund 10 Tiles zu jeder Seite. Liegt das Tor 16 Tiles neben dem Schalter, ist es nicht im Bild, wenn es aufgeht. + + Auch Ziele kann der Raum zeigen, bevor der Spieler sie erreicht. In Portal trägt der Spieler einen Würfel durch ein langes Level und legt ihn am Ende auf einen Schalter. Nach einer gescheiterten ersten Fassung steht auf den Folien von Valve: „Always see the button.“ ([Portal Post-Mortem, GDC 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)). Das Level Design Book führt „collectibles or powerups visible in the distance“ bei 80 % Sicherheit. Hidemaro Fujibayashi hat für Breath of the Wild von 引力 gesprochen, einer Anziehungskraft. Laut dem Bericht von 4Gamer definiert er sie als 「プレイヤーにとってお得であるがゆえに，そこに向かいたくなってしまう力」, in eigener Übersetzung: „eine Kraft, die den Spieler dorthin ziehen will, weil es sich für ihn lohnt“ ([4Gamer, 2017](https://www.4gamer.net/games/341/G034168/20170901120/)). + + Verstecken bleibt erlaubt. Dan Taylor schreibt, es sei „entirely appropriate to hide areas from the player, to add depth and replayability through exploration (as long as you provide the necessary visual or narrative clues)“ ([Ten Principles, Teil 1](https://www.gamedeveloper.com/design/ten-principles-of-good-level-design-part-1-)). Versteckt ist etwas, dessen Zeichen leise ist, nicht etwas ganz ohne Zeichen. + + ## Spuren, die führen und erzählen + + Information beantwortet „Was kann ich hier tun?“. Erzählung beantwortet „Was ist hier passiert?“. Eine Spur kann beides. Das Level Design Book führt Erzählen über die Umgebung als Orientierungshilfe mit 50 % Sicherheit: „trail of blood on floor (Doom), trail of destruction (BioShock)... clear authored path formed by a character or event“. Norman nennt Trampelpfade, „desire lines“, als Zeichen, das andere Menschen hinterlassen haben. + + Soll eine Spur führen, muss sie zuerst als Weg lesbar sein: zusammenhängend, in Laufrichtung und mit einem Ende, das man erreichen kann. Ihre Bedeutung kommt danach. Eine Spur, die nur erzählt, darf leiser sein, denn niemand muss ihr folgen. Wie Räume über Spuren erzählen, zeigt [Erzählen über Handlung, Umgebung und Folgen](/narrative/umgebung-erzaehlt). Hier zählt, wohin die Spur führt. + + Ein Spiel kann ganz ohne Text auskommen. Heart Machine hat für Hyper Light Drifter früh entschieden: „We decided pretty much at the beginning as a full team we did not want any text in the game whatsoever“ (Teddy Diefenbach bei [Kill Screen, 2014](https://www.killscreen.com/building-wordless-world-hyper-light-drifter/)). Dann muss die Umgebung alles tragen, was sonst eine Texttafel sagt. Auch Klang kann ein Hinweis sein; das behandelt der spätere Sound-Kurs. + + ## Deine Blockout-Vokabel + + Bevor du in Godot einen Blockout baust ([Blockout in Godot](/level-design/blockout)), legst du fest, welche Form und welcher Tonwert was bedeutet. Diese Liste ist deine Blockout-Vokabel. Im Blockout gibt es keine fertige Grafik, nur graue Formen und flache Platzhalter-Tiles, deshalb trägt der Tonwert die Hauptlast. Warum der Tonwert vor der Farbe kommt, erklären [Licht und Tonwerte](/pixelart/licht-werte) und [Komposition und Blickführung](/level-design/blickfuehrung). + + Die Vorlage hat sechs Zeilen. „Blockiert hoch“ sperrt Weg und Sicht, „blockiert tief“ nur den Weg: + + ```text + Kategorie Form Tonwert + begehbar + blockiert hoch + blockiert tief + gefährlich + benutzbar + Hinweis + ``` + + Fünf Regeln halten die Vokabel brauchbar: + + - Jede Kategorie hat genau ein Zeichen, jedes Zeichen genau eine Bedeutung. + - Begehbar und blockiert unterscheiden sich im Tonwert, damit es auch in Graustufen und mit zusammengekniffenen Augen lesbar bleibt ([Lesbarkeit prüfen](/pixelart/lesbarkeit-pruefen)). + - Gefährlich unterscheidet sich von blockiert auch in der Form, nicht nur im Tonwert. Sonst liest der Spieler eine Gefahr als Wand oder eine Wand als Gefahr. + - Das Hinweis-Zeichen ist selten. Es markiert die Stellen, die in deiner Absichtsnotiz unter „Hinweise“ stehen, und nichts sonst. + - Die Vokabel gilt für den ganzen Abschnitt und bleibt, wenn später Grafik dazukommt. + + Welche Formen und Tonwerte du wählst, entscheidest du. Lass dir die Vokabel nicht von einer KI vorschlagen. Sie ist die erste Designentscheidung deines Blockouts. + + > [!INTERVIEW] „Was ist der Unterschied zwischen Affordanz und Signifikant?“ + > Die Affordanz ist, was möglich ist, in einem Spiel also das, was Kollision und Regeln erlauben. Der Signifikant ist das wahrnehmbare Zeichen dafür. Don Norman rät, sich um Signifikanten zu kümmern, weil Menschen nur nutzen, was sie erkennen. Im Level prüfe ich beides getrennt: Stimmt die Kollision, und sieht der Spieler, was sie erlaubt? Heikel sind die Stellen, an denen beides auseinanderläuft, also Kulisse, die benutzbar aussieht, und Wege, die wie Wand aussehen. + + ## Häufige Fehler + + - **Kulisse sieht benutzbar aus.** Drei gleiche Türen, nur eine geht auf. Gib der Kulisse ein eigenes Zeichen oder mach sie zur Wand. + - **Ein Zeichen, zwei Bedeutungen.** Dieselbe Farbe steht für Gefahr und für Belohnung. Der Spieler lernt die eine Regel und erlebt die andere. + - **Ausnahme ohne Zeichen.** Eine einzelne begehbare Wand ohne Riss. Spieler lernen daraus, dass Wände lügen, und laufen jede Wand ab. + - **Pflichtweg nur subtil markiert.** Der einzige Weg weiter hängt an einem Zeichen mit 10 % Sicherheit. Prüf die Stufe jedes Pflichtwegs. + - **Zustand ändert sich außerhalb des Bildes.** Schalter und Tor liegen auf verschiedenen Bildschirmen, und nichts zeigt die Änderung. + - **Formpsychologie statt Wiederholung.** „Rund wirkt freundlich“ ersetzt keine Regel, die der Spieler gelernt hat. + + ## Zusammenfassung + + - Affordanz ist, was möglich ist; ein Signifikant ist das wahrnehmbare Zeichen dafür. Im Spiel entscheidet die Kollision das eine, die Grafik das andere. + - Kulisse, die benutzbar aussieht, kostet Zeit und Vertrauen. Versteckte Möglichkeiten passen zu Geheimnissen, nicht zu Pflichtwegen. + - Eine visuelle Sprache gibt jeder Frage einen eigenen Kanal und jeder Bedeutung genau ein Zeichen. Bedeutung entsteht durch Wiederholung. + - Das Level Design Book ordnet Hilfen von subtil (1–20 %) bis direkt (95–98 %). Pflichtwege brauchen mehr Sicherheit als Nebenwege. + - Zustände brauchen eigene Zeichen, und Änderungen müssen im Bild passieren. Ein sichtbares Ziel zieht den Spieler dorthin, wo es sich lohnt. + - Information beantwortet „Was kann ich hier tun?“, Erzählung „Was ist hier passiert?“. Eine führende Spur muss zuerst als Weg lesbar sein. + - Deine Blockout-Vokabel legt Form und Tonwert für begehbar, blockiert, gefährlich, benutzbar und Hinweis fest. +exercises: + - id: luecke-in-der-wand + type: choice + title: Die Lücke, die keiner sieht + prompt: | + Lehrbeispiel: In der Wand eines Hofs ist eine Lücke von zwei Tiles, durch die die Figur passt. Die Lücke hat denselben Tonwert wie die Wand daneben, nur die Kollision fehlt. Alle Tester laufen vorbei. Wie beschreibst du die Stelle mit Normans Begriffen? + options: + - text: Eine Affordanz ohne Signifikant. Möglich ist der Durchgang, sichtbar ist er nicht. + correct: true + why: Die Regeln erlauben den Weg, die Grafik zeigt ihn nicht. Für ein gewolltes Geheimnis kann das richtig sein, für einen Pflichtweg nicht. + - text: Ein Signifikant ohne Affordanz. Sichtbar ist ein Durchgang, möglich ist er nicht. + correct: false + why: Umgekehrt. Hier ist der Durchgang möglich, aber nicht zu sehen. + - text: Ein Fehler in der Kollision, der sich nur im Code beheben lässt. + correct: false + why: Die Kollision tut, was sie soll. Das Problem liegt im Zeichen, also in der Grafik. + - text: Eine zu starke Markierung, die Tester abschreckt. + correct: false + why: Es gibt gar keine Markierung. Die Lücke sieht aus wie Wand. + explanation: | + Gibson nennt das, was eine Umgebung einer Figur erlaubt, Affordanz. Norman betont, dass Menschen nur nutzen, was sie über ein Zeichen erkennen. Ob die Lücke ein Fehler ist, entscheidet deine Absicht. Soll sie ein Geheimnis sein, braucht sie ein leises Zeichen, etwa einen Riss. Soll sie der Weg sein, braucht sie ein deutliches. + hints: + - Was erlauben die Regeln, und was zeigt der Bildschirm? + resources: + - title: Don Norman, „Signifiers, not affordances“ + url: https://jnd.org/signifiers-not-affordances/ + + - id: drei-tueren + type: choice + title: Drei Türen, eine geht auf + prompt: | + Lehrbeispiel: Ein Lager mit drei gleich aussehenden Türen. Zwei sind Kulisse, eine führt weiter. Welche Änderungen machen den Zustand der Türen lesbar? + options: + - text: Die beiden Kulissentüren werden zu Wand, etwa mit einem Regal davor, sodass sie keine Türform mehr haben. + correct: true + why: Was nie aufgeht, sieht nicht mehr wie eine Tür aus. Der Signifikant passt wieder zur Affordanz. + - text: Die echte Tür bekommt den hellen Rahmen, den im ganzen Abschnitt nur Türen haben, die aufgehen. + correct: true + why: Das ist ein Zeichen mit genau einer Bedeutung, wenn du es überall so hältst. + - text: Über der echten Tür hängt ein Schild mit der Aufschrift „Ausgang“, sonst bleibt alles gleich. + correct: false + why: Schilder in der Welt stehen im Level Design Book bei 40 % und werden leicht für Dekoration gehalten. Die Kulissentüren sehen weiter benutzbar aus. + - text: Alles bleibt gleich. Die Tester sollen ausprobieren, das gehört zur Erkundung. + correct: false + why: Damion Schubert beschreibt genau das als Bruch der Immersion, weil das Ausprobieren die Schwächen der Simulation zeigt. + explanation: | + Ein Ding mit Zuständen zeigt, in welchem Zustand es ist. Kulisse, die wie eine geschlossene Tür aussieht, verspricht eine Möglichkeit, die es nicht gibt. Zwei Wege führen heraus: Die Kulisse verliert ihr Türzeichen, oder die echte Tür bekommt ein Zeichen, das im ganzen Abschnitt nur echte Türen tragen. Beides zusammen ist am deutlichsten. + hints: + - Zwei Antworten sind richtig. + resources: + - title: GamesRadar+, Debatte um gelbe Markierungen (Schubert) + url: https://www.gamesradar.com/debate-over-resident-evil-4-remakes-yellow-paint-resurfaces-as-devs-explain-just-how-much-players-really-need-realism-is-less-immersive/ + + - id: information-oder-erzaehlung + type: choice + title: Was kann ich hier tun? + prompt: | + Lehrbeispiel: Ein Wachraum mit mehreren Details. Welche Details beantworten vor allem die Frage „Was kann ich hier tun?“ + options: + - text: Ein heller Rahmen an der einzigen Tür, die aufgeht. + correct: true + why: Das Zeichen sagt, wo es weitergeht. Es erzählt nichts über die Vergangenheit. + - text: Ein feiner Riss in der Wand, hinter der ein Durchgang liegt. + correct: true + why: Ein leises Zeichen für eine Möglichkeit, also Information, auch wenn sie leise ist. + - text: Fußspuren im Staub, die vom Eingang zu einer Falltür führen. + correct: true + why: Die Spur führt zur Falltür und informiert damit. Zugleich erzählt sie, dass jemand hier war. + - text: Ein umgestürzter Stuhl und eine halb leere Tasse auf dem Tisch. + correct: false + why: Das erzählt, dass jemand den Raum plötzlich verlassen hat. Was der Spieler tun kann, sagt es nicht. + - text: Ein verblasstes Bild an der Wand. + correct: false + why: Ein Detail für die Frage „Was ist hier passiert?“, keine Information über Wege oder Möglichkeiten. + explanation: | + Information sagt, was möglich ist und wohin es geht. Erzählung sagt, was hier geschehen ist. Die Fußspuren tun beides, und so eine Spur ist nützlich, solange sie zuerst als Weg lesbar ist. Die Erzählung selbst behandelt [Erzählen über Handlung, Umgebung und Folgen](/narrative/umgebung-erzaehlt). + hints: + - Drei Antworten sind richtig. + - Frag bei jedem Detail, ob es einen Weg oder eine Handlung zeigt. + resources: + - title: The Level Design Book · Wayfinding, „Coarse“ (environmental storytelling) + url: https://book.leveldesignbook.com/process/blockout/wayfinding#coarse-35-60-certainty + + - id: hilfen-nach-sicherheit + type: order + title: Von leise bis laut + prompt: | + Bring diese Hilfen in die Reihenfolge der geschätzten Sicherheit aus dem Level Design Book, von der leisesten zur sichersten. + lang: prose + lines: | + Ein ungewöhnliches Detail, etwa ein feiner Riss in der Wand. + Licht und Farbe, etwa ein hell erleuchteter Ausgang. + Eine Spur, die eine Figur oder ein Ereignis hinterlassen hat. + Eine Reihe von Fundstücken, die zum Ziel führt. + Ein tiefer, breiter Abgrund, der den Weg sperrt, aber nicht die Sicht. + Eine feste Wand, die Weg und Sicht sperrt. + explanation: | + Die Tabelle des Level Design Book nennt für das ungewöhnliche Detail 10 %, für Licht und Farbe 40 %, für Spuren 50 %, für Reihen von Fundstücken 80 %, für tiefe, breite Abgründe 95 % und für feste Wände 98 %. Das Buch nennt die Zahlen selbst eine grobe Schätzung. Sie helfen dir, die Stärke eines Zeichens zu seinem Zweck zu passen: Pflichtweg weiter unten in der Liste, Geheimnis weiter oben. + hints: + - Was den Spieler körperlich aufhält, steht am Ende. + resources: + - title: The Level Design Book · Wayfinding aids + url: https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids + + - id: zeichen-doppelt + type: output + title: Ein Zeichen zu viel + prompt: | + Du hast in einem Raum notiert, welches Zeichen welche Bedeutung trägt. Das Modell sucht Zeichen mit mehr als einer Bedeutung. Was gibt es aus? + lang: python + code: | + funde = [("rot", "gefährlich"), + ("hell", "begehbar"), + ("rot", "Belohnung"), + ("Kreis", "benutzbar"), + ("hell", "begehbar"), + ("Gitter", "blockiert")] + je = {} + for z, bed in funde: + je.setdefault(z, set()) + je[z].add(bed) + doppelt = [z for z in je + if len(je[z]) > 1] + print(len(je), doppelt) + expected: | + 4 ['rot'] + hints: + - "`set()` speichert jede Bedeutung nur einmal. „hell, begehbar“ kommt zweimal vor und zählt als eine." + - Es gibt vier verschiedene Zeichen. + explanation: | + Vier Zeichen kommen vor: rot, hell, Kreis und Gitter. Nur „rot“ hat zwei Bedeutungen, Gefahr und Belohnung. Ein Spieler, der Rot als Gefahr gelernt hat, meidet die Belohnung, oder er lernt, dass Rot nichts Sicheres bedeutet. Die umgekehrte Prüfung gehört auch dazu: Hat eine Bedeutung mehrere Zeichen? Das prüft das Modell nicht. + resources: + - title: Python · dict.setdefault + url: https://docs.python.org/3/library/stdtypes.html#dict.setdefault + + - id: stufen-je-weg + type: output + title: Welcher Weg ist lauter? + prompt: | + Hinweise eines Lehrbeispiels mit der Sicherheit aus der Tabelle des Level Design Book. Licht am Tor, Riss in der Wand und Schild am Tor liegen am Pflichtweg, ein Fundstück in Sicht und eine Spur am Boden am Nebenweg. Das Modell zählt je Weg die Hinweise ab 35 % und nennt den stärksten Wert. Was gibt es aus? + lang: python + code: | + hinweise = [ + ("Pflicht", "Licht", 40), + ("Pflicht", "Riss", 10), + ("Pflicht", "Schild", 40), + ("Neben", "Fundstück", 80), + ("Neben", "Spur", 50), + ] + for weg in ("Pflicht", "Neben"): + werte = [p for w, _, p in + hinweise if w == weg] + stark = [p for p in werte + if p >= 35] + print(weg, len(stark), + max(werte)) + expected: | + Pflicht 2 40 + Neben 2 80 + hints: + - Der Riss liegt unter 35 und zählt nicht mit. + - "`max` nimmt alle Werte des Wegs, auch den Riss." + explanation: | + Beide Wege haben zwei Hinweise ab 35 %, aber der stärkste Hinweis im Raum liegt auf dem Nebenweg. Ein Fundstück, das man von Weitem sieht, zieht stärker als Licht und Schild am Tor. Wenn deine Absicht ist, dass der Spieler zuerst durchs Tor geht, arbeitet dieser Raum gegen dich. Die Zahlen sind grobe Schätzungen, aber sie zeigen dir, wo du im Playtest hinsehen musst. + resources: + - title: The Level Design Book · Wayfinding aids + url: https://book.leveldesignbook.com/process/blockout/wayfinding#wayfinding-aids + + - id: begriffe-information + type: gap + title: Möglichkeit, Zeichen, Sicherheit + prompt: | + Ergänze die Begriffe aus der Lektion. + lang: prose + code: | + Was eine Umgebung einer Figur tatsächlich zu tun erlaubt, nannte J. J. Gibson ⟦Affordanz⟧. Das wahrnehmbare Zeichen dafür nennt Don Norman ⟦Signifikant⟧. Das Level Design Book ordnet Hilfen zur Orientierung nach geschätzter ⟦Sicherheit⟧, von subtil bis direkt. Die Frage „Was kann ich hier tun?“ beantwortet die Umgebung als ⟦Information⟧, die Frage „Was ist hier passiert?“ als ⟦Erzählung⟧. + gaps: + - label: was möglich ist + hint: Englisch affordance. + accept: ["Affordance", "Affordanzen"] + - label: was man sieht + hint: Englisch signifier. + accept: ["Signifier", "Signifikanten"] + - label: Maß der Ordnung + hint: Das Buch spricht von „% certainty“. + accept: ["certainty", "Gewissheit", "Wahrscheinlichkeit"] + - label: erste Frage + hint: Das Thema dieses Moduls. + accept: ["Informationen", "Hinweis"] + - label: zweite Frage + hint: Das Thema von „umgebung-erzaehlt“ im Narrative-Kurs. + accept: ["Erzählen", "Geschichte", "Environmental Storytelling", "Storytelling"] + explanation: | + Affordanz und Signifikant trennen das Mögliche vom Sichtbaren. Die Sicherheit des Level Design Book ist eine grobe Schätzung, wie viele Spieler eine Hilfe bemerken und nutzen. Information und Erzählung sind zwei Fragen an denselben Raum; eine Spur kann beide beantworten. + resources: + - title: Don Norman, „Signifiers, not affordances“ + url: https://jnd.org/signifiers-not-affordances/ + + - id: vokabel-doppelt + type: bug + title: Zwei Kategorien, ein Zeichen + prompt: | + Lehrbeispiel: eine Blockout-Vokabel. Die Zeile für die hohe Wand steht seit dem ersten Entwurf fest. Eine andere Zeile macht zwei Kategorien ununterscheidbar. Finde sie. + lang: text + code: | + begehbar: hell, glatt + Wand hoch: dunkel, voll + Hindernis: mittel, Kreuz + Gefahr: dunkel, voll + benutzbar: mittel, Kreis + Hinweis: sehr hell, Raute + lines: [4] + explanation: | + Gefahr und hohe Wand haben denselben Tonwert und dieselbe Form. Der Spieler liest jede Gefahr als Wand und hält Abstand, oder er lernt, dass Wände wehtun können. Mindestens die Form muss sich unterscheiden, besser beides. Hindernis und benutzbar teilen sich den Tonwert, unterscheiden sich aber in der Form; das ist erlaubt, solange die Form deutlich genug ist. + hints: + - Vergleiche die Zeilen paarweise, Tonwert und Form zusammen. + resources: + - title: The Level Design Book · Environment Art, „Color and value“ + url: https://book.leveldesignbook.com/process/env-art#color-and-value + + - id: pflichtweg-subtil + type: bug + title: Der einzige Weg ist leise + prompt: | + Lehrbeispiel: Hinweise aus einer Absichtsnotiz für einen Lagerhof. Der Hof hat genau einen Weg weiter, den Durchbruch im Osten. Eine Zeile passt in ihrer Stärke nicht zu ihrem Zweck. Finde sie. + lang: prose + code: | + Hohe Mauer rings um den Hof: sperrt Weg und Sicht, damit der Hof nur über den Durchbruch verlassen wird. + Fundstück halb sichtbar in der Nische West: Belohnung für Neugier, Nebenweg. + Feiner Riss in der Ostwand: einziges Zeichen für den Durchbruch, Pflichtweg. + Brunnen in der Mitte: Landmarke, an der sich die Wege treffen. + lines: [3] + explanation: | + Ein feiner Riss steht im Level Design Book bei etwa 10 %. Für ein Geheimnis passt das. Für den einzigen Weg weiter heißt es, dass die meisten Spieler den Hof nicht verlassen. Der Pflichtweg braucht eine stärkere Hilfe dazu, etwa Licht am Durchbruch oder eine Sichtlinie auf das, was dahinter liegt. Der leise Riss darf bleiben, als zusätzliches Zeichen. + hints: + - Welche Zeile nennt einen Pflichtweg? + - Wie sicher ist ein Riss laut der Tabelle? + resources: + - title: The Level Design Book · Wayfinding, „Subtle“ + url: https://book.leveldesignbook.com/process/blockout/wayfinding#subtle-1-20-certainty + + - id: lesehierarchie + type: explain + title: Valves Lesehierarchie im Blockout + prompt: | + Auszug aus Jason Mitchells Folien zu Team Fortress 2. Erkläre in drei bis fünf Sätzen, welches Prinzip dahintersteht und wie du es auf die Blockout-Vokabel eines Top-down-Abschnitts überträgst. + lang: prose + code: | + Read Hierarchy + Team – Friend or Foe? Color + Class – Run or Attack? Distinctive silhouettes, Body proportions, Weapons + Selected weapon – What’s he packin’? Highest contrast at chest level, where weapon is held + points: + - Die Fragen des Spielers stehen in einer Rangfolge, die wichtigste zuerst. + - Jede Frage hat ihren eigenen Kanal, etwa Farbe, Silhouette oder Kontrast an einer Stelle. + - Im Blockout bekommt die wichtigste Frage, etwa „Kann ich hier gehen?“, den stärksten Kanal, meist den Tonwert. + - Kein Kanal trägt zwei Fragen, sonst widersprechen sich die Antworten. + explanation: | + Valve hat die Fragen, die ein Spieler bei einer Figur stellt, nach Wichtigkeit geordnet und jeder einen Kanal gegeben: Farbe für Freund oder Feind, Silhouette für die Klasse, Kontrast an der Brust für die Waffe. Die Folien sprechen über Figuren, das Prinzip lässt sich aber auf Räume übertragen. Im Blockout ist die wichtigste Frage meist, wo man gehen kann, und sie bekommt den Tonwert, weil der auch in Graustufen und auf Distanz trägt. Gefahr bekommt einen anderen Kanal, etwa die Form, und benutzbare Dinge wieder einen anderen. Teilen sich zwei Fragen einen Kanal, muss der Spieler raten, welche gemeint ist. + hints: + - Lies jede Zeile als Frage und Antwortkanal. + resources: + - title: Jason Mitchell, „Connecting Visuals to Gameplay at Valve“ (MIGS 2008) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/MIGS08_ConnectingVisualsToGameplay.pdf + + - id: ohne-text + type: explain + title: Lehren ohne Texttafel + prompt: | + Alex Preston, der Gründer von Heart Machine, im Interview über Hyper Light Drifter, ein Spiel ohne Text. Erkläre in drei bis fünf Sätzen, was diese Entscheidung für die Umgebung bedeutet und wie du prüfst, ob sie trägt. + lang: prose + code: | + Just today we were talking about teaching people certain functions, and there’s mechanics in our game that can be relatively esoteric, and the best way to do that usually in a game is just blurt some text on the screen [...] but in our game we can’t tell people that with text so we have to find a different way to do that, and that requires more effort from us. + points: + - Ohne Text muss die Umgebung zeigen, was möglich ist und wie es funktioniert. + - Das kostet mehr Arbeit, weil jede Information ein eigenes Zeichen im Raum oder in der Handlung braucht. + - Ob ein Zeichen ohne Text verstanden wird, zeigt nur das Verhalten von Testern, die das Spiel nicht kennen. + - Was keine Texttafel erklärt, steht als Hinweis in der Absichtsnotiz und wird im Playtest geprüft. + explanation: | + Ein Satz auf dem Bildschirm ist das billigste Werkzeug, eine Funktion zu erklären. Wer darauf verzichtet, muss dieselbe Information über Raum, Form, Licht oder eine gespielte Situation vermitteln, und Preston sagt offen, dass das mehr Aufwand ist. Jede dieser Informationen wird so zu einem Hinweis im Sinne dieses Kurses: Sie braucht einen Ort, ein Zeichen und einen Zweck. Ob sie ankommt, prüfst du nur im Test mit Menschen, die das Spiel nicht kennen, denn du selbst weißt die Antwort schon. Ob dein Spiel Text nutzt, entscheidest du. + hints: + - Was übernimmt die Umgebung, wenn die Texttafel fehlt? + resources: + - title: Unwinnable, „Interview with Alex Preston“ (2015) + url: https://unwinnable.com/2015/12/02/interview-with-alex-preston-the-creator-of-hyper-light-drifter/ + + - id: raum-inventur + type: practice + title: Die Sprache eines fremden Raums + prompt: | + Wähle einen Raum aus einem veröffentlichten Top-down-Spiel, das du kennst, oder ein Standbild aus einem Video. Notiere in höchstens fünf Stichpunkten, welches Zeichen dort für begehbar, blockiert, gefährlich und benutzbar steht. Such eine Stelle, an der ein Zeichen zwei Bedeutungen haben könnte oder Kulisse benutzbar aussieht. + lang: prose + starter: | + Spiel, Raum: + begehbar / blockiert: + gefährlich: + benutzbar: + Zweifelhafte Stelle: + checklist: + - Spiel und Raum sind genannt. + - Zu jeder der vier Kategorien steht ein konkretes Zeichen (Tonwert, Form, Kante, Licht oder Bewegung). + - Du hast eine zweifelhafte Stelle benannt oder begründet, warum du keine gefunden hast. + - Was du vermutest, ist als Vermutung markiert, etwa mit „vermutlich“. + explanation: | + Veröffentlichte Spiele haben fast immer eine feste Sprache, auch wenn sie nirgends aufgeschrieben ist. Wenn du sie ausliest, siehst du, welche Kanäle das Spiel für welche Frage nutzt. Die zweifelhafte Stelle ist der wertvollste Teil: Dort hat das Spiel eine Ausnahme gemacht oder eine Bedeutung doppelt belegt, und du kannst prüfen, ob es das durch ein anderes Zeichen auffängt. + hints: + - Schau zuerst auf den Boden. Wo hört begehbar auf? + resources: + - title: The Level Design Book · Environment Art, „Readability“ + url: https://book.leveldesignbook.com/process/env-art#readability + + - id: eigene-vokabel + type: practice + title: Deine Blockout-Vokabel + prompt: | + Leg deine eigene Blockout-Vokabel fest, eine Zeile je Kategorie, mit Form und Tonwert. Welche Formen und Tonwerte du nimmst, entscheidest du. Du baust sie später in Godot als Platzhalter-Tiles ([Blockout in Godot](/level-design/blockout)). + lang: prose + starter: | + begehbar: + blockiert hoch (Weg und Sicht): + blockiert tief (nur Weg): + gefährlich: + benutzbar: + Hinweis: + checklist: + - Jede der sechs Kategorien hat eine Form und einen Tonwert. + - Keine zwei Kategorien teilen sich Form und Tonwert zugleich. + - Begehbar und beide Arten von blockiert unterscheiden sich im Tonwert. + - Gefährlich unterscheidet sich von blockiert auch in der Form. + - Du kommst mit höchstens fünf Tonwerten aus. + - Du hast notiert, wofür das Hinweis-Zeichen benutzt wird und wofür nicht. + explanation: | + Die Vokabel ist die Legende deines Blockouts. Mit wenigen Tonwerten bleibt sie in Graustufen lesbar, und weil jede Kategorie ein eigenes Zeichen hat, kannst du im Playtest unterscheiden, ob ein Tester ein Zeichen übersehen oder falsch gelesen hat. Halte die Vokabel neben der Absichtsnotiz fest, damit du sie bei der Ausgestaltung wiederfindest. + hints: + - Fang mit begehbar und blockiert hoch an. Sie sind die häufigsten Tiles. + resources: + - title: The Level Design Book · Environment Art, „Avoid shape and color psychology“ + url: https://book.leveldesignbook.com/process/env-art#avoid-shape-and-color-psychology diff --git a/content/level-design/modules/werkstatt-abschnitt.yaml b/content/level-design/modules/werkstatt-abschnitt.yaml new file mode 100644 index 0000000..69754fa --- /dev/null +++ b/content/level-design/modules/werkstatt-abschnitt.yaml @@ -0,0 +1,475 @@ +id: werkstatt-abschnitt +title: "Werkstatt: dein begehbarer Abschnitt" +level: 3 +minutes: 240 +summary: Der ganze Zyklus an einem Abschnitt, den du selbst auswählst – Umfang, Absichtsnotiz, Skizze, Blockout, eine Testrunde mit mindestens drei Testern ohne Erklärung, ein Vergleich von Absicht und Verhalten mit Spuren, mindestens eine Überarbeitung und auf Wunsch die Ausgestaltung mit Regressionstest. +place: pc +goals: + - Du wählst einen Abschnitt von 2 bis 4 Bildschirmen mit einer einzigen Absicht und schreibst sie als Absichtsnotiz mit beobachtbaren Zeichen. + - Du übersetzt die Zeichen deiner Absichtsnotiz in Zonen und Zahlen, die der Wegschreiber misst. + - Du baust Skizze und Blockout, testest mit mindestens drei Personen, ohne zu erklären, und sicherst jede Runde mit Tag, Protokollen und Spuren. + - Du vergleichst Absicht und Verhalten in einer Tabelle und trennst Beobachtung von Deutung. + - Du überarbeitest eine Stelle pro Runde, prüfst die Änderung mit neuen Testern und dokumentierst den Weg in einer Werkstattmappe. +resources: + - title: The Level Design Book · Blockout, „How to blockout“ + url: https://book.leveldesignbook.com/process/blockout + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting + - title: Jakob Nielsen · Why You Only Need to Test with 5 Users (NN/g, 2000) + url: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ + - title: Kim Swift, Erik Wolpaw · Portal Post-Mortem (Folien, GDC 2008) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf +lesson: | + Dieses Modul bringt keinen neuen Stoff. Es lässt dich den Zyklus des Kurses einmal ganz durchlaufen, an einem Abschnitt, den du auswählst: Absicht notieren, skizzieren, blocken, testen, vergleichen, überarbeiten, wieder testen. Am Ende hast du einen Abschnitt, der nachweislich tut, was du wolltest, oder eine begründete neue Absicht. Dazu eine Mappe, die zeigt, wie du dahin gekommen bist. + + Plane dafür mehrere Tage ein. Am PC sitzt du ungefähr vier Stunden; dazu kommt die Zeit, bis drei Menschen für einen Test Zeit haben. Welchen Ort du baust, ob aus deinem Spiel oder ein neutraler Übungsraum, entscheidest du. Der Kurs gibt dir keinen vor. Eine KI darf dir Skripte schreiben, Dateien sortieren und Tabellen formatieren. Die Absicht, das Layout, die Hinweise und die Deutung der Beobachtungen sind deine Arbeit. + + ## Der Zyklus im Überblick + + Das Level Design Book fasst den Ablauf für einen Blockout in Schritten zusammen: skizzieren, testen, „Diverge, iterate, and playtest again“, wiederholen ([Blockout](https://book.leveldesignbook.com/process/blockout)). In diesem Kurs sieht das so aus: + + | Schritt | Grundlage | Ergebnis | + | --- | --- | --- | + | 1. Umfang wählen | [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze) | 2 bis 4 Bildschirme, eine Absicht | + | 2. Absichtsnotiz | [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze) | Notiz mit beobachtbaren Zeichen | + | 3. Skizze | [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze) | Karopapier im Tile-Maßstab, erwarteter Weg | + | 4. Blockout | [Blockout in Godot](/level-design/blockout) | Abschnitt mit Tag `r1`, Selbsttest | + | 5. Testrunde 1 | [Beobachten, ohne zu erklären](/level-design/playtest-methode), [Playtest am PC](/level-design/playtest-godot) | 3 Protokolle, Wege, Übersichtsbild | + | 6. Vergleich | dieses Modul | Tabelle Absicht gegen Verhalten | + | 7. Überarbeitung | [Überarbeiten](/level-design/ueberarbeiten) | eine Änderung, Tag `r2` | + | 8. Testrunde 2 | wie Runde 1, neue Tester | zweiter Vergleich | + | 9. Ausgestaltung (optional) | [Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung) | Dressing, Regressionstest | + | 10. Rückblick | dieses Modul | Werkstattmappe | + + Die Übungen dieses Moduls folgen diesen Schritten. Jede Praxisaufgabe hat eine Checkliste, die prüft, ob ein Schritt vollständig ist, nicht ob dein Abschnitt gefällt. + + ## Umfang: klein genug, um ihn dreimal zu bauen + + Ein Abschnitt von 2 bis 4 Bildschirmen ist klein genug, um ihn nach jedem Test umzubauen, und groß genug für eine echte Entscheidung des Spielers. Mit den Platzhaltern des Kurses, 320 × 180 Pixel und 90 Pixel pro Sekunde, quert die Figur einen Bildschirm in 3,6 Sekunden. Ein Tester, der sucht, braucht für 2 bis 4 Bildschirme eher ein bis drei Minuten. Mit Begrüßung und ein paar Fragen danach sind das gut zehn Minuten pro Person, für drei Tester also eine gute halbe Stunde, mit Aufbau und Pausen etwa 45 Minuten. + + Wichtiger als die Größe ist, dass der Abschnitt **eine** Frage stellt. Zwei Absichten in einem Abschnitt, etwa „Der Spieler soll den Seitengang entdecken“ und „Der Spieler soll vor der Freifläche einen Überblick bekommen“, kannst du nach einem Test nicht auseinanderhalten. Wähl eine. Die zweite bekommt einen eigenen Abschnitt. + + > [!MERKE] + > Ein Abschnitt, eine Absicht, eine Änderung pro Runde. Nur so kannst du sagen, was gewirkt hat. + + ## Von der Absicht zu Zonen und Zahlen + + Die Absichtsnotiz kennst du aus [Absicht notieren, Layout skizzieren](/level-design/absicht-skizze): + + ```text + Abschnitt: + Absicht (ein Satz): Der Spieler soll … + Erwarteter Weg: + Hinweise (wo, was, wofür): + Zeichen, dass es klappt: + Zeichen, dass es scheitert: + ``` + + In der Werkstatt kommt ein Schritt dazu: Jedes Zeichen bekommt eine Messung. Was der Wegschreiber aus [Playtest am PC](/level-design/playtest-godot) zählen kann, sind Zonen, Zeiten, Halte und Wege. Ein Lehrbeispiel mit neutralen Orten: + + | Zeichen in der Notiz | Messung | Quelle | + | --- | --- | --- | + | erreicht das Tor, ohne den Seitengang zu betreten | Zone `Tor` im Log, `Seitengang` nicht | Zonen-Log | + | erreicht das Tor in unter 40 Sekunden | Zeit des ersten Eintrags `Tor` | Zonen-Log | + | bleibt an der Gabelung nicht länger als 3 Sekunden stehen | höchstens 12 Punkte auf einer Stelle | Übersichtsbild, CSV | + | sagt etwas über die Laterne, bevor er losgeht | Eintrag im Protokoll | Beobachtung | + + Die Grenzen, 40 Sekunden oder 3 Sekunden, setzt du vor dem Test, aus deinem Maßstabsraum und deinem eigenen Durchlauf. Setzt du sie danach, passt du sie unbewusst an das an, was du gesehen hast. Valve beschreibt diese Haltung in den Folien zum Playtesting so: „Game designs are hypotheses“, „Playtests are experiments“ ([Ambinder, GDC 2009](https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Die Absichtsnotiz ist deine Hypothese, die Grenzen sagen, wann sie widerlegt ist. + + Nicht jedes Zeichen lässt sich messen. „Der Spieler fühlt sich frei“ beobachtest du weder in einer Spur noch im Protokoll. Formulier es als Verhalten, etwa „Der Spieler betritt mindestens zwei der drei Bereiche, bevor er zum Ausgang geht“, oder lass es weg. + + ## Testrunde: mindestens drei Tester, keine Erklärung + + Jakob Nielsen hat für Usability-Tests von Software begründet, warum wenige Tester pro Runde und mehrere Runden besser sind als ein großer Test: „The best results come from testing no more than 5 users and running as many small tests as you can afford.“ Zum Minimum schreibt er: „Even 3 users are enough to get an idea of the diversity in user behavior and insight into what's unique and what can be generalized“ ([NN/g, 2000](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)). Ein Level ist keine Software-Oberfläche, aber die Rechnung trägt: Ein einzelner Tester kann zufällig richtig oder falsch gehen, bei dreien siehst du, ob ein Muster da ist, und eine zweite Runde ist besser als zwei weitere Tester in der ersten. + + Für jede Sitzung gilt, was du in den Testmodulen geübt hast: getaggter Stand, Einverständnis, Sitzungsnummer statt Namen, Notizen und Spuren im Spiel aus, Stoppuhr mit dem Spielstart, Protokoll ohne Deutung. Das Level Design Book nennt die Form, die du brauchst, einen blinden Playtest, „with minimal guidance or prompting; pretend they are playing the level by themselves, alone, and see what they do“ ([Playtesting](https://book.leveldesignbook.com/process/blockout/playtesting)). Eingreifen darfst du, wenn jemand ganz festsitzt; dann steht der Eingriff mit Zeit im Protokoll, und alles danach zählt für dieses Zeichen nicht mehr. + + Die Tester einer Runde kennen den Abschnitt nicht. Für Runde 2 brauchst du neue, sonst misst du, was sie sich gemerkt haben. + + ## Vergleich: Absicht gegen Verhalten + + Nach der Runde legst du Absichtsnotiz, Protokolle, Zonen-Logs und Übersichtsbild nebeneinander und füllst eine Tabelle, ein Zeichen pro Zeile, ein Tester pro Spalte: + + ```text + Runde 1 · Stand r1 · T1–T3 + Zeichen T1 T2 T3 Quelle + Tor ohne Seitengang ja nein, Seitengang nein, Seitengang Zonen-Log + ab 0:14 ab 0:18 + Tor in unter 40 s ja, 0:21 nein, 1:01 nein, nie Zonen-Log + Halt an Gabelung über 3 s nein ja, 0:09–0:13 ja, 0:13–0:18 Übersicht + Laterne erwähnt ja nein nein Protokoll + ``` + + Diese Tabelle ist reine Beobachtung. Erst darunter schreibst du, was du vermutest, mit Verweis auf die Protokollzeile: „T2, 0:09: bleibt an der Gabelung stehen, dreht die Figur zweimal nach links, sagt nichts; 0:14 im Seitengang.“ Die Diagnose führt [Überarbeiten](/level-design/ueberarbeiten) aus: Jede Stelle, an der ein Zeichen nicht eingetreten ist, bekommt eine der vier Arten „nicht bemerkt“, „falsch gelesen“, „nicht befolgt“ oder „unbeabsichtigte Folge“, mit Beleg aus dem Protokoll. Ist ein Zeichen eingetreten, steht dort „Absicht erfüllt“. + + Die Tabelle hat zwei mögliche Ausgänge. Entweder die Zeichen sind eingetreten, dann ist der Abschnitt für diese Absicht fertig. Oder nicht, dann entscheidest du: Änderst du einen Hinweis, oder änderst du die Absicht? Beides ist erlaubt. Eine Absicht bewusst zu ändern ist ehrlicher, als das Level so lange zu biegen, bis die Zahlen passen. Welche Entscheidung du triffst, entscheidest du; die Tabelle sagt dir nur, worüber. + + ## Überarbeiten und zweite Runde + + Pro Runde änderst du eine Stelle, wie in [Überarbeiten](/level-design/ueberarbeiten) und [Tuning als Experiment](/combat/tuning). Die Änderung kommt mit Begründung ins Iterationsprotokoll, der Stand bekommt einen neuen Tag, dann testest du mit neuen Testern und füllst dieselbe Tabelle. Der Vergleich der beiden Tabellen zeigt, ob deine Änderung das Verhalten getroffen hat, das du ändern wolltest, und ob sie an anderer Stelle etwas verschoben hat. + + > [!PRAXIS] Ein fester Testtag + > Bei Valve testen Level-Designer laut Level Design Book jeden Freitag. Phil Co beschreibt den Wochenrhythmus seines Teams so: „Everything we do during the week is focused on that Friday playtest.“ Die Folien zum Portal Post-Mortem fassen die Haltung in drei Zeilen: „Watch your playtests“, „Adjust gameplay to what players look like they need.“ und „Watching a playtest exposes what isn’t working.“ ([Playtesting at Valve](https://book.leveldesignbook.com/process/blockout/playtesting#playtesting-at-valve), [Swift und Wolpaw, GDC 2008](https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf)). Für dich allein kann das heißen: Leg den Testtag für Runde 2 fest, bevor du mit der Überarbeitung anfängst. + + Wann ist Schluss? Wenn die Zeichen in einer Runde mit neuen Testern eingetreten sind. Oder nach drei Runden ohne Fortschritt; dann liegt das Problem meistens in der Absicht oder im Umfang, nicht im nächsten Hinweis. + + ## Optional: Ausgestaltung und Regressionstest + + Hat der Blockout seine Runde bestanden, kannst du einen Bildschirm oder den ganzen Abschnitt ausgestalten, wie in [Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung). Danach wiederholst du den letzten bestandenen Test mit neuen Testern und füllst dieselbe Tabelle noch einmal. Fällt eine Zeile zurück, liegt es vermutlich an der Grafik; das Protokoll zeigt, ob etwas anderes dazukam. Dieser Schritt ist optional; der Kern der Werkstatt ist der Zyklus mit grauen Tiles. + + ## Die Werkstattmappe + + Alles, was im Zyklus entsteht, kommt in einen Ordner neben dem Godot-Projekt. So kann jemand anderes, oder du in drei Monaten, den Weg nachvollziehen: + + ```text + werkstatt-abschnitt/ + ├── absicht.md Absichtsnotiz, jede Fassung mit Datum + ├── skizze.jpg Foto der Skizze auf Karopapier + ├── runde-1/ + │ ├── protokoll-T1.md Beobachtungsprotokoll, ohne Namen + │ ├── protokoll-T2.md + │ ├── protokoll-T3.md + │ ├── sitzung_01_weg.csv Kopien aus user://wege/ + │ ├── sitzung_01_zonen.csv + │ ├── … + │ ├── uebersicht.png + │ └── vergleich.md Tabelle und Deutung + ├── runde-2/ + │ └── … + └── iteration.md Iterationsprotokoll aller Runden + ``` + + Im Git-Repository des Projekts stehen dazu die Tags `r1`, `r2` und so weiter. Die Mappe enthält keine Namen; die Tester heißen T1 bis T3 pro Runde. Nach Ende der Werkstatt löschst du die Rohdaten, die du nicht mehr brauchst, und behältst die Übersichtsbilder und Tabellen. + + > [!INTERVIEW] + > „Erzähl von einem Level, das du nach einem Playtest geändert hast.“ Gute Antwort in vier Teilen: Absicht in einem Satz und woran ich gemessen habe, ob sie eintritt. Was drei Tester getan haben, mit Zahlen, etwa „einer von drei am Tor, zwei im Seitengang“. Welche eine Änderung ich daraus abgeleitet habe und warum diese. Was die zweite Runde mit neuen Testern gezeigt hat. Dazu das Übersichtsbild vorher und nachher. Wer so antwortet, zeigt, dass er Level als Hypothesen behandelt und nicht als Geschmackssache. + + ## Häufige Fehler + + - **Zu groß angefangen.** Sechs Bildschirme mit drei Absichten. Nach dem Test weißt du nicht, welche Beobachtung zu welcher Absicht gehört. + - **Zeichen erst nach dem Test festgelegt.** Dann passen sie zu dem, was passiert ist, und prüfen nichts. + - **Erklärt statt beobachtet.** Ein Satz wie „Du musst da zum Tor“ macht die ganze Sitzung für dieses Zeichen wertlos. + - **Dieselben Tester in Runde 2.** Sie wissen, wo das Tor ist. + - **Mehrere Änderungen auf einmal.** Die zweite Runde ist besser oder schlechter, und du weißt nicht, warum. + - **Deutung in der Beobachtungstabelle.** „Verwirrt“ steht in keinem Zonen-Log. In der Tabelle stehen Zahlen und Ereignisse, die Deutung darunter. + - **Grafik vor dem bestandenen Test.** Dann misst die Runde Layout und Grafik zugleich. + + ## Zusammenfassung + + - Die Werkstatt ist der ganze Zyklus an einem Abschnitt: Umfang, Absicht, Skizze, Blockout, Test, Vergleich, Überarbeitung, zweiter Test. + - 2 bis 4 Bildschirme, eine Absicht. Der Ort ist deine Wahl. + - Jedes Zeichen der Absichtsnotiz bekommt vor dem Test eine Messung: Zone, Zeit, Halt oder Protokolleintrag. + - Pro Runde mindestens drei Tester, die den Abschnitt nicht kennen, ohne Erklärung, mit Einverständnis und ohne Namen. + - Die Vergleichstabelle enthält nur Beobachtungen. Deutung und Diagnose stehen darunter. + - Pro Runde eine Änderung, neuer Tag, neue Tester, dieselbe Tabelle. + - Ausgestaltung mit Regressionstest ist optional und kommt erst nach einer bestandenen Runde. + - Die Werkstattmappe hält Notizen, Protokolle, Spuren, Tabellen und das Iterationsprotokoll zusammen. +exercises: + - id: zyklus-ordnen + type: order + title: Der Zyklus der Werkstatt + prompt: | + Bring die Schritte der Werkstatt in die Reihenfolge, in der du sie machst. + lang: prose + lines: | + Du wählst einen Abschnitt von 2 bis 4 Bildschirmen mit einer Absicht. + Du schreibst die Absichtsnotiz und legst für jedes Zeichen eine Messung fest. + Du skizzierst den Abschnitt auf Karopapier mit dem erwarteten Weg. + Du baust den Blockout, läufst ihn selbst ab und setzt einen Tag. + Drei Tester spielen, du beobachtest, ohne zu erklären. + Du füllst die Vergleichstabelle und schreibst die Deutung darunter. + Du änderst eine Stelle und testest mit neuen Testern. + explanation: | + Die Messungen gehören vor die Skizze, weil sie mit der Absicht entstehen; sonst passt man sie später an das an, was man gesehen hat. Die Skizze kommt vor dem Blockout, der Selbsttest vor dem fremden Test. Der Vergleich braucht die Daten der ganzen Runde. Die Überarbeitung beginnt erst danach, mit genau einer Änderung. + hints: + - Wann legst du fest, woran du Erfolg erkennst, vor oder nach dem Test? + resources: + - title: The Level Design Book · Blockout, „How to blockout“ + url: https://book.leveldesignbook.com/process/blockout + + - id: umfang-waehlen + type: choice + title: Welcher Umfang passt? + prompt: | + Welcher Umfang passt zur Werkstatt? + options: + - text: Ein Abschnitt von drei Bildschirmen mit einer Absicht und einer Abzweigung, an der sich der Spieler entscheidet. + correct: true + why: Klein genug zum Umbauen, und die Abzweigung gibt dem Tester eine Entscheidung, die du beobachten kannst. + - text: Das ganze erste Level deines Spiels, damit sich der Aufwand lohnt. + correct: false + why: Zu groß für mehrere Runden. Jede Änderung zieht weitere nach sich, und die Tests dauern so lange, dass du nach einer Runde aufhörst. + - text: Zwei Bildschirme mit drei Absichten, damit ein Test möglichst viel prüft. + correct: false + why: Mit drei Absichten weißt du nach dem Test nicht, welche Beobachtung zu welcher gehört. Ein Abschnitt stellt eine Frage. + - text: Ein einzelner Gang ohne Abzweigung, damit sicher nichts schiefgeht. + correct: false + why: Ohne Entscheidung gibt es nichts zu beobachten. Ein Test, der nicht scheitern kann, prüft nichts. + explanation: | + Der Umfang muss zwei Bedingungen erfüllen: Du musst ihn mehrmals umbauen können, und der Tester muss darin etwas entscheiden. 2 bis 4 Bildschirme mit einer Absicht erfüllen beide. Größere Abschnitte teilst du in mehrere Werkstätten. + resources: + - title: Jakob Nielsen · Why You Only Need to Test with 5 Users + url: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ + + - id: zeichen-pruefen + type: output + title: Klappt es bei T1, T2 und T3? + prompt: | + Das Modell prüft für drei Tester das Zeichen „erreicht das Tor in unter 40 Sekunden, ohne den Seitengang zu betreten“ aus deren Zonen-Logs. Was gibt es aus? + lang: python + code: | + # Zonen-Logs dreier Tester, Zeilen wie in sitzung_XX_zonen.csv + sitzungen = { + "T1": ["3.25,Hof", "21.50,Tor"], + "T2": ["2.75,Hof", "14.00,Seitengang", "52.25,Hof", "61.00,Tor"], + "T3": ["4.00,Hof", "18.75,Seitengang", "40.50,Hof"], + } + + for tester, log in sitzungen.items(): + zonen = [zeile.split(",")[1] for zeile in log] + tor = [float(z.split(",")[0]) for z in log if z.endswith(",Tor")] + klappt = bool(tor) and tor[0] < 40 and "Seitengang" not in zonen + print(tester, tor[0] if tor else "-", "klappt" if klappt else "scheitert") + expected: | + T1 21.5 klappt + T2 61.0 scheitert + T3 - scheitert + hints: + - "`tor` ist für T3 eine leere Liste." + - "`float(\"21.50\")` wird als `21.5` ausgegeben." + explanation: | + T1 erreicht das Tor nach 21,5 Sekunden und war nie im Seitengang. T2 erreicht es, aber erst nach 61 Sekunden und über den Seitengang; beide Bedingungen scheitern. T3 kommt nicht ans Tor, `tor` bleibt leer, ausgegeben wird `-`. Ein Treffer von dreien: Das Zeichen ist nicht eingetreten. Warum T2 und T3 in den Seitengang gingen, sagt das Modell nicht; dafür liest du ihre Protokolle bei 14,00 und 18,75 Sekunden. + resources: + - title: Python · str.split + url: https://docs.python.org/3/library/stdtypes.html#str.split + + - id: deutung-in-der-tabelle + type: bug + title: Eine Zeile deutet schon + prompt: | + Lehrbeispiel: Auszug aus dem Beobachtungsteil einer Vergleichsnotiz, Runde 1. Finde die Zeile, die eine Deutung als Beobachtung notiert. + lang: text + code: | + T1 0:21 betritt Zone Tor, kein Halt davor + T2 0:09 hält an der Gabelung, 4 s + T2 0:14 betritt Zone Seitengang + T2 0:31 verwirrt am Brunnen, sucht den Ausgang + T2 0:52 betritt Zone Hof + T3 0:13 hält an der Gabelung, 5 s + lines: [4] + explanation: | + „Verwirrt“ und „sucht den Ausgang“ beschreiben, was im Kopf von T2 vorgeht. Die Spur kann einen Halt zeigen und das Protokoll, was T2 getan und gesagt hat, etwa „bleibt am Brunnen stehen, dreht sich zweimal, sagt: Hm.“ Ob das Suche war, Neugier oder Pause, gehört in die Deutung darunter, mit Verweis auf diese Zeile. + hints: + - Welche Zeile könnte keine Kamera aufnehmen? + resources: + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting + + - id: zeichen-nicht-messbar + type: bug + title: Ein Zeichen, das niemand sehen kann + prompt: | + Lehrbeispiel: eine Absichtsnotiz für die Werkstatt. Finde die Zeile, die du nach dem Test weder mit Spuren noch mit dem Protokoll prüfen kannst. + lang: text + code: | + Abschnitt: Hof mit Tor und Seitengang, 3 Bildschirme + Absicht: Der Spieler soll das Tor erreichen, bevor er den Seitengang betritt. + Erwarteter Weg: Start, über den Hof, Gabelung, Tor + Hinweise: Laterne am Tor, heller Weg vom Start zur Gabelung + Zeichen, dass es klappt: Der Spieler fühlt sich sicher, wohin er gehen soll. + Zeichen, dass es scheitert: Zone Seitengang vor Zone Tor im Log + lines: [5] + explanation: | + Ein Gefühl steht in keinem Log, und wer laut denkt, sagt nicht unbedingt „Ich fühle mich sicher“. Formuliere es als Verhalten, etwa „Zone Tor im Log vor Zone Seitengang, und an der Gabelung kein Halt über 3 Sekunden“. Dann kannst du nach der Runde für jeden Tester ja oder nein schreiben. + hints: + - Welches Zeichen beschreibt einen Zustand im Kopf statt ein Verhalten? + resources: + - title: Mike Ambinder · Valve's Approach to Playtesting (Folien, GDC 2009) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + + - id: vergleich-erklaeren + type: explain + title: Was sagt diese Tabelle? + prompt: | + Lehrbeispiel: die Vergleichstabelle nach Runde 1. Erkläre in drei bis fünf Sätzen, was die Tabelle zeigt, was sie nicht zeigt und welche Entscheidung jetzt ansteht. + lang: text + code: | + Absicht: Der Spieler soll das Tor erreichen, bevor er den Seitengang betritt. + Runde 1 · Stand r1 · T1–T3 + Zeichen T1 T2 T3 Quelle + Tor ohne Seitengang ja nein, Seitengang nein, Seitengang Zonen-Log + ab 0:14 ab 0:18 + Tor in unter 40 s ja, 0:21 nein, 1:01 nein, nie Zonen-Log + Halt an Gabelung über 3 s nein ja, 0:09–0:13 ja, 0:13–0:18 Übersicht + Laterne erwähnt ja nein nein Protokoll + points: + - Die Absicht ist in Runde 1 nicht eingetreten; nur T1 erfüllt alle Zeichen. + - T2 und T3 halten an der Gabelung länger als 3 Sekunden und betreten direkt danach den Seitengang, um 0:14 und 0:18; an der Gabelung trennen sich die Wege. + - Nur T1 erwähnt die Laterne. Welche der vier Arten aus „Überarbeiten“ bei T2 und T3 vorliegt, nicht bemerkt, falsch gelesen, nicht befolgt oder unbeabsichtigte Folge, sagt die Tabelle nicht; das klären die Protokolle an der Gabelung. + - Jetzt steht die Entscheidung an, einen Hinweis an der Gabelung zu ändern oder die Absicht zu ändern; in beiden Fällen eine Änderung und eine neue Runde mit neuen Testern. + explanation: | + Die Tabelle zeigt, dass die Absicht nur bei einem von drei Testern eingetreten ist und dass sich die Wege an der Gabelung trennen: Beide Tester, die scheitern, halten dort länger als 3 Sekunden und betreten eine Sekunde später den Seitengang. Sie zeigt auch, dass nur T1 die Laterne erwähnt hat. Warum die anderen nicht zum Tor gegangen sind, zeigt sie nicht; dafür liest du die Protokolle an der Gabelung und ordnest die Stelle einer der vier Arten aus [Überarbeiten](/level-design/ueberarbeiten) zu. War die Laterne „nicht bemerkt“, änderst du etwas an ihr oder an der Sicht auf sie. Wurde sie „falsch gelesen“, änderst du ihre Form oder ihren Ort. Wurde sie verstanden, aber „nicht befolgt“, weil der Seitengang mehr versprach, prüfst du zuerst die Absicht: Ist der Seitengang für dich die bessere Entdeckung, änderst du die Absicht. In jedem Fall ist es eine Änderung, und Runde 2 läuft mit neuen Testern. + resources: + - title: Kim Swift, Erik Wolpaw · Portal Post-Mortem (Folien, GDC 2008) + url: https://cdn.akamai.steamstatic.com/apps/valve/2008/GDC2008_PortalPostMortem.pdf + + - id: umfang-und-absicht + type: practice + title: Umfang und Absichtsnotiz + prompt: | + Wähle den Abschnitt für deine Werkstatt und schreib seine Absichtsnotiz. Welcher Ort es ist und was der Spieler dort tun soll, entscheidest du. Leg für jedes Zeichen eine Messung fest, bevor du skizzierst. + lang: prose + starter: | + Abschnitt (Größe in Bildschirmen): + Absicht (ein Satz): Der Spieler soll … + Erwarteter Weg: + Hinweise (wo, was, wofür): + Zeichen, dass es klappt: Messung: + Zeichen, dass es scheitert: Messung: + checklist: + - Der Abschnitt ist 2 bis 4 Bildschirme groß. + - Die Absicht ist ein Satz und enthält eine einzige Absicht. + - Im Abschnitt muss der Spieler mindestens eine Entscheidung treffen, etwa an einer Abzweigung. + - Jedes Zeichen beschreibt Verhalten, kein Gefühl. + - Jedes Zeichen hat eine Messung mit Quelle (Zonen-Log, Übersichtsbild, CSV oder Protokoll) und eine Grenze in Sekunden, Zonen oder Anzahl. + - Die Zonen, die du dafür brauchst, sind benannt. + hints: + - Schreib die Zeichen so, dass du nach jeder Sitzung ja oder nein dahinter schreiben kannst. + explanation: | + Die Messungen sind der Unterschied zwischen einer Absicht und einer Hoffnung. Mit ihnen weißt du schon vor dem Bauen, welche Zonen der Wegschreiber braucht und welche Spalten deine Vergleichstabelle hat. + resources: + - title: The Level Design Book · Layout + url: https://book.leveldesignbook.com/process/layout + + - id: skizze-und-blockout + type: practice + title: Skizze und Blockout + prompt: | + Skizziere den Abschnitt auf Karopapier im Tile-Maßstab und bau ihn als Blockout in Godot, mit Wegschreiber und Zonen. Lauf ihn selbst ab und setz den Tag für Runde 1. Jede Wand, jede Breite und jeder Hinweis ist deine Entscheidung. + lang: prose + checklist: + - Die Skizze zeigt den Rahmen der Bildschirme, den erwarteten Weg und jeden Hinweis mit Symbol; ein Foto liegt in der Mappe. + - Der Blockout nutzt deine Blockout-Vokabel auf `Ground`, `Walls` und `Cues`, ohne fertige Grafik. + - Jede Zone aus der Absichtsnotiz ist eine `Area2D` in der Gruppe `zones`. + - "`ExpectedPath` folgt dem erwarteten Weg der Skizze, `Notes` ist im Spiel aus." + - Dein eigener Durchlauf hat eine Weg-Datei und ein Zonen-Log erzeugt, die zu deinem Weg passen. + - Der Stand ist committet und hat den Tag für Runde 1. + hints: + - Weicht der Blockout von der Skizze ab, notiere die Abweichung, statt die Skizze nachzuzeichnen. + explanation: | + Der eigene Durchlauf prüft die Technik und die Maße. Er sagt nichts darüber, ob ein Fremder den Weg findet, denn du kennst ihn. Aber er erspart dir, einen Tester an einem Gang scheitern zu lassen, in dem die Figur hängen bleibt. + resources: + - title: The Level Design Book · Blockout + url: https://book.leveldesignbook.com/process/blockout + + - id: testrunde-eins + type: practice + title: Testrunde 1 mit drei Testern + prompt: | + Lass mindestens drei Personen deinen Abschnitt spielen, die ihn nicht kennen. Wen du fragst, entscheidest du. Beobachte, ohne zu erklären, und sichere jede Sitzung. + lang: prose + checklist: + - Mindestens drei Sitzungen auf demselben getaggten Stand. + - Jeder Tester wusste vor dem Start, was aufgezeichnet wird, und hat zugestimmt. + - Keine Namen in Dateien, Protokollen oder Mappe; die Tester heißen T1, T2, T3. + - Du hast den Abschnitt nicht erklärt; jeder Eingriff steht mit Zeit im Protokoll. + - Zu jeder Sitzung liegen in `runde-1/` das Protokoll, die Weg-Datei und das Zonen-Log, und jedes Protokoll nennt die Sitzungsnummer seiner Dateien. + - Das Übersichtsbild der Runde liegt in der Mappe. + hints: + - Plane gut zehn Minuten pro Person und mit Aufbau etwa 45 Minuten für die Runde. + explanation: | + Drei Sitzungen sind das Minimum, um zufälliges Verhalten von einem Muster zu unterscheiden. Der feste Stand sorgt dafür, dass alle drei denselben Abschnitt gespielt haben. Wie du ohne Erklären beobachtest, steht in [Beobachten, ohne zu erklären](/level-design/playtest-methode). + resources: + - title: The Level Design Book · Playtesting, „How to run a playtest“ + url: https://book.leveldesignbook.com/process/blockout/playtesting#how-to-run-a-playtest + - title: Nielsen Norman Group · Talking with Users in a Usability Test + url: https://www.nngroup.com/articles/talking-to-users/ + + - id: vergleich-schreiben + type: practice + title: Absicht gegen Verhalten + prompt: | + Füll die Vergleichstabelle für Runde 1 aus Zonen-Logs, Übersichtsbild und Protokollen. Schreib darunter deine Deutung und die Entscheidung, die daraus folgt. Was du daraus schließt, entscheidest du. + lang: prose + starter: | + Runde 1 · Stand · Tester + Zeichen | T1 | T2 | T3 | Quelle + + Deutung (mit Protokollzeile): + Art je Stelle: nicht bemerkt / falsch gelesen / nicht befolgt / unbeabsichtigte Folge / Absicht erfüllt + Entscheidung: Hinweis ändern / Absicht ändern / fertig + checklist: + - Jedes Zeichen der Absichtsnotiz hat eine Zeile, jeder Tester eine Spalte. + - In der Tabelle stehen nur Zahlen, Zonen und Ereignisse, keine Deutung. + - Jede Deutung verweist auf eine Protokollzeile oder eine Stelle im Übersichtsbild. + - Für jedes nicht eingetretene Zeichen steht eine der vier Arten aus „Überarbeiten“ (nicht bemerkt, falsch gelesen, nicht befolgt, unbeabsichtigte Folge) mit Beleg und der Stelle, an der sich das Verhalten trennt; eingetretene Zeichen stehen als „Absicht erfüllt“ da. + - Die Entscheidung nennt genau eine Änderung oder eine neue Absicht, mit Begründung. + hints: + - Füll die Tabelle, bevor du die Protokolle ein zweites Mal liest. + explanation: | + Die Tabelle trennt, was passiert ist, von dem, was du daraus machst. Wer später fragt, warum du etwas geändert hast, findet die Antwort in der Zeile darunter, mit Quelle. Wie du eine Stelle diagnostizierst, steht in [Überarbeiten](/level-design/ueberarbeiten). + resources: + - title: Mike Ambinder · Valve's Approach to Playtesting (Folien, GDC 2009) + url: https://cdn.akamai.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf + + - id: runde-zwei + type: practice + title: Eine Änderung, neue Tester + prompt: | + Setz die eine Änderung aus deinem Vergleich um, teste mit mindestens drei neuen Personen und füll dieselbe Tabelle für Runde 2. Welche Änderung es ist, hast du entschieden; hier prüfst du, ob sie gewirkt hat. + lang: prose + checklist: + - Zwischen Runde 1 und Runde 2 ist genau eine Stelle geändert, und das Iterationsprotokoll nennt sie mit Begründung. + - Der neue Stand hat einen eigenen Tag. + - Mindestens drei Tester, die weder den Abschnitt noch Runde 1 kennen. + - Die Tabelle von Runde 2 hat dieselben Zeilen wie die von Runde 1. + - Du hast notiert, ob sich das Verhalten an der geänderten Stelle verändert hat und ob sich an einer anderen Stelle etwas verschoben hat. + - Das Iterationsprotokoll sagt, wie es weitergeht, mit einer weiteren Runde, einer neuen Absicht oder dem Abschluss. + hints: + - Leg die Übersichtsbilder beider Runden nebeneinander. + explanation: | + Erst die zweite Runde zeigt, ob deine Deutung stimmt. Hat sich das Verhalten an der geänderten Stelle verändert, war die Diagnose richtig. Hat es sich nicht verändert, war es eine andere Ursache, und du weißt mehr als vorher. Beide Ergebnisse sind brauchbar, solange du nur eine Sache geändert hast. + resources: + - title: Jakob Nielsen · Why You Only Need to Test with 5 Users + url: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ + + - id: ausgestalten-und-wiederholen + type: practice + title: Ausgestaltung und Regressionstest + prompt: | + Optional, wenn eine Runde bestanden ist: Gestalte den Abschnitt oder einen Bildschirm davon aus und wiederhole den bestandenen Test mit neuen Testern. Wie der Ort aussieht, entscheidest du. + lang: prose + checklist: + - Ausgestaltet hast du erst nach einer Runde, in der die Zeichen eingetreten sind. + - Die Grafik liegt auf `Dressing` ohne Kollision, `Walls` ist unsichtbar und kollidiert weiter, `check_dressing.gd` meldet nichts. + - Der Regressionstest hat dieselben Zeichen, Zonen und dieselbe Zahl an neuen Testern wie die bestandene Runde. + - Die Tabelle vorher und nachher steht nebeneinander in der Mappe. + - Jeder Rückschritt hat Ort, Zeit und eine Änderung an der Grafik als nächsten Schritt. + hints: + - Ein Bildschirm reicht, um das Verfahren einmal durchzuspielen. + explanation: | + Der Regressionstest beantwortet, ob die Grafik etwas gekostet hat. Weil das Layout gleich geblieben ist, liegt ein Rückschritt vermutlich an der Ausgestaltung; das Protokoll zeigt, ob etwas anderes dazukam. Die Einzelheiten stehen in [Vom Blockout zur Ausgestaltung](/level-design/ausgestaltung). + resources: + - title: The Level Design Book · Environment Art + url: https://book.leveldesignbook.com/process/env-art + + - id: werkstattmappe + type: practice + title: Die Werkstattmappe und dein Rückblick + prompt: | + Räum die Werkstattmappe auf und schreib einen Rückblick von höchstens einer Seite: was du beabsichtigt hast, was die Tester getan haben, was du geändert hast und was du beim nächsten Abschnitt anders machst. + lang: prose + checklist: + - Die Mappe hat Absichtsnotiz mit allen Fassungen, Skizze, einen Ordner pro Runde und das Iterationsprotokoll. + - Jede Runde hat Protokolle, Zonen-Logs, Übersichtsbild und Vergleichstabelle. + - Die Mappe enthält keine Namen von Testern. + - Der Rückblick nennt die Absicht, die Ergebnisse jeder Runde in Zahlen und jede Änderung mit Begründung. + - Der Rückblick nennt mindestens eine Sache, die du am Vorgehen ändern willst, nicht nur am Abschnitt. + - Rohdaten, die du nicht mehr brauchst, sind gelöscht. + hints: + - Schreib den Rückblick so, als würdest du ihn im Vorstellungsgespräch erzählen. + explanation: | + Die Mappe ist der Beleg, dass du Level als Hypothesen behandelst: Absicht, Messung, Beobachtung, Änderung, neue Messung. Der Satz über dein Vorgehen ist der wichtigste im Rückblick, denn er macht den nächsten Abschnitt schneller. + resources: + - title: The Level Design Book · Playtesting + url: https://book.leveldesignbook.com/process/blockout/playtesting diff --git a/content/level-design/projects.yaml b/content/level-design/projects.yaml new file mode 100644 index 0000000..8114735 --- /dev/null +++ b/content/level-design/projects.yaml @@ -0,0 +1,253 @@ +projects: + - id: analyse-abschnitt + title: Analyse eines Abschnitts aus einem veröffentlichten Top-down-Spiel + level: 1 + hours: 5 + summary: Du liest einen kurzen Abschnitt aus einem Top-down-Spiel deiner Wahl so genau, dass ein anderer ihn nachvollziehen kann – Skizze im Raster, Hinweise, Orientierung, Rhythmus und vermutete Absicht, gegengeprüft mit einer Quelle oder einem zweiten Spieler. + brief: | + **Ausgangslage:** In den Modulen hast du einzelne Mittel an vielen Spielen gesehen. Hier liest du einen einzigen Abschnitt gründlich, einen, den du selbst gespielt hast. Die Analyse ist keine Kritik und keine Nacherzählung. Sie zeigt, wie der Abschnitt gebaut ist und warum du dich darin so bewegt hast, wie du es getan hast. + + **Anforderungen:** + + - Ein veröffentlichtes Top-down-Spiel deiner Wahl und darin ein Abschnitt von zwei bis vier Bildschirmen. + - Eine Skizze im Raster, ein Kästchen pro Tile, mit Bildschirmrahmen, deinem ersten Weg und markierten Hinweisen. + - Fünf Gesichtspunkte: Blickführung, Orientierung (Wege, Kanten, Knoten, Bereiche, Landmarken), Maßstab und Dichte, Rhythmus, Umgebung als Information. + - Gesehenes und Gedeutetes sind getrennt. Jede Tatsache über das Spiel hat eine Quelle oder ist als eigene Beobachtung gekennzeichnet. + - Die vermutete Absicht in einem Satz, gegengeprüft mit einer Entwicklerquelle oder mit dem Weg eines zweiten Spielers, dem du nichts erklärst. + + **Rahmen:** Notizen und Skizze gehen unterwegs auf Papier und am Handy, die Ausarbeitung am PC, zusammen etwa fünf Stunden. Grundlage sind [Level lesen](/level-design/raum-lesen), [Blickführung](/level-design/blickfuehrung), [Orientierung](/level-design/orientierung), [Maßstab und Dichte](/level-design/massstab-dichte) und [Rhythmus](/level-design/rhythmus). Die Analyse schreibst du selbst. + skills: [analyse, skizze, blickfuehrung, orientierung, rhythmus, quellenarbeit] + steps: + - id: abschnitt-waehlen + title: Spiel und Abschnitt wählen + detail: Wähle einen Abschnitt, den du selbst gespielt hast, zwei bis vier Bildschirme groß. Notier sofort aus dem Gedächtnis, wo du beim ersten Mal entlanggegangen bist. + - id: skizze-raster + title: Im Raster skizzieren + detail: Spiel die Stelle noch einmal oder halte ein Video an und skizzier sie auf Karopapier, ein Kästchen pro Tile, mit einem Rahmen für einen Bildschirm. Zähl Schritte oder vergleich mit der Figur, um Maße zu schätzen. + - id: hinweise-markieren + title: Hinweise markieren + detail: Markier alles, was Blick oder Weg gelenkt hat, mit Ort und Art. Ordne die Orientierungselemente nach Lynch zu ([Orientierung](/level-design/orientierung)). + - id: rhythmus-zeichnen + title: Rhythmus als Taktplan + detail: Schreib die Folge aus Bewegung, Beobachtung, Entdeckung und Begegnung mit geschätzter Dauer als Taktplan auf ([Rhythmus](/level-design/rhythmus)). + - id: gesehen-gedeutet + title: Gesehenes und Gedeutetes trennen + detail: Geh deine Notizen durch und teil sie in zwei Spalten. Unter „Gesehen“ bleibt nur, was eine Kamera aufnehmen könnte. + - id: absicht-pruefen + title: Absicht vermuten und gegenprüfen + detail: Formulier die vermutete Absicht in einem Satz. Such eine Entwicklerquelle oder lass eine zweite Person die Stelle spielen, ohne etwas zu erklären, und vergleich ihren Weg mit deinem Satz. + - id: ausarbeiten + title: Ausarbeiten + detail: Fass alles auf zwei bis drei Seiten zusammen, mit Skizze, Quellenliste und einem Absatz, was du für eigene Abschnitte daraus mitnimmst. + acceptance: + - id: skizze-mit-rahmen + text: Die Skizze zeigt den Abschnitt im Raster mit Bildschirmrahmen, erstem Weg und mindestens fünf markierten Hinweisen. + - id: fuenf-gesichtspunkte + text: Alle fünf Gesichtspunkte sind behandelt, jeder mit mindestens einer konkreten Stelle. + - id: gesehen-getrennt + text: Beobachtungen und Deutungen stehen getrennt; Tatsachen über das Spiel haben eine Quelle oder sind als eigene Beobachtung markiert. + - id: absicht-gegengeprueft + text: Die vermutete Absicht steht in einem Satz und ist mit einer Quelle oder einem zweiten Spieler gegengeprüft; das Ergebnis der Prüfung steht dabei, auch wenn es der Vermutung widerspricht. + stretch: + - Denselben Abschnitt nach einigen Wochen noch einmal lesen und vergleichen, was dir jetzt auffällt. + - Einen zweiten Abschnitt aus einem anderen Spiel mit gleicher Aufgabe danebenlegen, etwa zwei erste Dungeonräume. + portfolio: | + Eine Analyse zeigt, dass du Level nicht nur spielst, sondern liest. Zeig die Skizze mit markierten Hinweisen und den Vergleich zwischen deiner Vermutung und dem, was der zweite Spieler getan hat. Im Gespräch fragen Designer gern, welches Level du zuletzt so gelesen hast und was du daraus gelernt hast. + + - id: massstab-baukasten + title: Maßstabsraum und Blockout-Baukasten + level: 2 + hours: 6 + summary: Am PC misst du die Werte deiner eigenen Spielfigur in einem Maßstabsraum aus und legst daraus einen Baukasten aus Platzhalter-Tiles mit deiner visuellen Sprache an, auf dem alle späteren Blockouts stehen. + brief: | + **Ausgangslage:** Bevor du Abschnitte baust, brauchst du Maße, denen du traust: Wie breit muss ein Gang für deine Figur sein, wie groß eine Fläche, in der sie zweimal ausweichen kann, wie viel zeigt ein Bildschirm? Dieses Projekt beantwortet das mit deiner Figur, nicht mit den Platzhaltern des Kurses. + + **Anforderungen:** + + - Eine Godot-Szene „Maßstabsraum“ mit Gängen in mehreren Breiten, Durchgängen, einer offenen Fläche und Abständen, die du in Tiles beschriftest. + - Deine Figur mit deinen eigenen Werten für Tempo, Fußfläche und, wenn dein Spiel eins hat, Ausweichen. Woher die Werte kommen, entscheidest du; Platzhalter aus dem Kurs markierst du als solche. + - Ein Platzhalter-TileSet mit deiner Blockout-Vokabel, je eine Tile für begehbar, blockiert hoch, blockiert tief, gefährlich, benutzbar und Hinweis ([Umgebung als Information](/level-design/umgebung-informiert)), als flache Tonwerte, wo nötig mit einfacher Formmarke, ohne Ausgestaltung. + - Eine Tabelle `MASSE.md` mit gemessenen Werten und den Regeln, die du daraus ableitest, etwa „Gänge mindestens N Tiles“. + + **Rahmen:** Godot 4.7 am PC, etwa sechs Stunden. Skripte für Messhilfen darf eine KI schreiben; welche Maße du festlegst, entscheidest du. Grundlage sind [Maßstab und Dichte](/level-design/massstab-dichte), [Umgebung als Information](/level-design/umgebung-informiert) und [Blockout in Godot](/level-design/blockout). Wie ein TileSet entsteht, steht im Godot-Kurs ([2D-Level aus Tiles](/godot/level-tilemap)). + skills: [metriken, godot, tilemaplayer, blockout, visuelle-sprache, dokumentation] + steps: + - id: werte-sammeln + title: Werte der Figur sammeln + detail: Schreib Tempo, Fußfläche, Ausweichweite und alles andere auf, was über Platz entscheidet. Rechne jeden Wert in Tiles und Sekunden um. + - id: tileset-vokabel + title: Platzhalter-TileSet mit deiner Vokabel + detail: Leg für jede der sechs Kategorien deiner Blockout-Vokabel einen flachen Tonwert fest, wo nötig mit einer einfachen Formmarke. Prüf mit dem Unschärfetest, ob man sie unterscheidet ([Blickführung](/level-design/blickfuehrung)). + - id: gaenge-bauen + title: Gänge und Durchgänge bauen + detail: Bau Gänge in mehreren Breiten und Durchgänge daneben. Lauf, weiche aus, dreh dich in jedem und notier, wo es eng wird. + - id: flaeche-bauen + title: Offene Fläche bauen + detail: Bau eine offene Fläche und miss, wie viele Ausweichbewegungen sie quer und längs fasst und wie viel davon auf einen Bildschirm passt. + - id: kamera-pruefen + title: Kamera und Bildschirm prüfen + detail: Setz Kameragrenzen und prüf, was am Rand der Fläche im Bild ist. Notier, wie viele Tiles du in jede Richtung siehst. + - id: regeln-ableiten + title: Regeln ableiten + detail: Schreib in `MASSE.md` drei bis sechs Regeln mit Begründung aus deinen Messungen. Jede Regel nennt eine Zahl. + - id: sichern + title: In Git sichern + detail: Commite Szene, TileSet und `MASSE.md` mit einer Nachricht, die die Figurwerte nennt. Ändern sich die Werte später, wiederholst du die Messungen. + acceptance: + - id: massstab-szene + text: Die Szene startet in Godot 4.7 ohne Fehler und enthält Gänge in mindestens drei Breiten, Durchgänge und eine offene Fläche, jeweils in Tiles beschriftet. + - id: masse-dokumentiert + text: "`MASSE.md` nennt die Figurwerte mit Herkunft (gemessen, festgelegt oder Platzhalter) und mindestens drei abgeleitete Regeln mit Zahl und Begründung." + - id: vokabel-unterscheidbar + text: Das Platzhalter-TileSet hat für jede der sechs Kategorien der Blockout-Vokabel eine eigene Darstellung, die auch im unscharfen Bildschirmfoto zu unterscheiden ist. + - id: nur-blockout + text: Der Baukasten enthält keine Ausgestaltung; alle Tiles sind flache Tonwerte, höchstens mit einer einfachen Formmarke. + stretch: + - Eine zweite Figur oder ein Gegner mit anderer Größe im selben Raum, und welche Regeln sich dadurch ändern. + - Ein kleines Skript, das Abstände zwischen zwei Markern in Tiles und Sekunden anzeigt. + portfolio: | + Ein Maßstabsraum zeigt, dass du Räume aus den Werten des Spiels ableitest statt nach Augenmaß. Zeig ein Bild des Raums mit Beschriftungen und die Tabelle der Regeln. Im Gespräch kommt oft die Frage, wie du vorgehst, wenn sich Tempo oder Größe der Figur spät im Projekt ändern. + + - id: einfuehrung-testen + title: Eine Möglichkeit einführen, testen und variieren + level: 2 + hours: 10 + summary: Du wählst eine Möglichkeit deines Spiels und baust als Blockout eine kurze Folge, die sie einführt, sicher ausprobieren lässt, prüft und variiert – getestet mit drei Personen, die sie nicht kennen, und einmal überarbeitet. + brief: | + **Ausgangslage:** Eine Mechanik, die niemand versteht, gibt es für den Spieler nicht. Dieses Projekt baut eine Folge von drei bis fünf kleinen Räumen, in der Spieler eine Möglichkeit ohne Text verstehen, ausprobieren und am Ende in einer neuen Lage anwenden. + + **Anforderungen:** + + - Eine Möglichkeit, die du selbst wählst: eine Bewegung, ein Gegenstand, eine Eigenschaft der Umgebung. Der Kurs schlägt keine vor. + - Eine Absichtsnotiz für die ganze Folge und eine Zeile je Raum mit seiner Aufgabe (einführen, entwickeln, wenden, abschließen oder eine eigene Gliederung mit Begründung). + - Ein Blockout in Godot 4.7 mit Platzhalter-Tiles, ohne Text auf dem Bildschirm, der die Möglichkeit erklärt. + - Ein Test mit drei Personen, die die Folge nicht kennen, mit Protokoll, und eine Überarbeitungsrunde mit einer Änderung und neuen Testern. + + **Rahmen:** Godot 4.7 am PC, Skizzen und Auswertung auch unterwegs, etwa zehn Stunden. Technik darf eine KI übernehmen; Möglichkeit, Räume und Reihenfolge entscheidest du. Grundlage sind [Möglichkeiten einführen](/level-design/einfuehren-variieren), [Absicht und Skizze](/level-design/absicht-skizze), [Blockout](/level-design/blockout), [Playtests beobachten](/level-design/playtest-methode) und [Überarbeiten](/level-design/ueberarbeiten). + skills: [einfuehrung, kishotenketsu, blockout, playtest, ueberarbeiten, godot] + steps: + - id: moeglichkeit-waehlen + title: Möglichkeit wählen + detail: Wähl eine Möglichkeit und schreib in einem Satz, was der Spieler am Ende damit können soll. + - id: folge-planen + title: Folge planen + detail: Schreib je Raum eine Zeile mit Aufgabe, Preis eines Fehlers und dem, was neu ist. Pro Raum kommt höchstens eine Neuheit dazu. + - id: skizzieren + title: Räume skizzieren + detail: Skizzier jeden Raum im Raster mit erwartetem Weg und Hinweisen. + - id: blockout-bauen + title: Blockout bauen + detail: Bau die Räume mit deinem Baukasten. Prüf selbst nur, ob alles technisch geht, nicht ob es verständlich ist. + - id: erster-test + title: Erster Test + detail: Drei Personen, die die Folge nicht kennen, spielen ohne Erklärung. Du notierst Weg, Halt, Versuche und Gesagtes je Raum. + - id: auswerten + title: Auswerten + detail: Ordne jede Abweichung einer Art zu und wähl eine Stelle für die nächste Runde ([Überarbeiten](/level-design/ueberarbeiten)). + - id: zweite-runde + title: Zweite Runde + detail: Eine Änderung mit schriftlicher Erwartung, dann mindestens zwei neue Tester. + - id: zusammenfassen + title: Zusammenfassen + detail: Fass auf einer Seite zusammen, was die Folge lehren sollte, was Tester taten und was die Änderung bewirkt hat. + acceptance: + - id: ohne-text + text: Die Folge erklärt die Möglichkeit nicht mit Text auf dem Bildschirm; Steuerungshinweise auf Tasten sind erlaubt und als solche gekennzeichnet. + - id: eine-neuheit + text: Jeder Raum hat eine notierte Aufgabe und bringt höchstens eine Neuheit; der erste Raum lässt die Möglichkeit ohne nennenswerten Preis eines Fehlers ausprobieren. + - id: drei-tester + text: Ein Protokoll von drei Testern, die die Folge nicht kannten, liegt vor, mit Weg und Verhalten je Raum. + - id: eine-aenderung + text: Die Überarbeitungsrunde ändert genau eine Sache, hat eine vorher notierte Erwartung und mindestens zwei neue Tester. + stretch: + - Eine zweite Variation am Ende, die die Möglichkeit mit einer bekannten anderen kombiniert. + - Dieselbe Folge mit einem Tester, der die Möglichkeit aus einem anderen Spiel kennt, und ein Vergleich. + portfolio: | + Eine Einführungsfolge zeigt, dass du Lernen gestalten kannst. Zeig die Raumliste mit Aufgaben, ein Bild jedes Raums und eine Stelle, an der der Test dich überrascht hat. Im Gespräch fragen Designer, woran du merkst, dass ein Spieler eine Mechanik verstanden hat, und nicht nur, dass er weitergekommen ist. + + - id: abschluss-abschnitt + title: "Abschlussprojekt: ein begehbarer Abschnitt mit Absicht und Beobachtung" + capstone: true + level: 3 + hours: 30 + summary: Ein kleines Studio schickt dir einen Level-Design-Test. Du baust in Godot einen eigenen begehbaren Abschnitt von zwei bis vier Bildschirmen – Absichtsnotiz, Skizze, Blockout, mindestens zwei Testrunden ohne Erklärung, aufgezeichnete Wege – und lieferst einen Vergleich zwischen Absicht und beobachtetem Verhalten. Alle Designentscheidungen triffst du. + brief: | + ## Auftrag + + Malte Kern leitet ein Indie-Studio mit fünf Leuten in Kassel. Das Studio arbeitet an einem Actionspiel in der Draufsicht mit Pixelart. Für die Stelle „Level Designer (m/w/d)“ schickt er dir einen Designtest. Seine Lage: + + - Die Tester des Prototyps verlaufen sich in den ersten Räumen, und das Team weiß nicht, ob es an der Grafik oder am Grundriss liegt. + - Level entstehen bisher direkt in fertiger Grafik. Jede Änderung am Grundriss kostet Tage. + - Niemand schreibt auf, was ein Raum bewirken soll. Diskussionen drehen sich um Geschmack. + + Gesucht ist kein fertiges Level, sondern ein Beleg, dass du einen Abschnitt mit einer prüfbaren Absicht baust, fremde Spieler beobachtest, ohne zu erklären, und gezielt überarbeitest. Was der Abschnitt zeigt und wohin er führt, gibt dir niemand vor. Wenn du willst, ist er ein erster Abschnitt für Project Delicate Flower; der Kurs schlägt dafür keinen Ort und keine Begegnung vor. + + ## Was du lieferst + + 1. **Eine spielbare Szene** in Godot 4.7: ein Abschnitt von zwei bis vier Bildschirmen als Blockout mit Platzhalter-Tiles, getrennten Ebenen für Boden, Wände und Hinweise und einem Wegschreiber. + 2. **`ABSICHT.md`:** die Absichtsnotiz für den Abschnitt und für jede Stelle mit eigener Absicht, mit erwartetem Weg und beobachtbaren Zeichen; jede spätere Fassung mit Datum. + 3. **Die Skizze** auf Papier oder am Handy, als Foto oder Scan, mit Bildschirmrahmen. + 4. **`PROTOKOLL.md`:** mindestens zwei Testrunden mit zusammen mindestens fünf Testern, die den Abschnitt nicht kannten, Beobachtungsprotokoll je Tester und je Runde ein Eintrag im Iterationsprotokoll. + 5. **`VERGLEICH.md`:** Absicht und beobachtetes Verhalten Stelle für Stelle nebeneinander, mit den aufgezeichneten Wegen als Bild und einer ehrlichen Liste, was nicht aufging. + 6. **Ein Video** von höchstens zwei Minuten: der erwartete Weg und die aufgezeichneten Wege übereinander. + + ## Technischer Rahmen + + Godot 4.7, GDScript, Auflösung und Tilegröße nach deiner Wahl. Skripte wie den Wegschreiber oder Hilfen im Editor darf eine KI schreiben. Layout, Orte, Hinweise und jede Designentscheidung triffst du selbst; erzeugte Level oder Karten sind nicht erlaubt. Eine Ausgestaltung ist nicht verlangt. Machst du eine, kommt danach ein weiterer Test mit derselben Absicht dazu. + + Grundlage sind alle Module dieses Bereichs, besonders [Absicht und Skizze](/level-design/absicht-skizze), [Blockout](/level-design/blockout), [Playtest am PC](/level-design/playtest-godot), [Überarbeiten](/level-design/ueberarbeiten) und die [Werkstatt](/level-design/werkstatt-abschnitt). + skills: [level-design, absicht, blockout, godot, playtest, wege-aufzeichnen, ueberarbeiten, dokumentation] + steps: + - id: umfang-festlegen + title: Umfang festlegen + detail: Leg fest, wie groß der Abschnitt ist, zwei bis vier Bildschirme, und wo er beginnt und endet. Schreib in einem Satz, was ein Spieler darin tun oder bemerken soll. + - id: absicht-schreiben + title: Absichtsnotiz schreiben + detail: Fülle die Absichtsnotiz aus, für den Abschnitt und jede Stelle mit eigener Absicht. Jede Zeile „Zeichen, dass es klappt“ muss beim Zusehen abzuhaken sein. + - id: skizzieren + title: Skizzieren + detail: Skizzier den Abschnitt im Raster mit Bildschirmrahmen, erwartetem Weg und Hinweisen. Prüf vor dem Bauen mit deinen Maßen, ob Gänge und Flächen passen. + - id: blockout + title: Blockout bauen + detail: Bau den Abschnitt mit deinem Platzhalter-Baukasten, mit getrennten Ebenen und Kameragrenzen. Keine Ausgestaltung. + - id: wegschreiber + title: Wege aufzeichnen + detail: Bau den Wegschreiber ein oder lass ihn bauen und prüf an einem eigenen Lauf, dass Datei und Spur stimmen ([Playtest am PC](/level-design/playtest-godot)). + - id: runde-eins + title: Erste Testrunde + detail: Mindestens drei Personen, die den Abschnitt nicht kennen, spielen ohne Erklärung. Du protokollierst, sicherst die Wegdateien und fragst erst danach nach. + - id: auswerten + title: Auswerten + detail: Leg die Wege über den erwarteten Weg, ordne jede Abweichung einer Art zu und entscheide, ob du das Level oder bewusst die Absicht änderst. + - id: runde-zwei + title: Zweite Testrunde + detail: Eine Änderung mit schriftlicher Erwartung, dann mindestens zwei neue Tester. Halte das Ergebnis im Iterationsprotokoll fest. + - id: vergleich-schreiben + title: Vergleich schreiben + detail: Stell Absicht und Verhalten Stelle für Stelle nebeneinander, mit Bildern der Wege. Schreib auch auf, was nicht aufging und was du als Nächstes testen würdest. + - id: abgabe + title: Abgabe zusammenstellen + detail: Video, Dokumente, Skizze und ein README mit Godot-Version und Startanleitung. Lies alles einmal als Malte Kern. + acceptance: + - id: spielbar + text: Die Szene startet mit Godot 4.7 ohne Fehler; der Abschnitt ist von Anfang bis Ende begehbar und umfasst zwei bis vier Bildschirme. + - id: blockout-getrennt + text: Boden, Wände und Hinweise liegen auf getrennten Ebenen aus Platzhalter-Tiles; eine Ausgestaltung, falls vorhanden, liegt auf einer eigenen Ebene und ändert keine Kollision. + - id: absicht-pruefbar + text: "`ABSICHT.md` nennt für den Abschnitt eine Absicht in einem Satz, den erwarteten Weg, die Hinweise und mindestens zwei beobachtbare Zeichen für Erfolg und Scheitern; Änderungen sind datiert." + - id: tests-ohne-erklaerung + text: "`PROTOKOLL.md` belegt mindestens zwei Runden mit zusammen mindestens fünf Testern, die den Abschnitt nicht kannten; Beobachtung und Deutung sind getrennt, Eingriffe sind vermerkt, Tester sind nicht namentlich genannt." + - id: wege-aufgezeichnet + text: Für jeden Tester gibt es eine aufgezeichnete Wegdatei, und `VERGLEICH.md` zeigt die Wege über dem erwarteten Weg. + - id: eine-aenderung-je-runde + text: Jede Überarbeitungsrunde ändert genau eine Sache und nennt eine vorher notierte, zählbare Erwartung und das Ergebnis. + - id: ehrlicher-vergleich + text: "`VERGLEICH.md` nennt mindestens eine Stelle, an der das Verhalten auch nach der Überarbeitung nicht der Absicht entspricht, oder begründet, warum es keine gibt." + - id: git-verlauf + text: Das Projekt liegt in Git; jede Runde ist ein eigener Commit mit Verweis auf ihren Eintrag im Protokoll. + stretch: + - Eine Ausgestaltung mit eigener Ebene und ein Regressionstest mit neuen Testern, der zeigt, ob die Hinweise noch tragen. + - Eine dritte Runde, die eine andere Stelle als die zweite untersucht. + - Eine Fassung, in der du eine Absicht bewusst änderst, und ein Test, der die neue Fassung prüft. + portfolio: | + Das Projekt ist eine vollständige Fallstudie: Absicht, Skizze, Blockout, Beobachtung, Überarbeitung, Vergleich. Zeig im Portfolio das Video mit den Wegen, die Skizze neben dem Blockout und eine Stelle, an der deine Erwartung falsch war. Im Gespräch fragen Designer, was du ohne Testergebnis geändert hättest, wie du entscheidest, ob du das Level oder die Absicht änderst, und wie du einem Artist erklärst, welche Hinweise die Ausgestaltung nicht verdecken darf. From f670f9b14df9dba91b4214d840d70b7e938c5f5b Mon Sep 17 00:00:00 2001 From: Steven Hernandez Date: Thu, 22 Oct 2026 15:44:25 +0200 Subject: [PATCH 2/3] =?UTF-8?q?Handbuch,=20README=20und=20Erz=C3=A4hlhandw?= =?UTF-8?q?erk=20kennen=20den=20Bereich=20Level-Design?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - HANDBUCH: Farbe #8EE06B in der Liste vergebener Farben; unter „Kurse ohne Code“ die Rasterkarten des Bereichs (ein Zeichen pro Tile, 20 Zeichen = ein Bildschirm, höchstens 34 Zeichen unterwegs). - README: Level-Design in der Liste der Bereiche, dazu das bisher fehlende Erzählhandwerk. - Erzählhandwerk, Modul umgebung-erzaehlt: Der Hinweis auf einen „geplanten“ Level-Design-Kurs verlinkt jetzt Orientierung und Umgebung als Information. Nur Lektionstext, kein Fingerprint ändert sich. Co-Authored-By: Claude Opus 5.5 --- HANDBUCH.md | 3 ++- README.md | 2 +- content/narrative/modules/umgebung-erzaehlt.yaml | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/HANDBUCH.md b/HANDBUCH.md index aea57ce..86e6a8f 100644 --- a/HANDBUCH.md +++ b/HANDBUCH.md @@ -71,7 +71,7 @@ Eine vollständige, minimale Vorlage mit jeder Übungsart liegt in [`tooling/fix 1. **Lehrplan entwerfen.** Schreibe zuerst die Liste der Module auf: 10–16 Module in 2–4 Tracks, vom Einstieg bis zum Profi-Niveau. Frage dich bei jedem Modul: *Was kann ich danach, was ich vorher nicht konnte?* Und: *Würde ein Arbeitgeber das erwarten?* 2. **Ordner anlegen:** `content//` mit `area.yaml` (Abschnitt 4). Die Ordner-ID ist kurz, klein und kebab-case, zum Beispiel `go`, `typescript`, `devops`. -3. **Farbe wählen.** Eine kräftige Farbe, auf der schwarzer Text gut lesbar ist (Kontrast ≥ 4,5 : 1 zu `#0B0B0B`). Vorhandene Farben nicht wiederholen: `#A98BFF` Kotlin, `#FF6A3D` Rust, `#FFD400` Linux, `#4D8BFF` Python, `#2BD97C` Automation, `#FF5CA8` Git, `#22D3EE` Data Analysis, `#C6F432` Testing, `#FF9F1C` PostgreSQL, `#F4A3FF` Erzählhandwerk, `#FF4D6D` Combat Design. Gute freie Kandidaten: `#FFC6A8` (Apricot), `#B5E3FF` (Eisblau). +3. **Farbe wählen.** Eine kräftige Farbe, auf der schwarzer Text gut lesbar ist (Kontrast ≥ 4,5 : 1 zu `#0B0B0B`). Vorhandene Farben nicht wiederholen: `#A98BFF` Kotlin, `#FF6A3D` Rust, `#FFD400` Linux, `#4D8BFF` Python, `#2BD97C` Automation, `#FF5CA8` Git, `#22D3EE` Data Analysis, `#C6F432` Testing, `#FF9F1C` PostgreSQL, `#F4A3FF` Erzählhandwerk, `#FF4D6D` Combat Design, `#8EE06B` Level-Design. Gute freie Kandidaten: `#FFC6A8` (Apricot), `#B5E3FF` (Eisblau). 4. **Module schreiben** (Abschnitte 5–7). Ein Modul pro Datei, Dateiname = Modul-ID. 5. **Karten, Projekte, Glossar, Spickzettel, Berufsseite** ergänzen (Abschnitt 8). 6. **Prüfen:** `pnpm content:check `, dann `pnpm verify `, dann `pnpm test` und `pnpm build`. @@ -152,6 +152,7 @@ Manche Bereiche lehren Handwerk ohne Programmcode, zum Beispiel Erzählhandwerk. - **Übungen** nutzen `lang: prose` (Abschnitt 7). `output` passt nur, wo man wirklich etwas vorhersagt, etwa den Zustand einer Verzweigung; die Warnung „keine Vorhersage-Übung“ ist dort bewusst akzeptiert. `bug` heißt „die gemeinte Zeile finden“, meist ohne `fix`. - **Kreative Aufgaben** lassen die Lösung offen. Es gibt keine Mustertexte: `practice` mit `lang: prose` hat keine `solution`, die Checkliste enthält überprüfbare Kriterien, keine Geschmacksurteile. Analysen veröffentlichter Texte dürfen eine Musterantwort haben. - **Callouts** `INTERVIEW` und `PRAXIS` nur, wenn sie wirklich passen; `PRAXIS` zeigt dann, wie Studios oder Autoren arbeiten. +- **Level-Design** zeigt Räume als Rasterkarten in `text`-Blöcken, ein Zeichen pro Tile (`#` Wand, `.` Boden, `S` Start, `A` Ausgang, `L` Landmarke, weitere Zeichen stehen jeweils als Legende daneben). 20 Zeichen sind ein Bildschirm von 320 × 180 Pixeln bei 16-Pixel-Tiles; in Unterwegs-Modulen bleibt eine Zeile bei höchstens 34 Zeichen. Ein `bug` lässt die Zeile mit dem Problem anklicken. Ob ein Raum wirkt, prüft der Lernende im Playtest mit anderen Menschen und mit Checklisten, nie mit einer automatischen Prüfung. ## 6. Lektionen schreiben diff --git a/README.md b/README.md index 04f272a..ababb03 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # learn.kiumu.app -Private Lernplattform für Kotlin & Android, Rust, Linux, Python, Automation mit Python, Git, Data Analysis mit Excel, SQL und Python, Testing & Softwarequalität, SQL & PostgreSQL für Anwendungsentwickler sowie Combat Design & Game Feel mit Godot 4. Live: [learn.kiumu.app](https://learn.kiumu.app) · Öffentliches Repository: [hernstev97/learning-platform](https://github.com/hernstev97/learning-platform) +Private Lernplattform für Kotlin & Android, Rust, Linux, Python, Automation mit Python, Git, Data Analysis mit Excel, SQL und Python, Testing & Softwarequalität, SQL & PostgreSQL für Anwendungsentwickler, Erzählhandwerk & interaktive Entscheidungen, Combat Design & Game Feel mit Godot 4 sowie Level-Design: Orientierung & Exploration. Live: [learn.kiumu.app](https://learn.kiumu.app) · Öffentliches Repository: [hernstev97/learning-platform](https://github.com/hernstev97/learning-platform) Die Plattform ist kein Nachschlagewerk. Jedes Modul besteht aus einer Lektion, die ein Denkmodell aufbaut und auf die offizielle Dokumentation verweist, und aus 10–14 Übungen in fester Reihenfolge: verstehen → vorhersagen → schreiben → Fehler finden → erklären → anwenden. Jeder Bereich hat Interview-Karteikarten mit Wiederholung, Projekte und ein Abschlussprojekt, das wie eine Take-Home-Aufgabe im Bewerbungsprozess geschnitten ist. diff --git a/content/narrative/modules/umgebung-erzaehlt.yaml b/content/narrative/modules/umgebung-erzaehlt.yaml index 75b1b12..a9a5454 100644 --- a/content/narrative/modules/umgebung-erzaehlt.yaml +++ b/content/narrative/modules/umgebung-erzaehlt.yaml @@ -44,7 +44,7 @@ lesson: | Harvey Smith (Arkane Studios) und Matthias Worch (LucasArts) haben das Thema 2010 auf der Game Developers Conference (GDC) unter dem Titel „What Happened Here?“ behandelt. Ihr Vortrag stellt die Umgebung gegen die klassische Exposition, denn der Spieler holt sich die Information selbst. Ziel sind „game spaces that invite the player's mind to piece together implied events“ ([GDC Vault](https://gdcvault.com/play/1012647/What-Happened-Here-Environmental)). Als Werkzeuge nennen sie Requisiten, geskriptete Ereignisse, Texturen, Licht und Bildaufbau, dazu Spielsysteme, mit denen die Umgebung auf den Spieler reagiert. Der Spieler wird so nach ihren Worten „an active participant in narrative“. > [!NOTE] Bedeutung, nicht Wegführung - > Carson behandelt auch Orientierung („Where am I?“) und Details, die den Spieler in den nächsten Raum ziehen. Das gehört zum Level-Design, für das ein eigener Kurs geplant ist. Hier geht es darum, was ein Raum bedeutet. + > Carson behandelt auch Orientierung („Where am I?“) und Details, die den Spieler in den nächsten Raum ziehen. Das gehört zum Level-Design, siehe [Wege, Landmarken und Sichtlinien](/level-design/orientierung) und [Umgebung als Information](/level-design/umgebung-informiert). Hier geht es darum, was ein Raum bedeutet. ## Vier Arten nach Henry Jenkins From 0c259290333894698552d62c6be669d88b7bd37b Mon Sep 17 00:00:00 2001 From: Steven Hernandez Date: Thu, 22 Oct 2026 15:44:55 +0200 Subject: [PATCH 3/3] =?UTF-8?q?Level-Design:=20Blickf=C3=BChrung=20verweis?= =?UTF-8?q?t=20f=C3=BCr=20bewegte=20Hinweise=20auf=20den=20Animationskurs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5.5 --- content/level-design/modules/blickfuehrung.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/level-design/modules/blickfuehrung.yaml b/content/level-design/modules/blickfuehrung.yaml index 1b79bc4..0e32751 100644 --- a/content/level-design/modules/blickfuehrung.yaml +++ b/content/level-design/modules/blickfuehrung.yaml @@ -63,7 +63,7 @@ lesson: | **Licht** ist Tonwert mit einem Grund. Für Left 4 Dead nennt Mitchell beim Licht in dunklen Szenen ausdrücklich „Aid navigation“ und „Players tend to follow the light“. Das Level Design Book listet bei Licht und Farbe den „path implied by light placement (Left 4 Dead)“ und „visibly lit entrances and exits“. In der Draufsicht heißt das: ein beleuchteter Durchgang in einem dunklen Raum, eine Reihe Laternen entlang eines Wegs, ein heller Fleck am Ende eines Gangs. Wie du Licht und Schatten in Pixelart zeichnest, steht im Pixelart-Kurs. Hier zählt, wo es liegt. - **Bewegung** zählt nach der dritten Regel ebenso. In Half-Life 2 sind es die Vögel. Das Buch führt Tiere und Figuren, denen man folgt, als subtile Hilfe, „birds in Half-Life 2“ steht als Beispiel. In einem Standbild aus lauter ruhigen Tiles fällt eine bewegte Stelle auf: eine flackernde Flamme, Wasser, ein Tier. Daraus folgt auch das Gegenteil. Bewegt sich überall etwas, etwa animiertes Wasser über die halbe Karte, verliert Bewegung ihre Wirkung. + **Bewegung** zählt nach der dritten Regel ebenso. In Half-Life 2 sind es die Vögel. Das Buch führt Tiere und Figuren, denen man folgt, als subtile Hilfe, „birds in Half-Life 2“ steht als Beispiel. In einem Standbild aus lauter ruhigen Tiles fällt eine bewegte Stelle auf: eine flackernde Flamme, Wasser, ein Tier. Daraus folgt auch das Gegenteil. Bewegt sich überall etwas, etwa animiertes Wasser über die halbe Karte, verliert Bewegung ihre Wirkung. Wie solche Schleifen im Spiel getaktet und gezeichnet werden, ist Thema des Animationskurses ([Animation im Spiel](/animation/animation-im-spiel)); hier zählt nur, wo sie stehen. **Linien** führen den Blick entlang ihrer Richtung: ein Weg aus anderem Boden, ein Zaun, ein Fluss, eine Kante zwischen zwei Bodenarten, eine Reihe Säulen. Das Buch nennt solche Führung „ground composition“ mit Beispielen wie „train tracks (Team Fortress 2)“ und betont die „clear gameplay function“. Eine Linie führt dorthin, wo sie endet. Endet sie an einer leeren Wand, kommt der Blick dort an und findet nichts.