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.