Posts Tagged ‘UI’

The decal system

A World without UI

Let’s imagine a RTS game where you’d play without an HUD, or even without a proper UI, just by clicking around with your mouse and learning by heart dozens of shortcuts. Pretty annoying, right ? You couldn’t tell how healthy is your army, assuming that you managed to create it, without a hint of which building is selected, and no construction menu. Think about all the stuffs you would miss.

That’s right, efficiently printing information on the screen is one of the main challenges in making a strategy game, and precisely the point I am actively working on. But let’s start with the beginning, before taking a look at what will come for you in the next releases. A lot of UI elements are already implemented in the game, like the tracking of the actions you programmed, by printing little circles on the floor, but how does it work ?

The decal system

Well those little indicators are called decals, and are wildly used in the large variety of games, from heraldry on a knight’s armor to a GPS arrow on the floor. The technique is inspired by real-life decalcomania, which is basically the art of printing a 2D image on a 3D surface, by pressing it and copying it on a support. What we want to do here is exactly the same, applying a texture on the terrain, but we have to do this in the most efficient way possible, since there can be a lot of decals, and they are refreshed every frame. (hint : we use the GPU for that).

Giving the example of the selection decal, let’s take a look at what we have to work with :

→ A texture of the pattern we want to print: cercle

→ The depth-map, giving the height of the terrain for every pixel on the screen: depthmap

→ The position where we want our decal to be, and the color we want it to have

Life is like a box of pixels

Now we are only a few steps away from the best UI ever.

First, we create a box around the given position, large enough to contain the full decal. To make this simple, we give it the maximum height of the terrain, and the size of our texture. This aims to reduce the number of pixels the shader will compute, since everything outside the box will simply get discarded.

Then, the challenge is to detect which part of the box is intersecting with the terrain, to know where to apply the texture. We do this by casting rays from the camera (in blue in the drawing) to every pixel of the box visible by the camera. There are three possible results:

  1. the ray enters and gets out of the box, intersecting the terrain after the box (top ray)
  2. the ray enters and doesn’t get out, intersecting the terrain (mid ray)
  3. the ray doesn’t even enter the box, intersecting the terrain before the box (bottom ray)

boite

Thanks to the depth map, we get the surface we want by the rays in the second case, and we can get the corresponding texture coordinates by projection.

However, the technique is not perfect, and we still compute a lot of pixels for nothing. The box is almost always way too big since we take the maximum height of the terrain. Actually, we consider a box, independently of the shape of the decals, which brings us to draw a lot of useless pixels. In the case of the selection decal, only the circle is used, so 80 % of the texture is transparent. With small decals it is not a problem, since drawing a small number of superfluous points has no impact on the performance, but when it comes to very large shape, such as printing the range of an artillery for example, we have to think another way.

An other problem is that the decal is relying on an input texture that is static. But we could need something computed dynamically from the game state, like an influence zone drawn by the whole army.

So yes, there are a lot of complications ahead, but don’t worry, you will hear from all of this very soon, in a future article.

Kranchy

At your service – The user experience

Insane User Experience

Hello everyone!

Looking at this blog posts, we can easily realize we write a lot about programming, but not that much about game-design. One facet of the game-design consists in thinking the user interface (UI). But writing about UI these days is so outdated! Now, people talks about UX, and UX only. Actually, it’s about the user global experience of the game. We can find lots of theories and recommendations all over the Internet.

Factory build queue
Factory build queue

The insane UX process

I have a practical approach about it :

  1. I reasonably code the UI. I want it convenient, plain and understandable.
  2. I test it, you test it,
  3. I improve it.
  4. And so on. Back to step 2.
Energy and Sharp Crysal gauges
Energy and Sharp Crysal gauges

 

The best feedbacks we had so far were from players who tested the game during some fairs (Stunfest, Utopiales)…even if it often makes us start all over again.

Our approach of the Win That War! UI

Why should you have to double-click while a simple click is enough? Why should you have to move the mouse till the very bottom of your screen while the menu could come up in its middle? UI is all about giving the player a nice experience,  that’s why I try to remain faithful to those principles :

  • every clickable component (no matter if 2D or 3D) has to react on mouse-over
  • every change in the game has to be visually and easily identifiable…
  • …and every visual change has to be the exact reflection of the simulation (damages, building progression, etc.)
  • at one time, necessary information only have to be showed up depending of the situation
  • in order not to penalize the player, the action has to be restricted ( ONE click, ONE button, ONE mouse-move…)
  • the more common is an operation, the more it has to be simple to execute.
  • for every action, we’ve integrated visual and sound feedback to easily inform the player that this action was taken into consideration.

Well, well, well…written like this, it may sounds really easy to do, but actually it requires a lot of work…

Feedbacks building tank traps
Feedbacks building tank traps

Since my latest post about UI, we worked on the conception of a brand new animated SVG-based panel. The UI is entirely javascript-coded.  And I’m using only 3 external libraries :

Jquery (I mean…How I’m supposed to do without it?)

requirejs (To fill Javascript major gaps)

snap (To easily manipulate the SVG)

 

 

 

The new alpha version of Win That War! will be released soon, so you could test it and send us your feedbacks. Then “back to step 2”

More on WTW UI : CEF3 Integration

Hello everyone,

In the previous post, Etham kindly entrusted me to talk about behind the scene : how do you display web pages in a game?

Initially , we used Awesomium ” HTML UI Engine” . It can be seen as an old version of Chromium, well packaged, which allows rapid integration into any engine .

To sum it up, it can instantiate multiple Web views, and provides access to an offscreen buffer for each of them. An event is called as soon as a view rectangle changes, and getting connected to it is enough to update the graphics resource used in the engine. Long story short, it is not very complicated, not more than two hours are needed to display a first page.

Last week , we changed for the Chromium Embedded Framework with Xlium.CefGlue as a .Net wrapper. The principle remains the same, but the integration is a bit more complicated. Indeed, Chromium’s architecture is multithreaded and multiprocess. Display events are issued in a different thread for each view, which complicates matters a lot when it comes to updating the corresponding texture in the engine. So the full integration took me a small week and it took Etham less than a day to migrate our pages to the new system (due to an improvement of the interface that I had found useful !)

But it was worth it, the rendering is now very fast, and the support for HTML 5, the same as a recent Chrome, is excellent.

Enough bullshit, here goes a small tech demo :

See you next week,

Doom

About the qualities of a video game UI.

Today, I am talking User Interface (UI).

The UI of Win That War ! must be:

Nice

Well, of course, this is a matter of taste… but I cannot say that my first draft fulfills this goal !

WTW Action Panel

WTW Action Panel

WTW Action Panel

WTW Action Panel

Once again, please be indulgent: our team still lacks an artist, who will work on the visual identity of the game… Meanwhile a poor AI developer have to deal with UI design !

Simple and intuitive

Claiming that I do the job of an ergonomist expert may seem chancy, but with a little common sense we can still get something.
I will just do my best to:

  • at one time, display only possible actions and useful information
  • use symbols instead of text
  • reduce to a minimum the number of actions performed by the user

This results in an interface that changes depending on the selection. No drop down menu, everything must be done in one click!
Regarding the use of symbols, everything remains to do.

Responsive (1/2)

MVP

MVP Class Diagram

Responsive design stands for web sites that adapt the layout to the device. Waiting for the day when Win That War! runs on tablet or smartphone, we already need to support the various screen ratios and resolutions on PC.

I say web? Precisely, Win That War ! UI is completely based on HTML5. For those of you who are developers, I use the MVP (Model View Presenter) pattern. The model is our game-logic, written in C#. The view is the HTML5 web page. The presenter (coded in C#) makes the bridge between the view and the model.

Responsive (2/2)

Not to mention responsive design, a good game UI still needs to be responsive, in other words we strive to:

  • reduce the latency of actions
  • give a systematic feedback to any user action

To sum up, the UI must be at the user’s beck and call.
Indeed, what is more annoying than a UI putting a few tenths of a second to trigger an action? What is more annoying than a button that the player is tempted to click several times because he is not certain that the order has been understood?

At the moment, we are using Awesomium to embed a browser in our game. For latency and performance reasons, Doom is working to replace it by a direct use of Chromium Embedded, but he may talk about it better than I in a further post.

See you next time,

Etham

Return top