Designing Effective Vehicles for Second Life

Elegant vehicle design in Second Life is easy to pick up, hard to master.   I was noodling around Balance— the old-school vehicle testing sim– in a 2009 Tread, and realized that a few useful design decisions surface again and again in each of my successful vehicles.

Time to reflect on vehicle design principles a bit using some experiences, actual SL vehicle use statistics, and broader design ideas from the web and beyond.

Simple Dashboard, Powerful Engine

Perhaps my most fun (my metric for successful) vehicle in Second Life is the Elemental.  It transforms into about a dozen distinct vehicles: planes, airships, hovercraft, cars, submarines, etc.  Very early on in the design process for the Elemental, it became clear that a dozen (now even more than that! Crazy.) modes would need quite a user interface to keep things fluid and easy,  so that these extra features were fun and not a hindrance.  Immediately, the decision was to use a Heads Up Display (“HUD”).

The reasoning was simple.   Before SL added HUD attachments, users had to endure experience-disrupting blue dialog windows for the rare vehicle, like the Dominus Shadow, that was smart enough to use them.  Much more often, a user had to:

1. learn chat command syntax (e.g., “start” and “hover” to activate various vehicle functionality)
2. remember the syntax across sessions
3. take the time to correctly type out the command, time away from having fun
4. understand what the command would do

It is an experience design disaster.

So instead, Elemental users got a smart little HUD, where only the absolute minimum visual information necessary was displayed at any given time.  This is a design principle that Google, Inc. has in its very genetics, closely regulating the number of words on its homepage.  From a user experience standpoint, every moment my mouse is buried in the HUD is a moment I’ve lost forever.  So the HUD uses collapsing menus:

This way, new users have a gentler learning curve.  Why?  Because SL has been hard to learn since Day One.  No need to make it any more frustrating.  This was especially important when I was designing vehicles through Electric Sheep Company for Nissan, Reuters, and other companies interested in having an engaging presence in SL.  They were bringing totally new users inworld, so things had to be dead simple to learn, but fun.

Of course simple, intuitive UI does not mean boring.  The Elemental is still one of the only vehicles to pack a dozen modes, cloaking, three combat systems, 5 point sound, skinning/coloring/custom license plates, decals, Tiny mode, autopilot, onboard music, and more.  But the point is that the decisions to use or ignore all these elements aren’t all clamoring for the user’s attention.  They are neatly tucked away, ready for when the user is ready to explore more fun.

A similar principle applies beyond HUDs, right into the physical shape of the vehicle itself.  When I was in the process of designing the precursor to the Elemental, the Tread, a series of informal qualitative interviews helped me to understand that the prims I was gluing together were more than a chassis, they were the user’s avatar with respect to the physics engine.

The ramp on the Tread above is invisible to the user, completely unannounced unless the user decides to edit the vehicle and discovers it for him/herself.   Given the extremely haphazard environment in SL, users get stuck in vehicles all the time.  So behind the scenes — under the hood, if you will– we vehicle designers have an obligation to protect the user from the sligns and arrows of cruel grid life, without limiting the user in his or her options.  Simple hacks like adding invisible ramps and the ability for cars to either jump or fly adds orders of magnitude more spaces that your users can access. And that means more fun for them and better-satisfied customers for you, the designer.

To drive home the point (pardon the pun): the following graph is a time series (x axis)  of vehicle velocity (y axis, m/s) for a typical Elemental user.   Note the average speed, but even more importantly, note how jagged the graph is.  This is a user battling rough terrain and the normal clutter of SL, trying to have fun.

By contrast, a similar graph for a helicopter user:

If you can hack an existing vehicle script to perform how you like, you can add a hover mode or jump functionality.  No excuses, do it. We all win when the general calibre of vehicle designs in SL gets elevated.

Who cares if cars can’t fly or jump in real life?  The immersion vs. augmentation shtick has been done to death for years now. At the end of the day, users still get stuck in vehicles too easily, when the vehicle desingers can easily solve that problem a priori.

Bottom line for this aspect of SL vehicle design: think so your users never really have to.  Not that they can’t.  Just that they shouldn’t have to if they don’t want to.