CYPEST Entwicklung Blick zurück
Blick zurück 05.01.2018 - 19:51 4
Folgenden Nutzern gefällt das Design: alistez, TroMu, damios, eitelkalk

Spieleentwicklung ist fast ausschließlich eine evolutionäre Angelegenheit. In kleinen, oft mühsamen Schritten wird das Werk immer besser. Bei den, gefühlt, eine Million Schritten, vergisst man ganz gerne, was man tatsächlich erreicht hat. Nachfolgend möchte ich einen Blick zurück werfen und zeigen, wie das bei CYPEST war. Außerdem möchte ich noch zeigen, was der nächste Schritt sein wird.

Meine Arbeitsweise hängt von der Größe des Projekts ab. Ich unterscheide zwischen kleinen, großen und sehr großen Projekten. Ein kleines Projekt ist ein Spiel, dessen Entwicklungszeit weniger als 12 Monate dauert. Was darüber geht, ist groß, mehr als 3 Jahre ist sehr groß.

Kleine Projekte haben ein konkretes Ziel. Eine Deadline, eine begrenzte Vision davon, was erreicht werden soll. Wenn das erreicht ist, wird vielleicht noch gepatcht, dann ist das Projekt Geschichte. Bei großen Projekten sieht es anders aus, weil sich meistens die Zielsetzung unterscheidet. Das erfordert nicht nur eine bessere Planung, sondern vor allem dem Überwinden des inneren Schweinehundes. Bis zu einem gewissen Maß ist nichts jemals fertig.

CYPEST ist mittlerweile ein großes Projekt. Obwohl man es dem Spiel auf den ersten Blick nicht ansieht, steckt enorm viel Arbeit, Technik und Kreativität darin. Leider merkt man das momentan erst dann richtig, wenn man es Spielt.

Als ich mit der Entwicklung begann, erstellte ich die ersten Grafiken und baute eine spielbare Version im GameMaker. Ich wusste genau, wie das Spiel von seiner Mechanik her funktionieren soll und was die wesentlichen Features sein werden. An diesem Kern hat sich bis heute fast nichts geändert. Alles Andere wurde mittlerweile mehrfach auf den Kopf gestellt. Am deutlichsten wird das am Screenshot:

CYPEST evolution

Links ist der Prototyp zu sehen, rechts die Version 1.0. Wirklich final ist das eigentlich auch noch nicht.

In etwa bei 2/3 der Entwicklung (aus der Sicht von heute) gab es eine Richtungsänderung. Die Lichter waren schon immer geplant, der Neon-Look hingegen kam nach einer ausführlicheren Teambesprechung und hatte weitreichende Folgen. Das Neon ist nicht nur ein anderes Grafikset, es ist ein fester Bestandteil der Engine, zumindest bei den Wänden. Im Editor werden noch die alten Grafiken gesetzt. Wenn das Level gestartet wird, rechnet die Engine das komplette Level neu und generiert die Wände als eine riesige Textur (vereinfacht gesagt). Dabei wird nicht einfach nur die Wandfarbe bestimmt, sondern auch die Kanten und der korrekte Schein nach Außen in allen möglichen Kombinationen. Eines der vielen Vorteile daran ist, dass wir die Farben variieren können, ohne neue Grafiken zu brauchen. Wir können auch Texturen drüber mappen, was wir ab Version 1.2 tun werden:

Diese Änderung hatte weitreichende Folgen, die wir heute noch spüren. Beispielsweise mussten alle Gegnergrafiken geändert werden. Ebenso Virus, Logo und Menüs. Ursprünglich sollte es eine „Pixelgrafik mit Licht und Schatten werden“. Auf der Webseite merkt man, Stand heute, dass der modernisierte Wechsel dort niemals ankam.

Die Änderungen an der Grafik sind nur ein Teil der permanenten Verbesserungen. Es werden nicht nur Grafiken ausgetauscht und, beispielsweise, neue Hintergründe hinzugefügt, sondern auch am Sound hat sich vieles geändert.

Ursprünglich sollten 8Bit / 16Bit Lieder abgespielt werden, wie man es noch im Cracktro des Spiels hört. Zum Neon passt das aber nicht mehr. Deshalb wurden alle Lieder verworfen und neue komponiert. Vorwiegend sind nun Acid / House und Goa Musik zu hören. Dabei stellte ich bei Versuchen fest, dass 140 BPM so ziemlich das optimale Tempo für das Spiel sind. CYPEST hat unterschiedliche Geschwindigkeiten (aufgrund der Speedfelder) und somit musste eine Geschwindigkeit gefunden werden, die einen guten Kompromiss darstellt. 170 BPM D&B wäre perfekt für Ultraspeed, aber bei Slowspeed ist das einfach zu schnell und das Spiel fühlt sich viel zu träge an. 140 sind der perfekte Kompromiss.

Nachdem sich ein Testspieler über die Musik beschwerte, werden immer wieder neue Lieder erstellt und die „nervigsten“ Lieder ausgetauscht. Das Problem bei jedem Spiel ist, dass manche Lieder auf Dauer sehr nerven können. Dies ist auch ein Punkt, der laufend verbessert wird.

Gleiches gilt auch für die Engine. Was mit GMS2 begann, mündete in C++. Der entscheidende Vorteil ist, dass wir nun alles im Griff haben und nicht auf das Wohlwollen einer schlecht gepflegten Entwicklungsumgebung angewiesen sind. Doch auch hier wird laufend optimiert. Immer wieder wird die Geschwindigkeit erhöht und kleine Details verbessert, die in der Summe das Spielerlebnis bereichern.

Der Unterschied zu einem kleinen Projekt ist folgender: Immer wieder schaue ich mir das Spiel an. Auf selbst erstellten Videos, Screenshots oder in dem ich es spiele. Dann suche ich mir die Punkte heraus, die mich am meisten stören und arbeite es dann ab. Über mehrere Versionen hinweg bleibt kaum ein Stein auf dem anderen, aber man merkt rückblickend, wenn man alte Videos und Screenshots anschaut, wie das Spiel wesentlich besser wurde. Abgesehen von den vielen Partikeln, die nun das Spiel zieren, fällt auf alten Videos am ehesten auf, dass die Lichter links und rechts über den Levelrand hingen. Das klingt wie eine Kleinigkeit, aber wenn man es direkt vergleicht, sind das Welten.

Selbst bis 1.2, der bevorstehenden Version, wird sich noch viel tun. Wer weiß, wie die Version in drei Monaten aussieht?


Grund:
05.01.2018 - 20:02
GWRon
In den letzten 60 min online
GWRon
Rang 9

Projekte: 3
Designs: 3
Blogs: 7
Aktivität:
Nicht sehr aktiv
GWRon
In den letzten 60 min online
GWRon
Rang 9

Projekte: 3
Designs: 3
Blogs: 7
Aktivität:
Nicht sehr aktiv

Vielen Dank fuer den Bericht - das ist so eine Sache, die ich echt gerne lese. Man leidet mit, man erkennt Parallelen...

Als Entwickler selbst bekommt man die Aenderungen ja schleichend mit - da fallen die teils krassen Unterschiede "Anbeginn" zu "jetzt" oft nicht mehr auf.

 

@ Musik
TVTower braeuchte auch noch gaengige (freie) Musik ;-)

@ C++ und Unabhaengigkeit
Ihr benutzt ja libSDL (in Teilen) so underem auch den sdlMixer. Koennt ihr darueber mehrere Musikstreams parallel "streamen"? Glaube das war ja irgendwie auf eine Musikquelle limitiert. Sprich "Crossfading" waere da nur drin, wenn man selbst den Datenstrom (bspweise eines OGG-Streams) modifiziert.

Fuer "BlitzMax NG" und die SDL-Anbindung fiel sdlMixer deswegen raus. Fuer Linux, Windows und Mac bestehen ja gute Alternativen, aber Raspi und Co sind da oft aussen vor.

 

Weiter so mit den interessanten Einblicken und Artikeln. Das stellt fuer pewn.de sicher gerade einen richtigen Mehrwert dar.

 

bye
Ron


05.01.2018 - 20:09
Ersteller
ParaDigma
In den letzten 60 min online
ParaDigma
Rang 4

Projekte: 1
Designs: 0
Blogs: 4
Aktivität:
Sehr aktiv
Ersteller
ParaDigma
In den letzten 60 min online
ParaDigma
Rang 4

Projekte: 1
Designs: 0
Blogs: 4
Aktivität:
Sehr aktiv

Es geht immer nur ein Stream. Bei CYPEST macht das aber nichts aus.

In den kommenden Wochen sollte es auch immer wieder einen Blogbeitrag geben. Das nächste Thema steht schon fest, ab dann muss ich mal weiter sehen. Eventuell ergeben sich Themen auch durch Nachfragen. 


06.01.2018 - 03:40
Ersteller
ParaDigma
In den letzten 60 min online
ParaDigma
Rang 4

Projekte: 1
Designs: 0
Blogs: 4
Aktivität:
Sehr aktiv
Ersteller
ParaDigma
In den letzten 60 min online
ParaDigma
Rang 4

Projekte: 1
Designs: 0
Blogs: 4
Aktivität:
Sehr aktiv

Ach ja, noch eine kleine Anekdote: häufige Frage, wenn wir eine neue Version releasen wollen und es an die Changelog geht ist: "Was haben wir eigentlich alles geändert?" 

Wer kennt das noch?


06.01.2018 - 10:39
GWRon
In den letzten 60 min online
GWRon
Rang 9

Projekte: 3
Designs: 3
Blogs: 7
Aktivität:
Nicht sehr aktiv
GWRon
In den letzten 60 min online
GWRon
Rang 9

Projekte: 3
Designs: 3
Blogs: 7
Aktivität:
Nicht sehr aktiv

Weiss nicht, ich schau was meine Git-Commits sagen und "freu" mich dann darauf, alles zusammenzufassen (fuer die Spieler unwichtiges rausstreichen, Fixes der Fixes entfernen usw.) - und am Ende alles nochmal auf Deutsch niederzuschreiben.

Selbst meine Abschlussarbeit wurden mit Git versioniert ;-)

 

bye
Ron