There are a number of different ways you can approach the UI problem for a game.

1) Use a large toolkit of general-purpose 'widgets' for users to use, and remove from the users any responsibility for implementing the actual widgets or having to deal with them in any way outside of usage. Users only wire up various pre-determined widgets together to build a UI. This is the approach that toolkits such as Qt use. They often do provide the ability of allowing the user to build custom widgets via plug-in. The problem with this approach is how heavyweight it is. There may be a lot of features and tasks going on that you just don't need in your game engine. Also, many of these toolkits want to handle everything, including rendering using their own rendering process that stands outside your game pipeline. In the case of Qt, I believe that is where a lot of the performance hit comes from. These general-case UI frameworks tend to be mostly designed for standard document and UI models such as you see in non-game applications, in order to give users a familar-feeling interface; think "File Edit View" menu bars and docking toolbars.

2) Use a general-purpose widget toolkit as above, but impose on the user the requirement of supplying a front-end for the toolkit to use to handle some jobs, such as rendering and input handling. I believe this is how CEGUI works. The user must provide functionality to allow CEGUI to render itself, using the user's own rendering framework; additionally, the user must gather inputs from their own input system and inject those into CEGUI. This can provide performance bonuses, since the user can ensure that the UI rendering routines are optimized for their particular framework, rather than relying on whatever rendering engine the UI framework developer wants to use.

3) Write your own. General-purpose toolkits, I've noticed, tend to include lots of the "standard" types of widgets: radio buttons, list views, etc... Lots of things that games don't necessarily need. Additionally, they often don't have direct analogues for things like Skill Icons with a cooldown sweep, drag-and-drop inventory slots, health globes with swirly, multi-layered animated textures and perhaps a custom shader (think Diablo 3 health globes here; for all the flaws of that game, those health and resource globes are awesome; but you won't find a widget for them in Qt, no sir).

There needs to be a difference between the UI that you use for the game proper, and the UI that you use for editor and tools. There is no reason your editor needs to have a swirly layered health globe widget in the interface, and there is no reason that your game needs to have a listview box rendered in default Windows style. Game UI and tool UI are just too different.

My personal preference is to use 1 for tools. When your task is to build a tool, you don't want to get bogged down in the messy details of implementing UI from scratch. At worst, I would go with 2 and use CEGUI, if Qt just wasn't going to work for me. For the game, I almost always go with 3.

Now, many engines provide UI capabilities themselves, and if the engine was built with games in mind then a few of the widgets might be suitable for game use. But even so, I typically expect to have to do a lot of work implementing the things like swirly health globes, things that it just isn't practical to expect the engine developer to provide, since such widgets are so dependent upon the style and feel of the game itself.

As far as a Blender-like interface, you're not going to find such a thing built into many engines, since Blender's interface was tuned and tooled with Blender's needs in mind. Games typically require other styles. You might conceivably find game tools built with such an interface in mind; and, in fact, Blender itself is both a game engine and a game tool. But as far as standalone engines go, you might have your work cut out for you trying to find an engine whose packaged editor tools use an interface like Blender's. You might end up having to write that UI yourself.

The take-home message here is that everything is so highly dependent upon the engine framework that you choose. Also, expect to have to do a lot of tedious work to tweak any pre-built UI libraries to your needs, since flexibility equates to complexity, and no framework can possibly take everyone's needs into account.

There are a number of different ways you can approach the UI problem for a game.

1) Use a large toolkit of general-purpose 'widgets' for users to use, and remove from the users any responsibility for implementing the actual widgets or having to deal with them in any way outside of usage. Users only wire up various pre-determined widgets together to build a UI. This is the approach that toolkits such as Qt use. They often do provide the ability of allowing the user to build custom widgets via plug-in. The problem with this approach is how heavyweight it is. There may be a lot of features and tasks going on that you just don't need in your game engine. Also, many of these toolkits want to handle everything, including rendering using their own rendering process that stands outside your game pipeline. In the case of Qt, I believe that is where a lot of the performance hit comes from. These general-case UI frameworks tend to be mostly designed for standard document and UI models such as you see in non-game applications, in order to give users a familar-feeling interface; think "File Edit View" menu bars and docking toolbars.

2) Use a general-purpose widget toolkit as above, but impose on the user the requirement of supplying a front-end for the toolkit to use to handle some jobs, such as rendering and input handling. I believe this is how CEGUI works. The user must provide functionality to allow CEGUI to render itself, using the user's own rendering framework; additionally, the user must gather inputs from their own input system and inject those into CEGUI. This can provide performance bonuses, since the user can ensure that the UI rendering routines are optimized for their particular framework, rather than relying on whatever rendering engine the UI framework developer wants to use.

3) Write your own. General-purpose toolkits, I've noticed, tend to include lots of the "standard" types of widgets: radio buttons, list views, etc... Lots of things that games don't necessarily need. Additionally, they often don't have direct analogues for things like Skill Icons with a cooldown sweep, drag-and-drop inventory slots, health globes with swirly, multi-layered animated textures and perhaps a custom shader (think Diablo 3 health globes here; for all the flaws of that game, those health and resource globes are awesome; but you won't find a widget for them in Qt, no sir).


There needs to be a difference between the UI that you use for the game proper, and the UI that you use for editor and tools. There is no reason your editor needs to have a swirly layered health globe widget in the interface, and there is no reason that your game needs to have a listview box rendered in default Windows style. Game UI and tool UI are just too different.

My personal preference is to use 1 for tools. When your task is to build a tool, you don't want to get bogged down in the messy details of implementing UI from scratch. At worst, I would go with 2 and use CEGUI, if Qt just wasn't going to work for me. For the game, I almost always go with 3.

Now, many engines provide UI capabilities themselves, and if the engine was built with games in mind then a few of the widgets might be suitable for game use. But even so, I typically expect to have to do a lot of work implementing the things like swirly health globes, things that it just isn't practical to expect the engine developer to provide, since such widgets are so dependent upon the style and feel of the game itself.

As far as a Blender-like interface, you're not going to find such a thing built into many engines, since Blender's interface was tuned and tooled with Blender's needs in mind. Games typically require other styles. You might conceivably find game tools built with such an interface in mind; and, in fact, Blender itself is both a game engine and a game tool. But as far as standalone engines go, you might have your work cut out for you trying to find an engine whose packaged editor tools use an interface like Blender's. You might end up having to write that UI yourself.

The take-home message here is that everything is so highly dependent upon the engine framework that you choose. Also, expect to have to do a lot of tedious work to tweak any pre-built UI libraries to your needs, since flexibility equates to complexity, and no framework can possibly take everyone's needs into account.

Pen and paper are extremely helpful tools for programming as well, not just for jotting down an idea to avoid forgetting it.

If you're having troubles implementing an algorithm, or doing various kinds of math (simplifying equations, solving geometric problems, etc), doing it by hand can be very beneficial.

Pen and paper are extremely helpful tools for programming as well, not just for jotting down an idea to avoid forgetting it.

If you're having troubles implementing an algorithm, or doing various kinds of math (simplifying equations, solving geometric problems, etc), doing it by hand can be very beneficial.

Has anyone tried to use http://blogs.gnome.org/clutter/ for game UI?

I'm also searching for a suitable UI framework and looked briefly at Qt and CEGUI. Both seem a bit too heavyweight or complex for what I need, and clutter seems more what I'm looking for. I don't need a lot of different widgets types, just a few standard ones and some custom ones. I want a lean C/C++ library, that focuses on the UI architecture, and nothing else. It should be dynamic, i.e highly moddable, preferrably with lua scripting.