Yes. I’m talking about Opensim even though I said I was moving away from it.
I am aware that all three of these things makes me a Grade A Shlub. I’ve also decided to stop letting those three things stop me. I’m also going to stop pretending to have a more refined writing style.
Leslie is a bad idea because while LSL was a decent attempt to solve the problem of giving users the power to add interactivity, it’s pretty much a dead end. LSL works (sort of) when you’re Second Life and Linden Lab can make assurances that each sim will have pretty much the exact same implementation and features.
You can’t make that assumption with Opensim. One sim might have modules for better combat, another might have a completely new way of handling in-world purchases. This adaptability is one of Opensim’s greatest strengths, and LSL holds it back. Leslie was going to solve that by tacking on more complexity to deal with that uncertainty.
No. Bad Alan. No Biscuit.
LSL already has enough exotic features and odd conventions that scare away established programmers. Adding more won’t help one bit. On top of that, recompiling incoming scripts in entities moving from one region into another is a contributor to the dreaded region crossing hang. The extent of that is arguable, but it is definitely there.
What’s needed is a solution that goes in the other direction. We need a solution which is friendlier to in-world creators, friendlier to module creators, and friendlier to overall performance.
Tune in next rant for my idea which will hopefully be less wrong than Leslie.
LSL/OSSL were and are responsible for imparting a great deal of the interaction magic which has made SL and Opensim be what they are today. However, the language (they really are the same, just with a few different command sets) is hobbled in a few ways which really prevent it from moving past the stage of a toy language and into the realm of a useful language which could be used to develop serious functionality.
Additionally, the current way LSL/OSSL is structured, it is strictly bound to platforms very much like SL/Opensim, meaning that there is a catch-22 of adoption. Fewer users mean fewer scripters which means fewer things done with the language that inspire new users to join.
As I shift my focus to OHM (which will also need a scripting language), I’ve been designing a new hypothetical scripting language based very heavily on LSL that solves some of these problems and a few more. I’m calling it Leslie (LSL-Evolved).
Here’s how Leslie differs from LSL:
All platform-specific commands are stripped from the command set. Leslie doesn’t implicitly know about or care about regions, agents, etc. This not only makes Leslie easier to learn, it makes it far more portable to other contexts.
The addition of a command module add-in system and commands to detect the presence of modules. Platform-specific functionality can be mixed back into scripts through this feature, as well as novel functionality provided by other modules.
Commands to handle the execution of the script, such as the ability to kill the script, or start another script included in the object. The Leslie model does not assume that all scripts are automatically running, and these commands allow for a much more intelligent use of system resources, provides for compartmentalized code and adaptive behavior based on modules present in the environment.
Boolean variable type to replace the cute but ultimately badly designed use of the integer type for boolean operations.
An external template-based structured data-type similar to flat JSON. This frees programmers from having to rely on strided lists for any kind of complex data representation. It also allows Leslie to have struct-like data but without resorting to dot notation and maintains the asynchronous data and event model LSL already has.
These differences are designed to make Leslie portable, expressive, and useful to professional programmers while retaining much of what makes LSL already work. The result for environments like SL/OS would be increased functionality, better memory footprint, and utilizations of the platform which simply haven’t been feasible up to this point. I plan on documenting Leslie more in the future, especially the struct model which requires more explanation. This is by no means a finalized design, and I would love feedback from the community on Leslie.
As I work on designing the specifications for OHM, I can’t help but think that many would ask me what point I saw in such an undertaking. It’s an excellent question, and one which I struggled with for some time. Indeed, it was one of the main questions holding me back from embarking on the endeavor.
The point of OHM is mostly this: The world sorely needs the collaborative social benefits that a fully realized Metaverse could bring, but it hasn’t received such a Metaverse yet for a host of reasons:
Most Metaverse implementations currently are too inflexible to be useful beyond a certain small range of uses.
Building/Deploying a virtual world platform is still a massive undertaking, so most who do end up focusing on implementations and deployments designed to make money to recoup the costs of the effort. This generally leads to closed systems.
There is very little effort being expended on building a set of shared protocols for a Web-Scale Metaverse. Such protocols would lay the foundation for true interoperability.
The repeated media hype cycles focusing on various implementations have drained a large degree of the general public’s enthusiasm for the Metaverse. Breakthrough usefulness will be crucial to countering the public’s well-earned skepticism.
I feel that the point of OHM is to address these problems head on. OHM is designed to be flexible to be used in a very wide range of ways. It is designed to have minimal startup costs, allowing for a more open ecosystem of implementations and deployments. OHM is also fundamentally a set of shared protocols and specifications much in the same way the Internet is. This gives developers a shared set of blueprints from which to work and reduces the amount of wheel-reinvention necessary. Finally, OHM is designed to quickly evolve to hone in on what is useful to users, allowing for the conversation on the Metaverse to begin afresh.
This is not a small undertaking and I recognize there is a very strong possibility of failure. However, I believe we have only barely glimpsed at the transformative potential of the Metaverse, and I gladly vest myself in this effort to deliver that potential.
Right now, the Social Internet (of which I will include the Metaverse for brevity) exists in a state of virtual feudalism. We as users inhabit kingdoms of proprietary service ruled over by rulers of largely unchallengeable authority. Through our participation in these services, we create value for the kingdom, but rarely if ever does that value move anywhere but to the lords of the land. While these kingdoms rise and fall, rarely do those but the lords of the land wield any true power.
These kingdoms are sometimes not absolute in their insularity and may in fact allow their subjects to interact with those from other kingdoms. However this is allowed only so long as the keepers of the kingdom deem it beneficial to the might of the kingdom.
This mentality of kingdom-first preempts even our fundamental rights as humans (to privacy, freedom of speech, etc). Dictates may be passed down without notice, and forces brought to bear without recourse.
To say this is the natural way of things or that the Social Internet mandates such authoritarianism is absurd. Our rights do not end where our fingers touch the mouse, keyboard, or touchscreen. There is no natural order which mandates that such monolithic empires of services are the only way.
We are in need of a Renaissance. We need services which start with an absolute guarantee of individual sovereignty and which build from their to form larger woven patterns of association. Efforts such as Diaspora* are a good start, but are only just that: a start.
This position is not a new or singular one. The technology to deliver us from virtual serfdom already exist. The tools are in hand. We must now use them to craft a better future Of the Users, By the Users, and For the Users.
Open protocols are important for the same reason literacy is important.
When literacy in a language is low, the conversation can only occur between a very limited set of individuals and the discussion tends to stagnate. The language also becomes stiff and difficult for an outsider to learn. Conversely, when literacy is high, the discussion retains its dynamism and the language remains approachable.
Open protocols provide a down-payment on the literacy of developers to be able to collaborate on large complex software systems, such as those found in the Metaverse space. To my mind, the Metaverse space has largely been suffering from a literacy issue. This is one of the reasons why I am focusing first and foremost on protocols as I design OHM.
Dear Opensim, It's not you, it's Me(taverse Protocols)
It’s time we sat down and had a talk. I’ve been putting off telling you this because I didn’t want to hurt you, but I can’t keep hiding this from you. The truth is that I’ve found someone new and we’ve been very involved for some time now. It’s name is OHM, and it’s a set of open protocols for building a web-scale Metaverse. We’ve been together for several years, and things are starting to get serious.
Now please don’t blame yourself, you’ve been wonderful and the things you do make you special, never doubt that. The fire’s gone out on my end of the relationship because I’m just not the kind of guy who can settle down with just one virtual world implementation, even a special one like you. I need more freedom to evolve and grow than you can offer Opensim, and if I stay I’ll only get pent up and frustrated. You don’t deserve that, and I don’t think its good for me either.
Even though I need to move on, I’d still very much like to remain friends. After all, it’s not that I don’t like you, it’s just that I can’t keep pretending that I’m faithful to you. I hope you’ll come visit some day, I think you’ll really like OHM once you get to know it.
Take care of yourself Opensim, after all there’s no one else in the world quite like you.
I’m not an expert on Second Life, far from it in fact. Excluding yesterday, it’s been over a year since I have logged in to explore it. Every time I return I ask myself why I waited so long, because I always enjoy my time I spend in the world. Perhaps a bit too much and my self-preservation kicks…
Up until now I and most others have awkwardly used the terms HyperGrid and (Open) Metaverse interchangeably as though they were the same thing. The more I think on this, the more I am convinced this is short-sighted and only serves to confuse things.
The HyperGrid is not the entirety of the Metaverse and shouldn’t be. It’s tempting to think of it as such, but ultimately, the HyperGrid is just a Opensim-centric prototype of what should be a larger vision.
There are and will be other platforms which provide equally compelling solutions to the challenges of the Metaverse. The end goal must be to create a seamless open system in which a Metaverse user can interact with and move between a wide variety of these platforms.
It is with this in mind that I propose a new term to describe such a system:
Open Hyperlinked Metaverse (“OHM”)
OHM makes no suppositions about whether the worlds linked together are Opensim, Aurorasim, RealXtend, or Wonderland. It assumes only that it is an open network of virtual worlds which allow travel between each other much like the HyperGrid allows travel between compatible worlds today. Indeed, OHM may end up as an advanced version of the HyperGrid protocol, evolved to expand it’s assumptions to facilitate a wider variety of worlds.
The name OHM also has some nice features:
It’s a lot less clumsy/wonkish to say than “HyperGrid” or “Metaverse”.
The path of least resistance is tempting, seductive even. It lulls us into doing the bare minimum and following the easiest path. It doesn’t ask much anything of us, it’s comforting, predictable, and seemingly safe. That path is not the path the Metaverse should take, because it’s a long gentle path into oblivion. We need to take the other path, the one that’s nearly a sheer cliff and has no clear markings. We need to take the Path of Most Resistance.
The Path of Most Resistance means asking ourselves the tough questions about what’s not working with the way things currently are and then fixing the problems. It means keeping a strong spirit of imprudence and scepticism, challenging what we think we know from what we can actually prove to be so. Sometimes it means rebuilding something from the ground up because we just can’t keep slapping patches on the old version. It means trying things that we know may not work.
Let’s not kid ourselves, it’s the route that most people avoid and will go out of their way to tell us to avoid as well. It is also a path which will be hard, confusing, and sometimes even scary. But the destination at the end of the Path of Most Resistance is worth the struggle, the risk, and the uncertainty. The destination is the fulfilment of seemingly impossible dreams and the utter reshaping of the world around us.
We can follow the Path of Least Resistance and let the dream of a Metaverse fade into the night, or we can choose the Path of Most Resistance and usher in a new dawn.
Right now, getting help with things related to Opensim is a bit confusing and scary for new users. Because Opensim is so new, there’s a lot of possibilities for things to go right and even more for them to go horribly wrong. There are a lot of good resources for Opensim, but no easy place to find them. New users who don’t know a region from a viewer are the ones who need the most help, but have the least idea where to go to get that help.
I’ve started a new website called GridHelp! to try and make that better.
Here’s the three things GridHelp is going to provide:
A Q&A service that lets users post a question and solicit answers from the community
A Knowledge-base wiki filled with fleshed out solutions to common problems and resources throughout the community
Tutorials and FAQ articles written in plain English for normal people
GridHelp still very much under construction, but it’s up and running and ready for action. You can follow GridHelp on Twitter for updates and to ask questions. To ask a question from Twitter, just send a tweet to @GridHelp use the hashtag #needHelp.
If you’re like me you like the idea of making big, complex things in Opensim. You’re probably also frustrated that there’s really no good way to pass messages back and forth securely between objects. What should be a simple procedure suddenly turns into a horrendous tarball trying to work around the limitations of Opensim’s messaging model. This shouldn’t be the kind of thing getting in the way of creators with big dreams. I decided to try and fix all that.
Building big things in Opensim shouldn’t make you want to pull out your hair.
It’s my pleasure to introduce PubSubmarine, a simple secure script messaging system.
PubSubmarine is a region module that makes it easier for objects to create,share,and use secure communication channels called Topics. It does this by adding a few more custom commands to the scripting language that let script writers quickly and easily tap into PubSubmarine’s power. Like the name hints, PubSubmarine follows the Publisher/Subscriber model, meaning that many scripts can subscribe to a topic channel and all get the same messages. It also means that neither the broadcasting scripts or the subscribing scripts need to know the identity of any other script.
One of PubSubmarine’s main priorities is security, and therefore it’s been built so that only the scripts with the right authentication can access the topics. Authentication is split up between publishing and subscribing, meaning you can decide who can broadcast and who should just listen. Unlike chat channels, PubSubmarine passes messages to subscribers anywhere in the region regardless of distance. It uses the link_message event to pass messages, meaning messages are efficiently delivered and only to the intended recipients.
How easy is PubSubmarine to use? Well, here’s a simple script that makes a new secure topic and publishes “Hello World!” to that topic every time it’s touched:
PubSubmarine is still not quite ready for release, I’ve got a few things I need to polish before it’s ready for prime-time. For instance, the recent release of Opensim 0.74 means I need to add the actual commands shown above instead of using the horrible clunky modSendCommand() method. I’ll be keeping you up to date with it’s progress. In addition, I’ll be posting up some more in-depth documentation on how it works.
This article just barely scratches the surface of what PubSubmarine is capable of, and I can’t wait to see how others will put it to use. Let me know in the comments how you think you’d use it, or how I can shape it to make it even better!
Writer’s note: Apologies for being silent as of late. While I hope to eventually be able to turn my full energies toward the Metaverse, I am currently at the mercy of a new schedule which leaves me on a fraction of the day to focus on much outside of work and family. Watch this blog and my twitter account for updates as I shift things around.
"Let me never fall into the vulgar mistake of dreaming that I am persecuted whenever I am contradicted." -Ralph Waldo Emerson
Thank you to everyone who helps to turn my occasionally unhinged diatribes into serious discussion. Thank you for sharing your insight and your honest opinions, they are more valuable than a million ass-pats.
I’m going to propose something heretical: Rather than focusing on making mega-regions, we should be focusing on making smaller ones. Specifically, regions with a quarter of the footprint of what is the current standard.
Why? Funny you should ask.
Quick note/disclaimer: These are largely the result of study/research from a moderate distance from the actual nuts-and-bolts, so many of these points may have issues with them. If you think I’ve gotten something wrong, feel free to join the conversation in the comments and point out where I’ve gone awry.
Reason #1: Regular-sized regions are too much for small projects
The open Metaverse is (for now) largely composed of driven individuals creating small projects for themselves. 256m x 256 m is too much room for most of those projects. Dropping the size of regions will help greatly to combat the dreaded sprawl-bloat of mostly-empty regions which plagues grids everywhere.
Reason #2: Quarter-sized regions = 4x the population density
Note: There’s some contention over this, check out the comments.
A common gripe about OpenSim is the fact that you can only fit around 20 people to a server before it gets unstable and crash-prone. By making regions which are 128X128, those server resources are in effect quadrupled, allowing more users to occupy the same land footprint. This is critical for pushing the social aspects of OpenSim, which in turn is critical for the long-term adoption of the open Metaverse.
Reason #3: Smaller regions are better for web and mobile
OpenSim, in it’s current incarnation, is incredibly punishing for even well-provisioned gaming computers. If the open Metaverse is going to expand out to the web via WebGL and to mobile devices, it needs to go on a serious computational-resource diet. One good way to start is to chop down the size of the regions. Generally speaking, smaller regions will contain less things for a mobile or web viewer to draw, making them far more manageable.
Reason #4: It forces us to deal with region crossings
One reason we have gravitated toward mega-regions is that we hate the horrible, unreliable experience of region crossings, especially for anything involving vehicles or complex scripted objects. Mega-regions are a way for us to avoid dealing with that problem. Avoidance is bad when it comes to critical technical challenges like this. Smaller regions give us an intervention and force us to face the challenges head-on. Whatever the end solution may be, it’s one we can avoid for only so long before, like an overdue bill, it bites us suddenly and painfully in the posterior.
Reason #5: The size of a region is completely arbitrary
There is literally no technical or practical reason why regions have to be the size that they are. The only reason they are the size they are is that regions are 256m x 256m is that was the size that Linden Labs decided (quite arbitrarily) was the right size. It played well into their model of sub-parceling regions for rent or sale. That model worked for them, but Opensim is a completely different beast subject to completely different economics. When anyone can run their own region for free, there’s a lot less demand to rent a fraction of that region from the owner. The region size could be anything, the only limits are the performance of the server running it and the load being placed upon it.
So, let’s recap: Smaller regions can make the Metaverse more social, more populous, more mobile/web friendly, less sprawl-tastic, more seamless, and do away with a outdated arbitrary convention put in place for reasons that have no bearing on the current realities of and open Metaverse.
This post is part of a continuing series taking the seminal web design book “Don’t Make Me Think!” by Steve Krug and applying the lessons to the design of virtual environments (with a focus on the Opensim platform)
Now that we’ve gone over how to treat the design of a Landing Zone like the design of a website’s home-page, let’s go over what happens when the user doesn’t arrive through the front door. Like with a website, it is possible and indeed common for users to arrive in a region or grid in a place aside from the landing zone. Generally speaking we’d all like users to arrive through the landing zone, but often we have very little say in the matter. So how do we ensure that users aren’t disoriented or lost and can can quickly find what it is they’re looking for? On a web page, we have a navigation bar which contains strategically selected links to other pages. In a virtual environment we generally don’t have that option. Instead we need to opt for a more concrete metaphor for navigation, which in many cases is a healthy dosage of good old paths and signs.
But how do we make sure that we’re ensuring that the signs and paths are doing their job? Krug has a test for questions like this called the Trunk Test. In the Trunk Test, the user is blindfolded, locked in the trunk of the car, driven around for a while, and then dumped on a page in the bowels of a web site*. If the site is well designed, the user should be able to quickly get answers to these questions:
What site is this?
What page am I on?
What are the major sections of this site?
What are my options at this level (within the site)?
Where am I in the scheme of things?
How can I search?
With the possible exception of the last question, all of the answers for these questions can be designed into a environment. The use of themeing and well integrated signage that shows the user where they are and where they can go next are the key to making it obvious to the user where they are and where they can go from there. Paths and signs do not necessarily need to be utterly blatant or disruptive to the experience. Indeed, they should be as unobtrusive as possible. For instance, many paths can be handled by way of visual cues (like cobblestones) suggesting a path rather than a cattle-chute which makes the user feel locked into the path. Likewise signs can and should be integrated into the surrounding environment, present, findable, and readable when the user is looking for them but not dominating the experience.
This being said, there are times when you do want a cattle-chute and you do need big freaking signs. Use your judgement to determine when the right time is for that and what level of obtrusiveness matches the needs of your experience. If you absolutely need users to go from one point to another in order without deviation, or absolutely need to force them to make a Path A or Path B decision, then you probably need to be more obtrusive. Users are fine with strong cues and forceful guidance as long as they feel it’s justified. Put yourself in user’s shoes and think about how they’ll perceive it. Better yet, get some people to test it out and find out directly from the horse’s mouth.
In regards to the last question, this is an area where there is a need for a technical solution that to my knowledge doesn’t exist yet. The ability to be able to search for things in a environment using a search bar is something which would allow users to quickly narrow in on what they’re looking for rather than stumbling around growing progressively more frustrated. I have some ideas for how something like this might work which I hope to share soon. Until we have a system that does this, we can make do with a signs that allow the user to teleport directly to their destination. This at the very least allows users quickly searching for specific things to narrow in on what is hopefully the right area to look for them in.
*Krug uses this metaphor top point out that the web experience is very much like this, where the browser will whisk the user away to a destination in parts unknown. The Opensim experience is much the same way.
Continuing along with my earlier post about the need for a new baseline viewer, I felt it would be a good idea to list out some of the key goals (as I see them, feel free to add your own):
We need a viewer…
That’s easier to use
Tailored to the realities of an open Metaverse
With a license which is compatible with that of Opensim (i.e. not a viral GPL license)
That allows the experience to be taken to other, non-desktop platforms
That allows developers to focus on pushing the boundaries of what’s possible, not forcing them to polish existing features
Allows for rapid evolution of what the Metaverse experience can be
That makes developers and users’ lives easier
That makes it easier for non-programmers to participate in the development process
Like I mentioned in the earlier post, I think I’ve found a good fit. It’s a young, actively developed game engine that uses the MIT license. It’s powerful and flexible (capable of running on android and iOS along with the Big Three desktop OS’s), and the brainchild of one of the developers of the RealXtend platform*.
I’d like to introduce you to Urho3d (Hero for those who aren’t up to speed on their Finnish).
The page doesn’t do a particularly good job selling it’s potential, especially to those without a technical background (a tragic commonality among young, promising open source projects). In summary for those who don’t want to wade through the details, Urho3d is already incredibly well-featured, with many of the features already present in current viewers. In addition to those features, Urho3d has some which have been on the wish-list of many Opensim users for some time, including AngelScript and client-side physics (courtesy of the Bullet physics engine, includes ragdoll!).
I’ve taken the liberty of making some screenshots of the very simple demo scenes included with the engine to give you a flavor of it’s capabilities, even at this early state.
I believe very strongly that if a group of developers from both the viewer and server community collaborated on crafting a viewer out of Urho3d, the Opensim ecosystem would be well on the way to breaking the shackles of the past which currently hog-tie it. There are of course some hurdles that would need to be cleared to make Urho3d compatible, but those are for a more technical discussion elsewhere.
We need a new baseline viewer if we’re going to seriously champion Opensim as the path to a fully realized open Metaverse. Without a strong foundation to build upon, the effort will be perpetually crippled. Urho3d fits the ticket and would prevent us from having to start from scratch. To me, that sounds like a win-win scenario.
*RealXtend, for those unaware, is a virtual world platform which initially started out as a fork off of Opensim. Their platform offers radically more flexibility, but as of right now lacks any method for linking worlds together into a network.
As promised, I’m starting a series of posts taking some of the excellent lessons in “Don’t Make Me Think!” by Steve Krug and exploring how they relate to the Metaverse. Up first on the roster is appropriately about first impressions. The home page of a website is a critical piece of the site’s experience. In many ways it acts as the backbone upon which all of the other pages in the site are built. Because of it’s importance, and the tendency for home pages to become cluttered messes, Krug points out that they need to serve one core need: conveying the big picture. To this end, he counsels that at a glance, a good home page needs to quickly answer four questions:
What is this?
What can I do here?
What do they have here?
Why should I be here (and not somewhere else)?
I feel like there is a strong equivalent relationship between a web site’s home page and a region’s landing zone, the place in the environment where a user first rezzes upon arriving. In specific, the area of the landing area within the immediate field of view of the user is very much like a home page. Well designed landing regions make it very easy to quickly find answers to the four questions. Bad landing zones immediately make the user feel lost, confused, or disoriented, three emotions you generally want to go out of your way to prevent your users from feeling. Lost, confused, disoriented users quickly either become frustrated users or defeated, log-off-and-wonder-why-they-even-tried users. If your landing area leaves users scratching their heads, you’re probably blowing a good deal of your chances to show them later why they should give a damn about the region you’ve built.
So how can you make a good landing zone? I have a few suggestions (feel free to add your own in the comments):
Figure out what direction your users are most likely going to rez in facing. Focus on using the area they’re facing to present your regions’ case.
Use simple, easy to read signs that match the flavor of your region/experience that quickly help answer the four questions.
Make it clear where the user can/should go next. It’s your job to shepard them out into the wider experience.
Make sure the assets in your landing zone load fast and reliably, otherwise you’ve defeated teh purpose of the landing zone altogether.
Use the PRFCT model to guide your answers for the four questions. You’ve managed to get the user to your region, make sure they get to see why they should stick around.
For the next DMMT post, I’ll be go over what Krug has to say about what to do when a user doesn’t come in through the front door and how to design a region to make sure a user gets clued in quickly.
Linden Labs has removed the ability for Opensim to peacefully coexist with Second Life. They do not intend on fixing this breakage, for reasons allegedly due to their aggressive march toward the use of the proprietary Havok physics engine. They are severing the proverbial umbilical cord.
To some, this may be seen as a time to fret, I say otherwise. For some time, the open Metaverse has been held back by the close bonds between Second Life and Opensim. Features and improvements that could be implemented have been sidelined or shelved because it would break compatibility with Second Life. Opensim developers have also had to develop on a proverbial treadmill, always responding to implement a feature released by Linden Labs to maintain compatibility. No longer. If Second Life is truly closing the door, then we are free to walk our on path, to craft a fully realized Metaverse. Maybe one day Second Life will reopen its doors to the Metaverse, but it is my hope that when it does it will be as a equal participant in a vibrant and thriving network of worlds.
We knew this day would eventually come, perhaps a little further down the road than today, but we have known that eventually the vision of the open Metaverse would outgrow the limited ambitions of Linden Labs.
It’s the end of the beginning, and the promise of the future is bright. Don’t forget your sunglasses.
As slick as the old theme was, I’ve decided it’s time to try something new which is bit more functional. The new look is a pretty radical departure from the old one, but I think it helps. For one, you can actually tell what’s a link! *gasp!*
I’ve also been pretty dissatisfied with the lack of tools for those not already on Tumblr (the platform this blog is hosted on) to leave comments/questions/angry death threats. I really love getting feedback (death threats not so much), so I’ve added the Disqus comment system to the blog. Give it a try and let me know if it’s making things better/worse. I’m also completely open to feedback on the blog’s overall layout. If need be I’m willing to break out the machete and start hacking away at the CSS.
About a week ago I picked up the excellent book on web usability “Don’t Make Me Think!” by Steve Krug. It’s a refreshingly short read, but loaded with insightful advice on how to make web sites more approachable for web users. Reading through it, I was struck by just how much of it’s advice could be applied directly (or very nearly so) to the design of the entire virtual experience. While it’s true that the concepts are designed with 2D websites in mind, it’s almost hard to find a rule or principle in the book which isn’t adaptable for virtual worlds.
Not only are the ideas in the book applicable to the design of virtual space, it should be something grid owners and indeed anyone involved with building the Metaverse should pay attention to. Because any Metaverse experience is a collaborative effort between viewer developers, server developers, region owners, and content developers, the more each of these parties can work to make the use experience intuitive and seamless, the better.
Over the next few weeks/months I’ll be posting up Metaverse-specific adaptations of concepts from “Don’t Make Me Think!” but don’t let that stop you from getting your own copy and thinking about it on your own. It’s a quick read and well worth the cost!
In an earlier post, I made the case for letting viewers begin to separate apart based on different functional needs. While I still believe that a hard-coded “one-size-fits all” user experience is a bad idea, I’ve come to the realize that my initial viewpoint was wrong.
Letting the viewers split apart into a different functional groups is only allowing a broken status quo to perpetuate itself. The status quo is that the development of a fully realized Metaverse is ham-strung by the continued reliance on viewers based on Linden Lab code.
There are two reasons why relying on the Linden Lab code-base is a bad thing:
It tethers us to Linden Lab’s limited vision of what the Metaverse can and should be. What we envision the Metaverse to be is something far more varied and expansive than anything they have envisioned for the future of Second Life. The Metaverse has the potential to be everything from games to engineering collaboration software, not merely a social environment with some user generated content tools tacked on. It has the potential to be decentralized, open, and participatory like the Internet, not a walled garden sequestered away from the rest of the world.
The incompatibility in licenses between the Viewer code (GPL) and Opensim (BSD) puts collaboration at a deadlock. Because of this incompatibility there is no way that developers can collaborate effectively to evolve the viewer and server code to add truly innovative features without running the risk of violating the licences the software has been released under. Without the ability to collaborate, relations between viewer development and server development will remain distant, if not bordering on antagonistic. This must not be allowed to continue for the sake of all parties involved.
We need a new “root” viewer that we can base the continued evolution of the Metaverse upon, free of the limited vision of Linden Labs and the straight-jacket of license conflicts. We must critically re-examine how a viewer can be both a powerful platform that attracts professional developers while remaining flexible, simple, and intuitive enough to be used by complete newcomers. This is not a trivial challenge, but it is a critical one. Furthermore, I believe it is possible. I will save the details of how such a viewer could be constructed for another post, but from my research I believe many of the technologies needed already exist in forms ready for use.
We should not fragment the experience of the Metaverse in these early days to avoid addressing the unifying problem essential to moving the Metaverse forward.
Centralized conventions are a huge ordeal to plan and execute, not to mention massively expensive.
Very few centralized conventions (to my knowledge) are actually self-sustaining. They require a year-round staff of individuals with an unshakable obsession for making it happen.
Centralized conventions place inordinate expectations on both attendees and organizers(especially if volunteers). The word “convenient” rarely coincides with the word “convention”
Venue cost and travel costs are both very large components of the overall cost of a convention
We should still be doing conventions based on the Metaverse, but in a different way
We need to think, small, sustainable(for organizers and attendees), and distributed
We need many regional/local “un-cons” unified by a virtual convention.
Cheap and convenient CAN coincide with a distributed virtual un-con.
Opensim allows us to do this, cheaply and sustainably. This is in many way what the platform was meant for(!!!)
We can have panels and presentations without a physical venue. Web cams, voice channels, and Google Hangouts make all of the meatspace presentations fast and easy.
We can have exhibits without a physical venue. In fact, the physical venue gets in the way of effectively showcasing many virtual exhibits.
With a virtual un-con, those who want to keep their virtual lives and real lives separate can do so, as they should be able to.
We need to look to the future and the growth of the Metaverse separate and apart from any one grid or company. That is where the promise lies, not in the hands of the company that merely showed us that it was possible in the first place. We shouldn’t be waiting for their permission to move forward.
As the Opensim community and Hypergrid grow, we need a good, friendly place for people to ask questions and get answers. Gridcache is great for sharing what you’re up to, but isn’t really set up for the kind of Q&A people really crave.
So I’ve gone ahead and made OnRez, a community where you can ask questions and get answers about Opensim and the Hypergrid. If you’ve ever heard of or used Stack Overflow, it’s a lot like that.
Update: I’ve edited this because in rereading it I’ve realized that I was overly general and perhaps a bit too harsh.
I have a real beef with virtual currencies owned by for-profit entities. Perhaps I’m merely jaded and cynical, but the whole practice seems borderline predatory. I mind it less when it’s a closed economy, such as Sony Station Cash or L$ in Second Life. In these cases, the provider of the products/services being sold is the issuer of the currency. It’s still a raw deal, but the system is self contained and self-referential. The cases which truly grate on me are those in which a proprietary currency is being used in a open system, such as the Metaverse.
The only virtual currency with any kind of widespread “adoption” (I’ve yet to actually see anything for sale using it) on the Hypergrid is the Open Metaverse Currency (OMC). This is a currency which to the best of my knowledge is controlled completely by Virwox, a company which specializes in exchanging various virtual currencies. I trust Virwox about as far as I can throw them when it comes to OMC. It’s nothing personal against them, I’m sure they do an excellent job converting virtual currencies back and forth. Two things make me not trust them when it comes to OMC.
One: They are a for-profit company in charge of the implementation and value of OMC. If they close up shop tomorrow or decide to stop supporting OMC, good luck to all the poor folks who’ve got a balance of OMC. I highly doubt they would do anything to ensure those individuals would be compensated.
Two: Despite being the sole patrons of OMC, they seem to have done little to champion the effective adoption of the currency by consumers and merchants alike. Instead, they have merely provided a set of developer tools and some passable documentation, seemingly hoping that magically this will result in a healthy ecosystem of OMC users.
Ultimately, it boils down to commitment to the “greater cause” of the currency, a passion to relentlessly improve the spread, security, trustworthiness, ease of use, and effectiveness of the currency above all else. A company is only mandated to look out for it’s bottom line, and a to a company a virtual currency is just another service which either makes money or needs to die.
The Metaverse is a part of the Web. The Web is a part of the Metaverse. Pretending otherwise, trying to keep the two seperate, only impoverishes each piece. I have seen grumblings by various members of the Opensim community bemoaning the fact that the technology has to rely on systems outside of Opensim itself.
This is silly.
Opensim is good at doing the nitty-gritty of a very specific type of virtual environment simulation. Asking it to be other things in addition to that while still being good at it’s original function is like being upset at a chef when he’s no good at unicycling and multivariable calculus lectures at the same time.
We should be making it easier for Opensim to talk to the rest of the Web, not pretending its some precious jewel which must be kept far and apart.
Outside of statistics wonks and intellectual masochists (is there really a difference?), not many people get excited when the words “metrics” or “analytics” enter into a discussion. Yet, despite their lack of appeal, metrics are the lifeblood of any serious effort to build better products and services. This applies just as much to virtual worlds as it does to anything else, perhaps even more-so.
Right now our metrics tools are quite crude when it comes to Opensim. The system knows how many users are in a region, and with some extra effort, its possible to pull together a reasonable snapshot of how many users are logged into a grid. Beyond that (to my knowledge) there are no tools which can provide much in the way of data which world creators can make real use of.
The easier it can be made to collect meaningful data about how users interact with the worlds we build, the better we will become at building worlds users flock to. Without metrics we’re just stabbing around in the dark.
What if we limited the inventory you could access anywhere to just nine items?
Heresy, I know.
Second Life and Opensim have always offered unlimited access to a user’s inventory. Every script, texture, piece of clothing, and trinket is given an equal treatment and is available for immediate use. This may seem like a convenient idea, after all it lets you have access to everything, no matter what you’re doing or where you are.
So what’s the problem? The problem is that it lets you have access to everything, no matter what you’re doing or where you are. As any experienced user will tell you, a bloated inventory full of hundreds if not thousands of items is about as inevitable as death or taxes. Without constant upkeep, the inventory becomes a thicket of content, the vast majority rarely used. Not only does this system discourage experienced users, it most likely confuses the prims out of new users who are just trying to wrap their heads around the blizzard of other novel concepts SL/Opensim throws their way.
So why not create an intentional limit for our own sanity? Nine items is about the maximum that a human brain can focus on at any one time, so it seems like a nice number to limit the “active inventory”. This active inventory wouldn’t count worn clothes or attachments against your nine-slot limit, but anything else would. You could still access the rest of you inventory, but it would either be something you had to open a secondary window to access, or something you could only access from a in-world terminal.
To be sure, this is not a system that would work well for everyone, and it falls under the same category of modifications as my earlier rant on gamification. However, I believe it is something worth experimenting with in a non-mandatory way. It may ease the pains of day-to-day inventory use and make it easier for new users to get a grip on the whole system.
Right now, if you want to access Opensim worlds, your options are pretty limited. Regardless of whether you are a seasoned developer or someone who’s only just learned what “virtual world” means, you are stuck with pretty much the same viewer experience. Yes, there are a thousand flavors of viewers each offering slightly different features in slightly different wrappers, but by-and-large they are all pretty much very minor deviations from the root Second Life viewers. Most are crammed to the rims with features, trying to provide functionality to keep everyone happy.
This is not a good place for the state of viewer software to be, for any party except for those who are casual users with a high-degree of proficiency in the current setup. In other words, it’s great for the people already sold on the platform, but terrible for anyone looking to enter into the wacky universe we Metaversians inhabit. This is not the strategy for any kind of serious adoption, either by developers (who can push the system to achieve bigger and better things) or by those with lower technical literacy (who, by the way, have most of the money that the developers would like to have in return for building bigger and better things).
In order for the platform to grow and evolve, we must allow viewers to evolve away from this one-size-fits-all model to fit specific niches of functionality. Yet there are those in the community now who decry this conclusion as heretical. “It will break the parity of experience!” they cry. “Different users will get different experiences!” Well, yes. That would be the point. Different kinds of users need different kinds of experiences.
This being said, such an argument has some legitimate grounding. A viewer which intentionally deprived users of core parts of the experience (say, chat or the ability to see other avatars) without having strong reasons to do so would fragment the experience too much. That can and should be avoided.
In order for this technology to evolve we must take a hard look at it and figure out what parts of the experience are core, and which are merely a consequence of the way we’ve been building viewers up to this point. It will yield better experiences for more people, help grow the platform, and allow viewer developers to focus on developing better features rather than trying to juggle everyone’s needs. The Metaverse deserves no less.
For instance, gamifying Opensim/SL so that you had to play games to upload textures or even make prims might work, but it would break the very essence of what the platforms are. It deprives the system of a capability that is expected and even necessary, users need no extra encouragement to create things. On the other hand, gamifying the process of discovering and sharing high quality content is something that could be genuinely useful if it’s something players can opt into or ignore completely without detriment.
As long as your method of gamification doesn’t break the core experience, doesn’t force everyone to use it, and enhances the experience of those who do opt in, gamification can be a good thing. When you force users into a game they didn’t want to play in the first place, you’re degrading their experience.
Minecraft is an excellent example of this. The core experience is building cool things out of blocks that you can show your friends. The Survival mode was added later to add a game structure around that core experience, but the core experience was never taken away. Yes, Survival players will feel much more accomplished for building the same thing in Survival mode as a player in Classic mode, but it’s still a matter of choice. Had the option to play Classic mode been taken away, I doubt that Minecraft would have experienced anywhere near the same level of success it has.
PRFCT: Building Worlds Users Keeping Coming Back To
When you get beyond the software and servers, what is it that makes a virtual world really work? What makes a world the kind of place which users keep coming back to again and again? After some thought and too much coffee, I’ve invented a too-clever-by-half acronym: PRFCT.
Population: Your world needs to have people in it in order for people to want to be in it. This may seem like a circular statement, but it’s true. We’re social creatures, and even when we’re in virtual environments, we crave social interaction. Without it we get restless and bored. Even more important than just having people there, having the right number of people and the right type of people matter. Some kinds of worlds really need large crowds. Others really need small groups. Some need highly social competitive users, others need more restrained users. Many need a mixture of many kinds. Finding out the balance of population size and makeup that’s right for your world is no small task, but ultimately worth the effort. A world with a well-tuned population will keep users coming back again and again.
Reliability: In order to have people come back to your world, it has to be reliable. Full stop. If your world suddenly disappears, or crashes every 15 minutes, you’ll have a very difficult time convincing people that its someplace they should keep coming back to. Reliability isn’t just about the big stuff or even just about technology. Each time your user can’t accurately predict whether the a vendor object will work or not, or whether someone will actually get to back to them when they have a problem, you are killing their perception of your worlds’ reliability (not to mention your own). The antidote for this is to constantly view the experience through the eyes of your users, especially the brand new ones. Find where the gaps in the reliability net are and sew them shut tight. Sometimes that’s as trivial as changing the text on a sign. Other times it means biting the bullet and moving the whole operation to a new grid. Do what you have to do.
Functionality: If there isn’t something, or many somethings for your users to do, all you’ve made is a pretty life-sized diorama. For a certain type of experiential-oriented user (more on different user types later), this is fine. These types of users prefer wandering from world to world, soaking in the sights and sounds. Just don’t count on them sticking around. Having things to do in your world is key to creating a stable population of committed users. This can be as simple as an environment built to facilitate meaningful conversations or as complex as a full-blown RPG. As long as its’ well crafted and reliable (there’s that word again) functionality can breathe life into otherwise dead worlds. It’s also worth noting that the functionality you provide in your world must make sense. Having a business collaboration suite in the middle of a raging volcano just sends off the wrong vibes (unless you’re aiming for the supervillain set).
Having fresh and interesting content for your users to experience/consume is key to attracting their attention. Content is a fickle beast. Well designed content can act as a very strong attractor for users, but the rate at which content moves from “fresh” to “stale” is shocking. Worse, the more you focus on providing a relentless stream of fresh content, the more users will expect of you. Because of this, using only content as your method of keeping user attention is a sure way to work yourself deep into the red. Use well-crafted and meaningful content as the incentive to get users interested in the first place, but neglect the other elements at your peril.
The user’s interaction with the world should leave an impact, the more constructive and longer-lasting, the better. By being able to tangibly alter the world, the user invests some ownership in its’ future. This includes allowing users to become land owners, recognizing prolific members publicly, or even displaying user-made content. It also includes less visual methods, such as bringing trusted users into the support crew running the world. Give your users the ability to contribute, and they will stick around to help evolve the world with you. The flip-side of this is of course is that by allowing users to influence the world, it places the additional responsibility on you to cultivate that influence and weed out the inevitable bad contributions.
Like all cutesy acronyms, PRFCT doesn’t cover everything. However, it gives us all a handy framework to break down the big how and why questions of virtual world designs. It also gives us a handy set of tools we can use to troubleshoot worlds which aren’t living up to their potential. Let’s get building!