Mono Game UI

1

I am about to begin work on the UI portion of my game and I have a few questions to get started. First, should I make my own UI system or should I find a library that does it for me? If the latter which libraries should I use? Also if you have any other tips they would be helpful. This is something I haven’t had to do yet and any help would be welcome.

2

Depends on your needs. I’ve lately become an advocate of doing the minimum necessary to achieve your goals… I know I’ve found myself spending a lot of time creating things I don’t need and in the last few years I’ve really been trying to stop that :smiley:

So if you need a very light weight UI, just create your own. Make sure you put everything behind interfaces and design it well though because if your needs change, you can always just create another implementation that wraps a more extensive UI package.

If you want something involved, there are a lot of libraries other people have created which I’m sure will work for you. I picked this one off the front page of this forum.

Good luck!

3

Reason to make your own:

  1. You want to learn how.
  2. You like building UIs.
  3. You couldn’t find anything that suit your needs.

Unless 1 or 2 are true, I think you should start by trying out existing solutions (but first try to figure out what exactly do you need from the UI, because once you start with something its hard to switch to something else). You can find some options in this ancient thread:

And here’s my shameless self promotion because why not:

:slight_smile:

1 Like
4

There are quite a few UI options if you want to use something existing.

There’s also the not so well known:

  • ImGui.Net Port
    • Immediate-mode is actually really nasty to use in C# since C# is a bumbling idiot with variable declarations (no statics in methods, obnoxious ref/out qualifiers, etc)
    • Stuff in Git is incomplete, I’ve completed but haven’t put my changes onto git or submitted a PR to the original author
    • There are wrapper ports out there too, I’m not listing them because wrappers are tedious to do any extensive changes in the guts … and DearIMGUI is not out of the box usable in any form
  • WPFLight
    • Heavy-weight
    • Missing quite a few controls one might expect in anything WPF
      • With the exception of datagrids those are all easily done (and actually are done as such in WPF) via specialized ItemsControls anyways
5

I think it could be a lot nicer with C#7 features. Not sure what you mean by statics in methods. If out is used to return multiple values it can be replaced with tuples, which can be deconstructed by the caller.

I really like to use ImGui for in-game tools. It’s easy to use and very quick to get some stuff on screen. For game UI I usually write my own stuff, but I’ve never done anything UI heavy.

6

Not sure what you mean by statics in methods.

You can slap a static bool myVar = false inside of a function/method in C++. The initialization will only occur the first time the function is called. It’s useful for all of those state variables that are mostly throw-aways but needed. As long as it’s a big “I do this window” function they’re harmless.

All of the IMGUI code I’ve written in C# has ended up with a big block of bools and ints just for storing state that is nothing but mandatory garbage.

Could just be me though.

I really like to use ImGui for in-game tools. It’s easy to use and very quick to get some stuff on screen. For game UI I usually write my own stuff, but I’ve never done anything UI heavy.

I love it for tools and anything with heavy databinding or threading issues. It’s usually a pain to keep a UI in sync when there’s threading or multiple occurences of the same field (properties view + data-grid view + name-in-scene-tree, etc) In an IMGUI it mostly just works since it’s rebuilt constantly or frequently enough. Which is a welcome reprieve from QT and MFC’s usual woes.

1 Like
7

Could be worth a try

1 Like