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.

The Tread is a 'simple' single mode land vehicle in Second Life
The Tread is a 'simple' single mode land vehicle in Second Life. Simple to the user because it has been scripted with much user-centric complexity.

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 HUD for the Elemental is 100% buttons.
The HUD for the Elemental is 100% buttons.

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:

The Elemental HUD reveals additional UI elements and choices only as necessary
The Elemental HUD reveals additional UI elements and choices only as necessary.

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.

Note the invisible ramp prim affixed to the front end of this ground vehicle, used to skate over small obstacles.
Note the invisible ramp prim affixed to the front end of this ground vehicle, used to skate over small obstacles.

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.

Note the inconsistent movement rate of a typical land vehicle session.
Note the inconsistent movement rate of a typical land vehicle session.

By contrast, a similar graph for a helicopter user:

Note fewer speed inconsistencies, suggesting a better-controlled vehicle experience.
Note fewer speed inconsistencies, suggesting a better-controlled vehicle experience.

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.

Vehicle Use in Second Life: Spatial Distribution

As part of an ongoing effort to understand vehicles and their users in Second Life, I created a series of maps that depict where users of the vehicle that I’ve designed, the Elemental, go while they’re using it.

Currently there are about 100,000 Elementals in circulation on the Second Life grid.  About a third of those, or 30,000+, have been active in the last month or so.  There may be a better way to understand how many Elementals/users are out there and active, but I will let LL, Massively,  and Terra Nova wrestle that out.  It isn’t my focus.

When you make a gridwide plot of where the vehicles have been (about a quarter million records), you get a map something like the following, composed in ESRI’s ArcMap:

Point Plot of Vehicle Use Locations in Second Life

Using the Elemental use as a proxy for vehicle use more broadly, we see interesting tidbits emerge.  The outlines of the “mainland” continents are clearly  in the lower right quadrant of the map.  Vehicle use on private estates, by contrast, is much much lower.  This spatial relationship becomes much more apparent when we use a smoothing algorithm to interpolate densities of use between known points:

Density Map of Vehicle Use in Second Life

Density Map of Vehicle Use in Second Life

View this like a thermal image: lighter equals more dense vehicle use.  Black means little or none.  This kind of spatial interpolation is something of a ruse, though in the SL grid; vehicle use must be zero in True Void, that is, those gaps in the grid where no simulator is happily simulating away.  In practice, so much of the grid is the True Void.  In RL, the surface of the Earth has no such gaps.  Still it provides a useful visualization of vehicle use on the grid.

Interestingly, it is apparent that only a few dozen private estates feature vehicle use as  densely as the mainland.  I would speculate that this is due to region contiguity, that is, it is more fun to operate a vehicle on the grid when you have lots of connected sims nearby– you cover a 256m square pretty fast in a vehicle.  However, I must underscore that my speculation is just that.  Unfortunately, I don’t have an automatic way to evaluate region contiguity yet, or other possible contributing factors.

Zooming in a bit on the mainland areas and cranking down the search radius for the density algorithm, a clear hotspot for vehicle use emerges.  Perhaps unsurprisingly, the sandbox and vehicle regions in the extreme southwest of the old original landmass are the most densely used areas for vehicle use:

Old Mainland Vehicle Use

It seems clear that several ingredients are necessary for heavy vehicle use, which also appear to be unifying factors among the sims most heavily used above: clear, open, gently terraformed terrain, powerful servers (except in the case of water void sims, where few collisions occur) , and contiguity.

Note the clear visibility of the marine strait connecting the old main continent to the Lepidoptera continent to the north (lepidoptera are butterflies and moths, etc.).  Also, note the small cluster of sims to the far east.  I believe those are water voids as well.

Unfortunately, this reveals a powerful quandary in vehicle design: proper enjoyment of this aspect of Second Life requires large open spaces with unmediated access which are very expensive!  Given the tight competition of the vehicle market, I would be surprised to see any vehicle makers easily able to provide this kind of resource for customers.   Pontiac, a huge RL carmaker, is closing up shop in Second Life, shutting down one of the most active and well-managed vehicle centers on the grid. Lacking these resources, vehicle enthusiasts are more or less forced to rely on the largesse of void sim owners for space to recreate.  Food for thought.