I made a game engine and built an RPG on top of it in Java for a course I teach, which can be found here: https://github.com/a-r-t/SER-225-Game-RPG. That Java game is built using Java Swing, which isn't an actual game framework. A lot of my inspiration for it came from my past experiences with Monogame, so I figured why not port it over to Monogame itself. I might use it in the future to make a game...if I ever have free time. But it is free and open for anyone else to use.
Install .NET 8.0 from here if not already installed.
- Install Visual Studio Community Edition, NOT Visual Studio Code, from here if not already installed.
- Open the project solution file (
Monogame-RPG-Engine.sln) in Visual Studio and it should handle everything else from there for you as far as opening up the project, restoring external libraries, etc.
After opening the project successfully, you should be able to run the game and play my fun little cat RPG identical to the Java version. Just make sure the dropdown says 'Debug' instead of 'Release' for shorter build times.
In the same dropdown where you selected 'Debug', select 'Release' and run the game again.
Since Visual Studio is now unsupported by Microsoft on MacOS, we have to get a little creative when running the project. By getting creative, I really mean using the command line.
- Run
dotnet restoreto download all of the necessary libraries and tools.
- Run
dotnet build. This will place a development build inbin/Debug/net6.0. - Ensure you're in the
net6.0directory, then run./Monogame-RPG-Engine.
Currently, the project builds in a mess of folders and directories, but it runs! This will guide you through the current process of getting an almost distributable version of the project built.
- Run the command
dotnet publish -r osx-x64 -c Release /p:PublishSingleFile=true. This will place the final set of files tobin/Release/net6.0/osx-x64/publish. - Ensure you are in the
publishdirectory, then run./Monogame-RPG-Engine. This will run the executable in the correct folder, so all of the references within the code work properly.
There are two main parts of this project: the game engine and the game that's built on top of it.
The game engine is inside the Engine folder, while the game itself is in the App folder.
All content (graphics, font, etc.) is inside the Content folder.
If you were to want to create your own game out of this, you can pattern match against the way my game in the App folder is made and the way it uses the engine,
and then once remove all of my stuff and do your own thing.
I recommend leaving the Engine folder alone until you get to the point where you need to add support for something.
This is a BASIC 2D RPG game engine with a fixed timestep; a lot can be done with it and it is very flexible/expandable, but it is not going to pump out an AAA game out-of-the-box.
For documentation on how the engine/game works, the Java version's docs here should suffice. There are several differences/inconsistencies here and there due to the different tech stack, but the vast majority of it is still relevant and useful.
The actual game itself is the same as the Java version, but I had to change the engine here and there to be more compatible with Monogame. Frankly the engine runs so much better now that it is actually backed by an actual game framework hahaha.
If you are new to Monogame or game dev in general, the patterns around content (loading, pipeline, unloading, etc.) may be confusing at first, but essentially the goal of any game is to manage content (e.g. graphics, sounds, fonts) as efficiently as possible. This includes aiming for the fastest load time possible, only load what is needed, leaving the lowest memory footprint possible, and just overall being strategic with how/where/when content is being managed.
This project uses a library called Nopipeline, which allows for writing a config file and automatically configuring the content pipeline vs having to use the terrible built-in content poipeline tool.
The configuration for the "no pipeline" library is the Content/Content.npl file.
This project also uses a font library FontStashSharp for loading/rendering fonts, because...well Monogame's SpriteFont leaves a lot to be desired. This engine has built-in support for FontStashSharp type fonts. I also implemented SpriteFont support into the engine just because they are "tried and true", but the FontStashSharp font rending is just so much better, I highly recommend using it over generic SpriteFonts.
The actual "main" method is inside the App/Main/Run.cs file.
Inside the Engine/Core folder is a GameLoop.cs file which is essentially Monogame's "entry point".
This is what kicks off the game loop cycle (update/draw).
Oh and I guess I should mention that this project is written in C#, not Java, so yeah that's a pretty big difference.
There is still a lot of refactoring I need to do to the engine, and improvements/more features I want to work on as well. ...And some project/code clean up. We'll see if I ever get around to it, but feel free to contribute if you are interested!