Martin Pichlmair (@martinpi) is wearing a lot of different hats at indie game developer Broken Rules. He's mostly responsible for business development, production and game writing. But he's also working on the in-house Ginkgo Engine, game design and the toolchain. Broken Rules is currently working on the aerial action game Chasing Aurora.
Posts by Martin Pichlmair
  1. Game Prototyping 101 ( Counting comments... )
  2. Game Thinking ( Counting comments... )
  3. Layers of Depth, Layers of Fun ( Counting comments... )
  4. Risk and Reward Deluxe ( Counting comments... )
  5. How We Scrum ( Counting comments... )
  6. Learning From Indie Studio Successes ( Counting comments... )
  7. Looking into the Future ( Counting comments... )
  8. Building your GUI with Gwen ( Counting comments... )
  9. The Quest for the Ginkgo GUI (2): Going for Gwen ( Counting comments... )
  10. The Quest for the Ginkgo GUI ( Counting comments... )
  11. Living With Game Reviews ( Counting comments... )
  12. Digital Distribution Woes ( Counting comments... )
  13. Thoughts On University Education ( Counting comments... )
  14. Indie Project Budgets ( Counting comments... )
  15. The Ginkgo and the Unanswered Questions ( Counting comments... )
  16. Rules We Don't Break ( Counting comments... )
  17. Ginkgo's Game Loop ( Counting comments... )
  18. Growing a Ginkgo (2): Components ( Counting comments... )
  19. Growing Ginkgo Pt. 1: The Reading List ( Counting comments... )
Game Design / Technology/ Code /

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.

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. Wolfire Games are fans of Awesomium, a custom version/wrapping of Apple's WebKit (which started out as a branch of KHTML of KDE fame). There's also an open source BSD-licensed equivalent to Awesomium called 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 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.
  • 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.