Hallo ihrs,

Nachdem Sascha euch das nicht vorenthalten will (hast ja Recht )


Sascha Willems hat ja in seinem Blog betreffend Projekt "W" auch ein paar allgemeine Bemerkungen zum Game Design gemacht. Kann man zwar auch studieren, aber da ich noch nicht mal die Schule fertig hab, frag ich mal lieber hier

Ich hab ja schon so eine grobe Idee von dem Spiel, aber die Details sind eben recht unscharf. Daher hab ich mir gedacht, ich mache es endlich mal richtig und plane vorher, was ich eigentlich will.

Welche Fragen sollte man sich bei der Planung eigentlich so stellen? Nicht, dass man irgend etwas wichtiges vergisst und nachher alles neu programmieren muss... Klar, ich könnte das jetzt ausprobieren, aber ich denke mal, man kann es auch gleich richtig machen.

Wäre schön, wenn mir da jemand ein paar Tipps geben könnte

mfg,
Sebastian

_________________
Gott sei Dank bin ich Atheist!

Da wären die Softwaretuts wärmstens zu empfehlen

UML hat bei mir irgendwie kein gutes Image, erst recht nach den Tutorials nicht. (OT: Wobei ich auch MindMaps nicht mag...) Das kann aber durchaus daran liegen, dass ich den Sinn der Sache nicht ganz verstehe, und das erst recht nicht auf Spieleprogrammierung beziehen kann.
Bei dem NapalmBomber-Tut geht es ja auch gleich ans Coden.

Nur hat ja Sascha hier zum Beispiel bei Some infos about gamedesign geschrieben, dass ein Block Papier der beste Freund des Programmierers ist.
Mir ging es eigentlich darum: was landet da alles drauf

GUI, Flussdiagramme, (Pseudo)Codeschnipsel, sprich einfach alles was einem einfällt
ODER
Man stellt sich bestimmte Fragen. Irgendwie hab ich die UML-Tuts auch so verstanden.

Das Problem ist eben: das ist das erste mal, dass ich halbwegs "professionell" arbeiten möchte, und daher völlig unbeleckt bin

_________________
Gott sei Dank bin ich Atheist!

Also ich überlege mir als erstes genau was die engine alles können soll. Also die Grundfeatures, und wie/wo sie erweitert werden kann. Dann arbeite ich noch die ungefähren Datenstrukturen aus.

Also sonderlich viel zum Gamedesign kann ich dir auch nicht sagen, da ich ein sehr intuitiver Programmierer bin. Selbst bei größeren Projekten wie Projekt "W" fang ich einfach an zu proggen und auf meinem Block sind größtenteils Zeichnungen von Dialogen mit Beschriftungen was genau welcher Teil machen soll, ausserdem dann noch die Hauptansichten. Quellcodes oder gar Codeaufbau mach ich zur "Laufzeit", also während ich programmiere.
Wichtigste Datensammlung ist mein Game-Design Dokument dass sehr umfangreich ist. Da stehen halt elle benötigten Infos zur Spielmechanik drin die ich dann so direkt ins Spiel umsetzen kann, auch Spielinhalte wie Gebäude und Einheiten oder Technologien stehen da drin, aber die setz ich ja mit einem eigenen Editor um.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hm, also doch einfach drauf los

Hab ich dann auch gleich gemacht, und sofort gehen die Probleme mit kaputtem Culling los... Mist. Naja, dafür hab ich euch ja...
Hab aber immerhin auch schon ein Programmflussdiagramm zu Papier gebracht. Das bringt wirklich was, das sieht man, was zu tun ist

_________________
Gott sei Dank bin ich Atheist!

Also "einfach drauf los" und sehen was passiert ist denke ich wohl nicht immer so praktisch und wohl auch nicht immer ganz richtig. Ich denke im groben und ganzen wird sich jeder schon so seine Gedanken machen. Zu Begin muss man nicht alles bis ins kleinste Detail ausführen. Es genügt ein grober Überblick und das generelle Zusammenspiel zwinschenen den Dingen. Und dieses noch sehr "schwammige Etwas" wird man mit der Zeit immer weiter formen. Gleich am Anfang an alles zu denken ist unmöglich. Es kommt immer anders als man es erwarten würde. Das ist einfach so.

Bei Schnittstellen ("engines" oder sonst etwas) ist es aber dennoch sehr wichtig, dass man sich genau gedanken darüber macht was man damit alles machen möchte und was man evtl später noch damit machen möchte. Damit dies in seinem Design und in der Schnittstelle entsprechend berücksichtigen kann.

Wichtiger ist wohl eher der Aufbau des Codes. Es ist wichtig seinen Code modular aufzubauen. Also so, dass man einige Teile wiederverwenden und/oder leicht erweitern kann. Aber dabei kommt es immer darauf an was man damit vor hat. Bzw ist es auch eine Sache der Erfahrung, die einen automatisch dabei beeinflusst. Je nachdem was man schon alles gemacht hat würde man evtl das ein oder andere so oder so gestalten. Das lässt sich leider nicht näher beschreiben, weil das von jedem Entwickler abhängt. Geschmackssache, Erfahrung oder einfach Intuition.

UML: Das ist in den Tutorials alles gut und schön. Aber wenn ihr mich fragt ist das kein sanfter Einstieg. Das ist ganz schön häftig. Ich persönlich sehe UML sehr einfach. Für mich ist es eine Möglichkeit die Abhängigkeiten zwischen verschiedenen Klassen/Packeten/Black Boxen darzustellen. Und sich zu überlegen ob das überhaupt Sinn macht. Wenn das UML Diagramm aussieht wie Picassos Braut dann stellt sich die Frage ob die Beziehungen zwischen den Dingen immer so gut gewählt wurden.

Hm, naja. Ganz einfach drauf los meinte ich auch nicht. Nur halt nicht nach "Schema F".

Modular programmieren tue ich sowieso, da ist das nicht so das Problem

Danke jedenfalls für die Antworten. Ich hoffe mal, das hat mich weiter gebracht.

_________________
Gott sei Dank bin ich Atheist!

Was auf dem Papierblock niemals landet ist Code/Pseudocode. Da müsste schon was ungewöhnliches passieren.

UML und vorallem der RUP sind Hilfsmittel um ein Problem zu analysieren und zu verstehen. Der RUP wurde für commerziele Projekte entwickelt wo die Programmierer eigentlich gar nicht wissen was der Kunde will. Der RUP hilft dem Programmierer zu verstehen was der Kunde braucht.

Da du beim Spieleprogrammieren weißt was du machen willst solltest du zuerst mal aufschreiben welche Sachen dein Spiel am Ende können soll. Das ist wichtig. Denn wenn du das beim programmieren entscheidest kommen immer mehr ungeplante Funktionen hinzu.

Als nächstes ist das Desinen der Oberfläche sinnvoll. Es gibt sogar Methoden die Sagen "Schritt 1 bei einem Projekt ist das Schreiben der Bedienungsanleitung samt Bildern/Skizzen der Menüs." Wenn man nämlich die Bedienungsanleitung hat, weiß man wie die Teile zusammenspielen und was wo gemacht werden muss.

Nachdem du das hast solltest du dir Gedanken machen wie du das MVC-Paradigma realisierst. Das ist wichtig, falls du mal an der Oberfläche oder den Daten was ändern musst.

Wenn du das auch weißt, solltest du dir Gedanken um die Entitys machen. Also die Klassen welche Datenspeichern. Das geht meist recht schnell.

Danach, und das ist wichtig, nimmst du dir deine Bedienungsanleitung (oder wie Sascha sein Game-Design-Dokument) und schaust dir an welche Anwendungsfälle es gibt. Anwendungsfälle/UseCases sind Prozesse/Abläufe welche in deinem Spiel passieren. Also z.B. Ein Kampf, Das Bauen von Gebäude, Forschung aber auch die Ereignisverwaltung etc.
Jetzt machst du dir konkrete Gedanken was jeder Controller eines jeden UseCases für Daten (Entitys) brauch und was er damit machen muss. Auch welche Oberflächen er aktualisieren muss (eventuell).

Abschließend solltest du dir dann noch gedanken machen wie die Controller untereinander arbeiten. Eventuell gibt es übergeordnete Controller welche die untergeordneten rufen. Eventuell kannst du die UseCases auch noch in kleinere Teile aufteilen die an verschiedenen Stellen wiederverwendet werden.

Wenn du das alles hast solltets du dir noch Gedanken um die Strukturierung deines Projektes machen.

Und dann ist eigentlich alles soweit das du mit programmieren anfangen kannst.


Noch ein Wort zu Sascha und seinem Vorgehen. Im Grunde genommen (jedenfalls glaube ich das) macht er auch nichts anderes als hier beschrieben. Sein Game-Design-Dokument ist im Grunde genommen die Bedienungsanleitung die zu erstellen ist. Ich kann mir gut vorstellen das darin auch die Entity-Eigenschaften und einiges mehr der oberen Punkte enthalten sind. Das er keine UseCases aufschreibt (oder nur rudimentär) geht deshalb weil er genug erfahrung hat um das abzuschätzen. Das geht weil Sascha allein programmiert. Wenn er im Team arbeiten würde/müsste geht das gegen die Wand. Wieso? Weil sein Kollege nicht weiß wie er was gemacht hat und umgekehrt. Schlimmstenfalls werden dann sachen doppelt geschrieben, bestenfalls wird Zeitverschwendet weil man sich in den Code des anderen einlesen muss.

Niemand sagt das ihr UML verwenden müsst. UML wurde entwickelt damit sich Programmierer verschiedenster Richtungen und Geschäftszweige miteinander unterhalten können ohne lange Codes analysieren zu müssen. UML ist quasi eine Sprache. Und durch die Codegenerierung geht auch auch nicht viel Zeit verloren. Schließlich purzelt am Ende dann ja Code raus, den ihr nur noch vervollständigen müsst.


... mal wieder etwas länger geworden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Flash hat da an sich recht. Wichtigstes Dokument ist zumindest bei einem komplexeren Projekt das Design Dokument. Meins sieht zwar nicht aus wie ne Anleitung (obwohls sicher Leute gibt die dass in so einer Form schreiben) aber es ist der zentrale Sammelpunkt für alle Spielideen und die Spielmechanik. Da steht bei mir kein Quellcode drin, aber z.B. welche Eigenschaften eine Region bestitzt, was hinter den Eigenschaften steckt und wie man diese als Spieler beeinflussen kann. Da steht auch drin was man in dem Spiel überhaupt machen kann, also quasi so etwas was man auf der Rückseite ner Spielpackung findet um den Spieler für sein Spiel zu gewinnen.

Aktuell ist mein Designdokument für Projekt "W" ~22 Seiten lang (wobei ich natürlich nicht in der Druckansicht schreibe, sondern im Weblayout wos keine Seitenzahl gibt) allerdings habe ich einige Sachen, wie z.B. die Gebäude- und Technologielisten zwecks Übersicht in externe Dokumente ausgelagert. Schlussendlich dürfte ich circa 30 Seiten an Gamedesignmaterial für Projekt "W" haben, wobei sich dass natürlich bis zum finalen Release noch erhöhen wird.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)