Wednesday, 26 June 2013

Designing a game UI with HTML and CSS, Urban Galaxy story

Recently we have made an enormous update on our game by releasing the new html5 client.

By saying html5 client one would mostly think about the 3D engine that replaced the previous one but the truth is that the whole underlying structure and code that supports the new client tries to get the most out of all the involved technologies.

In this post we will talk only about a really small part of the new client that is the actual user interface implemented for the in-game menus and interactions.

Story so far

In order to have a complete documentation of how the UI progressed - along with the game - in this section we will present all the steps that led us to where we are right now, so feel free to skip this.

The development started a long time ago and the client was in JMonkey until very recently. In the beginning of the project the scope was to give it a retro look closer to Fifth Element which was a great inspiration in all aspects of the game.

The initial design of the UI was mostly orange, with blue buttons....It was not beautiful, actually ugly, but it was very functional! The initial UI more or less set the various UI elements positioning. Designing the UI for the first time we had to solve one basic balance problem: the game was running in 800x550 dimensions only so we had to make the UI non intrusive to the gameplay and keep the player's view as clear as possible AND display all the useful info in the UI. What we finally came up is shown below

The design is not that great but again all the elements are there! Keep in mind that the look and feel we initially wanted was more retro than futuristic.
The different elements that we came up with were static with fixed sizes and positions (such as the player status element, the shortcuts area and the map) and with varied size and positions (inventory, ship ghost, quest window etc.).
We went on with this UI for a long time and gathered useful feedback to use in our next UI shown below.

In this version there are many changes and optimisations. The thought is always the user available space and functionality. What we have done in this version is group all the player related data in the lower bar along with the shortcuts, adding more info about the current user XP (little bar below shortcut #4). That alone released a lot of space in the upper left corner! Moreover we squished a bit more the selection window (upper left) and all the popup windows. And hey!! we decided to go with the blue as a more futuristic color. Also, we replaced rounded corners with lines to give a more crisp look.
This was the final version of the UI that you probably have played in the java client.

Initial thoughts and ideas

Having already experience from the previous UI we tried to improve and think all of the flaws and problematic areas in hand. Since we are talking about html5 client, all the UI is 100% pure html (not that pure actually since some elements are using raphael.js and most of the layout is handled through backbone with underscore templates!!).

Taking into account the above let's say "directions" we came up with the specifications:

  • Utilize responsiveness of the css/html elements to create more room for the user to see the action, we had to make all menus and ui-elements responsive so that they would adjust to the available space.
  • Make some of the ui-elements interactive in their functionality, so that the user can contract/expand them
  • Implement the whole interface so that it can be easily enhanced, altered and re-organized in the future.
During the whole process we thought of our game as a stand alone game and never thought of it as a browser game so as to avoid design and idea compromisations such as "it's just a website with a game skin", "that <div> can't do that stuff" and more like this that would result is something less fancy.

We wanted the design of the UI to reflect something futuristic with simple lines. We also wanted to included only what the player could really use and avoid any noise in the interface. Playing with the elements size and color also helped in grouping and making something more important.

Ideas on customisation

Since we will be working with HTML and CSS we have thought the idea of customised UI. Both HTML and CSS are well known technologies, so it would be a waste to not adopt this to our design. The idea is that the whole UI - eventually - be fully customisable in terms of elements/windows positions and sizes as well as colouring and fonts.
That in the end will allow each player to customise the UI to his liking and make it familiar to his own play flow.


After setting up the specifications and the rules we started prototyping the UI. In the game UI there are two main different areas of interaction, the actual interface that includes all the panels and the windows that the player uses and the hidden interface used to interact with the scene of the game that includes the  floating names that follow each ship and the interaction elements with all the active elements in the scene (enter a shop, enter a portal, hover a ship and select it etc).
So the initial layout of the UI and interactions is as follows:

  1. Canvas element that hosts the visual aspect of the game, is set in the bottom layer
  2. In-game hud interface that is interacting with the canvas elements and sits on top of the canvas
  3. Game UI with all the windows and panels sitting on the top layer
The whole player interaction involve layers 2 and 3.

Since we wanted to properly support customisation we had to include this capability from the beginning of the development. So in the backend we split the styling of the UI in CSS that can be customised and other that are not customisable and contain more generic rules that need to be applied in any case or as a fallback. Getting valuable info from css frameworks such as bootstrap we break the css rules and files in two groups:
  1. A group responsible for general positioning and ordering rules that are to be applied in any case
  2. A group responsible for the actual styling and actual positioning  of the elements
So in group 1 a css rule is looking like that:

#qlist-preview {position:absolute;display:block;overflow:hidden;}

While in group 2 the css rule for the same elements looks like that:

#qlist-preview {margin-top:255px;font-family:AldoSemiBold;font-size:1em;text-shadow: 0 0 1px rgba(0, 0, 0, 1);width:15em;margin-right:0.5em;}

In that way we try to separate the functional positioning and elements ordering from the styling of those elements. So the first group mainly contains all the basic styling that must be equal in all cases and the second one is a certain styling of the UI (customisation). Those CSS groups are applied to both UI layers.

Layer 2: In-game hud interface

The UI layer 2, in-game hud interface, should extend to the entire game area so it is of width/height 100% with a z-index greater than that of the canvas layer, to sit on top of it.

The hud interface contains elements that are absolute positioned and controlled by javascript to animate or fix their position and display.

Layer 3: Game UI core

The UI layer 3, actual game UI, is also absolute positioned and with width/height 100% and z-index greater that that of layer 2. This layer contains the core of the game interactions. Since we wanted customisation from the start we created some elements for better organisation of this aspect. Below is a graphic image showcasing the basic break down of the game UI layer.

So in the above image you see that we have defined 5 areas for UI elements placement:
  • Full area is placed on top of all other elements and has width/height 100%, used for all the popup windows and in general elements that are not shown by default in the UI like messages and info text on XP acquired etc. All UI elements placed in here are absolute positioned.
  • bottom,left, right and top areas are used as placeholders for docked elements of the UI. In general we try to keep any elements shown in these areas not overlapping with each other. In here we implemented additional positioning classes to align docked UI elements to the sides and the middle of the area. The idea here is to allow the player/user to customise the elements by dragging them along each area and snapping them.

Overview of a window container

So far we have defined the basic placement of the whole UI and the positioning of the UI windows. Here we will talk about the HTML and CSS of an actual window. In order to allow windows reposition we had to make a common base that all UI can share. In that way we could easily move a docked window to a floating position and readjust only the CSS of that window. The common base is as follows:

  1. A <div> as the window container, since most of the UI windows are unique an id is added on this level to distinguish each unique window (#playerbar, #chat, #map, #shop etc.). This element also defines the width and height of the window. The size is defined by the position of the element on an area (docked, left or right, top or bottom).
  2. HTML elements for styling using 4 <divs>, one for each corner of a rectangle (.top.left, .top.right, .bottom.left, .bottom.right). Using the position of the UI window we change the styling and size of those divs. Those elements don't cover all the possible needs of a window style but we heavily utilized the :before and :after pseudo rules to expand our toolbox. We had to add these styling elements because we couldn't handle a specific case where we have corner borders and transparency applied in almost every window.
  3. A <div> element absolute positioned with width and height of 100% where we put all the content of the window.
In some windows some extra HTML elements are used to display a title, a close option etc.
We will surely need some expansion of the basic window structure when we actually try to implement a different styling to the UI, but so far we didn't need to change the window container.

Minor "issues"

Since the UI of a game is quite dynamic in order to fulfill various needs are covered by inserting new elements in the UI. So more elements means expanding the DOM of the page. In a normal web application where the new DOM elements contribute to the UI and the application itself there is no problem....but....since we are talking about a webgl game where the page already contains a ton of 3D assets and information in a whole different level one should try and minimize the DOM as much as needed. A.k.a. better put that extra squeeze of browser/memory power on the canvas than on DOM elements manipulation and ordering and staff...
In that direction we use whenever possible the pseudo elements :before and :after and also avoid extra elements addition to the DOM when it can be avoided, as in the Shop were you can have a never-ending list of items. In the specific example each element contributes only one li element to the DOM and the slots are a repeated background on the ul element of width/height 100%.

Another issue we needed to address was the anchors. We thought that an anchor with an empty href will still interrupt the user experience with the link helper showing on the bottom of the browser (hover here for an example). So instead we used a span with an anchor styling to simulate pointer functionality.

Future work

More or less this is the current status on the UI. We can't say that we have something final, but we surely can say we have something functional. The transition from Java to html was worked quite successful and we think that we used some of the benefits that html brings on the table.
For sure this version of the UI is not final, like we said, and we already have some improvements and extensions in mind for the future. We would really like to create our own font-face to replace the static images that we currently use, making the interface more flexible and adjustable. Another idea we need to work on is the actual implementation of the customizable UI; meaning we have to create a proper framework and supporting css rules/files to help you customize the UI to your needs and preferences. Expand the responsiveness of the UI to accomodate even smaller screen sizes (the current cap is 800x550 actual game size).

As a conclusion, working with HTML and CSS to implement a game user interface was a great experience! The instant feedback you get from your design is liberating. One can freely test whatever his own skills allow him and sky is the limit! The restrictions that CSS and HTML bring to the table are easily surpassable and - top of it all - really really well documented and troubleshoot!! HTML and CSS are quite living languages that are actively evolving day by day, if you combine that with all the great capabilities and robustness of the modern browsers we see no reason to not walk this path.

Rock on!!

1 comment: