Episode 0: Which game? Why MonoGame?

Hello!👋

This "zeroth" episode of my devlog series is made for those people who want to know about the background of my project; how I came up with it, what my initial thoughts were, what I did before etc.

If you'd rather start right away with the project itself, I'd recommend starting with Episode 1 of the series.

Every beginning is difficult

Most people who are interested in game development know that most of the time it's a difficult and tedious process, that also requires a good amount of experience to be carried out effectively; I thought the same and of course, it's true.

What I didn't expect was how much time you need for it even before the actual coding starts. In my case, there were two major questions to answer:

1. Which game do I want to create?

2. What technology do I want to use?

Simple questions that are difficult to answer. Let's dive deeper into them.

What do I want to create?

What I'm most fascinated about are simulations. So I already knew that would be a major aspect of my game: an environment that can run without the need for player input. Just like the world we live in. It exists and evolves, even when we do nothing.

There are some more things I usually like in games:

• Medieval setting (with a bit of fantasy maybe?)

• City building

• Life simulation

• Roleplay

I think what is mostly forgotten is a quite simple pleasure: Sit back and relax. Sometimes love to let the game run for itself. Then I just observe what happens, follow a character in their daily routine, and find interesting or funny details in the world. I know exactly one game that offers all these things:

Dwarf Fortress.

People who know it will think: "Kev, forget it. Dwarf Fortress is one of the best and most complex games in existence. And it's developed for decades."
Those people I want to say: You are right. But let me explain what I think about this.

Most professional game developers suggest that newcomers start small. By doing so, you learn how to finish projects. I am a software developer by profession. With this, I'm used to working on large projects. Within these projects, I finish many smaller or bigger subprojects like bug fixes, feature requests or extensions. "Grim Veil" as my primary free time project can be a bit more ambitious I think. And even if it goes on for many years and isn't finished within the next decade, so be it!

So the first question is answered.

What do I want to create? A construction and management simulation with RPG elements that takes place in a medieval setting.

How do I want to create it?

In the last few years, I experimented with different approaches to develop a game or a similar program. I'm very familiar and comfortable with C#, so I have several technologies to choose from.

Here is a list of my tries and why they failed.

1. Unity
   Unity is a great engine, especially for newcomers like I was. Its main scripting language is C#, so should be great for me. However, the problem I stumbled upon affects every bigger game engine: It offers too many features. That might sound strange, but in my case, developing a feature happened to become more research for possibilities Unity offers than programming. That's not fun for me.

2. OpenTK
   The Open Toolkit Library is a graphics framework that offers C# wrappers for OpenGL, OpenAL & OpenCL. With the help of its tutorials, I created my own toolset to render simple 3D scenes. I thought, with this, I could create real games and say "I created this game completely from scratch, without any game engine. Look how cool I am!". But I was not up for the task. My code grew into a mess, I became demotivated and dropped the project. Besides that, I always felt like working with outdated technology, since OpenGL more or less was replaced by Vulkan.

3. SharpDX
   Just like OpenTK, this is a C# wrapper, but for the DirectX graphics API. With this, I didn't even manage to draw a single triangle. Maybe I spent too little time understanding it, nevertheless, for me the documentation seems to be worse than OpenTK's.

4. VulkanSharp
   Again just a C# wrapper, this time for the Vulkan API. Here I didn't even get the initialization finished.

All these attempts and failures led me to a conclusion: I need a technology, that lets me be independent from a game engine's ecosystem but doesn't force me to take care of all these low-level graphic card operations. Now I finally found it:

MonoGame

It is a reimplementation of the discontinued Microsoft's XNA Framework, and it provides the following features:

• Game Framework

• 2D and 3D rendering

• Sound effects and music playback

• Keyboard, mouse, touch, and controller inputs

• Content building and optimization

• Math library optimized for games

Quote from https://monogame.net/articles/index.html

With Monogame, I have the freedom to create my own ecosystem and only implement functionality when I need it. Like this, I avoid the feature overkill from the bigger game engines. If you want to know more about it, check out the link above or one of the many tutorials on YouTube.

So the second question is answered.

How do I want to create it? I will use MonoGame as the game's main framework.

Conclusion and future

So that's what is going to happen in the future. Creating a Dwarf-Fortress-like game based on the MonoGame framework.

But of course, I don't simply want to recreate it one-to-one. There are things about Dwarf Fortress that bother me. For example, it's so strictly tile-based that no smooth animations and no smooth camera are possible. Same as the UI. As far as I know, the whole presentation layer is tile-based, so the UI has similar restrictions.

Also, I want to alter the setting a bit. Dwarfs are cool to play, but I prefer playing humans. So some systems need to be adjusted. Dwarfs dig their fortresses into the mountains and underground. Humans build upwards. These are things I want to tackle.

So stay tuned for the future.

See you in the next episode.