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?"
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
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...
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.