spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Nein, macht keinen Sinn. In einem Projekt sind alle Schritte zumeist parallel, solche klaren Ablauffolgen sind nur nützlich, damit der strukturierende Mensch sich dabei wohlfühlt. Ich freue mich aber, dass Du einen realistischen Blick auf Dein Projekt hast. Spieleentwicklung ist ein schönes Hobby.

Meine Empfehlung: stelle Use Cases auf, also kurze Texte, was in einer Spielsituation passieren soll. Beschreibe dabei wirklich jeden Klick und jeden Tastendruck des Nutzers und was daraufhin passieren soll. Dann nimmst Du die Engine und stellst darin den Use Case nach und machst eine Liste, was noch notwendig ist, damit dieser Use Case auch wirklich genauso wie beschrieben ausgeführt kann. Grafiken kommen da am Anfang noch gar nicht vor, eine Ebene mit Zylindern als Akteure reicht völlig. Damit kann man schon ein vollständiges Kampfsystem implementieren, Interaktionen mit der Umgebung, oder auch eine ganze Charakterentwicklung. Modelle, Animationen, Texturen, Sounds, Musik... sind hier nur relevant, wenn sie für den beschriebenen Spielablauf tatsächlich einen Unterschied machen. Und die Erkenntnis aus vielen Projekten ist: in 99,99% der Fälle machen machen sie keinen Unterschied.

Ein Konzept ist für Dich persönlich eine gute Sache, weil Du damit Deine Projektvision und den Gesamtüberblick behältst. Du kannst daraus Use Cases ableiten genauso wie Listen an Modellen, Texturen, Animationen, Sounds. Den Rest der Welt interessiert ein Konzept eher weniger. Und halte jegliche Namen und Werte aus dem Konzept raus, beschränke Dich auf den spielrelevanten Teil.

Und in jedem Fall: fange KLEIN an. Entwerfe nicht vier Rassen pro Fraktion, solange Du nicht eine Rasse im Spiel hast. Erfinde keine fünf Varianten des Feuerballs, solange Du noch gar keinen Zauber implementiert hast. Definiere keine epischen Rüstungssets, solange Du nicht weißt, was sich daraus alles ableitet. Das Problem an einem MMO ist ja gerade, dass der Aufwand extrem schnell ins Unermessliche steigt. Fange also keine Listen an, bevor Du nicht in einem Einzelfall durchgespielt hast, was für Anforderungen sich aus jedem einzelnen Eintrag der Liste ergeben.

Und damit sind wir wieder bei Use Cases. Wenn die Grund-Spielmechanik mal läuft, kannst Du anfangen, einzelne Use Cases mal komplett mit Grafiken, Animationen und Sounds auszustatten. Und dann erkennst Du schnell, was alles nötig wäre, wenn es statt einer Rasse 8 gäbe, statt einem Gegner 200, statt einem Zauber 50 oder das Ganze statt in einer Höhle in einer Eishöhle, Lavahöhle oder Äther-Höhle stattfände.

Wenn Du dann eine konkrete Anforderung vorliegen hast, z.B. einen Gegner oder eine Rüstung für Charaktäre, dann ist der übliche Ablauf:
- Konzeptzeichnung, in Abstimmung mit Wer-Auch-Immer-Die-Designleitung-Hat
- Modellierung
- Texturierung
- Rigging
- Animationen

(wobei Du bei einem MMO nach Möglichkeit so viele Animationen wie möglich auf so viele Charaktäre wie möglich anwenden solltest. Man kann dort mit systematischer Mesh-Generierung wahrscheinlich auch ne Menge rausholen, um sich zu ersparen für jeden möglichen Körperbau Rüstungsteile neu modellieren zu müssen)

Use Case Es geht um Anwendungsfälle, also "wer soll was wie machen können". Der User ist zwar meist der, für den das ganze umgesetzt wird, aber es geht primär nicht um ihn, sondern um die Aktivität/Aktion an sich und den Nutzen, den der Anwender daraus zieht. Bei vielen Projekten versucht man intern notwendige Dinge komplett aus der Entwicklungsplanung raus zu halten (zumindest machen wir das bei agiler Entwicklung so. Beim Wasserfall ist das wieder ein anderes Thema). Das ist zwar nicht immer einfach, aber meist geht es. Man versucht also alles, was entwickelt werden soll, in einen "Kundennutzen" zu verpacken. Das heißt das Feature, was gebaut wird, hat irgendeinen Einfluss darauf, welche neue Möglichkeiten ein Designer, Modellierer oder Spieler mit dem laufenden Programm dann mehr hat als ohne dies. Der Kunde zieht also direkt einen Nutzen aus dem Feature oder der umgesetzten "Story". Auf diese Weise arbeitet man stets an etwas, was das Projekt auch nach außen hin voran bringt und was letztlich auch jedem Entwickler auf Dauer mehr Spaß macht als nur intern an etwas zu fummeln, was nach außen nie jemand sieht.

Man sollte übrigens darauf achten, diese klein zu halten. Also lieber ein "Der Spieler soll mit Taste XYZ einen Zauber auswählen können" und "Bei Klick auf die Maus soll der Zauber anfangen zu casten" statt "Mit XYZ wählt man den Zauber, aktiviert ihn mit der Maus, trifft oder verfehlt das Ziel, bewirkt Schaden/Buff/Debuff, zieht Leben ab, tötet das Monster". Schritt für Schritt. Auswählen, Casten, Effekt ausführen, das sind alles verschiedene kleine Teile eines großen Puzzles. Genau wie verschiedene Effekt-Typen auch verschiedene Teile sind. Fang mit einem an. Dann wende Dich einem anderen zu. Wahlweise geht das mit mehreren Entwicklern natürlich auch parallel.

Weitsicht ist übrigens zwar hilfreich, aber nicht immer das höchste Gut. Baue nichts übermäßig komplexes, weil Du meinst, dass Du es später eh mal brauchst. Baue etwas auf den Bedarf zugeschnitten. Erweitere es, wenn es soweit ist. Schrecke nicht vor notwendigen Refactorings zurück. Zu viel Weitsicht endet oft darin, dass etwas overengineered und am Ende nie benutzt wird oder doch nicht das tut, was man damit eigentlich mal vor hatte. Dinge ändern sich. Planung bis in's letzte Detail haut selten hin. Sei wandlungsfähig.