GUI toolkits and videogames

2015-06-11

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?

Tags: