One of the necessary evils in game development is designing and implementing a game's UI. There are a few UI frameworks used by developers that don't want to write their own from scratch. Sometimes choosing a framework is relatively easy if you're working within an existing game engine like Unity; these engines often have a few well-documented and popular frameworks.
Now I chose to write a game engine "from scratch" in C++, a decision I'll go into in another post. Of course writing an engine from scratch doesn't mean we can't chose existing libraries as a basis. As a solo developer I hardly have the luxury of writing my own engine, much less implementing every single system from scratch. Still, most DIY developers resort to writing UI from the ground up. Using OS specific frameworks usually aren't options; UI is about both look and functionality, and we usually want games to have their own look instead of having one imposed on us by Windows, OS X or Linux.
My project's needs include a robust in-game UI for editing levels. This rules out writing a separate editor tool application in C# or Qt. If you're a veteran game developer, you've probably figured out what I chose (hint: IMGUI or Immediate-Mode GUI.) If not, then I suggest you check out this popular talk by Casey Muratori1 on the subject.
In short, with IMGUI layout and input/output occur at the same location in application code without need for delegating widget events to listeners that decouple layout from controller logic (kind of flies in the face of MVC patterns.)
Over a decade ago I wrote 'retained-mode' UIs for a couple PC titles, modeling the APIs against old-school frameworks like MFC or Qt. Think deep class hierarchies with Window and Control base classes, messages, signaling, etc. Back in those days (we're talking pre- Scaleform)2 there were few options for games - you wrote your own UI. After about a month spent writing such a framework, you can get some good results. Once the system was alpha quality, adding and theming UI to our game was pretty trivial. But then a couple years ago this new "Immediate-Mode" approach has kind of taken over Game UI. There are even a couple great implementations I'll describe later.
Honestly though I don't have a horse in this game of which is better: retained vs immediate mode GUI. The argument that one is 'easier' to grok than the other relies on the programmer's experience. If you've written any client-side application using events or signals, it's not that much of a leap to use retained-mode GUI frameworks that rely on them. A well-written framework regardless of methodology will only help developer productivity. And many of the complaints people had about retained-mode GUIs, using listener classes or delegate methods, are mitigated somewhat in C++ if you're using lambdas and functors. I also believe that IMGUI was written in part as a reaction to legacy C/C++, which had lacked any grammar for closures, being the dominant game development language at the time.
For my current project I ruled out commercial solutions like Scaleform. I'd used Scaleform at a couple companies with flash developers and it worked out pretty well. For triple-AAA it's a decent solution, but otherwise is impractical for indie-development IMO. Finally one requirement I have is that any libraries or external code my project uses should be open-source with a permissive license.
I also looked at retained-mode solutions like CEGUI3 . But after some investigation their framework was very much like ones I'd written in the past - deep and wide class hierarchies. Inheritance was a programming style I preferred over a decade ago, but it's not one I try to use today. And another rule I have about using open-source libraries is that I have to like (or at least understand enough to easily modify) their code. One thing I liked about retained-mode solutions, including CEGUI, is their templating capability - data-driven, configuration based GUI layout. Typically these frameworks use XML files for such configuration.
Around 2010 I'd freelanced on a couple web projects and wondered if there were UI frameworks available that used HTML and CSS for their layout schema. There were a couple commercial and open-source frameworks available that basically allows you to embed an HTML/CSS/JS browser component into an application. Awesomium4 perhaps is the best free for under low-budget titles example. Of course, if you're looking for an open source HTML/CSS native framework your choices are much more limited. Chromium is an option, but using V8 or other JIT compiled JS engines isnt permitted on many platforms due to security issues.
When I needed to add some UI to my latest game project, I decided to try the IMGUI approach. My goal was to embed a level editor within the game, and needed a rich UI solution for this (think trees, dropdown menus, popups, etc.) I'd found a qualifying framework called OUI6, based on the NanoVG7 vector graphics library developed by Mikko Mononen (creator of Recast/Detour among other powerful C based game libraries.)
Like all IMGUI libraries, OUI requires that the application build the UI once per frame. Rendering either occurs immediately during layout, or is deferred to a separate render call that processes a list of rendering commands generated during layout. The application supplies the UI state for the current frame, and the IMGUI framework handles the processing and calls the necessary high level rendering methods like drawing box or a text string. My problem with the OUI framework is that it still relies on application supplied event handlers. OUI itself is a minimal framework for UI. It handles widget focus and delegating input events, but the application still needs to write any higher-level widget or rendering logic. For example, OUI does not supply a listbox or menu widget - the application writer must implement this using the OUI framework.
At some point in this game's development, I'll have to implement custom widgets and will likely write my own dedicated IMGUI solution. But for an editor's GUI I needed a comprehensive solution. The retained-mode GUIs mentioned above may fit my requirements, but when it comes to code size they're overkill for my tastes.
So I chose a popular IMGUI framework called "Dear Imgui"8 which seems to have it all. It fulfills the requirements for an IMGUI that I paraphrased above; layout and UI state are defined and read 'immediately' instead of communicated via signal handlers. It's also a fully-featured GUI.
After a day I was able to integrate Dear Imgui and add some basic functionality to my level editor.
Scaleform is a popular SDK from Autodesk, allowing SWF playback from within native applications. UI layout and logic are authored in Flash. Scaleform is used by many AAA game studios and has a significant licensing fee. http://www.autodesk.com/products/scaleform/overview ↩
Awesomnium is a commercial C++ SDK providing browser functionality from within a native client. It has a free option for low-budget/income titles, but otherwise requires you to purchase a license if you're going to sell your title. http://www.awesomium.com ↩