When we decided that it was time to include a GUI system in our engine, we set up a list of requirements. It should:

• Be easy to use as a game developer.
• Be able to render arbitrary shapes, sprites, all arbitrarily transformed.
• Support full Unicode font rendering, not only being able to render all the glyphs, but also arranging them in the correct way.
• Be able to render rich text (for example, single words in a text could be bold or in another color).
• Integrate with the other rendering of the engine: We wanted the possibility to use textures from the engine in the GUI, and we wanted to use GUI elements as textures in the engine.

We were unable to find any good and proven GUI library that was able to do all of this stuff. We considered using Qt, but at that time it did not integrate well enough with OpenGL and was not really usable as a game GUI either. A lot of AAA games are using GUI systems based on Adobe Flash, but nobody here at Upvoid likes Flash very much.

We were already working on a self-written GUI system, knowing that it would become a huge time-consuming side-project. But then we had an idea: What about the web browser’s rendering engines? Browsers have become strikingly fast at rendering HTML. Many of them are open-source, and we certainly will not find any library that is better and more reliable at rendering rich text.

Now maybe you are reading this with the same concerns we had at that time: HTML is a text markup language. When it was invented, it was not even intended to do all the website layouting it is used for today. How can it possibly be the best choice for a scenario where you want textured buttons, sprites and all the other graphics?

But look at these examples. HTML can do everything you expect from a GUI system:

• HTML and CSS can be used to create layouts that are not rectangular at all.
• HTML and CSS can be used to blend transparent sprites, arbitrarily transformed.
• With WebGL, HTML can even be used for realtime 3D graphics.

HTML5 has become such a rich development environment that it is actually used to make games today. It certainly is not the best environment for doing this from a technical point of view, but it is more than fast enough for 2D GUIs.

A point that is not so trivial is the integration with the other rendering systems in the engine. To display live-updating textures inside the HTML GUI, we would have to do some kind of video livestream. However, apart from this it fulfills all the requirements we set, and it also has several nice additional advantages:

• HTML is one of the most widespread technologies in the world. Dozens of libraries and toolchains exist to make development easier.
• With a web browser embedded in our engine, we can not only display our GUI, we can also load and display regular websites from the web. This way, it would be possible to integrate the help section of your website or even the community forum directly into your game - at almost no integration cost.
• If somebody would like to use Adobe Flash, this is possible without any overhead.

And here is another one I really like: We embedded an HTTP web server in the engine, and now we can display ingame GUI elements in other browsers. This is nice for debugging because of the really good debugging tools that are built into web browsers. Also, we have several GUI pages that show statistics, logs, and other information about the internal engine systems. One could also look at the ingame GUI from other devices. This could be used to display a minimap or inventory on your tablet, or to view the ranking on a multiplayer server from your browser, without having to start the engine locally.

Until now, the choice for HTML has worked out pretty well. We are using the Webkit version embedded in Qt, so we did not even have to bother with Webkit itself. We just tell it where to load the HTML code from, pass Qt input events to it, and when it tells us that certain parts of the screen have changed, we upload it to the graphics card.

There are some points where the system could still be better, like the integration with the scripting system, or using textures from the engine, but these are things that are just a matter of implementing them in our engine, not problems with HTML itself.