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