Gamedevelopment als Hobby

Die Entwicklung von „GreyHole“ Devblog Teil 1

Tapio entwickelt sein eigenes Game. Und Du kannst es Schritt für Schritt nachvollziehen. Schau Dir an, wie und mit welchen Werkzeugen ein Computerspiel entsteht.

Hallo werte IT-Talente Community,

ich habe quasi schon mein ganzes Leben unterbewusst davon geträumt, mein eigenes Computerspiel zu entwickeln. Seit nun ca. einem Jahr träume ich diesen Traum bewusst, sechs Monate davon ziehe ich ihn Stück für Stück in die Realität – und das neben der Arbeit in meiner Freizeit. In diesem Gästeblog möchte ich euch von dieser Reise berichten und euch einladen, mich ein Stück dabei zu begleiten. Der erste Beitrag hier soll alles zusammenfassen, was bisher geschehen ist, und einen kleinen Überblick über das entstehende Spiel geben sowie meine Motivation zu dem ganzen Projekt erläutern. Zukünftige Blogbeiträge werden dann den Fortschritt dokumentieren und meine Gedanken und Entscheidungsprozesse darlegen

Programme und Werkzeuge für das Game Development

Folgende Programme benutze ich hauptsächlich:

Online Tools:

trello.com – frei gestaltbare ToDo-Listen
bitbucket.org – Versionskontrolle auf git-Basis
wordpress.org – Blog-Software für meinen englischsprachigen Blog auf https://www.wuzzle.de

Vorgeschichte

Wer – so wie ich – für das Spiel „Game Dev Tycoon“ viel Begeisterung aufbringen konnte, wird sicherlich den Impuls, ein eigenes Spiel entwickeln zu wollen, nachvollziehen können. Als ich mich 2013 durch den Spieleentwickler-Simulator geklickt habe, hätte ich allerdings noch nicht geahnt, dass ich mich tatsächlich einmal an die Entwicklung eines Spiels wagen würde. So richtig hat das dann aber Anfang 2017 angefangen. Zu der Zeit gab es in einem der Humble Bundles die Spiele-Engine „Click Team Fusion“ (CTF) und ich entschloss mich, für wenige € einmal in die Entwicklung eines einfachen Spiels hereinzuschnuppern. CTF kommt mehr oder weniger ohne Programmierung aus und Wenn-Dann- und andere Beziehungen werden hauptsächlich über ein visuelles Verknüpfungssystem zusammengeklickt. Ich bekam relativ schnell erste Prototypen zusammengestellt und das bereitete mir auch ziemlich viel Spaß, allerdings stieß ich mit dem Projekt schnell an eine Grenze des für mich Umsetzbaren. Obwohl ich kein Programmierer bin, empfand ich diese visuelle Art der Programmierung als sehr umständlich, ineffizient und mit wachsender Spielkomplexität auch verwirrend. Das ging dann bis zu dem Punkt gut, an dem ich gemerkt habe, dass ich mich bei jedem Programmstart erst wieder einlesen muss. Mit dieser Erkenntnis war der erste Ausflug in die Spieleentwicklung dann für mich beendet. Und meine Ambitionen waren erst einmal auf Eis gelegt.

Ungefähr ein Jahr später stieß ich über eine YouTube Linkempfehlung per Zufall auf ein kleines Tutorial zu der Spiele-Engine Gamemaker Studio 2 (GMS2).

Verfasser des Videos ist Seth Coster von Butterscotch Shenanigans, das Studio, das das Spiel „Crash Lands“ entwickelt hat. Ich unternahm erste Schritte in der Trial-Version von der Engine anhand der kleinen Tutorialserie. Da die Desktoplizenz von GMS2 zu der Zeit ebenfalls im Angebot war, entschied ich mich nach wenigen Tagen Bedenkzeit dazu, die Vollversion zu kaufen und etwas tiefer einzusteigen. Während ich das Tutorial abarbeitete, nahm ich immer wieder einzelne Veränderungen an dem Spiel vor und merkte schnell, dass mir diese Art der Spieleentwicklung um Längen mehr liegt, als das visuelle Vorgehen bei CTF. Durch das Herumprobieren anhand des Tutorials, das eigentlich eine X-te Neuauflage von Asteroids darstellt, bin ich über eine Spielmechanik gestolpert, die später das definierende Gameplay-Element meines Spiels ausmachen sollte: Rotierende Kugeln. Nach einigen Tests stellte sich für mich heraus, dass ich komplett auf das übliche Schießen verzichten kann und dass das Steuern der rotierenden Kugeln durchaus viel Spaß bereitet.
Ohne großartiges Entwicklungsziel und mit dem Projektnamen „Butterscotch Tutorial“ entwickelte ich relativ unkoordiniert in den Abendstunden. Ich hatte mir nur ein kleines Ziel bewusst gesetzt: Eine Person in meinem Umfeld sollte Gefallen an dem Spiel finden. Dieses Ziel hatte ich dann überraschenderweise relativ schnell erreicht, da ein Freund, dem ich meinen aktuellen Stand zeigte, mehr als eine Stunde vor dem Laptop verbrachte und immer wieder von vorne begann. Das war ein riesen Erfolg für mich und ich fühlte mich wie ein echter Spieleentwickler – das war ich natürlich nicht, mein Spiel hatte quasi keine Grafiken, keinen Sound und außer der Spielmechanik der rotierenden Kugeln und einer rudimentären Punktezählung nichts zu bieten.
Dennoch geriet mein Projekt wieder ein wenig ins Hintertreffen, da ich in der Zwischenzeit stolzer Vater geworden war und dies einige Monate so ziemlich alle Freizeit in Anspruch nahm.
Da sich die Spieleentwicklung aber besser als einige andere Hobbies eignet, um sie im Umfeld der Familie ausleben zu können, überlegte ich mir, das Projekt als komplette Lernerfahrung aufleben zu lassen. Allerdings musste ich mir eine engere Struktur schaffen und eine klarere Zielsetzung in den ganzen Ablauf bringen.

Den Scope richtig setzen

Die wichtigste Variable für die Realisierbarkeit ist der sogenannte „Scope“. Was soll das Spiel umfassen? Was soll es können? Was sind die Mindestanforderungen für ein fertiges Produkt? Und vor Allem: was soll das Spiel nicht sein? In den meisten Spieleentwicklungsprojekten läuft der Scope schnell aus dem Ruder und wird immens groß. Viele Jungentwickler machen den Fehler und wollen direkt als erstes Spiel ein MMORPG mit allen bekannten und gewohnten Features bauen. Am besten dann noch Innovation einbringen und generell alles besser machen als alles bisher da gewesene – zumindest ist das das, was man oft in Foren und Entwicklerberichten liest. Dass das dann einen frischen Entwickler überfordert und es nie zur Fertigstellung kommt, steht außer Frage. Diesen Fehler wollte ich nicht begehen und habe mir deswegen einige Gedanken zu dem Entwicklungsablauf und dem Scope gemacht.
Fest stand, dass ich mich hauptsächlich auf die Spielmechanik der rotierenden Kugeln konzentrieren wollte. Dieses eine Gameplay-Element soll so gut aufpoliert sein, dass der Spieler die üblichen Shooter-Mechaniken nicht vermisst. Mit diesem Kernpunkt habe ich überlegt, welche Elemente ein ausgereiftes Spiel, das meinen Qualitätsansprüchen genügt, noch aufweisen müsste. Ganz klar muss es eine Vielfalt an Gegnern geben, von denen viele zeitgleich attackieren und dem Spieler einiges abverlangen. Dabei verzichte ich bewusst auf traditionelle Spielwelten mit Grenzen und Barrieren. Alles findet in einem offenen Raum statt und Gegner sollen in Wellen erscheinen. Durch den Verzicht von harten Spielweltbegrenzungen lege ich den Fokus ganz stark auf die Interaktion mit den Gegnern und muss auch wesentlich weniger präzise Kollisionsabfragen und Bewegungseinschränkungen implementieren. Das spart Entwicklungszeit und lenkt den Spieler nicht von dem Kern des Spiels ab: Horden von Gegnern besiegen. Natürlich dürfen Endgegner auch nicht fehlen und es soll eine zunächst lokale Highscoreliste geben. Als Mindestanforderung an ein modernes Spiel stelle ich generell ein Hauptmenü, das es ermöglicht, Grundeinstellungen zu Grafik und Tastenbelegungen anzupassen. Freispielbare Gegenstände, Skins oder ähnliche Dinge können immer noch nach Fertigstellung des Kernspiels hinzugefügt werden und sind nicht essenziell für die Umsetzung.

Entwicklungsschritte

Das Spiel hat sich nun im Laufe der Zeit schon ordentlich entwickelt. Anfänglich arbeitete ich viel mit Platzhaltern und konzentrierte mich auf die Funktion.

Dann fing ich langsam an, mich mit Inkscape vertraut zu machen, und erstellte erste Vektorgrafiken, die dann schon ein wenig ansprechender aussahen.

Zusammen mit einigen Partikel- und ein paar Soundeffekten, die ich in einem Humble Bundle günstig erwerben konnte, war es mir möglich, das Gameplay schon ein wenig aufzupolieren.

Aktueller Stand

Bisher haben sich seit der Konzeptionierung schon einige Unterpunkte meiner ToDo-Liste realisieren lassen. Das für mich wichtigste, die grundlegende Spielmechanik, ist implementiert und funktioniert nach einigen Iterationen auch so, wie ich mir das vorgestellt habe.

Aktuelles Gameplay Video:

Die Bewegungen des Hauptcharakters werden wahlweise über die WASD-/Pfeiltasten oder aber über ein Gamepad, wie dem Steam- oder den allseits beliebten Xbox-Controller eingegeben. Sonder-Attacken können aktivgeschaltet werden und auch die Drehrichtung der rotierenden Kugeln lässt sich anpassen.
Die Gegner lassen Gegenstände fallen, die aufgesammelt werden können. Diese bewirken beispielsweise das Hochzählen des Highscores, die Wiederherstellung von Lebensenergie, Schadenserweiterungen oder lösen temporäre Gravitationsschübe aus.

Diverse Partikeleffekte und code-basierte Animationen untermalen die Spielerfahrung.
Ein einfaches Menü ermöglicht schon viele meiner Anforderungen.

Eingabetasten für die Tastatursteuerung können geändert werden, außerdem ist es dem Spieler möglich, seinen individuellen Namen einzugeben oder auch Grafik- und Audiooptionen anzupassen.

Die nächsten Schritte

Das Grundgerüst ist nun fertig. Jetzt gilt es, das Spiel mit Leben zu erfüllen. Der nächste Schritt für mich sind nun ausgefeiltere Grafiken, deren Entwicklung ich mit Hilfe von Krita in Kombination mit einem Grafiktablet in Angriff nehme. In diesem Zuge entwickle ich auch weitere Gegnertypen, die auf den Spieler losgelassen werden. Der Grundgedanke ist, dass die kleinen Basisgegner eine Art Larve oder Made darstellen, die sich in unterschiedliche Gegnertypen weiterentwickeln können.

Jetzt, da ich auch zeichnerisch aktiv werden kann und nicht nur auf einfache Vektorgrafikformen begrenzt bin, versuche ich, den Gegnern einen etwas groteskeren Look zu geben. Sie haben zwar immer noch etwas „Niedliches“ an sich, wirken aber schon etwas verstörender. Das soll es den Spielern einfacher machen, gegen sie zu kämpfen.

Ein weiterer Punkt, den es anzugehen gilt, ist die Implementierung verschiedener Schadensmodi für die rotierenden Kugeln und ein geeignetes Ingame-Menü zur Verwaltung dieser, sowie eine Upgrade-Möglichkeit.

Das Grundkonzept ist eine Aufteilung auf fünf unterschiedliche Typen mit jeweils einem Sekundäreffekt und ein dazu passender Power-Up-Effekt. Hierzu wird es noch wichtig sein, ein passendes Gamedesign zu entwickeln. Wird man die Schadenstypen direkt im Spiel auswählen können? Muss ein „Load-Out“ vor Spielstart geschehen, kann man einzelne Schadenstypen erst freispielen? Soll man sie leveln können? Was wären levelbare Eigenschaften (vom Schaden abgesehen)? Diese und viele weitere Fragen müssen geklärt werden, sodass am Ende ein Konzept dabei herauskommt, das den entsprechenden Kriterien gerecht wird. Die Auswahl der Kriterien sollte dabei als erstes erfolgen.

Ein weiterer Eckpfeiler für ein Spiel ist die Musik, der Soundtrack. Für diesen Aspekt stehen meine Bemühungen und Gedanken noch ganz am Anfang. Ich werde mich zunächst an der eigenen Musikproduktion versuchen. Je nach Aufwand und Gelingen dieser Bemühungen werde ich eventuell dazu gezwungen sein, einen externen Musikproduzenten für das Projekt zu engagieren. Für dieses Hobbyprojekt ist die Musik der unsicherste Faktor und beinhaltet das Risiko, eine nicht unerhebliche Menge an Geld auszugeben. Einerseits ist meine Idealvorstellung, dass ich anhand eines Soundtracks den Spieleinhalt erstelle, um ein rundum stimmiges Gefühl erzeugen zu können, andererseits ist es für einen externen Musiker/Musikproduzenten sicher einfacher, die passende Musik zu einem möglichst fertigen Spiel zu erstellen und würde dementsprechend weniger Aufwand und dadurch geringere finanzielle Ausgaben bedeuten.