With dimensions measured not in meters but in fractional sim lengths (“1/2 a region long!”) superdreadnaughts are the floating capital ships of the Second Life grid. They tend to be powered by some variant of Jesrad Seraph’s suite of multimove scripts. The net effect, while functional, is hardly elegant. The comparison to inchworms is natural– the only way to move a vehicle of several thousand prims is to break it into 254 prim (or fewer) linkset objects and attempt to move them in some semblance of cohesive motion. The effect is rarely convincing.

However, by dint of sheer size, the rare superdreadnaughts rule the SL skies. They generally feature broadside turret weapon arrays, staterooms, hangars & landing strips, integrated vehicle and personal weapon rezzers, and command bridges. Higher-investment assets also sport improvements like shipwide commsystems, shiplong axial beam weapons, and slaved dropships.

Style-wise, the superdreadnaught-class ship is almost without exception a sci-fi build.

Examples: Moo Spyker’s Prometheus (images here), Zypher Yao’s Zypherion (images here),

Non-examples: The floating mall at Alcyon Sector, since it is not actually a vehicle. Also the SS Antares is essentially a dreadnaught-shaped building, highly detailed for roleplaying purposes, but unable to move under its own thrust.

This dreadnaught-like building serves as a well-themed floating mall, but is not functional as a flying vehicle in the traditional sense. Note author seated on upper deck, foreground for scale.

Dreadnaughts – megaprim single linkset

Frigates – cabin craft like the ever-popular Halo video game series Pelican

Runabouts – personal craft
–vehitars

–transforming vehicles

Tinies vehicles really fall under all the same categories as above, but they are appropriately scaled down a bit.

RC vehicles are vehicles at an API level (meaning, they use the same code that normal vehicles do, they simply lack the subroutine to check for the seated presence of an operator before enabling physics.

Regardless of genre: modern, sci-fi, whimsical, organic

Regardless of originality: IP theft to completely original

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 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.

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.

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.

By contrast, a similar graph for a helicopter user:

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.