A Sense of Place

I was going to write a long and tediously boring piece about the importance of designing virtual environments which have a "sense of place." A sense of place is that ephemeral quality which makes one environment/building/world/place unique from another. I was going to bore the spare few of you who stuck around to read the whole thing to absolute tears. Then I found this article over at Planetizen, which looks at the same thing through the lens of urban planning, and it does it in a refreshingly amusing way: Jargon.

For example, where else will you find the definition for the acronym BANANA? (its Build Absolutely Nothing Anywhere Near Anything, by the way).

Some of the terms are very exclusive to urban planning, but a healthy majority apply in one shape or another to the practice and politics of virtual world design and building.

Why Virtual Worlds Need Procedural Content

I'm going to break from discussing abstract concepts of community building and environment design to talk about another important aspect of virtual worlds: The Technology. In specific, I want to talk about the way we create and deliver content in virtual worlds, and how we need to start thinking differently about it. As always I'll be talking about it in regards to Opensim, but it pertains to every platform.

Put in as simple terms as possible: We need to expand the use of procedurally generated content, otherwise grids and Opensim will be too bandwidth heavy to expand effectively.

What do I mean by procedural content? Prims are actually a good example. Instead of sending a complete model of a complex object (say, a house) from the server to the user's viewer, the server sends what is in essence a recipe on how to make it; a set of instructions which the viewer then reads and follows to rebuild the model. It requires a little bit more crunch-work by the viewer, but the difference in amounts of information required is monumental. How monumental you ask? Well, consider three separate games which have used procedural content to their advantage. I'll go through them in order of file size from smallest (and most indie) to arguably the largest.

.kkrieger: Weighing in at a measly 96kB, kkrieger is a fully functioning FPS. Created by the (defunct?) demoscene team theProdukkt, it's a excellent example of how much can be done with so little. Here's a video of somone doing a playthrough; I can guarantee that the video is far larger than the game itself.

Minecraft: This freeform exploration/survival/world building game emerged out of obscurity late last year and has gone on to become a massively popular indie game. Despite its unassuming graphics, it boasts a impressive piece of procedural technology. Every world explored by each player is completely novel, generated procedurally when they start a new game file. These are not small worlds by any stretch of the imagination, the most common estimate passed around is each is eight times the surface area of the Earth. Even once you've explored and significantly altered the environment, the world files only grow to a few megabytes in size. Not too shabby.

FUEL: A major title on a actual console, from a team with a actual budget? Yup. That's right. Rather than restate what's already been said, I'll just direct you to Shamus Youngs' excellent article about it and its accompanying video. If you're looking for a quick overview, I recommend the video.

Pay attention to what he says at the end: The technology would be ideal in a open world sandbox-style game. Sound like Opensim to you?

We've already established that Opensims' use of prims is pretty good procedual handling for geometric shapes, but what about everything else? It is very possible to create procedurally generated textures, procedurally generated organic shapes, even sound and character animation. Utilized correctly with traditionally produced content, they could help keep bandwidth usage low while improving the immersiveness of the worlds. Also, consider the added bonus to amatuer creation it could bring about. Part of what makes SL and Opensim so fun to build in is the fact that anyone can pick up tools in-world and begin building something that the can share in real-time. Why not do the same with other content?

Building procedural tools won't be easy, and will probably require a patron organization dedicated to seeing them implemented. Ultimately, their utility would be well worth the effort.

Architecture in Virtual Worlds: Designing Structure with New Constraints

Of all the topics I've proposed talking about, adapting architecture for virtual environments seems to be the topic that has attracted the most interest. Let me preface this with the caveat that I am not a architect, and my observations stem far more from a designer standpoint. With that in mind lets talk architecture:

To my mind, good architecture can be thought of the aesthetic division of space using structure within a set of rules (the limits of engineering/material science). Skyscrapers, bridges, and cathedrals are good visible examples of this, although any building operates under the same principles. Each operates within the rules of material science and engineering to define a space for some purpose or use. Ideally they also transcend the bare utilitarian requirements and become an aesthetic creation.

In virtual worlds, the same standard applies, but with slightly different rules. Its the difference in the rules where many would-be virtual architects go astray. In many cases, simply replicating a real-world design into a virtual environment creates a unanticipated disappointing experience.

One major difference is that the main rules which constrain real world architecture (physics, engineering, cost of materials) do not directly apply to virtual environments. A digital model weighs nothing, and it is generally more efficient to simply ignore the physics of a static structure within a virtual environment anyways. Aesthetically, this gives virtual architects a unparalleled degree of freedom. However, we have new limits introduced by the inherent nature of virtual environments. Let's go through a few of them (I'm sure I'm forgetting several) and their implications using Opensim as our example:

Movement Constraints:

In the real world we can't fly, nor can we teleport. Real world architecture is therefore built to maximize access to all places by way of walking. While you can impose these limits within Opensim, you may have users complaining unless you give them good reason why you're stripping them of something that is inherent to the world. For virtual architecture, this means you should consider how people are going to move around your structure as well as enter and exit. Whatever you decide, make sure it is clearly communicated to visitors, nothing says bad user experience like a user wandering around a sealed structure looking for the exit because the don't know you can only exit via teleport. Movement options such as teleport also diminish classical notions of privacy and limited access.

Scale of Interface:

When a user interacts with a virtual environment, they do so through the small window created by their viewer. Interfaces like light switches and water taps may be fun to poke at in a virtual environment, but they aren't nearly as useful as they are in the real world. This also means that textual signs and graphical cues need to be appropriately sized for a user to comprehend.

View Constraints:

The flexibility and freedom of the user's ability to manipulate their view is one of the most interesting challenges inherent to architecture in Opensim. In the real world, we can only see things in first-person, which is not something we can count on in virtual environments. Because the designer can't assume the level of skill which the user will have with operating their camera, or even which view they will be using (third person, mouselook, or freecam) we must design our structures to be navigable, understandable, and enjoyable regardless. Much like movement constraints, the viewing constraints also eliminates many precepts of privacy that real world architecture relies upon.

Efficiency:

While virtual architecture is not constrained by the monetary cost of building materials, there is another cost factor which must be considered: how work intensive it is for the simulator and the client to operate and display the structure. This also includes how intensive the download is for the client. A structure which takes an excessive amount of time to download, which bogs down the frame rate of the client, or which bogs down the server with greedy scripts degrades the user experience for everyone.

Communication Methods:

In the real world, sound is king when it comes to communication. Text based communication is a optional accessory. The opposite is true in most virtual environments, in fact in many cases it is worth assuming that the user cannot hear or communicate by voice. Therefore, the concepts of designing structures to facilitate communication via voice apply far less to virtual worlds, although there is still some crossover.

Rather than turn this post into a TL;DR treatise, I'll end this here. I'll follow up with some more posts about what the new priorities virtual architecture are given our new constraints, and perhaps go into further depth on each of the limits.

Thursday Link Post: Nov 18

It's Thursday, which means the weekend is right around the corner. To help you fend off that end-of the week slump, here's a collection of gridbuilding related links for your reading pleasure:

Jor3l posted a extensive collection of Opensim logo banners for your website/blogging/sticking-on-the-back-of-laptops-because-you're-awesome-like-that needs.

Kenneth Rougeau has been posting a excellent in-depth multi part blog series on implementing NPCs into Opensim, including AIML (Artificial Intelligence Markup Languange) integration.

Finally, Maria Korolov posted a interesting article regarding the growth of virtual currencies in Opensim. Not too surprisingly, Inworldz 'I'z' currency is seeing some serious growth, outpacing OMC handily.

A Quick Note

If you're interested in the technical nuts and bolts of how OpenSim might grow into a Internet-Scale architecture, I highly recommend Justin Clark-Caseys' excellent paper on the topic: "Scaling OpenSimulator : An Examination of Possible Architectures for an
Internet­Scale Virtual Environment Network"

Its definitely for those of you who don't mind wading through a document filled with technical jargon and concepts, but worth a read. Justin does a excellent job illustrating both the promise and the problems embodied in OpenSim today, and his prescriptions for what needs to be done are insightful.

Community as the Metric

In this post I'm going to speak very generally about virtual worlds as a whole, but it applies just as much to virtual environments of any scale, right down to a build on a rented parcel.

It might seem like a painfully obvious truism, but a surprising number of virtual worlds fail to realize that their very existence hinges on one thing: Community.

It's very easy for a virtual world operator to get caught up in easily digestible numerical statistics, such as the number of new registrations, the percentage of logins, or the financial turnover in a given period. As useful as such statistics can be for getting a quick-and-dirty sense of activity within a virtual world, it does very little to illuminate the actual engine which drives it. The health of a community is very hard, perhaps even impossible to measure in numerical metrics, but its' importance to the survival of a virtual world cannot be understated. No matter how pretty your content may be, if no one sees your virtual world as their social forum of choice, all you have is a very pretty, very empty virtual environment.

Good content, kept in fresh and abundant enough supply can string a virtual world along for a while as a sort of virtual cargo cult of players obsessed with new content keep returning for more. Ultimately however, this puts the strain on the world operator to stay ahead of demand for new things, lest the cargo cult wake up and realize just how lonely your virtual world makes them feel.

Likewise, good functionality (like integrated games) can keep bodies in a virtual world for a while, but unless the functionality is social in nature, forget it. All you've done is taken a solitary experience that could have been performed on their own computer and moved it into a online environment. Unless you have a darned good reason why it belongs there and not as a local application, your players will wise up and eventually wander off.

So with all of this doom-saying said, how can a virtual world operator determine and maintain the health of a community within their world? Not surprisingly, it requires moving from a passive monitoring role into a active role within your community. Engage with players both as yourself, and as an anonymous visitor. Find out what they like, what they don't like, what they spend their time doing, and what they avoid wholesale. Their answers may surprise. The reason for the double role is fairly simple, people act far differently around a perceived authority figure (the VW operator) than they do around someone perceived more or less to be a equal. Unless a player has a real bone to pick with the operator, they probably won't be as forthcoming face to face as they will be with someone else. For bonus points, roleplay as a new player; the health of a community can be exposed very often by how easily they will accept someone new into the fold.

As an extra step, give the community every possible avenue which makes sense to communicate betwixt themselves and to the operator. It often makes sense to create a web-based forum, a blog for official news, and a Twitter/Plurk/Facebook presence as well. Whatever choices are made, its worth noting that communities are pragmatic organisms first, and as long as they aren't interfered with, they will organically grow communication methods of their own. If they find they can socialize better through these outside methods better than through the virtual world, know that it's not unheard of for a community which coalesces in one virtual world to abandon their original world to move to greener pastures.

The bottom line is this: Communities are difficult, fickle things, but ultimately they are the reason for virtual worlds in the first place. A good community can take a mediocre world and transform it into a gem, a bad one can turn a gem into a ghost town. Ignore the health of your community at your own peril.

A Topical Map (as it were)

I'm still assembling a lot of my thoughts, but at this moment here's a list of things I definitely know I want to address. These may become full posts, some may become even more than that. Some may disappear completely, lost somewhere in the whole mind-blog transmission process.

Community as the Metric
Functionality and Aesthetics: An Essential Duality
Designing for Community
Games as Social Utilities
The Content/Community Paradox
Architecture in Virtual Worlds: Designing Structure with New Constraints

I know for certain I'll think of more shortly, and please feel free to suggest others in the comments. I'm really looking forward to writing about all of this!