This post is part one of a short series of posts about my progress in searching a viable GUI solution for our in-game/live editor. It is live coverage of my research and implementation. I welcome any and all feedback.

We’ve integrated live-editing into AntTweakBar. Now that the system has outgrown what AntTweakBar has on offer, I’ve started the epic quest of finding a suitable OpenGL-based GUI solution. Our requirements are straight-forward:

  • Platform independence (i.e. Windows, OSX, possibly Linux and maybe even iOS)
  • Unicode support
  • Simple skinning
  • Either scriptable or easy to abstract
  • Copy&paste and Undo supported, or easy to add

I’ve spent the last two months on and off evaluating GUI libraries and toolkits in order to find the perfect one. Sadly, all of them have proven to have their downsides. Let me summarize what I’ve found out so far.

A failed experiment but you can see AntTweakBar in the top right corner.

What’s Out There

Of course I started my research by looking at projects that already have a working live editor and trying to find out what tools they’re using. Berkelium that uses Google’s Chromium (itself a modified WebKit, as far as I can tell) instead. Both offer the benefit of being easy to skin and script since they are windowless browsers rendering HTML and executing JavaScript. On the downside, they are pretty big, adding 80MB of foreign code to your project. Since we’re eager to keep control over our source code and would love to maintain portability, even for the in-game editor, both of those sound like a less than perfect solution for us. Of course, one could substitute Chromium/WebKit with EA’s open sourced portable WebKit, but that looks like a major engineering task while all I wanted was a window with some sliders and buttons.

A somewhat similar solution two the above is libRocket, the poor man’s ScaleForm. It’s a freshly implemented wrapper for a subset of XML that approximates a subset of HTML. In other words: You can build your GUI in HTML and the library is less than 80MB large. Sadly, I found it unnecessarily difficult to get the library running and it is more suited for in-game GUIs than for procedurally generated editor panes.

On the other side of the spectrum lies Capcom Game Studio Vancouver’s tool chain for Dead Rising 2 which they explained in great detail over at Pure Data, the open source audio programming language / live instrument I used to work on years ago. You’ve got a server – the game, the audio engine, … – and a client GUI that connects to the server. All communication between the two goes over sockets. The upside of this approach is that you can live-edit your game even on a console, with the editor running on your workstation. The downside is that this approach is less suitable for in-game editing (where the editor lives in a window in your game context). Every coin has two sides.

Apart from these two there are numerous GUI libraries out there of varying quality and simplicity. CEGUI seems behind the curve nowadays, with guichan are two packages of straight and simple C++ libraries I’ve recently had a look at.

A Quick Rundown Of What I’ve Found So Far

I’ve looked at a number of GUI libraries and attached a couple of them to our renderer – or at least configured their OpenGL rendering and hooked them up with our resource manager. Here’s a quick rundown of the pros and cons of those libraries:

  • AntTweakBar: Perfectly suited for live-tweaking values. I’ve rarely seen source code as dense. Reminds me of Pearl more than of C++. Due to that it is very hard to extend and not suited for anything else but tweaking strongly hierarchically displayed data systems.
  • Awesomium: A comfortable WebKit-based package for OSX and Windows. Closed source, unless you pay $$$. Can’t say how hard it would be to port it to Linux and/or consoles. 80MB large, which is hefty for a downloadable game. Easy to script the GUI in HTML5 and JavaScript. Simple skinning through CSS.
  • Berkelium: Same as Awesomium plus Open Source. Linux support available, yet similarly unfathomably hard to port.
  • libRocket: Does it’s own rendering but there’s not JavaScript support. I found it impossible to hook the system up with our resource system. But it sounds intriguing. Simple skinning with CSS. Lively community.
  • Qt: Replaces your application framework like so many good tools out there. Visual designer available. Lively community. All bells and whistles, but we’ve built our game around the easily substitutable and portable SFML instead.
  • Cocoa: OSX-only but, boy this library is good. Visual editor, beautiful and well working widgets, easy to integrate bindings. Object C-based and closed-source, so importable to other platforms.
  • MFC: Insert random joke here.
  • guichan: A small and portable GUI lib. Makes heavy use of exceptions but features quite good code quality. Widget set is rather small and there’s no copy&paste or undo management.
  • Gwen: Like guichan, Gwen is a straight C++ GUI lib. It does support copy&paste and does not require exceptions. Very good code quality from what I can tell. Made by the guys who make Garry’s Mod.
  • Tkinter: The standard python GUI. While the ugly standard flow layout might not be the perfect fit for everyone, scripting a GUI is the only viable replacement for a visual GUI editor.

Browsing my object hierarchy over telnet.

What I’m Doing Next

This week and the coming week I’ll implement a socket-based interface to our game engine. Then I’ll design a GUI that hooks up with that. What I’m planning is more of a browser than a full-fledged level editor. That way I hope to maintain the live-editing features of AntTweakBar but make everything far easier to access. I’ll keep you covered how that goes.