In the old days, in order to make HTML look the way you wanted, you used more HTML. Every element had to be individually styled, using ribbons of FONT and CENTER and B tags. Then CSS came along and gave web developers the ability to group elements into classes with similar display characteristics. The world heaved a sigh of relief, and developers started making more complicated websites, confident that site styling would not get in the way of functionality.

Then JavaScript and AJAX became popular, and suddenly it became commonplace for elements to have their classes modified by JavaScript, based on the results of AJAX calls from the server. When an element’s class changes, it is updated instantaneously to reflect the styles associated with the new class. That’s fine for some stuff, but sometimes you want the transition between classes to be a bit more, um, classy. Let’s say your site has a login box that remains hidden on a page until a user clicks the “log in” link. If you switch the box’s style from opacity: 0; to opacity: 1;, it will appear right away by default. If you want it to fade in, you have to write a JavaScript function that increments the opacity bit by bit until it reaches 1, and you have to call that function at the same time as you change the class of the login box. If you have a bunch of login boxes on your site, you have to attach that transitional behavior to each one of them manually. Because CSS doesn’t have the concept of transitioning through time, animation-heavy websites are stuck in the same place that pre-CSS websites were before CSS came along.

CSS transitions solve this problem by bringing styles into the 4th dimension. CSS transitions allow web developers to specify that if an element has its style modified, the browser should smoothly transition its appearance to the new style, rather than shifting it abruptly. They’ve been available in WebKit for about two years now, and just appeared in Gecko a few weeks ago. Since they’re not available in most browsers, webOS developers are among the privileged few who can take advantage of them. Here’s how.

The Basics

Suppose your login box is 300px wide and you want it to hide offscreen until a user clicks a link, at which point it should get the class active and appear onscreen.

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px;
}
 
#loginbox.active {
  left: 10px;
}

Here’s a version of that with transitions:

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px;
  -webkit-transition-property: left;
  -webkit-transition-duration: .5s;
  -webkit-transition-timing-function: ease-in;
}
 
#loginbox.active {
  left: 10px;
}

And here’s how it’d look if you wanted the box to fade in and slide in at the same time:

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px
  opacity: 0;
  -webkit-transition-property: left opacity;
  -webkit-transition-duration: .5s .25s;
  -webkit-transition-timing-function: ease-in linear;
}
 
#loginbox.active {
  left: 10px;
  opacity: 1;
}

Here’s a brief overview of the three -webkit-transition properties used above;

-webkit-transition-property

A space-seperated list of the properties that should be animated when they change. You should only use numerical properties. “top”, “width”, “border-width” and “opacity” work, but “display”, “text-decoration” and “list-style-type”, for instance, do not. If this property is omitted, all the properties of an element will be animated. This is probably not what you want.

-webkit-transition-duration

A space-seperated list of the durations of the transitions of the different objects. “s” stands for seconds. This is 0s by default, so you need to set it.

-webkit-transition-timing-function

From the W3C Working Draft:

The ‘transition-timing-function’ property describes how the intermediate values used during a transition will be calculated. It allows for a transition to change speed over its duration.

“ease-in” starts slowly and picks up speed at the end. “linear” keeps the same speed all the way through.

And here are some things that aren’t supported in webOS (as of 1.2.1), but probably will be eventually, since they are part of WebKit 4:

-webkit-transition-delay

Allows you to set a delay before the start of the animation.

Events

Currently, there’s no way respond when a transition animation finishes, and this is the main drawback of the CSS approach to transitions. WebKit 4 lets objects listen for animation events, which will let you string a bunch of animations together without needing to call setTimeout() to activate each part of the animation.

In addition to the reduced code clutter, CSS transitions can speed up your app, since they are run from native compiled code, rather than from interpreted JavaScript. Don’t expect miracles, though — I’ve found that webOS can only handle a few animations at one time before things get choppy, and the size and complexity of the elements being animated also makes a difference. I was unable to animate a 320×480 image without choppiness. While there is no programmatic way to cancel the animations, they are smart enough to smoothly reverse themselves if an element’s properties change in the middle of a transition. If the active class is removed from our login box while it’s still sliding in, it will slide out starting from wherever it happens to be at the moment the class was removed.

For more on the basics of transitions, check out the W3C docs, and keep in mind that all the properties should be prefixed with -webkit- in webOS.

Advanced Tricks with -webkit-transform

There’s another advanced CSS property in webOS, called -webkit-transform, that, when combined with CSS transitions, allows for some neat stuff. -webkit-transform is…well, I think of it as a mini-CSS within CSS. It lets you apply transformations to an element after it’s been rendered. In webOS, The available transformations (to my knowledge) are translate, scale, rotate and skew. To scale an element to twice its height and rotate it 30 degress (something that’s been impossible in HTML until now!), do like this:

#myDiv {
  -webkit-transform: scale(2, 1) rotate(30deg);
}

The crucial difference between scaling a div with -webkit-transform and scaling by manipulating its width and height is that -webkit-transform will scale (or skew or rotate) the entire rendered div and its children smoothly. For more on -webkit-transform, see this post at Art of Web.

You can animate -webkit-transform by passing it to -webkit-transition-property. If you’re using a WebKit browser, hover over the card below to see an example.

#cardexample {
  -webkit-transition-property: -webkit-transform;
  -webkit-transition-duration: 1s;
  -webkit-transform: rotate(0deg) scale(1, 1);
}
 
#cardexample:hover {
  -webkit-transform: rotate(180deg) scale(1.5, 1.5);
}

Our games Word Ace and Card Ace use this technique for pretty much every animation in the game. It’s a lot of fun to describe the behavior of a class in CSS and have elements automatically move around when they’re changed. There were times when I’d forgotten that I had set transition properties on an element, and was surprised when it started moving around of its own accord.

Caveats

Advanced animations are tricky with CSS. For example, the timers in Word Ace and Card Ace use transitions. In order to start a timer countdown, the yellow timer bar gets two classes set: one to set the bar to “full”, and another that sets it to “empty” with a transition, so that the width of the bar decreases slowly. My first pass at the code was something like this:

// CSS
#timer-bar.full {
  height: 22px;
  background-color: yellow;
  -webkit-transition-property: width;
  -webkit-transition-duration: 10s;
  width: 100%;
}
 
#timer-bar.full.counting-down {
  width: 0%;
}

// JavaScript
function startTimer() {
  var timerBar = $('timer-bar');
  timerBar.addClassName('full');
  timerBar.addClassName('counting-down');
}

It didn’t work. The timer bar never went to “full”. After some research, I discovered a blog post explaining that changes to element styles are batched during an event, and are processed all at once after an event has finished, for performance reasons. In this case, WebKit sees that the classes I’m adding would set the element’s width twice, so it only bothers setting the second width — 0%. If you need to do a multi-step transition this way, you need to chunk the DOM manipulation into different events:

function startTimer() {
  var timerBar = $('timer-bar');
  timerBar.addClassName('full');
  setTimeout(function() {
    timerBar.addClassName('counting-down');
  }, 0);
}

Tricky, huh? This also applies in cases where you need to set a hidden element to display: block; before you move it around.

In Short…

CSS transitions make our games smoother, more lively, and easier to maintain. They’re not without their pitfalls, but once you master the basics, they’re an easy, elegant way to add a bit of zest to your UI. For more information (not all of which applies to webOS, unfortunately), see the Safari reference and the W3C working spec.

Dan Kurtz is the webOS developer at Self Aware Games, makers of Word Ace and Card Ace for the Pre and Pixi. Both are online multiplayer card games that make extensive use of the advanced JavaScript and CSS techniques available in webOS.

Introduce yourselves and tell us about Self Aware Games.

Self Aware Games is a small development studio, started in early 2009, to make games that use the new wave of mobile technology and social networking to let people play games together. That’s the official statement, at any rate. To put it differently, Self Aware’s a small group of people from wildly diverse backgrounds who work really hard to make games that people will love to play together.

Who are those people?

Self Aware Games is:

Colin Bulthaup Liotta: Engineer, tech pioneer, jack-of-all-trades
Dan Kurtz: Engineer, thespian, man-about-town
Crystal Silva: Artist, pugilist, gourmand
Seppo Helava: Designer, speed-writer, the guy you’re talking to now

How did you get started programming games?

Each of us at Self Aware Games had a different start into the industry – but Self Aware Games, itself, was started earlier this year. Colin and I, who’ve been friends since we met 13 years ago at MIT, had made a homebrew Game Boy Advance game with some other friends for a contest a few years ago. That project was incredibly fun, both to build, and to play, so when Colin & I each found ourselves with a little unexpected “free time” earlier this year, we were both really excited about working together like that again. To round out our skill-set and fill out the team, we brought on Crystal and Dan, both ridiculously talented folks, and Self Aware Games was born!

Can you tell us some about your development process and tools?

The development process is focused around answering the important questions as quickly as possible. Obviously, the most important question is, “Is the game fun?” But answering that requires you to break down the game, and figure out where the fun actually is.

For instance, with Word Ace, the biggest question is, “Is it fun to bet on whether you can spell the best word given a poker-style hand made up of letter cards?” On one hand, that’s a pretty simple way to describe the whole game – but you’ll note that nowhere in that question does it say that the game has to be in any sort of electronic form.

Before anyone wrote a single line of code, we answered the question with the cheapest, fastest tools possible: a pen, some index cards, and a stack of loose change. A cheap set of poker chips and an actual deck of cards that we wrote letters on came after that – but by playing the game with some cheap, quick mockups, and a handful of willing players, we learned a lot. When you want to play “one more hand,” and you end half the hands laughing manically, it’s a sure bet the core mechanics are right.

That took us two days – it showed us what was critical about the game, where potential weak points were, and what we might do to address them. One of the biggest things we learned was how critical the social aspect of the game was. Winning wasn’t winning without the ability to mock your opponents. From a gameplay perspective, this kind of rapid prototyping is essential.

For the actual implementation of the game, we took a bit of an unusual direction. When faced with a new platform (compounded by the fact that it was a new piece of hardware with a new OS), getting your bearings is always a challenge. When building a game, making sure the game works properly is always a challenge. Building a game on a new platform compounds those challenges and makes them 10x harder.

What we decided to do was to separate the problems as much as possible.

Dan took on the task of tackling the Mojo SDK and getting familiar with the Pre hardware. He was able to focus on just that task for a reasonable amount of time, because Colin took on the task of getting the game code up and running on a platform we already had experience with. Once the game was running, and relatively stable, Dan was able to build a webOS client for the game, focusing only on the problems specific to webOS.

This made development much easier and much faster than it would otherwise have been, and allowed us to get a really polished, really full-featured game onto a brand-new platform in a very short amount of time.

Where did you get the idea for Word Ace?

The idea was sort of shockingly simple, but there’s a funny story behind it. The first thing we’d done was to try to figure out what kinds of games the Pre’s audience would like, what kinds of games the hardware would support, and what kinds of games we’d want to make. Word games and card games were the obvious choices, and so we bounced ideas for those kinds of games around for a couple days.

At 2 AM one morning, I woke up suddenly, sat bolt upright, and had this idea about how to smash the two together. I banged out an e-mail to the gang, and promptly fell back to sleep. In the morning, when we all got together to talk about it, we were all really psyched for the concept. Turned out, though, that everyone had completely misunderstood my e-mail – which was sensible, given that it was a garbled, mostly incoherent 2 AM mess – but that misunderstanding was better than the original idea… so we went with that, instead.

We ended up making a  prototype the next day with a stack of poker chips and a deck of hand-written index cards. We played for half an hour, and all of us knew this was what we had to do next.

What drew you to the webOS platform?

Obviously, it’s a feature-rich platform. Coupling things like background processing with the Pre’s hardware keyboard, GPS, touchscreen, and persistent connectivity – the possibilities are ridiculous! I can’t say anything about it at this point, but we’d laid out some long-term goals for Self Aware, and webOS’s features enable us to realize some of those goals in a way that can’t be done on any other platform. I’m afraid that’s all I can say about that, for now.

What experiences did you have with other mobile platforms before starting on Word Ace?    Are all your games solely for mobile devices?

Self Aware Games was started at the beginning of the year – but team members’ development experience ranges across lots of platforms, from the Game Boy Advance to the PSP to current-gen consoles and the iPhone. Our first game as Self Aware Games was Taxiball, for the iPhone, which let us get our feet wet with this incredibly powerful generation of mobile devices.

Our goal isn’t to focus on a single platform, but rather, a single concept – using new technology to let people do things together. While things like Twitter let you keep in touch with your friends, it’s almost more a notification service so that you friends can know what you’re doing on your own. Things like Word Ace let you have a shared experience with your friends, and interact with them *while you’re playing*. The goal was to get that “playing games with friends in your living room” vibe, but online.

So, to that end, we’re not focused on a single platform – we’re focused on putting that experience wherever it makes sense to have it.

Were there many surprises while developing Word Ace?

This may seem a little weird, but the biggest surprise while developing Word Ace was how few surprises there were. From the original concept, to the paper & pen prototype, to the implementation in-game of everything from the core mechanics to the “frills” like the emotes and chat… almost nothing changed. There were a few tweaks here and there – the UI changed slightly, and some little details came and went, but the game was incredibly clear to everyone from the start – and over the course of development, the biggest surprise was how smoothly it all went.

This may not be surprising to the casual observer, but having worked in game development for the better part of the last decade, I’d never seen anything like it. Every project has something that goes horrendously wrong. This one didn’t.

How did the roll-out of Word Ace go?

Overall, the roll-out’s been spectacular. Response to the game has been overwhelmingly positive! We had a couple hiccups during the rollout, but we were able (with Palm’s gracious support) to iron everything out in a matter of days, and the game’s been running like butter ever since! People have had some really insightful feedback, which we’re working to incorporate into our next update – we’re constantly striving to make the game the best it can be.

Will we be seeing another game for the Palm Pre in the near future?  Will we be seeing a port of Taxiball?

It’s very unlikely that Taxiball will be ported to the Pre for a variety of reasons, mostly that Taxiball was written specifically for the iPhone – and porting it would require rewriting the game from scratch. We’ve got a huge number of ideas in the pipe, and with only four people, we just don’t have the manpower for the port. At some point, maybe – but it’s not in the cards for the foreseeable future.

But will you see more from Self Aware for webOS? Absolutely. One of the most-requested games for the Pre has been an online multiplayer Texas Hold ‘Em. I’m happy to say that we’re in the process of fulfilling that request right now. With all the features players love from Word Ace, like online multiplayer, Awards, in-game chat, and our unique emote system, we think our version of Hold ‘Em is what everyone’s been waiting for.

Word Ace has been very well received by the Palm Pre community.  Did you have any concerns or were you confident it would be a success?

Oh, there are always concerns – but we’ve had Word Ace up and running for months, so we’ve been playing it daily for a pretty long time. There were a few times where we were pretty sure things were turning out alright. We had some people over for a BBQ a couple weeks before the launch, and usually, our BBQs eventually turn into Rock Band parties. This time, though, everyone ended up playing Word Ace instead! For hours. Until their batteries all died. And then were talking about it the next day.

At that point, we were pretty sure the game itself was gonna be just fine.

How important do you think is the social aspect of Word Ace to its success?

In two ways, it simply can’t be overstated. First, when you surprise everyone at the table and take the pot, there’s no better feeling than knowing that it’s real people flipping their sad avatars and writing notes in the chat window. That social element makes the game what it is, and there’s no replacing it with any amount of AI.

Second, people want to play with their friends. That’s what Self Aware Games has been about from the start. All of our games have a social element to them, and Word Ace is the evolution of what we started to build with the leaderboards in Taxiball. Playing games to kill time is a fine distraction, but playing games with your friends is more than a distraction – it’s the kind of interaction that reinforces old friendships, and builds new ones.  And if we can get people to take a minute of their day to interact with each other, then to us, that’s the biggest success of all.

Will we be seeing some new Word Ace awards soon?

Yes. We actually have a whole handful of Awards that haven’t rolled out yet – there’s a really spectacular series of money-related Awards, and a couple sets of Awards that’ll roll out when we unveil a couple new features for the game.

Word Ace features premium chip options.  When will that feature be enabled?

That will be ready soon. We wanted to make sure everything was properly up and running, and past any usual launch “hiccups” before anyone even had the option of paying for anything in the game. With the last update, we’ve got those hiccups ironed out, and you’ll see the chip packages enabled shortly.

Thank you very much for speaking with us.

Thanks!

Updated: Added shot of the prototype game and a link to Seppo’s video.