My name is Quinten and I'm a UI programmer in the AAA games industry. You may have seen my work in games such as Thief (2014), Lara Croft and the Temple of Osiris (2014) and Deus Ex: Mankind Divided (2016). As a lowly UI programmer, I'm mostly responsible for adding mouse controls to existing menus or implementing PC-specific user interaction. However, sometimes I will need a button graphic or an extra icon and I have to ask one of the artists to make one for me.

My hope is that by doing portfolio work for open source projects, I can improve my UI designer skills as well.

In the past few weeks I have been working on redesigning the main menu for OpenDungeons. I'm using Flash with the proprietary Scaleform library, so it will unfortunately be a challenge to share its source. However, I've put up a playable executable here. I'm looking for feedback on the layout itself, I'm fully aware that the graphics are far from done at the moment.

The first screen I focused on was the main menu itself:

What is noticeable right away (besides the gorgeous background art) is that the buttons seem to be floating away in a sea of whitespace. The buttons take up only 44% of the width and 22% of the height of a 1400x900 window. This problem isn't unique to your project and affects many games that weren't designed for large resolutions. The games I usually work on solve this problem in a very straightforward manner: design your UI for a fixed resolution and then stretch the buffer to fill the screen. In my version of the main menu I've chosen a fixed resolution of 1280x720. Leaving the aspect ratio intact, you could stretch this to 1400x788 when using a 1400x900 window.

This is my version of main menu:

What I've tried here is to make the buttons more pronounced, by increasing their size and aligning them to the left of the screen. I've picked a serif font for the text instead of the current sans serif font, because I'm going for the "dignified, but creepy" look that is associated with Dungeon Keeper. Aligning the buttons to the left would have overlaid them with the face of the background character, so I decided to flip the image. I've also promoted the options button from a tiny top-right icon to a main menu button. Finally, I organized the "Host" and "Join" buttons under a "Multiplayer" umbrella.

This new layout also leaves room for a "news ticker" on the bottom right, but I haven't had time to flesh that idea out yet.

Next up: the skirmish screens. The current version is split up into two screens. First, you select a map from the list:

And then you specify how many AIs you want to play with and in which team they belong:

Again, there is a disproportionate amount of whitespace used here, compared to the amount of information on the screen. So much so, that I was able to compact the two screens into one while adding a preview of the current map and a chatbox!

There's a lot going on here, so let's go over everything one-by-one. The first thing you'll note is the massive preview of the map being played. This is something I was missing in the current design of the skirmish screens: it's impossible to know what the map will look before you actually start playing it! Although I'm using an in-game screenshot right now, what I envision here is a general overview of the map, with markers to indicate spawn points for the players.

On the right side, I've compacted the player selection and used icons instead of the text for the different properties. This is another AAA trick: icons don't need to be localized.

What you might not have noticed is that the logo has disappeared. This was actually redundant information: by removing the logo we leave more room for the rest of the screen and we can increase the size of the screen's title as well. This was done to help the user navigate the different screens. Hopefully, she'll know what game she's playing, but if she comes back to it after having been away, she might not remember what she was doing at the time.

The button on the left expands a menu that allows you to select a map:

This pop-out menu effectively increases the usable horizontal space of the menu, at the cost of overlap with the map preview.

Finally, I've standardized the navigation buttons on the bottom. In the industry, we call this control a "context bar" or "button legend". The cool thing is that you can switch the mouse buttons to gamepad prompts automatically, without having to change the layout of the screen. Of course, it's unlikely that OpenDungeons will have gamepad support, but old habits die hard.

The final screen I redesigned was the saved games screen:

This screen really wasn't all that bad, except that the text doesn't actually fit in the list control. Here's what I came up with:

You can probably tell that I was struggling to fill the screen with meaningful information. Although only four save games can be displayed at once, they include a preview of the game and separate the date from the map being played.

This is it for now. Like I've said: I'm looking for feedback on the general layout of the screens. If the layouts are acceptable, I will start focusing on fleshing the screens out, improving their visual style and hopefully getting them in the game.

Your UI is pretty nice. I like it too. However, we use CEGUI for UI and we need to integrate the UI there to get it in the game. GUI related files are in the folder gui/ (if you installer OD in c:/od, gui would be c:/od/gui)There, you will find:- ODSkin.png -> the file where the images corresponding to the buttons are. Probably the most interesting file for you as it defines the images the buttons use. By replacing the images, you can get to your UI. Note that the image is composed of several pieces of the images used by the UI elements- ODSkin.imageset -> Defines the elements used by the GUI elements and matches them with the images in ODSkin.png. You might use to change that if you use custom controls or if you use image with different sizes- MenuMain.layout -> Defines the menu. That's the file you will need to change if you want to move the buttons on the main screen.

Note that if you change the image set (ODSkin.png or ODSkin.imageset), that will change every button in the game.

In any case, your help would be much appreciated. If you have some questions, do not hesitate.

Unfortunately, I haven't been able to test it in-game yet. I synced to head on the Git repository in order to create a new branch for my changes (local only). Unfortunately, I am unable to build the project because I'm currently stuck using Visual Studio 2012 and the minimum required version is 2013. I tried to use the 0.6.0 executable with the repository content, but even after some tweaking of the data files it crashes on load.

I'm going to install VS2013 later, but for now I've focused on getting familiar with the UI tools.

The first thing I noticed is that the CEGUI editor is... alright. A small list of grievances:

It doesn't restore the previously opened project files on load. A minor inconvenience.

When making changes to the data files in a different editor, the only way to see them in the editor is by closing the project and reloading it. See also previous grievance. Annoying.

Unable to lock x- or y- axes when moving items. Whoever designed the editor obviously never had to align a list of menu buttons...

Overall though, it's perfectly serviceable. My only concern is that I will probably have to modify code as well as art, which is exactly what I'm trying to avoid...

knight666 {l Wrote}:I've gone ahead and started work on porting the new layout to CEGUI

That looks good. Seems like you are learning CEGUI fast ^^

knight666 {l Wrote}:Unfortunately, I haven't been able to test it in-game yet. I synced to head on the Git repository in order to create a new branch for my changes (local only). Unfortunately, I am unable to build the project because I'm currently stuck using Visual Studio 2012 and the minimum required version is 2013. I tried to use the 0.6.0 executable with the repository content, but even after some tweaking of the data files it crashes on load.

Indeed, we use some c++11 stuff that is not supported by MSVS2012. You really need to go for MSVS2013 to compile the sources. Note that if you have MSVS212, it is better to install MSVS2013 if your OS supports it (win 7 I think) as you will be able to compile more projects and you will be able to use more advanced stuff.

knight666 {l Wrote}:Overall though, it's perfectly serviceable. My only concern is that I will probably have to modify code as well as art, which is exactly what I'm trying to avoid...

If you prefer to focus on the GUI (at least at first), you don't have to play with the code as long as you keep the button names. And if you really do change the GUI (for example you add/remove one or change the hierarchy), you can create a github pull request and we can handle the code part (at least I will do it if nobody does before).

Concerning the code, note that you can use the dev snapshots to be as close to the sources as possible. I usually build one per week. You can see them in this thread:viewtopic.php?f=45&t=4765

hwoarangmy {l Wrote}:Indeed, we use some c++11 stuff that is not supported by MSVS2012. You really need to go for MSVS2013 to compile the sources. Note that if you have MSVS212, it is better to install MSVS2013 if your OS supports it (win 7 I think) as you will be able to compile more projects and you will be able to use more advanced stuff.

The projects I work on on my dayjob have very strict requirements about the development environment. I've only recently been allowed to upgrade to Visual Studio 2012. VS2012 supports most C++11 features already, there's no use to always upgrade to the bleeding edge if you just end up cutting yourself.

hwoarangmy {l Wrote}:Concerning the code, note that you can use the dev snapshots to be as close to the sources as possible. I usually build one per week. You can see them in this thread:viewtopic.php?f=45&t=4765

I tried to run my changes with your build and it crashed the game as well. I then spent a godawful amount of time wrangling with CMake to build my own debug executable. What I found was honestly pretty shocking. The crashes were caused by changes! Because I changed some button names and moved them in the hierarchy, the menu classes could no longer find them. This didn't cause an assert or even a log message, but a full-blown unhandled exception!

I'm going to try and improve this sorry state of affairs this weekend. I've got some ideas about improving the logging mechanism, but I'll probably want to change these exceptions into asserts at some point. It's a bit hard to change the UI if the game keeps crashing!

One thing I noticed however, is that the game crashes due to a heap corruption if a sound cannot be found. This is because the logging macro calls Helpers::toString, which calls Ogre::StringConverter::toString. Although the Ogre string converter returns an Ogre::String, it's really a typedef of std::string. Unfortunately, different allocators are used for Ogre's std::string implementation and the game's, which causes a heap corruption when the string is cleaned up. This is because the ABI for STL types is not stable between compilers or even different versions of the same compiler. I've seen this problem before and there's really only two solutions:

Link everything statically. This ensures that all libraries use the same memory allocator. It also guarantees massive binaries.

Use a custom memory allocator for STL types. Both Ogre and CEGUI already support custom allocators, but we'd need to add our own memory allocator, link it to up to all third party libraries and ensure all code uses ODString instead of std::string, ODVector instead of std::vector. This is what we ended up doing.

Honestly, this is a pretty big issue, so I'm wondering why it never crashed before. Perhaps I need to compile Ogre as well? :P

knight666 {l Wrote}:The projects I work on on my dayjob have very strict requirements about the development environment. I've only recently been allowed to upgrade to Visual Studio 2012. VS2012 supports most C++11 features already, there's no use to always upgrade to the bleeding edge if you just end up cutting yourself.

Well, honestly, I also don't think it was a good thing to break compatibility with VS2012. It happened when one of us made some changes about the console (with some c++11 pretty advanced stuff). Since most people here use linux (in fact, I'm the only one who use windows), I didn't want to make them change everything for me.

knight666 {l Wrote}:I tried to run my changes with your build and it crashed the game as well. I then spent a godawful amount of time wrangling with CMake to build my own debug executable. What I found was honestly pretty shocking. The crashes were caused by changes! Because I changed some button names and moved them in the hierarchy, the menu classes could no longer find them. This didn't cause an assert or even a log message, but a full-blown unhandled exception!

I'm not very used to CEGUI. And since I always run in debug while coding, the debugger usually breaks when something happens. But indeed, throwing a generic exception seems weird. Even if I've already seen exceptions with more meaning be thrown like "Unknown control" (which is what I would have expected in your case).

knight666 {l Wrote}:I'm going to try and improve this sorry state of affairs this weekend. I've got some ideas about improving the logging mechanism, but I'll probably want to change these exceptions into asserts at some point. It's a bit hard to change the UI if the game keeps crashing!

If you don't want to mess with the code, you should better keep same button names and hierarchy. Unless you add/remove buttons, there should be no problem.

knight666 {l Wrote}:I'm going to try and improve this sorry state of affairs this weekend. I've got some ideas about improving the logging mechanism, but I'll probably want to change these exceptions into asserts at some point. It's a bit hard to change the UI if the game keeps crashing!

Actually, we all agreed that it was a problem to have the gui defined in xml files while the buttons are hardcoded (which is needed since we have to bind events to the buttons). However, if you have some better idea, do not hesitate. So far, we didn't really had the need to change so I guess nobody took time to do something better.

knight666 {l Wrote}:One thing I noticed however, is that the game crashes due to a heap corruption if a sound cannot be found. This is because the logging macro calls Helpers::toString, which calls Ogre::StringConverter::toString. Although the Ogre string converter returns an Ogre::String, it's really a typedef of std::string. Unfortunately, different allocators are used for Ogre's std::string implementation and the game's, which causes a heap corruption when the string is cleaned up. This is because the ABI for STL types is not stable between compilers or even different versions of the same compiler

Interesting. Then, I need the most simple is to remove the calls to Ogre::StringConverter::toString and use our own string converter in the helper.

knight666 {l Wrote}:Honestly, this is a pretty big issue, so I'm wondering why it never crashed before. Perhaps I need to compile Ogre as well? :P

I had too ^^ But if you want, I can provide you all the needed binaries (for mingw32, mingw64 or VS2013). I've already uploaded a bundle with release dependencies (needed by appVeyor CI). You can find them here:http://download.tuxfamily.org/opendunge ... s-win32.7zIt's only release versions (because I didn't want too big file) but I can create a debug one if needed.

knight666 {l Wrote}:A small victory though: my menu works in the game. Yeeh!

Cool. That looks nice ^^Are the ingame buttons impacted as well ? Do they look nice ?

By now I've managed to compile and run the game using Visual Studio 2013 and I've been busy porting my menu redesign to the game. In the process, I've managed to get distracted by the logging system and the build system. But not to worry, I've also been busy doing UI!

Here's the main menu, as it looks now:

The Multiplayer button is collapsed by default. When clicked, it expands the right-side button list.

I've added a subtle wooden background to the buttons, I feel it breaks up the monotony of the background somewhat. I've also been working on new decoration for the windows:

For inspiration, I've been looking at a lot of weathered wooden furniture and iron name plates. I'm currently working on new graphics for the dialog buttons, but I'm not quite ready to show that off yet.

I feel that the combination of old and darkened wood with cast-iron elements gives both the furniture and the UI a look that says: aristocratic, with a dash of evil. I've set up a Pinterest board where I gather this inspiration material. Did you know that it's actually possible to use Pinterest for things other than "cute DIY projects" and "amazing cake recipes"? I was amazed myself!

For those interested in my process, it's really quite simple. I look at photographs that express the "feel" of what I'm going for and try to capture that feeling in Flash, using a bucketload of gradients. After I'm satisfied with the result, I export the Flash and touch it up in GIMP. Then I import it in the CEGUI editor and try to use the new graphics in the UI.

I still have to take the time to look more closely at your proposed changes, but wanted to drop a small line already: "Skirmish" is actually the name we use for single-player games, so it shouldn't be in the expandable multiplayer menu. For the time being "Continue" wouldn't really serve a purpose as we lack a proper campaign; though it could be used to load the last saved game, and later on changed to load the next campaign scenario when campaigns are implemented.

Akien {l Wrote}:I still have to take the time to look more closely at your proposed changes, but wanted to drop a small line already: "Skirmish" is actually the name we use for single-player games, so it shouldn't be in the expandable multiplayer menu.

I get that. OpenDungeons right now is a multiplayer-only game, but if you look at other games like that, you'll see that they use the term "Skirmish" for "a local multiplayer game against AI opponents". However, something certainly could be said for keeping the button in the main list, because it's the only way to play the game offline right now.

Akien {l Wrote}:For the time being "Continue" wouldn't really serve a purpose as we lack a proper campaign; though it could be used to load the last saved game

Akien {l Wrote}:I still have to take the time to look more closely at your proposed changes, but wanted to drop a small line already: "Skirmish" is actually the name we use for single-player games, so it shouldn't be in the expandable multiplayer menu.

I get that. OpenDungeons right now is a multiplayer-only game, but if you look at other games like that, you'll see that they use the term "Skirmish" for "a local multiplayer game against AI opponents". However, something certainly could be said for keeping the button in the main list, because it's the only way to play the game offline right now.

Well that's what skirmish is already: local game against AI opponents. It does not really qualify for local "multiplayer" IMO, at least as long as one considers that a player is a human I guess in the future we would have:- Singleplayer > Campaign | Skirmish- Multiplayer > Host | Join (and/or Lobby)

@knight666 I will probably do some changes in the main UI soon. Did you manage to make your UI changes work ? If I do, I will probably make your changes not mergeable. So please tell me if I should wait.

First of all, I want to thank everybody for keeping me in the loop and apologize for not returning the favor. Although I do plan to continue reworking the UI, unfortunately I won't be able to until the next year. I have basically been swamped at work for the past two months. I've been pulled off one major project and put on another, which had a deadline of (wait for it...) three months. If you know where I work it will probably be pretty easy to figure out what happened.

All that stuff means that I haven't had much time to even think about much else lately.

In the new year, I hope to finish my art rework of the main menu, because I'm still pretty stoked about it!

Nice to see you are still around. No problem, it is a spare time project and everybody gives the time he wants (and has). Just tell us from time to time you are still around so we know we should avoid getting in your way

I've tried to download your repo and I like the new UI. It's pretty cool. Can't wait to see that ingame ^^