Introducing GimGui
This being the first post of this blog, I thought it would be fitting to introduce a project I’m working on at the moment: GimGui
What is it?
In short, GimGui is a game GUI library for C++. The core part is capable of managing a tree of GUI elements with attributes and there are also parts for taking care of rendering the tree into render-friendly data, and attaching logic to the elements.
Why yet another GUI library?
There are currently many alternatives on GUI libraries out there to choose from. Some examples include libRocket, ImGui, CEGUI, GWEN, SFGUI, Awesomium, Guichan, the list goes on… Many of these are quite extensively in use by people, others are less known. I have tried out a few of them, and glanced over the API/usage of the others and I have yet to find one which suits my needs well. All of the ones I found had one or more to me off-putting drawbacks ranging from being a bit buggy and unmaintained, or being way too hardcoded to not being possible to style freely or having an overly convoluted API. It is also not just me, but I’ve seen the same concern being raised more than once, for example in this thread.
Note: I am not trying to say that all of these libraries are objectively bad and useless. I just mean that at least for my needs, they are lacking enough for me to not want to use them and you may or may not agree. :)
So with this in mind, since I still need a GUI for my game, and since it is fun, I decided to take a shot at making my own library as a response to this problem.
What’s the philosophies?
There are a few main ideas that I base GimGui on. Without further ado, they are as follows:
- Flexibility
- Extendability
- Simplicity of use
Flexibility is to me about not making assumptions about the codebase of the user, and is critical to make the library integrate well with whatever other tools and needs the target game has. For example, GimGui does not assume much about your rendering pipeline; it outputs basic vertex arrays and similar data for you to render yourself. It also has no built in vector/colour classes but these are provided by the user through template means. I also focus on hardcoding as little as possible, leaving configuration options open instead.
The second important aspect is extendability. This comes from recognising that there is no way to cover all the possible needs of games in the vanilla functionality of a library, and instead of trying and ending up with a huge messy codebase which would probably fall flat in the end anyway, it tries to provide only basic functionality and instead focus on making it pain free to extend the library to one’s own needs.
Finally, the last but IMHO very important philosophy of GimGui is simplicity of use. I myself find that I really value libraries that manages to keep an API powerful but simple and it often means that the library is well designed in other regards. Simple APIs also of course leads to more simple code which is naturally easier to maintain, also a good thing. Simplicity of use of course also means that there has to be a good set of default capabilities that would make the typical user able to do what they want without troubles.
I will in future posts go into the details of how these ideas affect specific design decisions of GimGui.
End notes
So that makes the end of this first post! If you found the ideas behind GimGui interesting, stay tuned for future news about it. :) As a finisher, I’ll leave you with a link to the github page and a screenshot from GimGui in action, showing different tiling/border modes.
