I need a GUI library. RPGs require a robust user interface. I've attempted to write my own GUI systems in the past and this has killed many a project. There was always something I didn't anticipate and couldn't work into my existing design. General application frameworks like Qt typically aren't suited for games due to performance needs and the custom graphics games usually demand (and in Qt's case I'm unsure about installing a whole development framework that rivals .NET and the Java SDK just for a GUI).
My own project has specific constraints that limit what libraries I can use.
- My game is a hobby project that will be freeware. I'm not getting paid for this game so I can hardly justify paying money for any library or toolkit.
- My game will be open source. Sine I'm not making money off this game, I might as well not hog the source code. I'm eventually going to put my game up on my Bitbucket account. I actually have a completed game there already, developed with Love. For faintly obvious reasons, I'm going to have a bias for open source libraries
- I have to worry about the specific license of any library I use. I normally use the Apache 2.0 License for my own projects and I lean towards BSD/MIT/zlib(/Apache) style licenses for third party libraries. Lots to keep track of.
- I'm developing on a Mac and intend to release my game for Mac and Windows; the Windows port mainly a courtesy of my ability to dual boot. Any library I use ought to be compilable on Mac computers, which usually means C/C++.
Beyond that, any library I use would hopefully be well established and actively maintained. Something that's not only available on someone's university web page that hasn't been updated since 1999.
Web searching has left me with a small pool of candidate libraries: CEGUI, SFGUI, Berkelium, GWEN, and libRocket. Each one falls short in at least one aspect for my project. They might not fall short for your project, but I'm still left wanting.CEGUI
Arguably the final word on open source, C++ based, game oriented GUIs. Beyond handling widgets and input logic, CEGUI also does its own rendering (with a choice of built-in renderers) and handles all of its resource loading and management. For a library meant to be used in other multimedia applications, I don't consider this a plus.
I would prefer to have an interface I could write against so that CEGUI goes through my game's rendering and resource management system instead of working in its own universe. Granted, I'm using SFML, which is based on OpenGL, and CEGUI has an OpenGL renderer available, but using CEGUI will still introduce inconsistency.
I've written a sprite system with SFML that makes heavy use of batching and texture atlases, with sprites associated with an ID. To draw a sprite I just need an ID and a transform. CEGUI would have to exist independently of of that. I would have to draw my GUI in a separate step, and I'm not sure how I'd put sprites used in my game in a CEGUI widget short of loading the sprite's image separately into CEGUI.
I've heard rumours that it's possible to write custom renderers for CEGUI, but I haven't seen anything that tells you how. Support for the Mac is also not the best apparently.SFGUI
SFGUI also controls its own rendering like CEGUI. It's meant to work with SFML though, so in my game it might not be such a mismatch.
SFGUI's default GUI theme is only coloured borders and rectangles though, and I haven't seen any documentation on how to create a custom theme aside from the source code and Doxygen class documents. SFGUI also requires GLEW as an extra dependency and I've been unsuccessful in building SFGUI on my machine anyway. SFGUI is overall a bit too new for my tastes.Berkelium
There's an interesting school of thought in GUI development about using web technologies to create GUIs. The layout and look of your interface is defined in a markup document while your application just handles the logic. WPF for example uses XAML and C# in much the same way web sites use HTML and JavaScript.
There are pair of WebKit/Chromium frameworks that lets you display web pages in your program. There is the original and commercial Awesomium and its open source offshoot Berkelium. Both of them promise you the ability to create your application's UI with web technologies. If you can create a web page, you can create a UI for a program with Berkelium in it.
Berkelium and Awesomium don't use HTML and CSS like WPF uses XAML though. They stuff a whole self-contained web browser into your program. By self-contained, I mean you need to use JavaScript to make your UI dynamic. I have not seen a way to control the DOM through Berkelium's C++ API. Considering that my game engine will be wrapped in Squirrel, I'd be forced to use a total of three programming languages for my game.
What I'd really want is a pure HTML/CSS renderer. Such a library doesn't seem to exist, except for libRocket (coming later) and the commercial Windows-only library HTMLayout.GWEN
GWEN stands for GUI Without Extravagant Nonsense. There's no HTML. No CSS. No JavaScript. No markup or config files. It doesn't handle rendering. It doesn't handle resource loading or resource management. It's just GUI logic. Anything else you have to provide. In other words, it's designed to not cramp your style.
It also only has a GitHub page to its name. It used to have an actual web page, but that's now gone. And with the original web site gone, the only real documentation GWEN ever had is now also gone. This doesn't inspire confidence about GWEN's status.
I'm also unsure about GWEN's skinning system. You give it a texture image containing all the graphics GWEN needs for a skin, but I'm unsure how I'm supposed to define size parameters like margins and paddings.libRocket
Due to the shortcomings of the libraries described above, libRocket ended up being the only library I've actually tried.
Like Berkelium, libRocket uses HTML and CSS to define interfaces. Unlike Berkelium, libRocket doesn't hide the DOM from you, so you don't have to stick JavaScript in the middle (though you can optionally use Python instead). libRocket fully expects you to write a custom renderer for it, and there's actual documentation on how to do this. libRocket still assumes that the images it's being given are files, but since it lets you create a custom renderer I've been able to take control of this so that it uses sprite IDs instead like the rest of my renderer.
I'm afraid the project is dead though. libRocket's last commit on its GitHub page is only a couple of months old, but the front page of its main site hasn't been updated in two years and the forums are dead.
There are a few other quirks with libRocket too. It doesn't use actual HTML and CSS, just its own subset (RML and RCSS). I also haven't wrapped my head around handling RML events application-side yet.
***
I wrote this after scouring the Internet, reading thread after thread about suggested GUI libraries for games. With the current selection today, picking a GUI library is not so much about deciding which one is the best as it's about deciding what I'm willing to put up with.
- I have to worry about the specific license of any library I use. I normally use the Apache 2.0 License for my own projects and I lean towards BSD/MIT/zlib(/Apache) style licenses for third party libraries. Lots to keep track of.
I experienced the same pains you've come up against.
The pain never really subsided until I chose to write for the web and was able to use the DOM/JQuery.