Boehrsi.de - Blog

Heute geht es mit dem Update #11 zu meiner Spieleentwicklung weiter. Nachdem in den letzten Beiträgen die Gegner und die Tower das Thema waren, wollte ich dieses Mal auf die Maps eingehen. Diesen Beitrag verschiebe ich aber etwas nach hinten, da ich in meinen freien Tagen den Fokus eher auf die Implementierung der Upgrades gesetzt habe. Mit selbigen bin ich in den letzten Wochen sehr gut voran gekommen und die Fortschritte in diesem Bereich wollte ich gerne mit euch teilen.
Da das Spiel als Ansatz eine Kombination aus Tower Defense und Action Roguelike ist, sind Upgrades essentiell. Konkret versuche ich die guten alten Warcraft 3 TD Zeiten mit Spielen wie Brotato zu kreuzen. In diesem Kontext machen die Upgrades die man am Ende der Runde oder via Meta Progression erhält natürlich einen markanten Teil des Spiels aus und bieten die Basis für Wiederspielbarkeit und unterschiedliche Spielstile.

Heute geht es um die Gegner innerhalb des Spiels. Während ich alle Tower und die Station komplett von Hand erstellt habe, kommt für die Gegner ein Blender Plugin zum Einsatz. Dadurch kann ich dynamisch und ohne großen Aufwand Gegner und Variationen von selbigen erstellen. Gleichzeitig erhalte ich einen einheitlichen Stil, was mir durchaus wichtig ist. Denn ich möchte das sowohl die eigenen Einheiten, wie auch die feindlichen, immer klar erkennbar sind, vor allem wenn viel auf dem Bildschirm los ist.
Da sich das Spiel bekanntlich noch in der Entwicklung befindet kann sich im Bereich der Gegner durchaus noch einiges verändern, vor allem da ich mit wenig Aufwand durchaus umfangreiche Änderungen mit Hilfe des genutzten Blender Plugins erreichen kann. Falls ihr übrigens auch mit dem Plugin arbeiten wollt, hier könnt ihr das Spaceship Generator | Procedural Geometry Nodes Plugin open_in_new kaufen.

Da Bilder ja bekanntlich mehr als tausend Worte sagen und ich mich bis dato sehr zurückgehalten habe mit eigentlichen Spielinhalten, will ich nun etwas mehr in diesem Kontext mit euch teilen. Heute geht es vor allem um das Design der Tower. Die Assets sind dabei alle von mir erstellt. Teils komplett von Hand und zum Teil mit Hilfe von extrem praktischen Blender Addons, letzteres gilt vor allem für die Gegner, welche in einem weiteren Beitrag Thema sein werden.
Generell habe ich versucht die eigenen Einheiten und die Gegner unterschiedlich zu gestalten, gleichzeitig aber für einen einheitlichen Look zu sorgen. Doch nun ohne weitere Umschweife direkt zum Content.

Lange gab es nicht neues, doch nun geht es endlich weiter. Project Space geht gut voran, für ein Projekt welches ich nebenher an Wochenenden und in meiner weiteren Freizeit entwickle. Konkret bedeutet dies, dass ich nun langsam die diversen Schritte unternehme um eine Steam Page einzurichten. Darüber möchte ich zum einen Sichtbarkeit schaffen und zum anderen eine Plattformen erschließen, auf welcher ich in Zukunft viele kleine einzelne Development Updates veröffentlichen kann. Denn wie man meinen vorherigen Updates zur Entwicklung hier im Blog entnehmen kann, klappt es hier einfach nicht wie gewünscht und ich erreiche nicht die gesamte Leserschaft, die ich gerne hätte. Damit meine ich vor allem den englischsprachigen Raum der Gaming Community, welcher wesentlich größer ist als mein aktuelles Einzugsgebiet.
Das mit wichtigste an Steam ist aber auch die Möglichkeit endlich mit Playtests zu starten. Denn ein Playtest involviert immer einen Distributionskanal, welchen ich entweder eigenständig irgendwo schaffen muss oder ich nutze einfach die Plattform die ich ohnehin für die finale Veröffentlichung anpeile. Doch damit nun genug der Einleitung und weiter mit dem aktuellen Status.

Devlog Nummer 7 steht an und ich merke gerade das ernsthaft schon wieder ein halbes Jahr vergangen ist, seit meinem letzten Beitrag zu diesem Thema. In diesem Kontext muss ich sagen, dass das aktuelle Format so nicht funktioniert. Denn auch wenn ich extrem viel zu tun habe und mitunter auch mehrere Wochen nicht aktiv am Spiel arbeiten konnte, so gab es diverse Fortschritte, welche in Form eines Beitrags hätten erscheinen können.
Doch wie wir sehen ist dies nicht der Fall, denn die Art und Weise wie ich dieses Format erstelle ist denkbar unpraktisch. Ich sammele diverse Inhalte, fasse selbige dann später zusammen und bastele daraus einen größeren Artikel. Doch ab wann habe ich genug Informationen für einen derartigen Artikel, wann finde ich die Zeit selbigen zu schreiben und wie schaffe ich es aufgrund des längeren Zeitraums nichts zu vergessen? Viele Fragen auf die es keine zufriedenstellenden Antworten gibt. Aus diesem Grund werde ich ein weiteres Mal eine mitunter große Änderung am Format vornehmen, doch zuvor erst einmal ein aktuelles Status Update zu Project Space.

Es ist schon fast ein bisschen traurig wie lange das letzte Update zu Project Space her ist. Doch leider wissen wir ja alle wie es ist, denn Zeit ist ein sehr begrenztes Gut und vor allem im letzten Quartal 2023 war ich mit meinem Umzug und diversen weiteren Dingen komplett ausgelastet. Auch wenn der Großteil in diesem Bereich abgeschlossen ist, so gibt es weiterhin diverse Aufgaben zu erledigen, sodass ich definitiv generell etwas weniger Zeit haben werde.
Es bleibt allerdings dabei, Project Space hat von meinen Softwareprojekten die höchste Priorität und wird entsprechend weiterentwickelt. Abseits davon habe ich noch einige Inhalte die ich noch nicht in Form von Beiträgen verarbeitet habe, ihr könnt euch also auf weiteren Content freuen. Denn zuletzt habe ich gute Fortschritte bei diversen Kernsystemen, dem Content und verschiedenen kleinere Teilbereichen gemacht.

Mit meinem fünften Game Devlog zu Project Space wird es nun wie angekündigt etwas konkreter. Denn während ich in den ersten vier Beiträgen die Idee, generelle Ansätze, das Tooling und Konzepte beschrieben habe, so möchte ich nun näher an den eigentlichen Content herankommen, sowohl vom Inhalt her, wie auch zeitlich. Früher oder später wäre ich gerne auf dem aktuellen Stand mit meiner Entwicklung, sodass ich nicht aus der Vergangenheit referiere, sondern direkt aktuelle Ereignisse mit euch teilen kann. Dadurch hoffe ich das weniger verloren geht.
Das Thema heute ist der Einstieg ins eigentliche Projekt, also auf technischer Ebene in Godot open_in_new. Hier ist der Anfang natürlich gewohnt schwer, denn auf einem quasi leeren Blatt Papier anzufangen ist immer eine Herausforderungen. Ich startete mit einigen Recherchen bezüglich Best Practices im Kontext von Godot, denn ich lege viel Wert auf Code Quality und Strukturen. Mit besagter Code Quality sollte man übrigens vorsichtig sein, denn man steht sich hier gerne selber im Weg, aber dazu später mehr.

Wie angekündigt ist heute das Thema Engine dran, denn wie bereits erwähnt habe ich in der zweiten Jahreshälfte 2022 von der Flame Engine open_in_new auf Godot open_in_new gewechselt. Dies ist auch zum Zeitpunkt dieses Artikels noch der Fall und derzeit gibt es keine Pläne dies zu ändern. Die Gründe habe ich hier zwar bereits kurz thematisiert, möchte sie aber auch in diesem Beitrag noch einmal zusammenfassen.
Ich bin ein erfahrener Entwickler im Bereich Apps und Server, doch Spiele habe ich, abseits von Game Jams, noch keine entwickelt. Entsprechend nehme ich dankbar jede Hilfe die ich bekommen kann. Bei der Flame Engine fehlten mir visuelle Tools, da die Entwicklung ganz normal in Android Studio stattfand und entsprechend stieß ich mit der Zeit an meine Grenzen. Etwas Recherche später schloss ich Unity open_in_new und die Unreal Engine open_in_new aus, da ich ein reines 2D Spiel entwickle und die beiden genannten doch eher in der 3D Welt unterwegs sind. Beim Vergleich der 2D Engines stach Godot heraus und als ich mich tiefgehender mit GDScript open_in_new, der in Godot genutzten Programmiersprache, auseinandersetzte und den Editor näher betrachtete, fühlte ich mich immer mehr zu Hause. Dieses Gefühl hat sich bis dato nicht geändert, auch wenn natürlich nicht immer alles perfekt ist, so bin ich sehr froh auf Godot gesetzt zu haben.

Der dritte Game Devlog steht an. Heute soll es nach zwei eher allgemeinen Beiträgen etwas konkreter werden. Denn genau dies ist auch in der zweiten Jahreshälfte 2022 geschehen. Während zuvor viel Planung, Recherche und Trial and Error auf der Tagesordnung stand, gab es in diesem Zeitraum diverse grundlegende Entscheidungen, welche bis dato gelten.
Das generell Konzept, wie im ersten Devlog beschrieben bleibt bestehen. Es gab und gibt weiterhin verschiedene Ideen zur Verfeinerung, doch derartige Dinge können erst entschieden werden wenn ein grundlegender Entwicklungsfortschritt gegeben ist.
Beim Tooling, was das Thema im zweiten Devlog war, gab es allerdings diverse massive Änderungen. Blender ersetzt GIMP und das bis dato durchaus erfolgreich. Blender open_in_new ist damit mein Haupttool zur Erstellung jeglicher Assets. Dies gilt für alle Tower, Feinde und weitere Objekte. Der Grund für den Wechsel sind meine fehlenden Fähigkeiten im Bereich Design und Zeichnen. Etwas bauen oder modellieren kann ich allerdings und entsprechend passt Blender wesentlich besser zu meinem aktuellen Skill-Set. Zusätzlich kann ich auf diesem Wege verschiedene Assets auf einmal erstellen.

Heute geht es weiter mit meinem zweiten Game Devlog. Dieses Mal geht es um meine ersten Versuche Dinge umzusetzen und auszuprobieren. Dabei liegt der Fokus vor allem auf meinem initial genutzen Tooling. In der ersten Jahreshälfte 2022 erstellte ich Mockups und versuchte meine vage Idee zu konkretisieren. Dabei arbeitete ich viel analog, einfach auf Papier. Grund dafür war vor allem die Flexibilität ohne Tooling schnell Kleinigkeiten zu visualisieren. Später wechselte ich auf mein gutes altes Rocket Book open_in_new, denn hier habe ich die Freiheit analog zeichnen und schreiben zu können, kann aber gleichzeitig alles schnell und einfach digitalisieren.