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 Ginkgo some time ago by hooking up our component system and 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.
What’s Out There
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 Gamasutra. Incidentally their architecture greatly reminds me of 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 “immediate mode” interfaces getting en vogue. Yet, IMGUI and its cousins are good for in-game displays but less suitable for level editors. Gwen and 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.
- Berkelium: Same as Awesomium plus Open Source. Linux support available, yet similarly unfathomably hard to port.
- 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.
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.