Welcome to the Wolfire Blog! This is where we keep everyone up to date on our progress on Overgrowth and other new stuff. Be sure to subscribe to get the latest news! Also, be sure to check out the forums for even more up to date news - or get on IRC for up to the second updates.

Working as a game developer, I often find myself thinking about everything in the terminology of games and programming. Sometimes, to change things up, I like to find a piece of jargon from a completely separate field and try applying it to my job. Politics is a gold mine for jargon. Maybe we can apply political concepts to game development. For example, what would it mean to make a Communist path finding algorithm? Would subprime lending be dangerous for a vertex shader? Okay, sometimes it's a bit silly. But sometimes it strikes a chord.

Libertarian paternalism is the political philosophy that the state should nudge citizens toward socially beneficial behaviors (paternalism), but only in ways that do not constrict the citizens' freedom to choose otherwise (libertarianism). In practice, this might mean setting up smart defaults. A company's employees might, for example, be automatically enrolled in a retirement savings plan. Rather than having to opt in to the plan, they would have to opt out. Since people tend to stick with the defaults they are offered, choosing these defaults wisely is an important and unavoidable responsibility.

Paternalistic design

How do we apply this political philosophy to the problem at hand: tool design for Overgrowth. First, let's look at what we can learn from paternalism alone. This is the philosophy that an authority figure should make wise decisions on behalf of others. Certainly, this is part of a tool designer's mandate. New users usually want a helping hand.

How can we help them? There's an oft-repeated maxim that 80% of an application's users will use just 20% of the applications features, or, similarly, users spend 80% of their time using 20% of an applications features. This suggests a way to organize our toolset. Instead of laying everything out at once, we should guide the user first and foremost to that 20% they will most often be using. And why not just cut out the 80% bloat?

...with a libertarian twist

Unfortunately, the paternalistic approach alone has some pitfalls. As Joel Spolsky points out on his blog, the most important 20% is different for each user. So, lightweight applications, which preserve only 'essential' features, often don't satisfy since everyone has one or two esoteric bits of bloat they cannot live without.

In addition, overly paternalistic guidance can be irritating and disruptive. When you master under-the-hood tuning, you don't want the program to fight against you and reset everything back to what it thinks you really wanted.

This is where the libertarian part comes in. Each user should have the freedom to find their own quirky 'bloat' features and run with them. And, expert users should not be held back by any tutorials, warnings, and railings that are in place for novices.

Overgrowth case study: decals

The two decal display modes. Left is 'surface mode'. Right is 'projector box mode.'

How can we gently guide a user through our tool set? For the Overgrowth decals, I tried to do this by including two display modes: the simpler 'surface mode,' and the trickier 'projector box mode.' By default, each decal is in the simpler mode. My hope is that this will guide users to generally interact with the decals in an intuitive way. Surface decals can be dragged, rotated, and scaled, but they sweep other details behind the scene: they automatically align to shoot straight at the ground, and there is no way to adjust their projection distance. However, for those special cases when a user needs full manual control, a simple keypress ('p' at the moment) pops out the full 3D projector box.

Since the pillows were placed after the moss decals, the moss does not project onto them.

How much routine functionality can we put on autopilot? As I've added more special case tools, I've realized that I usually don't want to have to deal with them. Most of the time, I just want the objects to behave in the most obvious ways. These obvious ways we can automate.

For example, awhile back I added a way to tell each decal exactly which objects it should project onto and which objects it should miss. After a bit of use, it became clear that in almost all cases I followed just a few simple rules. If I place a new object on a mossy hill, I want the new object to sit on top; the moss decals should automatically miss the new object. Similarly, if I drag a rock up the hill, it should lie on top of any new decals it encounters, but remain underneath the old decals it was originally underneath. Now, the editor automatically takes care of this. Of course, there is still an override. The user still has the freedom to explicitly manipulate the object miss list just as easily as before, but hopefully this will not often be necessary.

In many ways, a good information graphics excels at libertarian paternalism. It gently guides the viewer to the most important theme (here it's the dwindling troops in Napoleons army) yet generously displays a wealth of other information the viewer may freely explore (army size, location, and movement direction through time).

By learning from the philosophy of libertarian paternalism, I think we might be able to create tools that achieve a smoother transition from novice to expert use: Paternalistic guidance for the simple, common stuff, and libertarian freedom when you want to get under the hood.

Do you guys think this is a good design approach? What other ways might libertarian paternalism be applied to design, and what other disparate fields and ideologies could we look to for insight on game development.