My experience with Dear ImGui and thoughts about boring UI

What is ImGui?

ImGui is yet another a small C++ UI library.
What makes it different from most other UI libraries, tho, is the way you define
widgets with it. Let’s take a look at a basic example: I want a button, that logs something
to console when pressed.

Usual UI libraries would request you to do something like this:

static UiButton* button;

void initGame() {
    button = Ui::getContext()->createButton("Click me!");
    button.sayOnClick("Thanks <3");
}

void updateGame(float dt) {
    button.update(dt);
}

void renderGame() {
    button.render();
}

And here is the ImGui variant:

void renderGame() {
    if (ImGui::Button("Click me!")) {
        std::cout << "Thanks <3\n";
    }
}

Live demo, might take some time to load

I think you see, why this is so handy for prototyping UI really fast. And the API obviously doesn’t end
with buttons. ImGui features context menus, windows, sliders, text inputs, tags, and much more
than you can probably think of. And that all still in this simple form, bloat free (without having to store anything anywhere).

Really neat!

Burning Knight and ImGui

But as you know, I did not touch any C++ code for a few years now, and my current project is written in C#. So I never thought of using ImGui, until a few days ago, I saw yet another post on twitter featuring the library.

And then it struck me: there gotta be a way to wrap it for C#! In fact, some awesome guys already
wrote a wrapper for Net (that has support for Monogame too <3). Funny enough, the wrapper is based on a C wrapper of C++ based
ImGui. But it works well none-the-less.

UI in Burning Knight

I never liked UI coding, to be honest. Even tho, I started my programming with HTML and CSS (and that was a terrible mistake, but I had no one around to correct me), and I still use those languages a lot these days (like for this website, Burning Knight website and Ord website), I always thought that creating UI
takes too much effort.

Recently I started to take a smarter way going around usual UI I put in my PICO-8 games: I usually have this boooring
label, in the beginning, yielding at players Press X or something like that. With PICO-8 it’s not too much work to add such a prompt, but I found a much more interesting way to make menus (or you can say lazy if you will):

Pull!!!
Antiban

Because most of my games are level based, this requires almost no work, plus serves as a tutorial and a replacement for usually boring prompt.

So then I thought: why not to throw more UI stuff away? There was nothing left to throw out from my PICO-8 games, so I moved to Burning Knight :smirk:

Here it was even easier for me to decide against boring UI and move to in-game object interactions because UI required much more code (because with PICO-8 I use flexible dynamic-typed Lua and for Burning Knight – rigid but stable static-typed C#).

So now we can count the UI elements with fingers:

  • Player health display
  • Player lamp/active item display
  • Player ammo display
  • Rare label for item description (and it might get moved into in-game object soon too)

The need for UI that comes after throwing all UI out

Ok, so why do I need a UI library, if I’m throwing away most of the UI anyway?
Well, it’s important to note here: I’m throwing game UI, that part of UI, that all players will see.
But there is also a secret part of UI: all sorts of different editors that help to make the content for the game, as well as debug it. (Well, the tools are going to be a part of the workshop, so not so secret, but still)

I was going to talk about all the tools I made for Burning Knight, but the list started getting too long, and this post is already huge. But just in case you are curious, here is a small list:

  • Level editor
  • Dialog editor
  • Locale editor
  • Area debug view
  • Console
  • Save file explorer
  • Debug window
  • Item editor

And there is a 99% chance that I forgot something. But that’s not the point.

The point is, that making all those tools with default UI libraries would take months. But that was not the case with ImGui. All the tools listed above were developed under a week. But take into the account that I’ve been heavily traveling most of that time, and busy helping out with 2 other projects.

But why make tools for a specific game? Well just because it saves so much time! And it’s also saved me tons of brain cells. Editing items with UI is so much faster and safer than with JSON.

To wrap it up

So, to wrap things up: what ImGui is a good choice for and what it is not?

ImGui rocks if:

  • You need to make quick tools
  • You don’t care about the looks

But it won’t work so well if:

  • You need UI to look great
  • You need ultra complex UI

So yeah! I hope this post might help someone one day, but until then, take care!
Psss, Burning Knight devlog soon! 😉

You might also find interesting

Join the discussion!