Design-Dokumente und Spielkonzept

[Tejio]

Hallo und guten Abend euch allen,

ich bin unerfahren bei der Entwicklung von Spielen und das in dem Sinne, dass ich bisher nur kleinere Projekte im Zusammenspiel von C, Linux und OpenGl entwickelt habe. Neben meiner schulischen Ausbildung zum Medieninformatiker arbeite ich als einfacher, kleiner Programmierer unter C++.
Gemeinsam mit einem Kommilitonen möchte ich mich an ein größeres Projekt, einem kleinen 3D-Spiel, wagen. Um vielleicht etwas Unterstützung zu bekommen, wurde ich auf die Möglichkeit hingewiesen, dass man durch die Veröffentlichung eines Spielkonzeptes unter Umständen weitere Menschen für das Projekt gewinnen kann. Ebenso wurde mir gesagt, dass ein Design-Dokument auch nicht schaden würde.
Nun steht ich vor der Frage: Wobei handelt es sich bei diesen beiden Dokumenten und was beinhalten sie? GIbt es große Unterschiede zwischen ihnen?

Verzeiht mir bitte meine langatmige Einführung. Mir fällt es etwas schwer, einfach zum Thema zu kommen.

Liebe Grüße
Tejio

[pUnkOuter]

Das versteht jeder ein wenig anders. Ich sehe es so, dass das Spielkonzept eher ein allgemeines, kurzes Dokument ist, das so wenig wie möglich auf technische Einzelheiten eingeht (etwa wie das Vision Document hier: http://www.alanemrich.com/Class/Class_P ... 20Document). Das Design-Dokument ist dann die detaillierte Dokumentation des Spiels, welches während der Entwicklung ständig aktualisiert wird und vor allem zur internen Kommunikation verwendet wird.

[Jiba]

http://rft-wiki.fh-trier.de/index.php/D ... n_Document
Dort wird ganz gut beschrieben was es so üblicherweise für Dokumente für den Prozess der Spieleentwicklung gibt.

[BeRsErKeR]

Ich denke mal Ziel des Design-Dokumentes sollte sein, dass ein Leser weiß um was es geht und wie bestimmte Dinge (nicht unbedingt technisch) umgesetzt werden sollen.

Ein Grafiker sollte einen Eindruck bekommen, wie die Welt, Charaktere usw aussehen könnten, damit er seine Arbeit beginnen kann.

Ein Gamedesigner sollte wissen wie er bestimmte Teile zu designen hat, wie alles ineinander greift.

Ein Programmierer sollte grob den Aufwand abschätzen können, der hinter dem Projekt steckt.

Und so weiter ...


Ich denke um so ausführlicher, übersichtlicher, verständlicher und vollständiger ein Design-Dokument ist, umso besser ist es. Und es sollte im Laufe der Projektentwicklung immer mal wieder erweitert und vervollständigt werden.

[Andes]

Hallo,

ich weiß zwar nicht ob noch bedarf besteht aber ich wollte gerne auch mal eine Antwort schreiben.

Wie schon von anderen gesagt ist das Konzept tatsächlich ein sehr kurzes Dokument, welches auf den Punkt kommt. Dieses Konzept wird auch „High Concept Document“ (HC) genannt.
Dieses Dokument kann aus folgenden Punkten bestehen. (Allgemein gibt es in der Spielebranche keine Standards, daher kann es auch kürzer sein).

High Concept Statement
--Hollywood Pitch
--Elevator Pitch
Design Goals
Features
USPs
Game Goal
Game Information
Game Concept
Basic Gameplay
Extended Gameplay
Story
Team
Must Have
Nice to have
Planung Technologie

Hier mal ein Beispiel aus deine HC das ich 2007 geschrieben habe. Es handelt sich um ein Adventure.

High Concept Statement // Bei den Pitches geht es darum jemanden innerhalb von "einem" Satz zu überzeugen
Hollywood:
Back to the future meets Monkey Island
Elevator Pitch:
Rätsle dich mit Andrew Fuller durch ein comichaftes Zeitreise - Szenario und verhindere das Ende
der Welt. Auf deinem Weg begegnest du knackigen Rätseln sowie verschrobenen Charakteren und
besuchst obskure Schauplätze.

Design Goals // Was ist dein "persönliches" Ziel
Witziges Adventure im Zeitreiseszenario und verschiedensten Arten von Rätseln.
Stimmungsvolle Grafik und Sound; flüssige Animationen; logische Rätsel; interessante
Story; bewusst bisherige Fehler von Adventures (z.B. man weiß nicht wo der Bildschirm
weitergeht etc.) vermeiden

Features //Dürfte klar sein
• 3D Point & Click Adventure mit:
• 5 interessanten Charakteren
• 7 Schauplätzen
• Vielen tollen Items
• Lustiger Zeitreise – Story

USPs // Unique selling point/proposition Sprich, was macht dein Spiel einzigartig
• Tagebuch des Charakters mit Lösungshilfe
• Zeitreiseszenario
• Gut erkennbare Interaktionsmöglichkeiten

Game Goal // Was ist das Spielziel
Rätsle dich durch die Zeit und deine eigene Familiengeschichte um dich und deine
Gegenwart vor dem Untergang zu retten.

Game Information // Ist klar, oder?
Genre: 3D Point & Click Adventure
Plattform: Windows PC
Zielgruppe: Adventure Fans von 15 - 40
Spielzeit: ½ Stunde

Game Concept // Ab hier paar ausführlich erklärungen
„Modernes“ Point & Click Adventure in einer 3D Umgebung. Der Spieler muss einer Verkettung von
Ereignissen auf die Spur kommen, die in seiner Gegenwart zu deren Zerstörung führt. Dazu muss er
verschiedenste Rätsel lösen wie z.B. Itemrätsel und Logikrätsel. Spannung und Interesse werden durch Story
und Charaktere erzeugt. Man kommt nach und nach dem Ereignis auf die Spur, welches Andrews Gegenwart
zu vernichten droht. Ein zusätzlicher Unterhaltungswert stellt der schräge Humor dar, der sich in Spielwelt
und Charakteren widerspiegelt.

Basic Gameplay
Das Adventure wird allein mit der Maus gesteuert. Man bewegt Andrew in einer 3D Umgebung mit starren
Kamerawinkeln. Man untersucht und benutzt Objekte, nimmt sie in ein Inventar auf und kombiniert sie
miteinander oder der Umgebung. Zu den Interaktionen zählen auch Multiple - Choice - Dialoge mit den
interessanten NSCs, die Andrew im Verlauf seines Abenteuers trifft.

Extended Gameplay
Der Spieler bewegt Andrew mit einem Klick des rechten Mausbuttons durch die 3D Umgebung. Jedes Mal
wenn der Mauscursor ein interaktives Objekt berührt wird am oberen Bildschirmrand eine Beschreibung
eingeblendet. Klickt man dieses Objekt mit dem linken Mausbutton an erscheinen auf dem Objekt Icons. Ein
Klick mit der linken Maustaste auf das rechte Icon lässt Andrew das Objekt untersuchen. Ein Klick auf das
linke Icon löst je nach Kontext eine passende Aktion aus. „Öffnen“ bei Türen etc.; „Sprechen“ bei Personen;
„Benutzen“, „Nehmen“, „Drücken“ und „Ziehen“ bei Objekten. Ein Klick auf das Amulett morpht bestimmte
Gegenstände in der Zeit. Die Aktivierung des Objekts wird durch einen Klick mit der rechten Maustaste,
dem Selektieren eines anderen Objektes oder nach einer bestimmten Zeit von allein aufgehoben. Objekte
mit denen man nicht mehr sinnvoll interagieren kann, werden automatisch inaktiv und können vom Spieler
nicht mehr angewählt werden. Nimmt man ein Objekt auf so landet es im Inventar, welches als Balken am
unteren Bildschirmrand präsent ist. Aus dem Inventar heraus kann man Objekte mit demselben Iconsystem
untersuchen, aufnehmen und mit anderen Objekten, innerhalb und außerhalb des Inventars, kombinieren.
Dialoge zwischen Andrew und den Nichtspielercharakteren laufen nach einem Multiple - Choice - Verfahren
ab. Es stehen stets mehrere mögliche Antworten zur Verfügung. Es gibt Item-Rätsel, diese werden durch die
richtige Kombination mit anderen Gegenständen oder der Umgebung gelöst. Des Weiteren sind Logikrätsel
vorhanden. Sie stellen sich als Minispiele da, wie z.B. ein Mischrätsel.

// genug der Ausführlichkeiten

Story
Andrew Fuller ist 25 und Amerikaner. Er wacht eines Morgens, nach einer langen Party, völlig ahnungslos in
seinem Bett auf. In den Knochen hat er noch den Kater vom Vortag. Benommen hangelt er sich durch seine
Wohnung. Als er aus dem Fenster sieht, erblickt er eine gigantische Welle die die Realität selbst aufzusaugen
scheint und sich direkt auf seine Wohnung zubewegt. Panisch flüchtet er aus seiner Wohnung, doch anstatt auf
der Straße findet er sich in einem Zeitstrudel wieder. Es beginnt eine verrückte Reise durch die Geschichte um
die Wurzel der Katastrophe zu finden, und das Geheimnis um ein magisches Amulett zu lüften.

Das Team:
*******

Must Have // Was muss auf jeden fall rein
- Komplettes “Alpha” Modul (siehe externes Dokument)
- Basic Gameplay: Klicken, Bewegen, Inventar, Sprechen, Benutzen, Kombinieren
- Abgeschlossene, in sich stimmige Story
- Charakter Tagebuch

Nice To Have // Was wäre schön
- Mehr Charaktere, mehr Dialoge, mehr Rätsel, mehr Schauplätze
- Bonus Features

Planung:
***** Zeitplan *****

Technologie:
Trinigy Vision Engine
Ogre Engine
Autodesk 3D Studio Max
Adobe Photoshop CS3
MS Visual Studio 2005
Python


Natürlich kann man jetzt hier sagen: Hey da wiederholst du dich aber oft. Aber was soll ich sagen :) Ich war jung und brauchte das Geld, oder so?!. Bei den Wiederholungen muss man sich auch folgendes denken. Einen Programmieren, Grafiker oder Producer interessieren immer andere Punkte. So kommt es vor das nicht jeder, jeden Textblock liest.

Okay - kommen wir jetzt zum Design Dokument, auch Game Design Document (GDD) genannt. Diese Dokument ist so lang wie möglich und so ausführlich wie nötig. Das GDD wird vom Game Designer verfasst. In diesem Dokument muss man alles beschreiben. Für jeden (Programmierer, Grafiker, Musiker) muss klar sein was er zu tun hat und wie das ganz auszusehen hat. Das GDD für dieses Adventure ist ca. 60 Seiten lang (+30 Steiten Anhang), bei einer Spielzeit von 30-45 min. Natürlich hätte man sich an vielen Stellen kürzer fassen können aber gewiss an anderen auch ausführlicher werden.
Da Das den Rahmen sprengen würde, werde ich hier nur das Inhaltsverzeichnis reinposten.
High Concept Dokument................... 03
Technical High Concept Dokument... 07
Alpha Dokument................................ 08
Intro Story.......................................... 1 0
Rätsel................................................ 1 5
Zahnradrätsel....................... 1 5
Mischrätsel.......................... 1 5
Tagebuchfunktion............................. 1 6
Charaktere......................................... 1 9
Amulett.............................................. 23
Steuerung.......................................... 28
Dialog Plan........................................ 29
Asset Liste........................................ 46
Soundkonzept................................... 49
Entwicklertagebuch......................... 52
Anhang A........................................... 68
Charakterskizzen.................. 69
Schauplatzskizzen................ 71
Vorbilder......................................... 73
Anhang B........................................... 77
Verworfene Charaktere......... 78
Verworfene Schauplätze....... 87
Research............................... 92

Jetzt noch meine persönliche Erfahrung: Oft sind die Menschen lesefaul. Daher ist es "eigentlich" ratsam, die Fakten festzuhalten und Offensichtlichkeiten unter den Tisch fallen zu lassen. Wobei das natürlich auch nur eine Methode von vielen ist. Wie du dir schon denken kannst, birgt sie natürlich die Gefahr des "was ist schon offensichtlich".

Ich hoffe ich konnte dir damit helfen.

Viele Grüße, Andes

[Krishty]

Professionelles und wertvolles Beispiel. Danke!

[BeRsErKeR]

Jetzt noch meine persönliche Erfahrung: Oft sind die Menschen lesefaul. Daher ist es "eigentlich" ratsam, die Fakten festzuhalten und Offensichtlichkeiten unter den Tisch fallen zu lassen. Wobei das natürlich auch nur eine Methode von vielen ist. Wie du dir schon denken kannst, birgt sie natürlich die Gefahr des "was ist schon offensichtlich".

Das finde ich auch sehr gefährlich, denn gerade wenn man das ganze im Kopf hat und eine genaue Vorstellung von allem hat, ist "offensichtlich" meist an Dinge geknüpft, die für andere nicht unbedingt ersichtlich oder selbstverständlich sind. Außerdem sind Wissen und Erfahrung bei unterschiedlichen Menschen anders ausgeprägt. Das sieht man gut wenn man einen Arzt als Verwandten hat und der nur noch mit lateinischen Fachbegriffen um sich wirft und gar nicht merkt, dass die anderen nichts verstehen. Ist ja wie bei Benutzereingaben. Man kann nie dumm genug denken. Beim GDD finde ich wirklich "mehr ist manchmal auch mehr". :P

Ich schreib daher alles bis ins kleinste Detail auf. Das ist auch für mich selbst hilfreich, weil ich nach 2 Jahren nicht mehr unbedingt weiß warum etwas so sein soll, wie es da steht. Das ist mir in der Vergangenheit desöfteren passiert. Jetzt schau ich einfach nach und denke "Aha so ist das also. Du hattest damals echt viel Freizeit.". :D