Making a GUI for OpenGL Games?

stuck in a bind asks: "I am currently coding a civilization-type game (in C) but on a galactic scale. OpenGL is used to draw everything so far. However I have been unable to find a decent, nice GUI, practically all of them are coded in C++. The only other options I can think of is coding my own toolkit (too much work, and I would hate to reinvent the wheel here), using SDL to draw 2D bitmaps on top of my OpenGL window. The last option would be to switch to GTK and use the GTK GL widget. What would the educated gamer/programmers of Slashdot recommend?"

Invent a new wheel

[presearch]

If you're taking the time and effort to write "a galactic scale civilization-type" game that's written well enough that it's worth the time for others to play, why not go all the way and do the GUI from scratch too?

Are you in a hurry to get it out? Running out of steam? Face it. Odds are it's largely an academic exercise and your game isn't going to be the next Unreal super-hit anyway , so why go the extra mile and innovate instead of imitate? If it does turn out to be a super hit, wouldn't it be best to hand-craft a quality game from the ground up?

Besides, If you were really clever you've got most of the hard part already done in the game components,
so perhaps you can use the game engine itself, and it's active elements, to build the GUI as well and come up with something that's totally new.

--
Looking for short term neural disruption? Play tranquility [tqworld.com]

Re:It's been done

[BrookHarty]

Why is it someone wants to design a game, its "Been done".. Maybe he has new ideas. Let the guy try. What would of happened if Linus said "Well, Minix is good enough for me"....

Exactly...

Re:Because he prefers to remain blissfully ignoran

[doctormetal]

I suspect he's one of the hordes of (mostly C) coders who believe that using a C++ library requires you to write your entire application in C++

In most cases you have to. Rather impossible to call C++ classes from plain C, unless you make a wrapper around them.

Then again, if he's writing in straight C these days, I suspect that learning new and inconvenient facts might not be what he's looking for right now.

What wrong with plain c? OO languages aren't suitable for everything.

write your own or use C++

[nickos]

If I was in your shoes, I would think carefully about exactly what GUI elements you want to use. Most likely you'll find you only really need a small subset of the ones that you'd find in a full toolkit (maybe buttons, menus, text fields and comboboxes/dropdowns). If you insist on using C (and I guess you do), you'll probably find that you can code these in quite an efficient way (because your code won't have to be as flexible as code used in a full toolkit). A basic "toolkit" designed especially for your game isn't as much work or as hard as you think.

On the other hand you could just bite the bullet and use C++. Personally I really like C++, but it took me a long time to lose the prejudice I had towards it.

Good luck!

Re:Because he prefers to remain blissfully ignoran

[excessive]

Actually, it's hard to find a problem for which plain C would be a better fit

I'd like to see you suggest that on the Linux kernel mailing list...

Re:Why not use C++

[EzInKy]

OO is pretty much ideal for GUI programming. So why not code up your GUI in C++ and leave the rest of your game in C?

I can't say as I blame guy. Twelve years ago, before I decided to make healthcare my career and relegate programming as a hobby I thought C++ was the greatest thing since sliced bread since it wrapped up both the power of C and object orientation all in one nice tidy little package.

But now just when I've got some time on my hands that I want to devote to creating some programs I've got in mind I find someone has gone and mucked the whole thing up with namespaces and what not. Hell, they even changed the way standard header files are included.

But anyway, in the end you are right. Use just enough C++ for the gui and encapsulating the units and get on with the business of actually writing the game (this is aimed as much at me who has been spending way too much time writing macros trying to turn C into the great language that C++ used to be).

Re:Invent a new wheel

[Watcher]

Are you in a hurry to get it out? Running out of steam?

As a counter point to this: he probably wants to build the game, not the GUI. If he was focused on writing the best darned GL GUI out there, then he wouldn't have asked this question. Most game projects die because they get into writing horrid amounts of generic game code (sound mixers, UIs, cross platform IO, so on) that isn't specific to what they're doing. All that accomplishes is making it a much longer path to get to writing the game they want, and the project usually dies from boredom or lack of momentum. If you're paid to write that code, its one thing, but when its something you're doing in your own (generally limited) spare time, you really just want to write the game you want and not have to worry about all of the boring code until much later.

Re:Invent a new wheel

[presearch]

If I'm writing a game (or any application) and I'm footing the cost and time, and I see parts of it as boring to write, or not as part of the unifed whole, it's a clue that I might have a design error.

Re:Because he prefers to remain blissfully ignoran

[tepples]

Game programming has more in common with systems programming than some may think. In fact, I come from environments where all game programmers also must be systems programmers, namely Apple II, NES, MS-DOS, and Game Boy Advance.

GUIs are not easy

[UnConeD]

I'd strong recommend against making your own UI toolkit. Many programmers seem to have the idea that anything involving GUIs is easy, because it's designed for 'stupid users'. Not so.

UI's are complex beasts that need to be fast, consistent, flexible and powerful. 'Designing' a UI is not about making pretty skins for the buttons, but defining the behaviour and actions in the UI so that they form a harmonious whole.

Take for example, the 'simple' scrollbar. It consists of 4 areas to click on: the up/down arrows, the thumb to drag around and the gray area outside of the thumb which you can click to go up/down a page. The thumb's length should represent the visible portion of the document/item. If the view shows 75% of the item, then the thumb should cover 75% of the scroll 'gutter'. When viewing a list of lines or items, scrolling should stop as soon as the last item has appeared at the bottom. The granularity of the scrollbar should match the contents that are being scrolled (don't make a smooth scrolling bar if the contents only skip up/down line per line).

Nearly every Flash brochure site and computer game out there which implements its own widgets violate at least one of these rules for scrollbars. Think about all those tiny little implicit rules about buttons, checkboxes, menus, ...

If all you want to do is make a GUI, then by all means, code one. If you want to make a game, find a good, existing toolkit and use it.

Re:Invent a new wheel

[Watcher]

Or maybe you've just discovered that some sort of code isn't all that interesting to write. Maybe would much rather concentrate on getting your application written than writing the XML parser you need. It sounds to me like you're the type who ends up writing the end all be all libraries to write your application. That's all well and good if the libary is something you're interested in writing, but I've seen more than a few folks who wrote an impressive library to get some dinky little application written, burned out, and never got anything done. Personally, I'd much rather use something off the shelf so I can concentrate on getting the goal of the project done, then go back and write a new library later if the old one just isn't up to scratch. Better to ship something that works than never ship something because you burned out making some dinky part of it function.