Forging Forgecraft: Integrating CSS3 Transitions with Javascript
Forgecraft is a game currently in development using Ruby on Rails, Backbone.js, and all sorts of HTML5 buzzwords. Read an introduction here, and play the demo here.
With Forgecraft, and any game really, there are usually quite a few animations running concurrently. I found these moments to be choppy, unresponsive and frustrating when they were implemented in javascript (especially on lower CPU environments like the iPad) and needed another solution. CSS3 transitions were an obvious choice to check out, as they’ve been shown to be a great way to add a little pizzazz to a modern web app and can be executed natively (and even GPU accelerated).
But, can they provide the technical underpinnings for an interactive gamely element? To be effective in this context, they’d have to be:
- responsive, consistent and reliable
- noticeably smoother than their javascript counterparts
- simple to integrate with scripting
Regarding the first 2 points, CSS3 transitions’ effectiveness will really depend on your particular use-case. With Forgecraft they were definitely response, reliable, and smoother than javascript and I decided early on to use them in lieu of javascript wherever I could. But, I won’t go into the benchmarks and A/B comparisons in this article… perhaps later. Let’s just skip straight to the useful part:
Product Intergortion obscure 30 Rock reference →
Integrating CSS3 transitions with the game’s scripting is pretty straight forward:
- Define transitions in CSS on your master element
- Define classes with resulting properties changed
- Trigger a class change using javascript
- Listen for the transition-end event with javascript
Of course, there are a few pitfalls with each of these steps that I’ll go into here. Let’s take an example from Forgecraft: the Bonus Strike event. Randomly while forging the player will see a bar pop-up like this:
The bar moves from left-to-right and the player’s goal is to click the icon when the moving bar is directly under the target (large white) bar. The moving bar is animated with CSS3 transitions.
Defining the CSS:
We have a bar that needs an initial negative offset (the start position) that transitions to its final position. Simple enough: we define the base CSS on the #bar element and give it two classes (.new and .activated) defining each of its states. We also define the transition between the two states:
position: relative;
background-color: rgba(153, 153, 153, 0.3);
border-right: solid 5px white;
-moz-transition-property: left;
-webkit-transition-property: left;
-o-transition-property: left;
transition-property: left;
-moz-transition-duration: 1.5s;
-webkit-transition-duration: 1.5s;
-o-transition-duration: 1.5s;
transition-duration: 1.5s;
}
#bar.new {
left: 0px;
}
#bar.activated {
left: 600px;
}
One pitfall you may run into: for the animations to work in Firefox, you have to explicitly define the initial state for whatever property you are transitioning. In this example we are transitioning the left property of the #bar element. You normally wouldn’t define left: 0; — that’s the default! But Firefox requires this to trigger the transition when that property changes.
Triggering the Animation in Javascript
Using jQuery, we simply apply the classes that we defined in the CSS when we want to trigger the transition.
Listening for the transition-end event
CSS3 Transitions would be useless if we couldn’t get their context from within our scripting. Luckily, a series of events are fired in javascript while the transitions are running, just like you’d expect in a javascript-based animation. The primary event we care about is when the transition ends as you’ll most likely want to trigger callbacks.
Unfortunately, each browser vendor has decided to name these events differently… typical huh. Modernizr to the rescue! (If you’re not using Modernizr, you should be. But that’s another blog post altogether).
There’s a hidden gem in the comments in the source code of Modernizr that explains how to use its .prefixed() API to make a simple wrapper around the browser-specific transition event names. Here’s how I implemented it for the transition-end event. Feel free to use this wherever you need it:
var transEndEventNames = {
‘WebkitTransition’ : ‘webkitTransitionEnd’,
‘MozTransition’ : ‘transitionend’,
‘OTransition’ : ‘oTransitionEnd’,
‘msTransition’ : ‘msTransitionEnd’, // maybe?
‘transition’ : ‘transitionEnd’
},
CSS3_TRANSITION_END = transEndEventNames[ Modernizr.prefixed('transition') ];
Bam, now we can use one simple event binding to handle all browsers:
Stopping a Transition Early
When the player hits the hammer-and-anvil icon during the Bonus Strike event, I needed to stop the animation early. The easiest way I found to do this, was to just set the animating property to its current value. The transition delta becomes 0, so the animation stops:
Transition: End
You may find that integrating CSS3 Transitions into your game makes your interactions smoother and more responsive, and with a simple API for scripting against transition events, developing against them should look and feel a lot like working in pure javascript.
More Forging Forgecraft:
philbocq, and 
Cam, 
Vlad_savitsky and 7 others are discussing. 
, I just started it but contribution would be great, building a framework on node.js is sexxxxy
I like the Sinatra-esque lightweight approach.
peterlubbers 12:44 pm on January 11, 2010 Permalink
Nice post! I'd like to add Kaazing WebSocket Gateway to the list of implementations. It's a production-ready WebSocket Gateway. The best part? It has emulation for all the older browsers (Anything other than Chrome right now), so you can already use WebSocket APIs today.
Pl4n3 3:12 pm on March 12, 2010 Permalink
Nice posting! Games using WebGL and WebSockets is a nice perspective. I made a RTS-game demo using WebGL http://pl4n3.blogspot.com/2010/03/towards-webrt…, I also plan to integrate websockets for the multiplayer-part.
britg 3:38 pm on March 12, 2010 Permalink
Hey Pl4n3 — awesome that you're working on an RTS in WebGL! Your demo throws an error in Webkit nightlies, though — “Error: 0:3: 'uniform' : cannot initialize this type of qualifier” (with wegGL enabled)
Which browser are you recommending for the demo?
Pl4n3 4:09 pm on March 12, 2010 Permalink
Thanks, also for the RT
The RTS currently runs here with Firefox 3.7 (Minefield) nightly. Yesterdey it also worked with Chrome, but today WebGL could not initiate there, strange..
evilhackerdude 8:07 pm on March 16, 2010 Permalink
Hey, I tried the RTS demo with the latest Minefield nightly (3.7pre4 I thin), yet I got exactly same error as Brit.
Pl4n3 3:34 am on March 17, 2010 Permalink
Hi, i just updated Minfield to the latest version here (3.7a4pre), and the demo runs without problems. Currently cannot reproduce the error :/ Hopefully later, as WebGL gets more stable, this might resolve itself.
Lindsay Stanley Kay 5:08 am on July 2, 2010 Permalink
Aha great post this, cheers, helps me get started here.
Yes it seems that the WebGL framework hackers, having got things drawing, are rightfully turning their attention now to the backend. I just added Sockets to SceneJS as well: http://scenejs.wikispaces.com/SceneJS.Socket – early days – comments appreciated!
Pl4n3 – whoah – looking forward to seeing how you implement the game logic/protocol etc! PS Your demo works good for me in Chromium build #51510
lingerie 12:09 am on August 20, 2010 Permalink
It's so tough to encounter right information on the blog. I realy loved reading this post. It has strengthen my faith more. You all do such a great job at such Concepts… can't tell you how much I, for one appreciate all you do!
Arne Wieding 7:12 am on November 23, 2010 Permalink
Nice post, however i think you are being very optimistic here. I think this will rather take 4-5 years instead of 2. Especially since your post in now roughly a year old and not much has changed, the next browser generation still hasnt arrived in a stable form.
Furthermore id like to add that most modern games use UDP while WebSockets use TCP/IP which is not well suited for games. You might do some simple games with that, but any real time multiplayer games dont work that well.
Still interesting tech, but it will take some more years to mature.
modern home design 10:06 am on February 13, 2011 Permalink
It looks like webgl is more promising…
bouncy castles for sale 1:06 am on February 19, 2011 Permalink
Great!This is awesome!Thank you!
web design london 8:36 pm on August 11, 2011 Permalink
Nice posting! Games using WebGL and WebSockets is a nice perspective.