GameDevR Blogs MonoGame - Ein kurzer Erfahrungsbericht
MonoGame - Ein kurzer Erfahrungsbericht 29.08.2014 - 14:34 0

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.

Aktualisiert: 29.08.2014 - 14:39
Grund:
30.08.2014 - 00:17
damios
In den letzten 60 min online
damios
Rang 18
Administrator

Projekte: 3
Designs: 2
Blogs: 11
Aktivität:
Aktiv

Hey, das ist echt interessant zu lesen, was für Erfahrungen du mit dem MonoGame Framework hattest. C# zu lernen steht leider immer noch auf meiner ToDo-Liste :D  Da ich eher ein Java Freak bin, habe ich von den von dir genanten Alternativen bisher nur mit LibGdx Erfahrungen gesammelt ;) LibGDx hat ein relativ gutes Wiki und man findet genügend Beispielprojekte dazu. Probleme beim Laden von Assets hatte ich noch keine, und auch ansonsten bin ich 
recht zufrieden damit.

damios
In den letzten 60 min online
damios
Rang 18
Administrator

Projekte: 3
Designs: 2
Blogs: 11
Aktivität:
Aktiv
Administrator
30.08.2014 - 22:36
Ersteller
GameDevR
In den letzten 60 min online
GameDevR
Rang 9

Projekte: 4
Designs: 0
Blogs: 8
Aktivität:
Wahrscheinlich inaktiv

Hi damios, danke für dein Feedback! :)
Das ausführliche Wiki und die vielen (vorallem funktionierenden) Beispielprojekte sind ein großer Pluspunkt von libGDX, den ich sehr schätze.
Beruhigend zu wissen, dass wenigstens die Assets ohne viel Trara geladen werden.
Ich hatte libGDX vor etwa 2 Jahren das erste Mal ausprobiert ... ist es immer noch so, dass du ein Android-Projekt benötigst, in dem du deine Assets speicherst? Oder hat sich da etwas getan in der Zwischenzeit?

Ersteller
GameDevR
In den letzten 60 min online
GameDevR
Rang 9

Projekte: 4
Designs: 0
Blogs: 8
Aktivität:
Wahrscheinlich inaktiv
30.08.2014 - 23:08
damios
In den letzten 60 min online
damios
Rang 18
Administrator

Projekte: 3
Designs: 2
Blogs: 11
Aktivität:
Aktiv

Nein, mittlerwile braucht man kein Android Projekt zum Speichern der Assets mehr. Ich entwickle grad auch ein Spiel für den Desktop und alles klappt problemlos.

damios
In den letzten 60 min online
damios
Rang 18
Administrator

Projekte: 3
Designs: 2
Blogs: 11
Aktivität:
Aktiv
Administrator
31.08.2014 - 00:54
Ersteller
GameDevR
In den letzten 60 min online
GameDevR
Rang 9

Projekte: 4
Designs: 0
Blogs: 8
Aktivität:
Wahrscheinlich inaktiv

Klasse! laugh Dann werde ich libGDX wohl nach Abschluss des Medics einfach einmal ausprobieren und damit ein kleines Projekt zusammenbasteln.

Ersteller
GameDevR
In den letzten 60 min online
GameDevR
Rang 9

Projekte: 4
Designs: 0
Blogs: 8
Aktivität:
Wahrscheinlich inaktiv