UI work is never easy. Layout engines are full of kludges, styling elements can be overly complex, and targetting different screen resolutions is often completely uncharted territory.
With that said, I decided to take advantage of the DOM / CSS for our UI layout and styling without a moment's hesiation.
Pros
- I didn't have to write yet-another-bad layout system. I can't stress this enough. While the CSS box model has it's fair share of issues, there is a huge amount of available skill that already knows them and it's been used to create some of the richest UIs of the past decade.
- HTML / CSS enforces a good separation of layout and styling.
- CSS3 provides great out-of-the-box rendering capabilities such as rounded corners, drop shadows and gradients.
- Targetting different resolutions has many well-known approaches.
Cons
- Games often expect the UI to be rendered each frame. Unfortunately, rendering DOM is slow meaning our UI must be programmed very defensively. Using proper models to represent the data for your views can help out with this (we're using backbone.js.
- We won't receive the normal DOM events since we're trapping user input in our game (e.g. through requestPointerLock). A layer must be created that emulates DOM events such as
click from the trapped input in order to provide the same familiar ecosystem. - It may not be possible to directly access your image assets through <img> tags and background styles.
Again, having worked with enough difficult UI systems, the first pro was enough to sway me. After some initial tests showed that overlaying my UI on my canvas wouldn't impose any significant performance penalty, I was ready to get started.
For non-interactive menus, getting started is very easy. Basically, you're just throwing HTML in a div that's absolutely positioned and stretched across the top of your canvas element. Brandon Jones put together an excellent sample project showing how to do this.
The biggest hurdle in this approach comes when you need to interact with the UI. Once your WebGL canvas has requested a pointer lock, your input events are going to be contextual to it, having nothing to do with any UI you've absolutely positioned on top of it. The easy out here is to expect users to always break the pointer lock (which means pressing the escape key) to use your menus, but in the interest of providing a good user experience, I opted to emulate the basic DOM events for our views.
After a recent late-night QuakeLive session, I was curious to know how exactly it worked. Having never written a browser plugin, there were a lot of questions running through my head. How much porting was actually done as far as the engine was concerned? Can we use new technology like WebGL? Did the networking layer have to change to deal with browser restrictions?
With a free upcoming weekend, I set out to answer these questions by getting the excellent ioquake3 project up and running in the browser and document my process along the way.
A "journalistic-motorcycle-stunting-gypsy" would probably best describe my role in the summer of 2011. My personal project fueled by pure passion had led me to travel a criss-crossed path from ocean to ocean across America for the majority of 2010 and finally over the Atlantic to experience the European version for 2011.
This passion of course is motorcycle stunt riding.
It had captured my Type A, but paradoxically still shy and reserved teenage imagination in high school and ravaged my life like the bubonic plague from that point on. At 15 I started practicing the evolving urban sport and carried it with me to Los Angeles for my first job in video games. Seven years later in New York City I was still stunting and finally my hobby peaked with the decision I should take a sabbatical from my professional career to dedicate my time and skills to help it grow into its fledging maturity.
My girlfriend (also a stunt rider) and I decided to start a news website and provide regular and reliable news, event coverage and how-to information on this underground, entirely DIY sport. Our goal was to help grow the sport and allow anyone with the interest the opportunity to take part. The sport attracted social deviants, like most alternative hobbies and the sense of family and sweet taste of real accomplishment made men out of boys and confident, contributing humans out of rebellious, misunderstood characters.
StuntBums.com was born and we hit the road in 2010 to learn everything about the scene in America. With a whirlwind of success we saw our project taking off and decided we wanted to expand the project to Europe for 2011. After a lengthy and stressful visa application process, we touched down in France mid-February and by May we were ready to spend the summer on the road with a van, a caravan and two motorcycles in tow.
For more information on StuntBums, we wrote a three part series about its history over the past two years starting here.
Lately I've spent my free time working on a generic, distributed build project along the lines of Electric Cloud or Incredibuild. One of the main components of this system involves not only executing processes remotely, but to synchronize the input and output files for each operation between the systems.
Along the road to coming up with a robust, battle-ready solution I tried many things. Finding the right balance of security, practicallity and ease of setup was a trying process (yes, I'm looking at you OpenLDAP).
In the end, most of my attempts fell into one these two categories:
- Sandbox the remote process's i/o, sending over any input files before execution and sending back any new files upon completion.
- Tunnel all file i/o between machines through some clever mechanism so that the remote machine is working directly in the requesting machine's file system.
