Apos.Gui - UI library for MonoGame

1

I’ve been creating a game using MonoGame. I have separated the UI code into it’s own library so that it can be used by other games.

The advantage of using this UI library is that:

  • it’s designed to handle any input scheme. If you want your UI to handle mouse, keyboard, gamepad, touchscreens, or anything else that you can think of, it’s generally easy to do.
  • it handles UI scaling. Makes it easier to work with 2k or 4k screens.
  • it’s easy to modify the base components to match the look and style of your game.
  • it supports animations.
  • it’s easy to disable inputs on specific components or the whole UI.

There’s some information about the library’s design in the wiki: GUI design choices.

I’m also working on an API documentation website that can be found here: API.

Some tutorials have been written in the wiki for example: Tutorial 01

Full example code can be examined in my AposGameStarter. Specifically, look inside the Menu.cs file.

I use this library in my own game where I created an in game map editor. This lets me pop into the level editor, modify my levels and pop right back into the game to play what I just modified / created. This makes it possible for me to create my game from inside the game.

I’m sure I’m forgetting stuff, but I’ll be around to answer questions.

Don’t let the gif deceive you, you can style the UI to match your game’s graphics.

4 Likes
2

I released a new version today. It’s a complete rewrite into a more IMGUI paradigm.

Panel.Push();
if (Button.Put("Show fun").Clicked) {
    _showFun = !_showFun;
}
if (_showFun) {
    Label.Put("This is fun!");
}
if (Button.Put("Quit").Clicked) {
    Exit();
}
Panel.Pop();

An example menu can be seen here: https://github.com/Apostolique/AposGameStarter/blob/main/Game/Menu.cs.

Unlike Dear IMGUI, the goal for this one is to build user facing UIs.

4 Likes
3

I just published version 2.0.0 of the library. This version reworks the UI lifecycle slightly. Now the layout is done at the end of the update loop instead of at the start.

image
image843×541 21.9 KB

This cleans up a lot of the logic. In the past, updates that would invalidate the layout would need to be delayed until the start of the next update loop to prevent flickers before the draw.