Vorlesung 8 Flashcards
Ziele von Ludemtaxonomien
- Versuch Spiele auf Elemente (=Ludeme) herunterzubrechen
- Versuch etwas wie Softwaredesign Patterns für die Spieleentwicklungzu machen
- Ähnliche Überlegungen wie in der Gestaltlehre etc.
- Versuch der Erstellung eines Baukastensystems
- Ziel: Erschaffung einer Terminologie für Game Design
Probleme von Ludemtaxonomien
- Listen werden sehr lang
- Listen sind immer noch unvollständig•Elemente überlappen sich
- Elemente widersprechen sich
- Das Dahinterstehende fehlt
- Praktiker denken eher in Beispielen
- Wie Genre-Ansammlung in Spielezeitschriften
Aktivitätsframework (Bjork)
Spielekomponenten (Ludeme):
-Holistische Elemente:
Game Instance: Beschreibung dessen, was bei einem konkreten Spiel passiert
Game Session: Beschreibt den Ablauf eines kompletten Spieles aus der Sicht eines Spielers
Play Session: Aktivitätsbeschreibung, was in einer Spielsitzung passiert
Extra-Aktivitäten: SpielebezogeneAktivitäten, die nicht direkt zum Spiel gehören
-Begrenzungselemente:
Beschreiben das Abkommen zischen den Spielern
Spielregeln: explizite Regeln und systemeigene Regeln (schon viel drüber gesagt)
Spielziele: Schach mattsetzen etc. können hierarchisch sein (meist in Computerspielen)
Spielmodi: Zerlegung des Spieles in unterschiedliche Zustände, in denen verschiedene Regeln gelten (PacMan, Space Hulk, SplinterCell)
-Ablaufelemente:
Beschreibt den zeitlichen Ablauf und den Flow des Spieles
Actions: Was kann der Spieler machen, um den Spielzustand zu beeinflussen
Events: Was sind die Reaktionen des Spieles auf den Spieler (beide bilden das eigentliche Zentrum des Spieles)
Konvexitäten(Closures): In welche logischen Abschnitte lassen sich Spiele aufteilen
Endbedingungen: Was sind die Bedingungen für das Ende eines Spieles (unterschiedlich für Session und Instance –Rennspiel)
Auswertungsfunktion: Welche Endbedingung? Bildet mit Endbedingung die wesentlichen Elemente der Konvexität
-Strukturelle Elemente:
Beschreibt die Dinge, die vom Spieler manipuliert werden
Game Facilitator: Was erstellt und synchronisiert den Spielezustand? (Spielbrett, Karten, GM in RPGs)
Player: Diejenigen, die das Spiel spielen (mehrere Spieler können einen Spieler darstellen)
Interface: Kommunikation des Spielezustandesund der Handlungsmöglichkeiten (auch auf nicht Computerspiele bezogen)
Game Elemente: Die Dinge, die manipuliert werden können (Figuren auf Spielbrett)
Game Time: Welchen Einfluss hat der Zeitaspekt auf das Spielgeschehen?
Ludemtaxonomien (Bjork)
Spielelemente:
- Welten (Level, unerreichbare Regionen)
- Objekte (Gegner, Werkzeuge)
- abstrakte Objekte (Score, Leben)
- Orte (strategische Positionen)
Resourcen und Resourcen Management:
- Typen (Geld, Rohstoffe)
- Kontrolle (Besitz, Produzenten, Konsomentenverhältnis)
- Fortschritt (Investitionen)
Information, Kommunikation, Darstellung:
- Informationsqualität (Vollständigkeit)
- Verteilung (symmetrisch, asymmetrisch)
- Informationsdarstellung
Aktionen und Ereignisse (!):
- Aktionen (Kampf, Bewegung,..)
- Kontrolle von Aktionen (Fähigkeitenerwerb, irreversibel)
- Belohnungen und Bestrafungen
Narrative Strukturen und Immersion:
- Narrative Strukturen (Charaktere, Handlungen)
- Immersion (Immersion, Antizipation)
Soziale Interkation:
- Wettkampf (!) (Konflikt, Verrat)
- Zusammenarbeit
- Gruppenaktivitäten (Team Play, Allianzen)
Ziele und Zielstrukturen:
- Ziele (Überleben, Befreien, Töten)
- Zielstrukturen (Hierarchisch, Widersprüchlich)
Game Sessions:
- Single Player, Multiplayer
- Rundenbasiert
Spielkontrolle und Balance:
- Spielkontrolle (Timing, Puzzle, Glück)
- Balance (Fairness, Schwierigkeit)
Meta-Spiele
Ludemtaxonomien (Falstein)
- Provide clear short-term goals
- Provide parallel challenges with Mutual Assistance
- Begin at the middle (design process)
- Make the game fun for the player, not the designer or the computer
- Make the effects of the AI visible to the player
- Add a small amount of randomness to AI calculations
- Create AI in the mind of the player
- Ask: What does the user do?
- Make even serious games fun
- Gameplay comes first
- Make the game appear fair to the player
- Make learning the educational content optional but integral to the enjoyment (educational games)
- Make challenges require skill
- Do, Do not show
- Provide a reaction to every player action
- Put the money on the screen (alles sollte sichtbar sein)
- Trim the fat (aka keep it strictly simple)
Projektdokumentation
Ziele:
- Planungswerkzeuge: Risikoreduktion (nur bedingt gegenüber Prototypen), Möglichkeit Risiken in angrenzenden Bereichen (Technik etc.) zu erkennen
- Produktionskontrollelement: Was ist die zentrale Vision? Was ist goldplating?
- Vertragsgrundlage: Verkaufsprospekt für Verlage, Vertragsgrundlage, Kommunikationsmittel mit Auftraggeber
Design Treatment
- Erste Beschreibung des Spiels
- Leser soll die Frage beantworten können, ob er an dem Projekt teilhaben will oder nicht
Leser und ihre Ziele:
- Game Designer: Verifizierung der Ideen
- Entwicklungsteam: Vorgabe einer zentralen Vision
- Verlag: Einfacher Verkaufsprospekt, der schnell gelesen werden kann
- Investoren: Übersicht über Marktbedingungen, Kosten und Risiken
Design Treatment - Game Concept
- 1 Absatzbeschreibung des Spieles (siehe vorangegangene Vorlesung)
- Feature Liste: Was kann ich in diesem Spiel machen, das ich in keinem anderen kann?
- Regeln und Mechaniken: Gibt es spezielle technische Komponenten? Gibt es spezielle Zusammenhänge?
- Story, Plot und Charaktere: Je nachdem, wie storybasiert das Spiel ist
- Struktur: Viele lineare Level, Open World, ….
Design Treatment - Look and Feel
- Concept Art der Hauptcharaktere und Umgebungen
- Beschreibung des Kamera-Systemes: First-Person / Third-Person, Fix oder frei …
- Steuerung: Wie kann der Spieler mit dem Spiel interagieren?
Design Treatment - Technik
- Welche Komponenten sollen verwendet werden?
- Welche Ideen/Lösungen kommen zum Einsatz?
Design Treatment - Business Model
- Auf wieviel Zeit und Geld ist das Projekt geplant?
- Für welche Plattformen ist es entworfen?
- Ist es die Grundlage zur Begründung einer Marke? Was kann weiterverwertet werden?
- Zielgruppe: An wen wendet sich dieses Spiel? Wie sieht die Konkurrenzsituation am Markt aus?
- Voraussetzungen: Wieso ist man gut geeignet das Spiel zu machen? Ist man Besitzer einer Lizenz? Hat man Zugriff auf speziell qualifizierte Leute?
PDD (Preliminary Design Document)
- Ausweitung des Design Concepts
- Wird in der frühen Phase der Spieleentwicklung angefertigt (Conception)
- Beginn der Auslagerung von Technik und Artwork
- Dient als Planungs-und Vertragswerkzeug
- Meist als abhängiger Entwickler verwendet
- Ist an sich noch ein monolithisches Dokument
PDD Teile
Spielelementbeschreibungen:
- Zusammenfassung der Teile aus den Prototypen
- Darstellung der Spielkontrolle
- Schon viel erzählt
Level Listen:
- Was ist das Ziel oder der Punkt der einzelnen Level
- Wie passen Level in das Pacing und Ramping Konzept?
- Wie sind Level mit der Story verschränkt?
Game AI:
-Wie sollen sich freundliche und feindliche NPCs verhalten?
Marketing Informationen:
- Welchem Genre ist das Spiel zuzuordnen?
- Was sind Konkurrenzprodukte?
- Was ist besonders an diesem Spiel?
Storyaufschlüsselung:
- Wie sieht die Story aus (kurze Zusammenfassung, längere Version, Aufschlüsselung)
- Aquanox Beispiel
Charakterbeschreibungen:
- Auflistung der einzelnen Charaktere
- Aussehensbeschreibung
- Typische Verhaltensweisen in welchen Situationen
Itembeschreibungen:
- Auflistung aller wesentlichen Gegenstände
- Welche Rolle haben sie im Spiel?
- Welche Eigenschaften haben sie (Excel-Spreadsheet)
Interface Beschreibungen:
- Was muss dargestellt werden und wie?
- Setup Menu
- Ingame Menu
- HUD
- HUB / Ausrüstungsmenüs etc.
Spielzustände und Übergänge:
- Setup Phase
- Level Spielen Phase, etc.
VO Listen:
- Welche Sprachaufnahmen werden gebraucht?
- Wo reichen Sprachtags?
FMV Listen:
- Welche Videoaufnahmen werden gebraucht?
- Was wird als Machinima gemacht?
- Motion Capture Assets
Welche Assets sind generell zu lokalisieren?
FDD (Final Design Document)
- Reihe an losen Dokumenten
- Sehr dynamisch
- Dokumente werden je nach Bedarf zu unterschiedlichen Phasen der Produktion angelegt
- Balancing Spreadsheets von NPCs
- Detaillierte Gameplay Matrix
- Detaillierte Steuerungs-und Controllerbeschreibung
- Detailliertere Beschreibungen / Requirementsfür die einzelnen AIs
- Skizzen und Diagramme für Pacing, Balancing und Ramping
- Detailliertere Story Auflistung mit Dialogen
- Liste an zu erstellenden Voice Tags
- Lokalisierungskits und Planungen
- Detaillierte Planungen für FMVs
- Planungen für die Aufnahme von MoCap Daten
- Planungen für Animationen
- Planungen an Modellen
- Planungen und Auflistungen von Soundeffekten
- Detaillierte Planungen für Menüs/Einstellungen
- Anforderungsliste an technischen Features
- Planungen für Pressearbeit, Vorabversionen etc.
Weitere Dokumente
PDD, RDD und FDD werden häufig als GDD verallgemeinert
- ASG: artistic style guide - Art Aspekte
- TDD: Technical Design Document - Beschreibung der technischen Aspekte
Da Technik kritisch ist, gibt es häufig ein TDR (technicaldesign review)
