13. Mai 2024
Lesedauer 15 Min.
Es begann mit XNA …
MonoGame für Einsteiger, Teil 1
Eine Artikelserie für Indie-Game-Developer und solche, die es werden wollen.
dotnetpro
DirectX kennt jeder (Spiele-)Entwickler. XNA haben schon nicht mehr (so) viele auf dem Schirm. FNA haben nur sehr wenige kennengelernt. Und MonoGame? Allein nach dem Begriff im Internet zu suchen führt schon zu unerwarteten Beziehungs-Webseiten. Vielleicht ist es an der Zeit, damit ein wenig aufzuräumen, Vorurteile zu entschärfen und zugleich aufzuzeigen, dass „neuer“ nicht notwendigerweise „besser“ ist und Altes nicht notwendigerweise schlechter.Doch zunächst einmal ein wenig Historie, bevor es ans Eingemachte geht: Die Abkürzung XNA steht für „Xbox New Architecture“ (zumindest war das der interne Projektname; später wurde darüber gewitzelt, die Abkürzung stünde für „XNA’s not an Acronym“). Dieses Framework wurde von Microsoft mit dem Ziel entwickelt, es insbesondere Indie-Developern zu erleichtern, Spiele für Windows und die Xbox-Plattform zu entwickeln. Der besondere Clou dabei war, dass das integrierte Content-Pipeline-Tool sämtliche Assets verwalten und in ein plattformunabhängiges Format konvertieren konnte, sodass der Zugriff auf Grafiken, Sprites, Hintergrundmusik und vieles mehr wirklich sehr einfach wurde.Übrigens: Zwischenzeitlich war es auch möglich, mittels XNA Spiele für den Microsoft Zune zu entwickeln (@GenerationZ: Das war so etwas wie ein iPod, aber von Microsoft), und mit XNA 4.0 kam auch die Unterstützung für Windows Phone hinzu. Mit Xbox Live Arcade hatte Microsoft zudem einen Marktplatz geschaffen, der es Indie-Developern ermöglichte, selbst entwickelte Spiele auch ohne großen Publisher relativ einfach auf der Xbox zu vermarkten.Was damit erstmals 2004 für einen Umbruch in der Spieleentwickler-Szene und auch eine gewisse Demokratisierung sorgte, fand schlussletztlich 2013, knapp zehn Jahre später, ein vorläufiges Ende, als Microsoft ankündigte, XNA nicht mehr weiterzuentwickeln. Damit wurden die Spekulationen bestätigt, die seit Veröffentlichung des beliebten XNA Game Studio 4.0 im Jahr 2010 immer lauter wurden.
; tldr
Dieser Artikel dient als Einstieg in die Entwicklung von 2D-Spielen mittels MonoGame. Innerhalb der Serie, dessen ersten Teil Sie hier lesen können, wird dazu auf ein Game Asset Pack mit Pixel-Art-Grafiken zurückgegriffen. Für den Anfang lernen Sie etwas über die Historie von MonoGame, installieren die notwendigen Programme und Tools und setzen im Anschluss nicht nur ein Basisprojekt auf, sondern lösen direkt eine erste Herausforderung: eine pixelgenaue Kamera!
OpenXNA und MonoGame
Shawn Hargreaves, ein ehemaliger Mitarbeiter von Microsoft und einer der ursprünglichen Entwickler von XNA, startete daraufhin das Projekt OpenXNA, um eine Open-Source-Alternative zu XNA bereitzustellen. Er wollte es Entwicklern ermöglichen, ihren bestehenden Code auf die OpenXNA-Bibliotheken umzustellen und idealerweise ohne weiteren Migra-tionsaufwand an ihren Projekten weiterarbeiten zu können.OpenXNA wurde später umbenannt in MonoGame, das von einer Gruppe von Enthusiasten und Entwicklern in der Open-Source-Community kontinuierlich bis heute weitergeführt wurde. Diverse Erweiterungen und Unterstützungen weiterer Plattformen kamen ebenfalls im Laufe der Jahre hinzu.Während die Kompatibilität zu Spielen, die noch mit XNA entwickelt wurden, in MonoGame unter anderem durch die Nutzung gleichlautender Namespaces sichergestellt und dadurch der Aufwand einer Migration bestehenden Codes vereinfacht wurde, während zugleich die Nutzung von XNA-Dokumentation und -Beispielen möglich war (und ist), verfolgt FNA wiederum ein etwas anderes Ziel.
Unvergessliches Kornblumenblau
Warum die Kornblume hier als Standard-Hintergrundfarbe im Template genutzt wird, hat im Grunde genommen keine Bedeutung. Es gibt dazu aber interessante Hinweise im Internet [12].
FNA
FNA steht für „FNA’s Not XNA“. Rekursive Akronyme sind besonders in der Linux-Welt beliebt, und der Begriff FNA kommt entsprechend nicht von ungefähr.Der Entwickler Ethan Lee hatte ursprünglich viel Erfahrung in der Portierung von Spielen auf die Linux-Plattform. Um eine möglichst nahtlose Unterstützung von Windows- und Xbox-Spielen, die mit XNA entwickelt wurden, für Linux zu realisieren, begann er 2015 mit der Entwicklung von FNA. Das Ziel: eine möglichst identische Implementierung von XNA ohne Änderungen im API.Die Idee ist es dabei entsprechend nicht, die Entwicklung neuer Spiele zu fördern (so wie es MonoGame tut), sondern bestehende Spiele einfach zu portieren. Eine der größten Unterscheidungen besteht daher darin, dass MonoGame ein eigenes Content-Pipeline-Tool anbietet, während FNA-Projekte darauf angewiesen sind, Content-Projekte weiterhin mit den original XNA-Tools zu bearbeiten.60 Frames per Second
Für den Moment ist es ansonsten vielleicht interessant zu wissen, dass MonoGame das Programm mit 60 Frames per Second (FPS) laufen lässt. Sprich: Der Code in der Methode <span class="CharOverride-1">Update</span> wird 60-mal pro Sekunde ausgeführt. Es gibt mehrere Diskussionen darüber, wie sinnvoll das ist und wie sich das umgehen ließe. Insbesondere in Spielen, die exzessive physikalische Berechnungen durchführen, kann es interessant sein, die Kopplung zwischen der Update- und der Draw-Methode aufzuheben und somit das Update auch häufiger als 60-mal in der Sekunde auszuführen.
Framework versus Engine
Warum ist es heute, im Jahr 2024, interessant, sich mit MonoGame zu beschäftigen, und was unterscheidet MonoGame von Produkten wie der Unreal Engine oder Unity?Letzteres zuerst: Unreal Engine und Unity sind Produkte, die sich als voll umfängliche Game-Engines verstehen. Sie verfügen über visuelle Editoren, Inspektoren, Echtzeitbearbeitung, Asset-Management, Game-Loop, Scripting-Integrationen und wirklich vieles mehr. Ähnlich wie bestimmte Game-Development-Toolkits sind sie darauf ausgelegt, praktisch sofort mit der Entwicklung bestimmter Spiele-Genres oder einfach allem, was möglich ist, loslegen zu können.MonoGame hingegen ist „nur“ ein Framework. Keine Engine. Der Unterschied ist leicht zu verstehen: Mit MonoGame ist man direkt am Code des Spiels und entwickelt nahezu alles selbst, während die bekannten Game-Engines das meiste bereits als Komponenten bereitstellen und tendenziell eher UI-getrieben sind.Ausgelöst durch den Versuch von Unity Technologies im Jahr 2023, das Lizenzmodell drastisch zu verändern, gab es allerdings einen Ruck in der Community – insbesondere (aber nicht ausschließlich) bei den Indie-Developern [1]. Zwar wurde der Großteil der geplanten Änderungen infolge dieses Aufschreis später wieder zurückgenommen, dennoch bleibt ein fader Nachgeschmack bei dem Gedanken an die Abhängigkeit und die möglichen Konsequenzen – über die sich viele zuvor kaum Gedanken gemacht hatten.Dieses Ereignis führte zu einer ungewöhnlichen Reaktion: Der Entwickler des beliebten 2D-Sandbox-Spiels Terraria, Re-Logic, kündigte am 19. September 2023 an, aufgrund des Vorgehens von Unity Technologies in die Open-Source-Szene zu investieren, damit die langfristige Unabhängigkeit von derartigen Unternehmen abgesichert sei [2].Konkret bedeutete dies, dass Re-Logic erklärte, sowohl der GoDot Game Engine wie auch FNA insgesamt jeweils 100 000 US-Dollar zu spenden, in Form von 1000 US-Dollar pro Monat. Dazu gab es nur eine Auflage: „Bleibt nett und macht, was ihr könnt, damit eure Produkte mächtig bleiben und für alle Entwickler verfügbar.“Auf die Frage aus der Community heraus, was das für MonoGame bedeute, ergänzte Re-Logic etwas später, dass auch geplant sei, die MonoGame-Entwicklung unter den gleichen Bedingungen zu fördern [3].Die zeitliche Differenz ergibt sich dadurch, dass das Team hinter MonoGame kurz nach der Ankündigung durch Unity Technologies seinerseits angekündigt hatte, die MonoGame Foundation zu gründen (um ebenfalls die zukünftige Open-Source-Entwicklung und sich zugleich das unbedingte Vertrauen durch die Community zu sichern). Re-Logic musste nun die Gründung der Foundation abwarten, um dann für die geplante Förderung die entsprechenden rechtlichen Belange berücksichtigen zu können.Bildung ist wichtig, und diesem Auftrag ist der Artikel bis hierher umfänglich nachgekommen: Die Historie von MonoGame ist nun bekannt (vergleiche auch Bild 1). Bevor es aber wirklich losgeht, soll an dieser Stelle noch ein letzter Motivationsschub folgen.
Die Historie von MonoGame im Überblick (Bild 1)
Autor
Einige sehr bekannte Spiele, die zum Teil auf verschiedensten Plattformen veröffentlicht wurden, basieren auf MonoGame. Die Showcase-Website [4] von MonoGame listet hier unter anderem folgende Spiele auf:
- Celeste
- RE Dungeon
- FEZ
- Skulls of the Shogun
- Stardew Valley
Celeste: Spielspaß durch perfekte Steuerung (Bild 2)
Autor
Einstieg
Nach so viel Geschichtsunterricht sollte nun ausreichend Motivation entstanden sein, um endlich in die Praxis zu gehen.Zu Beginn wird das MonoGame-Framework in seiner aktuellsten Version installiert. Zum Zeitpunkt der Erstellung dieses Artikels ist das Version 3.8.1, die am 26. Juli 2022 veröffentlicht wurde.Auf der Website führt der Link GETTING STARTED direkt zu ein paar Informationen, die einen wiederum dazu einladen, über den ersten Punkt Setting up your development environment alles herauszufinden, was man wissen muss, um MonoGame unter Windows, macOS und Linux einzurichten [8]. Dieser Artikel geht davon aus, dass Windows als Plattform genutzt wird und Visual Studio 2022 als Entwicklungsumgebung. Wer VS Code präferiert, findet Informationen dazu im Kasten Visual Studio Code als Alternative.Visual Studio Code als Alternative
Visual Studio ist mächtig. Und groß. Man könnte sogar behaupten, es sei mächtig groß. In einiger Hinsicht ist es daher auch oftmals spürbar träger als leichtgewichtigere Alternativen wie beispielsweise Visual Studio Code.
Insofern Visual Studio bereits installiert ist und dabei auch die .NET-Desktopentwicklungs-Workload berücksichtigt wurde, kann im Anschluss direkt die Erweiterung „MonoGame Framework C# Project Templates“ installiert werden.
Transformationsmatrizen
Ob 3D oder 2D: In Computerspielen werden viele Details auf der Grundlage einfacher Schulmathematik berechnet. Dazu gehört die Positionierung von Elementen wie zum Beispiel Sprites mittels Vektoren, aber auch Berechnungen, die sich auf die komplette Szene auswirken. Dabei müssen oft die genauen Positionen praktisch aller Elemente ermittelt werden, und das geschieht über Matrix-Kalkulationen.
Das erste MonoGame-Projekt
Das Aufsetzen eines MonoGame-Projekts ist denkbar einfach. Mit File | New | Project öffnen Sie wie gewohnt den bekannten Template-Browser und die Suche nach „MonoGame“ fördert verschiedene Vorlagen zutage.Für den Anfang wählen Sie Folgendes aus: MonoGame Cross-Platform Desktop Application. Nach Eingabe eines Projektnamens und Bestätigung via Create öffnet sich kurze Zeit später das neue Projekt, das über die MonoGame-typische Struktur verfügt.Zu diesem Zeitpunkt lohnt es sich, das Projekt der Form halber einmal zu starten. Das Ergebnis sollte ein Fenster sein mit einem kornblumenblauen Hintergrund (siehe Bild 3). Nicht sehr aufregend, aber das kommt schon noch.
Blau, so blau ... (Bild 3)
Autor
Die Struktur
Die Struktur des MonoGame-Projekt-Templates ist extrem simpel. Das liegt natürlich (auch) daran, dass es da noch nicht sehr viel gibt. Im Grunde genommen existiert lediglich eine Einstiegsklasse (Game1), deren Methode Run initial in Program.cs aufgerufen wird. Zwar gibt es im Verzeichnis Content noch eine Datei Content.mgcb, aber die ist derzeit noch leer, und damit passiert auch noch nichts. Also richtet sich die Aufmerksamkeit erst einmal auf die Datei Game1.cs und die darin enthaltene, gleichnamige Klasse Game1:
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
namespace MyMonoGameGame
{
public class Game1 : Game
{
private GraphicsDeviceManager _graphics;
private SpriteBatch _spriteBatch;
public Game1()
{
graphics = new GraphicsDeviceManager(this);
Content.RootDirectory =
“Content”;
IsMouseVisible = true;
}
protected override void
Initialize()
{
// your initialization
// logic here
base.Initialize();
}
protected override void
LoadContent()
{
spriteBatch = new SpriteBatch(
GraphicsDevice);
// load your game content
// here
}
protected override void
Update(GameTime gameTime)
{
if (GamePad.GetState(PlayerIndex.One)
.Buttons.Back == ButtonState.Pressed ||
Keyboard.GetState().IsKeyDown(Keys.Escape))
Exit();
// your update logic here
base.Update(gameTime);
}
protected override void Draw(GameTime gameTime)
{
GraphicsDevice.Clear(Color.CornflowerBlue);
// your drawing code here
base.Draw(gameTime);
}
}
}
Der Code ist sehr klar strukturiert und besteht im Wesentlichen aus den Komponenten LoadContent, Update und Draw.Ohne besonders viel über die Implementierung zu wissen, lässt sich bereits jetzt schon einmal aus dem Code herauslesen, dass der Mauszeiger sichtbar sein soll. Interessant ist an dieser Stelle übrigens vielmehr, dass man ihn offenbar sehr leicht unsichtbar machen kann (und warum das aktuell noch nicht sinnvoll ist, darauf wird später ebenfalls noch eingegangen).Darüber hinaus ist ebenfalls offensichtlich, dass es neben dem einmaligen Initialisieren und Laden von weiteren Inhalten (Assets) wohl so etwas wie eine Schleife geben muss, in der die Methoden Update und Draw kontinuierlich aufgerufen werden.Das ergibt sich allein schon daraus, dass es Sinn macht, alles, was im Spiel passiert, permanent in dessen Status und Verhalten zu aktualisieren, um die Ergebnisse im Anschluss zu rendern.Die Methode Update prüft, ob auf einem möglicherweise angeschlossenen GamePad der Back-Button oder auf dem Keyboard die Escape-Taste gedrückt wurde, und beendet daraufhin das Spiel; die Methode Draw färbt aktuell den Hintergrund in Kornblumenblau ein.Das folgende Diagramm zeigt den Ablauf inklusive der sogenannten RunLoop (oder auch GameLoop) einmal übersichtlich (siehe Bild 4).
Game1: Ablauf in der Übersicht (Bild 4)
Autor
SpriteBatch
Bevor der erste Artikel dieser MonoGame-Serie endet und insbesondere damit er sich nicht (nur) nach einer Geschichtsstunde anfühlt, gilt es, ganz zu Anfang noch ein wenig über ein wichtiges Thema zu sprechen: den SpriteBatch. Obwohl der SpriteBatch ehrlich gesagt für den Moment gar nicht so ausschlaggebend ist; es geht um etwas ganz anderes.Doch zunächst einmal eine kleine Testmethode:
private Texture2D GenerateRandomTexture(
GraphicsDevice graphicsDevice, int width, int height)
{
Random rnd = new Random();
var data = Enumerable.Range(0, width * height)
.Select(_ => new Color(rnd.Next(256),
.Next(256), rnd.Next(256)))
.ToArray();
var texture = new Texture2D(
graphicsDevice, width, height);
texture.SetData(data);
return texture;
}
Ergänzen Sie diese Methode in der Klasse Game1 ganz am Ende und bereiten Sie als Nächstes die Ausgabe vor. Im Kopfbereich der Klasse definieren Sie dafür zunächst ein PlayerSprite wie folgt:
Texture2D playerSprite;
In der Methode LoadContent erzeugen Sie als Nächstes den Player:
playerSprite = GenerateRandomTexture(
GraphicsDevice, 16, 16);
Um das Sprite nun anzuzeigen, erweitern Sie die Methode Draw vor dem Aufruf von base.Draw() um folgende Zeilen:
spriteBatch.Begin();
spriteBatch.Draw(
playerSprite, new Vector2(50, 50), Color.White);
spriteBatch.End();
Sie erinnern sich an die versprochene Herausforderung? Wenn Sie das Spiel nun starten, bekommen Sie vielleicht bereits eine Idee davon (siehe Bild 5).
Die orthografische Kamera (Bild 6)
Autor
Das Sprite ist bewusst mit 16 x 16 Pixeln sehr klein angelegt. Das liegt daran, dass diese Artikelserie mit einem sogenannten Asset Pack arbeiten wird, das in Pixel-Optik entwickelt wurde und praktisch alles enthält, was man benötigt, um mit der Entwicklung von Spielen loslegen zu können (mehr dazu in der nächsten Folge). Für den Moment genügt es zu wissen, dass die Sprites darin mit 16 x 16 Pixeln bemessen sind und das im Vergleich zu einem Fenster, das vielleicht 1280 x 720 Pixel groß ist, nun … sehr klein ist.Die naheliegende Lösung: Heranzoomen. Doch dazu müssen wir uns zunächst erst einmal mit dem Thema „Kamera“ beschäftigen.
Vor oder hinter der Kamera
Ganz gleich, ob Sie ein 3D- oder ein 2D-Spiel entwickeln: Der Spieler sitzt vor dem Display (hinter der Kamera) und schaut wie durch ein Fenster in eine virtuelle Welt hinein. Dieser Blickwinkel kann dabei verstanden werden wie der Blick aus der Perspektive einer Kamera. Und diese kann – genau wie eine echte – verschiedene Einstellungen haben, die sich darauf auswirken, wie nah die betrachteten Objekte erscheinen, welche Objekte sich im Sichtfeld befinden und so weiter (siehe Bild 6).
Ja, wo ist es denn, das Sprite? (Bild 5)
Autor
Dabei ist es insbesondere wichtig, einen Weg zu finden, die Szenen so auf den Bildschirm zu bringen (zu rendern), dass das Spiel unabhängig von der vom Benutzer gewählten Bildschirmauflösung funktioniert – und dabei gut aussieht (was auch immer „gut“ in diesem Kontext bedeutet).Das Thema wird uns später noch begegnen. Im Moment nehmen wir erst einmal eine kleine Abkürzung und machen uns die Arbeit Dritter zunutze.Dazu installieren Sie in dem Projekt das NuGet-Paket MonoGame.Extended.Graphics. Aus Gründen, die später wichtig werden, werden Sie diese Bibliothek in Folgeartikeln voraussichtlich aus den Quellen selbst kompilieren. Zum jetzigen Zeitpunkt genügt allerdings das fertige NuGet-Paket.Nutzen Sie dazu den NuGet Package Manager oder geben Sie alternativ dazu in der NuGet-Package-Manager-Konsole von Visual Studio folgende Befehlszeile ein:
Install-Package MonoGame.Extended.Graphics MonoGame.Extended
Bei MonoGame.Extended handelt es sich um eine Sammlung von Bibliotheken, die Funktionalitäten bereithalten, die das MonoGame-Framework um sinnvolle und regelmäßig in der Entwicklung benötigte Funktionen ergänzen. Während es zwar für praktisch alle darin enthaltenen Komponenten auch Alternativen und zum Teil spezialisierte Lösungen gibt, mag ich persönlich MonoGame.Extended allein schon deshalb, weil die meisten Anforderungen, die ich an MonoGame haben könnte, hier in einem Produkt enthalten sind – und das aus einem Guss.Hier einige Beispiele für die Features, die MonoGame.Extended zu bieten hat: Tweening, Tiles, Screen-Management, Particles, Object-Pooling, Input, Graphics, Entities, Animations, Collisions und einiges mehr [9]. Das, was uns jetzt erst einmal interessiert, ist aber der Kamera-Support.Perfekt geeignet für die Entwicklung von 2D-Spielen ist die darin enthaltene orthografische Kamera. Orthografisch deshalb, weil dieses Spiel als 2D-Spiel mit einer ausschließlich rechtwinkligen Draufsicht konzipiert wird. Plus: Sie enthält bereits die notwendigen Transformationsmatrizen, die für das korrekte Rendern von SpriteBatches notwendig sind.Nach der Definition des SpriteBatchs zu Beginn der Klasse Game1 ergänzen Sie nun die orthografische Kamera:
private OrthographicCamera _camera;
In der Methode Initialize, vor base.Initialize, erzeugen Sie einen sogenannten Viewport Adapter und initialisieren damit die Kamera:
var viewportAdapter = new BoxingViewportAdapter(
Window, GraphicsDevice, 320, 180);
camera = new OrthographicCamera(viewportAdapter);
Die benötigte Transformationsmatrix erzeugen Sie nun in der Draw-Methode und übergeben sie dem SpriteBatch:
var transformMatrix = _camera.GetViewMatrix();
spriteBatch.Begin(transformMatrix: transformMatrix);
Aufgrund der Konfiguration des Viewports mit 320 x 180 Pixeln ist nun festgelegt, dass wir in unserem Fenster praktisch eine Auflösung von 320 x 180 Pixeln darstellen wollen – und zwar unabhängig davon, wie groß die Auflösung des Displays tatsächlich ist.Das sorgt automatisch dafür, dass das Test-Sprite von eben größer gerendert wird als zuvor, und das Ergebnis sollten wir uns einmal näher ansehen (Bild 7): „Pixelperfect“ ist etwas anderes, keine Frage.
Das ist noch suboptimal (Bild 7)
Autor
Nebenbei: Andere Tutorials haben zu diesem Zeitpunkt bereits perfekt auf das Ziel abgestimmte Grafiken geladen und zeigen Ihnen, wie Sie Ihre Spielfigur mit der Tastatur steuern können. Doch spätestens sobald Sie eigene Assets verwenden möchten oder vom Tutorial abweichen, fällt Ihnen genau dieses Problem auf die Füße.Denn irgendetwas ist hier schiefgelaufen, und damit die nächsten Teile dieser Artikelserie sich auf die jeweiligen Themen konzentrieren können (zum Beispiel Asset-Management und das Steuern Ihrer Spielfigur mit der Tastatur), gilt es zunächst, sich das Thema „Sampling“ etwas anzuschauen.
Sampling
Natürlich ist es für das Framework erforderlich zu wissen, wie genau die Spielobjekte „näher herangeholt“ werden sollen – oder weiter weg dargestellt. Letzten Endes sprechen wir hier weiterhin von Pixeln. Ob diese noch sichtbar sind, je weiter sie sich von der Kamera entfernen, ist abhängig davon, was für eine Bildschirmauflösung eingestellt ist. Doch wenn sie näher herangeholt werden, müssen sie vergrößert werden. Und dafür gibt es verschiedene Methoden.Die Standardmethode dazu implementiert eine lineare Interpolation. Das Ergebnis ist für Bilder sicher nicht verkehrt, führt aber bei starker Vergrößerung zu einer gewissen Unschärfe (deshalb finden sich im Internet übrigens immer mehr Onlinedienste basierend auf KI-Modellen, die sich auf das Thema „Upscaling“ verstehen).In diesem Beispiel erkennen Sie das Problem sehr deutlich, da das Ausgangmaterial aus einzelnen Pixeln besteht. Das Wort „Matsch“ wäre ebenfalls eine adäquate Beschreibung.Was Sie an dieser Stelle benötigen, ist ein punktbasiertes Sampling, damit das Ergebnis „pixelperfect“ ist. Das erreichen Sie, indem Sie der Begin-Methode vom SpriteBatch den gewünschten Algorithmus übergeben. Der Default-Wert lautet hier nämlich SamplerState.LinearClamp.Was Sie stattdessen benötigen, nennt sich SamplerState.PointClamp:
spriteBatch.Begin(transformMatrix: transformMatrix,
samplerState: SamplerState.PointClamp);
Und schon sind die Pixel wieder erkennbar, wie Sie in Bild 8 und Bild 9 sehen können.
Von unscharf ... (Bild 8)
Autor
… zu pixelperfect (Bild 9)
Autor
Fazit
Mit MonoGame haben Sie einen einfachen und kostenfreien Zugriff auf ein umfangreiches Game-Development-Framework, mit dem zahlreiche bekannte und sehr erfolgreiche Spiele nicht nur in der Vergangenheit, sondern auch heute entwickelt wurden und werden.Während Engines wie Unity oder Unreal Engine sich als das All-inclusive-Paket für die Entwicklung hochkomplexer Anwendungen und Spiele verstehen und dafür alle Mittel bereithalten, konzentrieren Sie sich mit MonoGame darauf, Ihr Spiel im Kern zu verstehen und zu entwickeln.Dabei brauchen Sie dennoch nicht auf Komfort zu verzichten: Mit Visual Studio nutzen Sie eine hochmoderne Entwicklungsumgebung und unzählige Erweiterungen sowie spezialisierte Bibliotheken, die MonoGame um Möglichkeiten ergänzen, die praktisch alle Ihre Wünsche erfüllen.In den folgenden Artikeln wird auf das bisher Gelernte aufgesetzt, und Sie lernen alles, was Sie wissen müssen, um passende Assets im Internet zu finden, sie zu laden, Sprites zu steuern, eine Kamera zu implementieren, Levels zu designen, Musik und Soundeffekte zu integrieren und vieles mehr.Wir treffen uns wieder zum zweiten Teil dieser Serie! Bis dahin kann es sich lohnen, sich am Discord-Server des MonoGame-Teams anzumelden und zumindest schon einmal als stiller Beobachter mitzulesen [10]. Hier finden Sie eine aktive und extrem hilfreiche Gemeinde sowie viele aktuelle und spannende Projekte.Fussnoten
- [1] Dominic Holzer auf BR24 zur Unity Engine, http://www.dotnetpro.de/SL2406MonoGame1
- [2] X, Re-Logic zu Investitionen in die Open-Source-Szene, http://www.dotnetpro.de/SL2406MonoGame2
- [3] X, Re-Logic zur Unterstützung von MonoGame, http://www.dotnetpro.de/SL2406MonoGame3
- [4] MonoGame Showcase, http://www.dotnetpro.de/SL2406MonoGame4
- [5] ARD Mediathek, Indie Game: The Movie, http://www.dotnetpro.de/SL2406MonoGame5
- [6] YouTube, Warum fühlt es sich so gut an, Celeste zu spielen?, http://www.dotnetpro.de/SL2406MonoGame6
- [7] NoelFB, Celeste-Code auf GitHub, http://www.dotnetpro.de/SL2406MonoGame7
- [8] MonoGame, Setting up your development environment for Windows, http://www.dotnetpro.de/SL2406MonoGame8
- [9] MonoGame.Extended, http://www.dotnetpro.de/SL2406MonoGame9
- MonoGame Discord, http://www.dotnetpro.de/SL2406MonoGame10
- Developing with Visual Studio Code, http://www.dotnetpro.de/SL2406MonoGame11
- Christine Amrhein, Unvergessliches Kornblumenblau, http://www.dotnetpro.de/SL2406MonoGame12
- YouTube, The Math behind (most) 3D games, http://www.dotnetpro.de/SL2406MonoGame13
