Used to be, games didn't need a proper Graphical User Interface the
way applications do. They'd show a title screen, you'd press fire,
the game would start. After game over, they'd show you the high score
list and that was that.
Nowadays expectations are a little higher. Any game needs at least
push buttons or some sort of menu, so you can see the credits, choose
your language or turn off sound. As a next step, you'll also need a
dialog pane, textbox control and image control so you can depict an
NPC speaking, for example. By the time you move on to strategy games,
we're talking sliders and spinners in addition to the lists you need
for, say, an RPG — practically all the controls in a full-blown GUI
toolkit. And that's a problem, because the latter aren't easy to make
at all.
But what if you could make a game using a general-purpose GUI toolkit,
say Swing, or Gtk+?
That wouldn't fly for a lot of games, mind you. Regular GUI toolkits
are too slow to render in real time, and they don't render to OpenGL
anyway, as a general rule. They also don't have visual appeal as a
primary design consideration. (Unfortunately — I've talked to many
people who think they should. But see below.) Still, that leaves
plenty of open possibilities, as I'll explain in a moment.
My first serious game was a Reversi implemented in Tcl/Tk. It was slow
and dumb, mind you, but I'm still proud of the user interface. I made
the board out of an 8x8 grid of push buttons, with icons on them to
represent the stones. It also had an ongoing score display and a big
"TO MOVE" indicator, in addition to a menu system for setting the
computer's skill level, and who played which color — stuff like that.
It was a bit overdone, to be honest. But it was fun to set up, and it
made a very good impression. Sadly I lost the source code a while ago.
So GUI toolkits definitely work for board games. What else? Well,
consider the city management screen from FreeCiv. There's
nothing on it you couldn't make with Swing. That includes the city map
— Swing happens to have a convenient canvas control. (It's more
complicated in Gtk+, but you can do it there as well.) You can even
change the background color of the window and controls. There's no way
to have a background image, but you can achieve much of the same
effect with well-placed labels. Or if your window is simple enough,
you can eschew a layout manager entirely and place controls by hand.
Of course, in both cases you'll want a fixed-size window, but that's
par for the course when it comes to videogames.
That adds a certain subclass of strategy games to our list. The engine
I described two months ago fits into this category, and I'm
sure others can be found. The real question is, why bother?
One big reason is that the likes of Swing and Gtk+ are very complete
and well-debugged, by virtue of having been widely used for decades.
While made-for-games GUI toolkits can be limited and unstable, coded
by lone-wolf programmers with only so much time and skill. I'm not
sure why that's the case, since most games need one, and indeed there
must be counter-examples out there (doesn't Unity come by default with
GUI controls you can put in your games?) Besides, games are hard
enough to make without adding another highly difficult task to your
list. But if you search for such a library to put in your OpenGL game,
you are going to find a ton of simplistic, unfinished and not really
documented examples, rather than a handful of industry-standard
solutions, as any business app developer can expect.
Another thing is that the major GUI toolkits have accessibility
support built-in. You know how visually impaired people can't easily
play many games apart from text adventures? With Swing or Gtk+ you
can also open up the world of strategy games to them. And speaking of
text adventures, late examples such as Magnetic Scrolls' Wonderland
(1991) use a perfectly ordinary windowed interface. Told you I
could find another example.
Third, a game made with Gtk+ can integrate with the desktop, whether
that means posting notifications or simply not having to reinvent
windows. And ever since the advent of mouse-driven operating systems,
there's been a tension between games and the rest of your programs...
Now let's talk about the downsides.
For one thing, as I pointed out already, general-purpose toolkits
aren't designed for performance. So making a real-time game with one
of them is right out. Sure, you can have timers that end your turn
after a fixed time and so on, but it still has to be a turn-based
game, or something the like.
More generally, the event-based model of typical business apps just
isn't a good match for games. You want to have control over your main
loop, and decide when to check for input — what kind of input, too.
In ncurses that's both easy and natural. In, say, HTML5 it's neither.
You can emulate the behavior you need... with time you don't have.
A last issue is that with Swing (and even more so with Gtk+) you don't
have as much control over the way everything looks as when you're
drawing everything yourself, at least not without excessive effort.
But see above. It's not that bad, and you can do something about it.
In conclusion: this approach would only work for a (small) subset of
games, and even then it won't be a perfect fit. But I say it's a thing
to try, because we need all kinds of games out there, and also because
we need to ease our work as software developers.
So think about it, why not?
Comments
For what it’s worth, in the commercial games space, there are quite a few GUI toolkits specifically for the needs of game GUIs. They’re generally closed-source and pretty expensive, but it’s a mistake to think that most games just reinvent their own toolkits all the time.
One particularly popular one on the PS3 (which I can’t remember the name of but their list of licenses was a mile long) actually implemented a useful subset of Flash, and converted the Flash primitives to underlying render system calls. And I think PhyreEngine (Sony’s own middleware for PS3/PS4/Vita) provides a GUI module as well.
It’s also pretty amazing what sorts of abuse you can do to the Android and iOS native widgets to make them look more game-like (although I think most mobile games end up just writing their own crappy GUIs using their own rendering, touch input handling, etc., which is IMO a mistake).
fluffy
Thanks for the input. I’m not familiar with the world of console game development. And as far as I can tell, the Android widgets look quite a bit more friendly and game-like than those of desktop toolkits by default — a smart decision on the part of Google, showing they understand how most people see computers and apps.
Felix