GUI solutions for GUI-intensive games

[Greysuit]

I want to program a 4X game somewhat like this, which is very GUI-intensive.

Having looked at the GUI libraries that integrate well with game engines like SFML (CEGUI, GWEN), I do not think that their features are sufficient for such an application. On the other hand, searching the web and forums suggests that solutions like GTK+ or Qt don't integrate well with SFML.

So, I'm just wondering if there is a solution that would allow me to integrate a more comprehensive GUI kit with SFML. Specifically, I would like to be able draw elements over the game window and not just flanking it.

[NoobsArePeople2]

Two I'm aware of that are SFML-specific are SFGUI and TGUI.

[Greysuit]

Thanks, but those are among the category that lacks the breadth and depth of features I seek.

[cpolymeris]

I want to program a 4X game somewhat like this, which is very GUI-intensive.

Having looked at the GUI libraries that integrate well with game engines like SFML (CEGUI, GWEN), I do not think that their features are sufficient for such an application. On the other hand, searching the web and forums suggests that solutions like GTK+ or Qt don't integrate well with SFML.

So, I'm just wondering if there is a solution that would allow me to integrate a more comprehensive GUI kit with SFML. Specifically, I would like to be able draw elements over the game window and not just flanking it.

I am creating a similar game (more in the vein of EU than HOI, but highly configurable and python-scriptable, see my sig, maybe we could colaborate!), and am currently using GTK. It has its share of issues, like the hack I needed to use to make it "embed" the SFML window, but so far it's the only GUI toolkit I have found that works well with SFML and has C# bindings. (I love C++, but I think the rapid development cycle C# allows makes more sense for a one-man-effort)

I am playing with the idea of switching to GWEN.Net, though, and if it worked with the latest SFML version I would probably have done so. I think that toolkit offers enough widgets, and more could be added, if necessary.

Widget-wise, what I miss from GTK is "sub-windows".

UPDATE: I am going forward with the transition to Gwen. Is it perfect? No. But it's simple enough that it works as a foundation for creating the more advanced UI controls I might need.

[eXpl0it3r]

The fact is, that there doesn't exist an optimal GUI library. Since your game would be heavily based on the UI, i.e. the UI is the core element of your game, then it would make sense to implement it yourself. If you go down that path, it might be helpful not trying to create a complete and general UI library, but to make it fit your game.
On the other hand, the people behind SFGUI are still looking for others to help them out advancing the library further. If you want a nice start point and want to contribute to the general public, then this would be a good starting point.

[Greysuit]

@cpolymeris
I also considered using GWEN and decided against it partly for the same reason. Also, its probably impractical to insist on maximum range of features, but I want to make sure that anything I need down the line will be available.


@eXpl0it3r

The fact is, that there doesn't exist an optimal GUI library.

Thanks for explicating this.

Since your game would be heavily based on the UI, i.e. the UI is the core element of your game, then it would make sense to implement it yourself.

This had occurred to me, and I think you're generally right, but it seems like a lot of challenging work that isn't my main interest. Since I'm not an experienced or gifted programmer, I want to avoid doing things myself as much as possible. So, I think I will probably just settle for flanking widgets and tabs for most of the UI. I'm thinking of using Qt for that. Then, for the stuff that I really want to do in the sf window, like tool-tips and whatever else, I will use something like SFGUI.

If you want a nice start point and want to contribute to the general public, then this would be a good starting point.

If I get my project to the point where it feels worthwhile to code custom UI widgets, it would be really nice to do it in a way that would contribute back to the community. However, at the moment, I dunno if I can get stoked on coding a GUI library.

[binary1248]

Don't forget that SFGUI not only serves as a widget toolkit, but in general as a framework for designing your own widgets should the need arise. SFGUI gives you access to it's numerous interfaces for handling almost all kinds of events and drawing at a very low level (basic primitives, lines, text etc.) as well as interaction with other widgets. If you have a vision of a widget that you might want, it is highly probable that you will be able to implement it with SFGUI.

SFGUI is still a work in progress, but progress is being made, sometimes slower than usual . At some point we plan on adding tooltip support, modal window support, keyboard-only control e.g. tabbing through widgets, and most importantly a bitmap rendering engine. We did have one in development named Bob but I have no idea where he wandered of too . I might probably end up writing one myself if I feel like it needs to be done at some point.

The main problem right now, is that creation of custom widgets is not documented at all. It is possible, however to do anything meaningful you really would need to take a look at how existing widgets are implemented and figure things out on your own. This should change sometime in the future however, since we don't plan on releasing something without adequate documentation .

[cpolymeris]

Don't forget that SFGUI not only serves as a widget toolkit, but in general as a framework for designing your own widgets should the need arise. SFGUI gives you access to it's numerous interfaces for handling almost all kinds of events and drawing at a very low level (basic primitives, lines, text etc.) as well as interaction with other widgets. If you have a vision of a widget that you might want, it is highly probable that you will be able to implement it with SFGUI.

SFGUI is still a work in progress, but progress is being made, sometimes slower than usual . At some point we plan on adding tooltip support, modal window support, keyboard-only control e.g. tabbing through widgets, and most importantly a bitmap rendering engine. We did have one in development named Bob but I have no idea where he wandered of too . I might probably end up writing one myself if I feel like it needs to be done at some point.

The main problem right now, is that creation of custom widgets is not documented at all. It is possible, however to do anything meaningful you really would need to take a look at how existing widgets are implemented and figure things out on your own. This should change sometime in the future however, since we don't plan on releasing something without adequate documentation .

Sounds great... If only it had C# (or at least C) bindings. Maybe I should consider writing the myself, but that SharedPtr stuff is going to be a PITA.

[cpolymeris]

@cpolymeris
I also considered using GWEN and decided against it partly for the same reason. Also, its probably impractical to insist on maximum range of features, but I want to make sure that anything I need down the line will be available.

Well, I did switch to GWEN (or more precisely, the .Net port thereof). Main reason being it's simple enough for me to modify to fit my needs if necessary. For instance, I am currently modifying it to load textures and fonts from my centralized resource manager, instead of using the standard SFML loaders and creating multiple copies of everything.
Something like that would have been very hard to do if I had continued to work with GTK or chosen any other of the more complex toolkits.