Nach einer längeren Jam-Abwesenheit nahm ich an der 11. ZFX-Action teil - damit erhöhten sich meine Jam-Teilnahmen auf insgesamt dreimal!

Themenwahl und Ideenfindung

Anders als bei meinen bisherigen ZFX-Actions, wurde diesmal kein zufällig generiertes Thema gewählt, sondern zwei, völlig frei interpretierbare Themen vorgegeben: "Strategie" und "Gravitation".

Die ersten Ideen kamen zwar rasch, waren aber allesamt zu komplex, um sie innerhalb der kurzen Zeit umzusetzen. Mein GameDev-Kollege und guter Freund Malthus hatte allerdings eine Idee parat: Einen Würfel durch Anziehung und Abstoßung von A nach B bewegen.
Tatsächlich klang es nach einer guten Idee, die rasch umsetzbar schien.

Namensfindung leicht gemacht

Der Arbeitstitel "Power Push Pull" entstand unspektakulär und ohne viel nachzudenken: Als Unity bei Projektanlage einen Namen erwartete, schrieb ich aus dem Bauch heraus "PowerPushPull". Somit ist wohl mein persönlicher Arbeitstitelfindungsrekord für alle Zeit gebrochen 

Prototyping

Prototyp #1 (Grundmechanik)

Der erste Prototyp entstand innerhalb weniger Stunden und gestaltete sich mithilfe der Unity-Engine nahezu unkompliziert. Im ersten Schritt galt es, die Strahlen zur Anziehung und Abstoßung umzusetzen und die Kernmechanik zu testen. Zu diesem Zeitpunkt war noch nicht ganz klar, in welche Richtung (Perspektive, Leveldesign, ...) das Projekt sich entwickeln sollte. 

Prototyp #2

Etwas Leveldesign von Malthus und das freie Setzen mitsamt Rotieren der Strahlenblöcke war in der zweiten Iteration des Prototypen möglich.
(Bild anklicken für animiertes GIF)

Prototyp #3

Dasselbe Leveldesign allerdings mit vordefinierten Stellen zum Setzen der Blöcke. Ebenfalls sieht man im animierten GIF den kurzzeitigen Einfall, dass der Spielerwürfel sich ebenfalls drehen kann. Diese Version kam näher ans Endergebnis heran, war aber keinesfalls optimiert.
(Bild anklicken für animiertes GIF)

Endergebnis

Die finale Version wurde optisch wie auch spieltechnisch stark optimiert.
(Bild anklicken für animiertes GIF)

 

Technische Basis

Ursprünglich entwickelte ich 2D-Spiele und setzte bei den bisherigen Jams auf das HaxeFlixel-Framework. Diesmal sollte es ein waschechtes 3D-Projekt werden, und da ich mich bereits längere Zeit mit Unity befasste, fiel meine Wahl auf diese Engine. Ich entwickelte bis dahin zwar schon kleine Unity-Projekte, doch schaffte es kein einziges an die Öffentlichkeit. Tatsächlich sollte "Power Push Pull" mein erstes, öffentliches Unity-Projekt werden.

Ich war mit der Wahl durchweg zufrieden, da ich mich (fast) ausschließlich auf das Gameplay konzentrieren konnte. Die Spiellogik wurde mit meiner Berufssprache C# entwickelt, wodurch die Einarbeitungszeit darin völlig weg fiel.

Hier und da stieß ich zwar auf einige Unklarheiten mit dem UI-System sowie einigen Eigenheiten der Engine, allerdings konnten diese mittels Google-Suchen rasch ausgemerzt werden. Ein wichtiger Faktor war wohl auch die Tatsache, dass ich in vielen Teilen bereits mit der Engine vertraut war.

Der Release-Prozess gestaltete sich als völlig unkompliziert. Mit nur wenigen Klicks standen Versionen für Windows, Linux und Mac parat, wovon ich allerdings nur erstgenannte ausführlich testen konnte. Und ich muss gestehen: Es war ein tolles Gefühl, einmal die Build-Funktion auszuprobieren! 

Assets

Mein Anspruch bei 2D-Spielen war immer, so viel wie möglich selbst zu machen. Bei einem 3D-Projekt sind die Rahmenbedingungen allerdings völlig andere. 

Etwas fürs Auge ...

Grafisch verließ ich mich auf die Unity-internen 3D-Modelle, die sich in meinem Fall auf Cubes und Planes beschränkten.
"Bei einem 3D-Spiel sollte es zumindest Texturen geben...", war einer meiner zahlreichen Gedanken. Doch schlussendlich blieb dafür keine Zeit mehr, und die verzweifelten Google-Suchen nach passenden Texturen waren mit mäßigem Erfolg gekrönt. Ich ließ die Modelle also einfärbig in der virtuellen Welt stehen, damit sie zumindest anders als nur trist weiß aussahen. Erst war ich von dem Grafikstil nicht angetan - doch nach mehreren Spielsitzungen, gefiel er mir doch immer mehr.

... und für die Ohren

Nachdem meine musikalischen Fertigkeiten weiterhin nicht vorhanden sind, suchte ich mir auf OpenGameArt einige Musikstücke heraus. Schlussendlich entschied ich mich für einen einzelnen Sidescrolling / Plattformer-Soundtrack, der sich wunderbar in das Spielkonzept einfügte, ohne aufdringlich zu wirken (meiner Ansicht nach). Als einziger Soundeffekt ertönt ein kleiner Explosionssound, sobald der Spielerwürfel mit etwas anderem als dem Zielfeld kollidierte - auch diesen fand ich zügig auf OpenGameArt.

Die letzten Stunden

... gestalteten sich am Sonntag, dem Abgabetag, doch ein wenig nervenaufreibend.

Bislang hatte das Spiel erst einen Level, es fehlte ein Menü mitsamt Game Over-Screen, der Forenbeitrag wartete auf seine Formulierung... und das mit einem kleinen Schlafdefizit.

Innerhalb kürzester Zeit las ich mich rudimentär in das UI-System der Engine ein, schustere ein notdürftiges Startmenü mitsamt Game Over-Screen zusammen und schrieb für das Startmenü einen kleinen Text, worum es denn eigentlich geht. Zumindest konnte ich nun behaupten, das Spiel habe so etwas wie Hand und Fuß.

Als nächste spannende Aufgabe galt es, neue Level zu gestalten. Um mich nicht zu verzetteln, plante ich insgesamt mit drei neuen. Binnen kürzester Zeit hatte das Spiel vier Level, in denen sich das Spielkonzept entfalten konnte.

Die anfängliche Beschränkung auf drei neue Level stellte sich übrigens als positive Entscheidung heraus: Natürlich tauchte ein mittelschwerer Bug im letzten Level auf, bei dem bei gewissen Strahlrichtungen der Spielerwürfel einfach abgestoßen wurde. Möglicherweise habe ich dieses Verhalten in meiner Night Coding Session mit eingebaut. Da ich ihn nicht auf die Schnelle beheben konnte, wurde das letzte Level kurzerhand so umgebaut, wodurch die betroffene Richtung nicht mehr gesetzt werden musste.

Nach einer kleinen Müslipause, schickte ich das Ergebnis erstmalig an meine beiden treuen Tester Sam Schattenhammer und Rauramina. Prompt wurde ich mit einem weiteren, seltsamen Bug bei Rauramina konfrontiert: Diesmal blieb der Spielerwürfel manchmal in den Strahlen hängen... WTF?! Dieses Verhalten trat noch nie auf und weigerte sich strikt, reproduziert zu werden. Da es zeitlich doch langsam eng wurde, reduzierte ich die Analyse auf ein Minimum ließ den Bug weiterleben, in der Hoffnung, dass er nicht mehr auftreten würde.

Auch hierbei sollte sich meine Entscheidung als richtig erweisen, denn das Schicksal meinte es erneut nicht gut mit mir: Upload-Geschwindigkeit war offenbar Mangelware an diesem Tag und natürlich vergaß ich mitten im Hochladevorgang einige essentielle Punkte im Release-Build. Somit lud ich das Projekt insgesamt zweimal á 20 Minuten hoch.

Ein wichtiger Aspekt fiel mir allerdings erst nach der finalen Abgabe auf, als mich der User Max Gooroo aus dem ZFX-Forum darauf aufmerksam machte: Das Spiel benötigte alle drei Maustasten - Notebooks ohne mittlerer Maustaste konnten es somit gar nicht spielen!
Ärgerlich, doch auf diese Details vergisst man sehr schnell...

Fazit

Heureka! So eine abenteuerliche ZFX-Action hatte ich noch nicht erlebt. Obwohl der Zeitrahmen von gut einer Woche vorgegeben war, musste ich mich aus Zeitgründen mit insgesamt dreieinhalb Tagen zufrieden geben, vorwiegend am Abgabewochenende.

Wie bei den bisherigen Game Jams, lernte ich auch diesmal wieder viel dazu, vor allem ist mir das Handling der Unity-Engine noch ein ganzes Stück vertrauter geworden. Und tatsächlich ist mir die Engine, aufgrund der raschen Prototyping-Möglichkeiten, ein ganzes Stück sympathischer geworden! 

Für das Spiel waren ursprünglich mehrere Arten von Strahlen geplant mitsamt ausgefeilteren Level und optischen Verbesserungen... doch ich musste an die wichtigste Lektion eines Game Jams denken: Kürzen, kürzen, kürzen!
Das Kernkonzept wurde umgesetzt und funktionierte, auch gab es keine folgenschweren Hürden bei der Ausarbeitung. Auf diesen Stand konnte man nun immer noch aufbauen, und tatsächlich sehe ich ein gewisses Zukunftspotential bei diesem Spielkonzept.

Insgesamt war es wieder eine verdammt positive, motivierende Erfahrung! Vorallem freut es mich immer wieder, die anderen Projekte mit teils verrückten Ideen anzutesten.

Ich danke euch für das Lesen und hoffe, ihr hattet auch diesmal wieder viel Spaß! 

Die 7. ZFX Action stand an und auch dieses Mal nahm ich teil - mein zweiter Game Jam 

Themenwahl und Ideenfindung

Da sich Orteils Game Idea Generator beim letzten Mal bewährte, wurde er auch dieses Mal eingesetzt, um die Themen via Nickname zu generieren.

Ich generierte das Thema “An action game where you repeat customers and you hate every single minute of it.”. Ideen waren dazu vorhanden, doch sie reichten nicht für ein fertiges Spielkonzept.

Wenige Tage vor Jam-Beginn, sah ich mir die Themenliste noch einmal durch und wählte ein anderes:
“A horror game where you resurrect squares with a slighly racist sidekick.”.

Die Ideen sprudelten diesmal förmlich aus mir heraus und so wagte ich mich an erste Concept Arts, um meine Gedanken zu visualisieren:

Mein Kerngedanke war in groben Zügen völlig anders, als das, was ich am Ende ablieferte:

• Ein Raumschiff schwebt über der Erde

• Kreisförmige Roboter entsteigen und greifen die rechteckigen Erdenbewohner mit Absorbationsstrahlen an (ähnlich dem Protonstrahlern der Ghostbusters) - alternativ hätten sie die Rechtecke zu bösen Kreisen “konvertiert”

• Square Man und sein Sidekick sind zur Stelle, die Aliens zurückzuschlagen. Im Laufe des Spiels hätte “Sidekick” seine Sprüche los gelassen wie Robin seinerzeit in der alten Batman-Serie.

“Square Man” wurde in den Grundzügen geboren...

Prototyping

... doch er starb schneller, als mir lieb war.

Das Prototyping selbst verlief außerordentlich gut, doch nach und nach bemerkte ich: Die Idee war im gewünschten Ausmaß nicht so rasch umsetzbar! Ich schmiss die Idee mitsamt Konzept kurzerhand über Bord und war frustriert…

Ich bastelte an weiteren Concept Arts und ließ meinen Gedanken erneut freien Lauf. Bei einer Skizze machte es Klick:

Ein Friedhof, in dem eine verstrahlte Rakete gestürzt war, wird zur Geburtsstätte toter Zombie-Rechtecke. Nur unser Held kann sie mithilfe seiner Antistrahlungsspritzen retten. Damit war das Konzept zu “Night of the undead squares!” geboren.

Ein paar Eindrücke des Entwicklungsprozesses:

Übrigens: Der Spieler ist weiterhin Square Man aus dem vorherigen Prototypen… ich versäumte es, die Sprites zu ändern 

Technische Basis

Da das HaxeFlixel-Framework beim letzten Jam sehr gute Dienste verrichte, war es auch dieses Mal die technische Grundlage. Allerdings würde ich mich nicht mehr als blutigen Haxe-Anfänger bezeichnen, sondern wusste über die Stärken und Schwächen des Frameworks Bescheid und auch, was wie umgesetzt werden muss.

Ich lernte die unzähligen Helper-Klassen im Laufe der drei Tage sehr zu schätzen: Automatisches Laden von Maps, Collision Handling, Asset-Handling, … - Dinge, die so einfach waren, dass ich mich voll und ganz auf das Gameplay konzentrieren konnte.

Nennenswerte Schwierigkeiten gab es (fast) keine. Bei einem Tester klappte es mit der Steuerung nicht so ganz, weshalb ich für ihn eine Windows-Version anstatt einer Flash-Version erstellen ließ (zwei Klicks -> fertig!).

Was ich mir noch wünschen würde, wäre eine minimal bessere IDE. FlashDevelop ist eine tolle Sache, doch vermisse ich kleinere Komfortfeatures, wie z.B. automatische Formatierung des Codes. Dinge, die allesamt keinen Showstopper darstellen, aber "nice to have" wären.

Assets

Als Grafikstil setzte ich auf altbewährte Pixelgrafik, der Sound blieb dem Retrostil treu (mit Ausnahme der Zombie-Geräusche ) und musikalisch… war ich einfach nicht begabt genug.

Dieses Mal wendete ich mehr Zeit für die Suche nach einem geeigneten Musikstück auf. Ich wollte im 8 Bit-Segment bleiben, das die düstere Stimmung einfing und nicht zu störend wirkte. Auf den einschlägisten Seiten hörte ich mich durch diverse Musikstücke, bis ich auf einen richtig tollen 8-Bit Soundtrack von Nick Perrin stieß: http://www.newgrounds.com/audio/listen/145362

Glücklicherweise war die Lizenz nicht restriktiv und ich konnte das Musikstück für mein kostenloses Spiel verwenden - und es trug wahrlich zur Atmosphäre bei, perfekt!

Die Asset-Erstellung ging gut von der Hand und bereitete die geringsten Schwierigkeiten. Grafisch war mein Spiel nicht allzu anspruchsvoll, die Sounds waren nach einer halben Stunde bfxr-Action abgehandelt und die Musik relativ rasch gefunden.

Finetuning und die letzten Stunden

Erstmalig nutzte ich die Gelegenheit, das Spiel von anderen Leuten (insgesamt zwei) testen zu lassen. Das Feedback war überwiegend positiv, einige Bugs wurden gemeldet & behoben und insgesamt wirkte das Gameplay nach einigen Anpassungen viel runder. So soll es sein! 

Ich erfüllte außerdem mein Thema größtenteils:

A horror game... - Check!

….squares…. - Check!

….resurrect squares…. - Check!

….slighly racist sidekick... - Che... Verdammt!

Einer meiner Tester hatte dazu einen passenden Vorschlag parat: “Bau doch einen sprechenden Werwolf ein!” - gesagt, getan:

Herausgekommen ist ein total verkorkster Werwolf, der im Eifer des Gefechtes als Gargoyle-ähnliches Wesen bezeichnet wurde, das sich als “Sidekick” über Rechtecke auslässt…

Am letzten Jam-Tag bereitete ich alles für die Abgabe vor: Der Forenpost wurde geschrieben (http://zfx.info/viewtopic.php?f=40&t=3760), die itch.io-Seite (http://gamedevr.itch.io/night-of-the-undead-squares) angelegt und abschließende Tests durchgeführt.

Am 03.05.2015 15:10 war das Projekt offiziell abgegeben - wenige Stunden vor der offiziellen Abgabe!

Fazit

Puh, geschafft! Drei Tage Jam-Power gingen zu Ende und ich lernte wieder massiv viel dabei. Ich hatte viel Spaß bei der Entwicklung, lernte mehr von HaxeFlixel kennen und zum ersten Mal konnte ich ein Spiel in voller Montur abliefern: Grafik, Sound und Musik waren vorhanden, Wahnsinn!

Anfangs hatte ich noch Bedenken, ob ich meine (zweite) Idee rechtzeitig umsetzen konnte. Ursprünglich waren noch mehr Features geplant, doch ich lernte eine wichtige Lektion: Kürzen, kürzen, kürzen! 

Die Programmierung war meiner Ansicht nach die produktivste Tätigkeit, denn die Leistung konnte ich im Gegensatz zur letzten ZFX Action enorm verbessern. Somit blieb mehr Zeit für abschließendes Finetuning und Optimierungen, was dem Spiel tatsächlich zu Gute kam.

Es war eine verdammt positive und motivierende Erfahrung - sowohl für diesen Jam als auch für meine anderen Projekte!

Fakt ist, dass ich bei der nächsten ZFX Action sehr gerne wieder dabei bin!

 

Ich danke euch für das Lesen und hoffe, ihr hattet dabei genauso viel Spaß wie ich beim Schreiben! 

Die ZFX-Action ist seit einigen Tagen vorbei und ich konnte nun etwas Abstand gewinnen. Hiermit gebe ich meine eigenen Erfahrungen wieder - einem absoluten Game Jam-Neuling!

Vorweg: Der gesamte Jam hat wahnsinnig viel Spaß gemacht! Sowohl das Entwickeln mit einer mir völlig neuen Technologie, das Beobachten der anderen Projekte als auch das Anspielen der  finalen Versionen, war einfach ein tolles Erlebnis. Auf jeden Fall wird es nicht mein letzter Jam gewesen sein!

Themenauswahl und Ideenfindung

Als sehr positiv empfand ich die Themenvielfalt. Jeder Teilnehmer konnte mit seinem Nickname unter http://orteil.dashnet.org/gamegen ein Thema generieren lassen und posten. In meinem Fall war es “A role-playing game where you must obtain collectible bats with magic.”.

Ich stellte mir Szenarien zu den unterschiedlichen Themen vor, zeichnete Ideen auf, blieb allerdings bei meinem eigenen hängen. Mir fielen dazu einfach die sinnvollsten und vorallem machbarsten Ideen ein... somit war “Bat of Justice” geboren.

Das Gameplay war relativ einfach gestrickt: In einem Raum sind drei Teile eines Baseballschlägers aufbewahrt und die Aufgabe des Spielers ist es, sie aus ihrer magischen Barriere zu befreien. Die Gegner kann man außerdem betäuben und davon schleudern.
Sobald man alle Schlägerteile zusammen hat, kann man mit dem “Bat of Justice” auf die Gegnerhorden eindreschen.

Für all jene die es interessiert, hänge ich einmal meine Brainstormingergüsse an (es sind darunter mehrere Themen zu finden):

 

Eine Frage der Technik

Ursprünglich wollte ich mit C# und Unity3D an den Start gehen. Doch andererseits sehnte ich mich danach, etwas Neues auszuprobieren.

HaxeFlixel wurde mir von Laguna schmackhaft gemacht, weshalb ich das Framework etwa eine Woche vor Jam-Beginn ausprobierte. Das Tutorial war ziemlich gut beschrieben und auch Haxe als Sprache schien einen ordentlichen Eindruck zu machen. Ich war richtig angetan!
Somit stand also fest: Haxe mitsamt des HaxeFlixel-Frameworks werden mich bei diesem Game Jam begleiten.

Als Map Editor wählte ich den Ogmo Editor (http://ogmoeditor.com) aus (Gewohnheit und HaxeFlixel-Tutorial sei Dank ).

Es geht los!

Trotz kleinerer Anfangsschwierigkeiten (und ein wenig Aufregung), hatte ich Freitagnacht einen spielbaren Prototypen ausgearbeitet, der die Kernmechanik (Bewegung, Gegner-Spawn, Schläger einsammeln) bot:

Unterstützt wurde ich dabei von Kaffee:

Nach einem fertigen Gameplay-Prototypen, begann ich mich an die Optik herzumachen, um ein wenig vom Programmieren weg zu kommen.

Der Spieler sollte zumindest eine Gehanimation und ein Sprite für Aktionen spendiert bekommen. Nach gut einer halben Stunde hatte ich den Spieler fertig:

Da das Spiel auch etwas von Baseball hat (ehrlich gesagt, fiel mir nichts anderes/besseres ein), sollten die Gegner zumindest ein wenig in dieses Setting passen. Ein erster Entwurf sah so aus:

Gegen Ende hin entschied ich mich, Monsterflair einfließen zu lassen und machte die Gegner größer, gefährlicher und bedrohlicher... gleichzeitig revidierte die Baseballkappe sämtliche dieser Eigenschaften:

Apropos Gegner: Zu diesem Zeitpunkt waren sie strohdumm. Sie bewegten sich immer genau auf den Spieler zu ohne jegliche Pfaderkennung, somit hingen sie auch bei den Schlägerteilen fest.
Leider ging einiges an Zeit drauf, die HaxeFlixel-integrierte Pfaderkennung zu aktivieren und für meine Bedürfnisse umzusetzen. Der Grund war weniger das Framework, sondern eher meine eigene Unfähigkeit und Müdigkeit. Das ganze noch zu koppeln mit dem geplanten Betäubungszauber, war eine weitere Herausforderung.
Die Bilanz: Aus geplanten zwei Verteidgungszaubern, wurde schließlich nur einer, dafür hängen die Gegner nirgends mehr fest!

Die letzten Stunden

Ich befasste mich am Sonntag großteils damit, das Spiel stabiler und ansprechender zu gestalten.
Mit bfxr ließ ich mir ein paar Retrosounds generieren und baute noch die ein oder andere Nebenanimation ein: Den Gegner-Spawn und Zerstörungszauber bei der Barriere.
Da ich wusste, dass ich musikalisch viel zu lange brauchen würde, verzichtete ich komplett auf etwas eigenes. Die Suche nach passender Musik verschob ich auf später, sofern noch genug Zeit blieb (war leider nicht der Fall).

Da ich kein unnötiges Zeitrisiko eingehen wollte, schmiss ich kurzerhand das Feature raus, bei dem man am Ende mit dem Baseballschläger die Gegner verprügeln konnte.
Ursprünglich sollte es auch mehr Level geben... Ein Levelsystem einzubinden und testen hätte ebenso zu lange gedauert. Daher entschied ich mich, das Spiel lieber als Ein-Level-Projekt abzugeben, das einigermaßen stabil lief.

Auf den letzten Drücker baute ich noch eine Manabegrenzung ein, um das Spiel nicht ganz so einfach zu machen.

Kurz vor Game Jam-Ende gab ich das Projekt ab. Endlich war es geschafft und gerade noch rechtzeitig!

Ein Fazit

Mein erster Game Jam lief gar nicht so schlecht. Ich hatte ein kleines Spiel mit einer mir völlig unbekannten Technologie gebastelt, war durchgehend motiviert und im großen und ganzen richtig stolz auf mich. Klar, es lief nicht alles rund, doch die Routine wird bei Game Jams einkehren.

Im Nachhinein betrachtet, war die Technik Fluch und Segen gleichzeitig. Einerseits hätte ich mir mehr Zeit im Vorfeld für die Grundmechaniken von HaxeFlixel nehmen sollen, andererseits fühlte ich mich trotz kleinerer Hürden schneller bei der Entwicklung, als es bei Unity der Fall gewesen wäre.
Ärgerlich ist es auf jeden Fall, dass ich keine Zeit mehr hatte, die Kollsion noch weiter zu optimieren und die gestrichenen Features einzubauen.

Ursprünglich wollte ich das Projekt samt Source Code rausgeben, doch ich glaube, der Code im jetzigen Zustand (zusammengehackt und unschön) ist keinesfalls für jemanden außenstehendes brauchbar.

Grafisch bin ich gut vorangekommen und hier merkte ich den geringsten Widerstand. Zwar hätte ich noch etwas mehr Juice einfließen lassen sollen (z.B. ein paar Partikeleffekte hier und da), doch auch hier nagte die Zeit. Die Erstellung der Sounds war mithilfe von bfxr gewohnt kein Problem und damit fast im Vorbeigehen erledigt.

Was ich diesmal versäumt habe: Der IRC-Chat! Beim nächsten Mal werde ich mich auf jeden Fall dort blicken lassen und aktiv teilnehmen.
Auch ein Timelapse sollte beim nächsten Jam im Rahmen des Möglichen sein.

 

Ich danke euch für das Lesen dieses Blogposts und hoffe, ihr hattet beim Lesen genauso viel Vergnügen, wie ich beim Schreiben! 

Hallo Leute!

Der pixelige Medic ist zurück mit Version 0.4 und hat einige neue Features samt optischen Verbesserungen dabei!

 

Was hat sich in dieser Version getan?

• Highscore
  Das Spiel bot in den vergangenen Versionen noch keine wirkliche Langzeitmotivation. Es wurde nun als erste Verbesserung ein lokaler Highscore eingebaut, mit dem insgesamt 10 Rekorde festgehalten werden können. Ideal für gemeinsames Zocken oder auch um sich mit einem selbst zu messen 
   
• Power Ups
  Arcade-Games boten immer eine Menge an Power Ups. Sei es nun Schnellschuss in Space Shootern, doppelter Speed in Jump'n'Runs oder kurzweilige Waffenverbesserungen. In "The Pixel Medic" soll es jene auch geben.
  Den Beginn machen in dieser Version ein
  • Speed-Power Up (schneller Laufen),
  • Double Score Point-Power Up (doppelte Punktzahl)
  • und ein NPC Spawn-Power Up (Spawn diverser NPCs)​​​​.​
     

• Sprites der Explosionen
  Die Explosionen waren ein wenig zu heftig geraten und passten nicht in das Gesamtbild. Ich habe daher die entsprechenden Sprites verkleinert und die Explosion damit weniger aggressiv gestaltet.
   

• Juice
  Das Spiel war einfach gestrickt: Wiederbelebte NPCs verschwanden einfach, explodierte NPCs verschwanden einfach, ... Ganz ohne Seele und relativ lieblos gestaltet. Natürlich sollte das Spiel etwas mehr bieten.
  Aufgrund einiger interessanter Links aus dem Spieleprogrammierer-Forum (siehe unten), bekam ich Inspirationen für Effekte, die das Spiel gleich wesentlich schicker und lebendiger machten. So zerbrechen nun NPCs bei einer Explosion in zwei Teile und wiederbelebte NPCs springen kurz auf und laufen aus dem Bildschirm.
   
• Anfänge von Musik
  Ich habe mir den FamiTracker heruntergeladen und ein wenig damit herumgespielt. Herausgekommen sind dabei zwei ultrakurze Tracks für den Game Over-Bildschirm und bei Erreichen eines neuen Highscore-Rekords. Sollte ich es schaffen, einen Loop-fähigen Track zu zaubern, werde ich diesen natürlich einbauen... doch mal sehen, ob meine musikalischen Fähigkeiten dafür überhaupt ausreichend sind.

 

Die nächsten Schritte

Für die nächste Version geplant sind die folgenden Punkte:

• Motivationsfaktor
  Als Verbesserung der Langzeitmotivation, werde ich den hier bereits besprochenen Motivationsfaktor einbauen. Damit wird auch das Punktesystem ein kleines Upgrade erfahren.
   
• Neue Levels
  Natürlich soll das Spiel nicht ewig mit einem Level ausgestattet sein, sondern mehrere beinhalten. Idealerweise mit einem passenden Leveleditor, damit auch Fans ihre eigenen erstellen können. Toll wäre ein kleiner Ingame-Editor, doch damit werde ich mich noch in den nächsten Wochen ausgiebiger befassen.
  Damit das alles gut klappt, werde ich einige größere Code-Anpassungen vornehmen müssen.
   
• Weitere Musik
  Mehr muss ich wohl nicht dazu sagen? 
   
• Juice
  Das Spiel gefällt mir persönlich aus visueller Sicht nun wesentlich besser. Sollten mir noch weitere Ideen zur Optik, werde ich diese natürlich umsetzen. Überladen will ich das Spiel damit allerdings auch nicht.

 

Für alle, die an den Links zum Thema "Juice" interessiert sind (Danke nochmals an Laguna und Frybird!):
http://indiestatik.com/2013/11/21/game-teaches-30-tricks-make-action-game-feel-better/
http://www.youtube.com/watch?v=Fy0aCDmgnxg
http://indieoutpost.org/en/treffen-6-followup/

Ich wünsche euch noch viel Spaß mit der aktuellen Version und freue mich wie immer über euer Feedback! :)

 

 #Arcade  #Platformer  #Windows  #CSharp #Monogame

Hallo Leute!

Etwas verspätet als geplant, ist es heute soweit: “The Pixel Medic” ist nun als spielbare Version 0.3 verfügbar und kann ab sofort hier heruntergeladen werden. Diese Version ist zwar bereits einigermaßen stabil, dennoch bezeichne ich sie vorsichtshalber noch als Alpha.

 

Welche Änderungen gibt es seit der Version 0.2?

• Soundeffekte
  Dank dem Tool bfxr (http://bfxr.net) konnte ich rasch die benötigten Sounds erstellen. Ich wollte dem visuellen Retrostil treu bleiben und entschied mich für einfache Effekte.
  Wem die Sounds auf die Nerven gehen, der kann sie Ingame via Tastendruck auf “M” ganz einfach stumm schalten bzw. wieder aktivieren. Sollte die Lautstärke zu hoch sein, kann diese in der Medic.exe.config angepasst werden. Ein entsprechendes Optionsmenü fehlt noch komplett, wird aber in eine der nächsten Versionen enthalten sein.
  Wer auf eine tolle Retromusik hofft, wird allerdings enttäuscht… ich habe noch keine passende Musik gefunden 

• Visuelle Änderungen
  Ursprünglich hatte die Titelfigur ein rotes Kreuz auf der Brust. Ich habe mich ein wenig mit Urheberrecht und Markenschutz befasst und bemerkt, dass das Rote Kreuz tatsächlich geschützt ist. So hat das Blaue Kreuz das Rote ersetzt (man weiß ja nie …) und die Farbgebung des Spiellogos samt Ingame-Texten mitbeeinflusst.
  Weiters hinzugefügt wurden ein paar neue Sprites, Titel- samt Game Over-Bildschirm und Explosionen ...

• ... die NPCs nach einigen Sekunden den Rest geben
  Bisher war es noch so, dass NPCs einfach verschwunden sind, falls sie nach einer gewissen Zeitspanne nicht gerettet wurden.
  Noch bleibt der Spieler hiervon unbeschadet, sollte er versehentlich in eine solche geraten... hier bin ich am überlegen, ob das so bleibt.

 

Abseits des Releases, steht nun auch der finale Titel fest, den ich schon hier und da erwähnte:

 

Weitere Schritte

Natürlich steht die Entwicklung nach diesem Release nicht still. Ich werde das Spiel noch weiter ausbauen und zu einem Abschluss bringen.

Für die nächste Version geplant sind die folgenden Punkte:

• Highscore
  Ich orientiere mich auch hier wieder an klassische Arcade-Vorbilder. Es wird einen rein lokalen Highscore geben, der ohne Onlinesynchronisierung oder dergleichen auskommt.

• Power Ups
  Das Spielprinzip schreit förmlich nach Power Ups. Ich werde mir dazu noch Überlegungen machen, welche sinnvoll sind und wie man das Gameplay damit verbessern kann.

• Feedback abarbeiten
  Natürlich wird es den ein oder anderen Bug oder Verbesserungsvorschlag geben, den ich beheben bzw. umsetzen werde.

• (Vielleicht) Musik
  Sollte ich bei meiner weiteren Suche keine passenden Musikstücke finden, werde ich mir externe Hilfe organisieren. Dazu folgen wohl etliche Forenposts bzw. werde ich aktiv auf einige Musiktalente zugehen. Mal schauen, ob sich da jemand passendes findet. Alternativ bliebe mir noch mein altes Keyboard ...

Nun genug der langen Reden. Ich wünsche euch viel Spaß mit der Alphaversion und freue mich bereits auf euer Feedback im Forum! 

Hallo Leute!

In diesem Blogpost gehe ich ein wenig auf meine bisherigen Erfahrungen mit dem MonoGame-Framework ein, die ich während der Entwicklung von “The Pixel Medic” gesammelt habe.

 

Wie Zuhause
MonoGame bietet auf den ersten Blick dieselben Möglichkeiten wie XNA. Die Projekterstellung selbst erfolgte anstandslos und prompt wurde ich vom bekannten, blauen Spielfenster begrüßt.

Ich baute nach und nach meine Klassen in das Projekt ein, benutzte die Content Pipeline für meine Texturen und schaffte es binnen kürzester Zeit, einen ersten Prototypen zusammenzustellen.

Nach und nach baute ich ihn weiter aus, verfeinerte die Codebasis und stieß bis dahin auf keine nennenswerten Herausforderungen.

Ein großer Pluspunkt: Der Großteil blieb gleich wie bei XNA. Bisheriges Wissen konnte ich anwenden und ich fühlte mich in einer vertrauten Umgebung wohl. Weiterer Pluspunkt: Die erste, spielbare und absolut minimal gehaltene Version war in relativ kurzer Zeit fertig.

 

Content Pipeline
Texturen waren keine Hürde und wurden anstandslos geladen.

Erst als das Thema Musik und Sound an Releanz gewann, gab es die ersten Stolpersteine. Vermutlich war ich einfach nur zu sehr von XNA verwöhnt, doch die Content Pipeline von MonoGame weigerte sich strikt, meine mit bfxr erstellten WAV-Dateien einzulesen.

Nach Recherchen stellte ich fest, dass WAV-Dateien nur in einem bestimmten Format (bestimmte Bitrate, bestimmter KHz-Bereich, …)  eingelesen werden können. Okay, kein Problem, konvertierte ich eben meine Sounds via Audacity und probierte es erneut aus:  Fehlanzeige.
Auch als ich das MonoGame Content Pipeline GUI nutzte und daraus ein SoundEffect-File erstellen ließ, weigere sich MonoGame strikt mit einer ContentLoadException, den Sound zu laden.

Ich beschloss, es anders zu probieren: Über die SoundEffect.LoadStream-Methode. Ein erster Test zeigte mir jedoch ähnlich negatives in Form einer NotImplemented-Exception...

Ich stocherte ein wenig im offiziellen Forum herum und besuchte das GitHub-Repository, wo ich in einem Issue fündig wurde: Die entsprechende SoundLoader-Methode für die Windows DirectX-Plattform war tatsächlich nicht implementiert worden, doch sollte ein aktueller Development Build eine funktionierende Implementierung bereitstellen.

Ich schnappte mir besagten Build und testete noch einmal die FromStream-Methode. Siehe da: Es funktionierte! Ich hatte endlich Sound!

Leider verweigerte die klassische Content.Load<SoundEffect>-Methode auch in diesem Build den Dienst, was nun weniger tragisch ist.

Ähnliches ist mir bei den Fonts aufgefallen, die nicht ohne weiteres geladen werden können. Hierfür müsste man mit der XNA Content Pipeline entsprechende *.xnb-Dateien generieren. Da im derzeitigen Projektstatus keine wirklichen Textausgaben benötigt werden, ist dies erst einmal kein Showstopper und habe mich noch nicht weiter befasst. Vielleicht später, sollte der Highscore eingebaut werden, werde ich mich genauer nach Lösungen umsehen.

 

Vollbild - oder auch nicht?

Mein Spiel soll natürlich im Vollbild laufen und in voller Pracht auf den Bildschirm erscheinen. Allerdings gibt es in MonoGame noch keinen “richtigen” Fullscreen. Laut einem Github-Issue ist die Funktionalität nicht implementiert und so gilt es, folgenden Workaround zu nutzen: Das Fenster an die Bildschirmgröße anpassen und den Fensterrahmen einfach ausblenden.

Es gab bisher noch keine Probleme oder Auffälligkeiten - ich hoffe, das bleibt so.

 

Erste Gehversuche mit Linux

MonoGame hatte ich aus dem Grund gewählt, um später auch für Linux und ggf. Mac kompilieren zu können. Ich konnte das selbe Windows-Projekt fast komplett übernehmen und kompilierte unter einem aktuellen Ubuntu-System samt aktuellem MonoGame-Build anstandslos.

Erste Spieltests waren ebenso positiv und äußerst zufriedenstellend. Sehr gut!

 

Ein vorläufiges Fazit

Viele Herausforderungen konnte ich lösen, indem ich fleißig suchte. Die meisten Lösungen waren Workarounds oder Hacks. Ein richtiges Out-of-the-Box-Erlebnis gab es nur zu Beginn. Alles, was über 2D Sprite Rendering hinausging, war in meinem Fall eine Baustelle und trübte den Eindruck doch sehr.

Obwohl MonoGame anscheinend lange Zeit existiert und bereits bei Version 3.2 angelangt ist, wirkt es noch immer unausgereift und unfertig.

 

Alternativen?

Ehrlich gesagt, weiß ich nicht, ob ich für mein nächstes Projekt weiterhin MonoGame nutzen will. Zum Teil aufgrund der bisherigen Erfahrungen, aber auch weil ich über den Tellerrand sehen und mich mit Non-XNA-Alternativen auseinandersetzen will.

Einige Kandidaten habe ich bereits vage ins Auge gefasst:

• SFML.NET: Ich kenne die Library noch aus meiner C++-Zeit und fand sie damals recht gut. Der .NET-Port soll ähnlich gut funktionieren und bereits von einigen Entwicklern gab es positives Feedback.
• HTML5/JavaScript: Cross Plattform pur - ich experimentierte bereits damit herum und mir gefiel es, auch wenn ich mich noch an JavaScript gewöhnen muss. Vielleicht arbeite ich mich hier etwas mehr ein, um etwas Vernünftiges auf die Beine stellen zu können. Desktop-Games sind Dank Wrappern (z.B. https://github.com/rogerwang/node-webkit) möglich, was mich sehr anspricht. Einzige Hürden sehe im Audiobereich, wo ich immer wieder über Herausforderungen lese.
• Unity: Die Engine hat sich in den letzten Monaten/Jahren verstärkt auf 2D-Techniken konzentriert und bringt ein tolles Out-of-the-Box-Feeling.
• LibGDX: Das libGDX-Framework ist das JAVA-Pendant zu MonoGame, mit dem Unterschied, dass es wesentlich ausgereifter wirkt und der Cross Plattform Support einmalig ist.

Hallo Leute!

In diesem Blogpost erläutere ich ein wenig die Anfänge zu meinem aktuellen Projekt "Medic".

Ein Medic musste her
Der Grundstein wurde im Juni 2014 gelegt, kurz nachdem das Juni-Thema "Doctor" des 1GAM-Contests bekannt gegeben wurde.

Erst war ich noch unschlüssig, was ich eigentlich genau machen wollte. Ich wusste nur: Als Fan von Pixelgrafik und einfachen Spielkonzepten, wollte ich etwas vergleichbares entwickeln. Ich wollte ein Spiel erstellen, dass grafisch nicht zu anspruchsvoll, einfach zu bedienen und für eine Person schaffbar war.

Nach einigen Tagen der Überlegung, kam ich auf den Gedanken, einen 2D Platformer zu erstellen, mit einem völlig unerwarteten Ziel: Leute retten - "Medic" wurde geboren.

Der HTML5-Prototyp
Ich hatte eine grobe Vision im Kopf und so konnte die Entwicklung eines Prototypen beginnen.
Ursprünglich sollte das Spiel im Browser spielbar sein, also begann ich mit HTML5 und JavaScript einen schnellen Prototypen zu erstellen. Die Grundidee war damit abgedeckt und ich konnte nach einer Woche Arbeit bereits etwas spielbares vorweisen:

In dieser Urversion gab es zwei Unterschiede zu jetzt:

• Der Einsatz des Defibrillators dauerte ein paar Augenblicke und wurde via gezeigtem Timer visualisiert, der sich zu einem Kreuz auffüllte
• Ebenen fehlten völlig - Spieler und NPCs sind nur am Boden zu finden

Die Idee spielte sich zwar gut und gefiel mir auch, doch merkte ich, dass sie noch ausbaufähig war. Ich beschloss, sie weiter auszuarbeiten.

Zurück zu C#
Da ich mich mit HTML5/JavaScript noch nicht sicher genug fühle und nicht wusste, ob ich das Projekt mit meinem derzeitigen Kenntnisstand und den geplanten Erweiterungen gerecht umsetzen konnte, wechselte ich auf meine Stammsprache C# und dem MonoGame-Framework.
Die Entwicklung begann technisch bedingt von vorne... und ganz ehrlich: Mein JavaScript-Code war ohnein für die Tonne.

Es dauerte fast 3 Wochen, bis die Version entstand, wie sie im allerersten Gameplay-Video sichtbar ist.
Es gab Ebenen, das Wiederbeleben erfolge sofort, der Spielfluss war flotter und wesentlich angenehmer - alles in allem eine positive Weiterentwicklung.

 

 #Arcade  #Platformer  #Windows  #CSharp 

#Platformer  #Arcade  #Windows  #CSharp 

Hallo Leute! :)

In der aktuellen Version 0.2 wurden nun folgende Punkte umgesetzt:

• Verbesserung des Sprungs
  In der ersten Version war der Sprung noch langsam und für das Gameplay völlig ungeeignet.
  Jetzt sieht er so aus, wie ich ihn schon immer vor Augen hatte: Schnell und an das Leveldesign angepasst!
• NPCs
  • Sprite für wiederbelebte NPCs
    Während des Prototypings war es noch in Ordnung, wenn ein geretteter NPC einfach so verschwand. Da diese Phase allerdings abgeschlossen ist, habe ich jenen NPCs ein entsprechendes Sprite spendiert.
  • NPCs und der Tod
    Lässt man sich mit der Rettung der NPCs zu lange Zeit, verschwinden diese. Noch ohne Animation oder Sprite ...
• Punktesytem
  Bisher war es recht einfach gestrickt: Pro geretteten NPC gab es konstant 100 Punkte. Ich wollte etwas mehr Dynamik einfließen lassen, in Form einer ...
  • ... variablen Punktzahl
    Je schneller man nun einen NPC wiederbelebt, desto mehr Punkte gibt es. Dies sollte der Spieldynamik gut tun.
  • Anzeige der Punktzahl über den NPCs

Die nächsten Schritte:

• Release einer spielbaren Version
  Die kommende Version 0.3 wird erstmalig eine öffentlich spielbare Version sein. Wenn alles gut geht, sollte es mit einem Release Mitte August klappen.
• Sound und Musik
  So langsam wird es Zeit, die Soundkulisse zu bedienen. Für die Sounds wird ein Tool wie bfxr (http://www.bfxr.net) ausreichend sein. Bei der Musik bin ich mir da noch nicht so sicher. Glücklicherweise gibt es ja reichlich freie Stücke :)
• Highscore
  Da man in diesem Spiel Punkte sammelt, ist ein Highscore kaum wegzudenken. Außerdem ist es doch toll, wenn man sich mit Freunden duellieren kann und den Rekord des anderen knackt. Um den Rahmen dieses Projektes allerdings nicht zu sprengen, wird der Highscore für "Medic" nur lokal gespeichert - einen Online-Highscore wird es nicht geben.
• Nicht gerettete NPCs
  Ob es einen Punkteabzug für einen nicht geretteten NPC geben sollte? Vielleicht eine zusätzliche Anzeige, wieviele NPCs gerettet wurden und wieviele nicht? Oder sollte es gar keine Konsequenzen geben?
  Ich werde mich noch weiter damit befassen bzw. auf Feedback warten.

Ich halte euch auf dem Laufenden! :)