« Da Boom? | Main | I <3 LL »

December 30, 2005


Flack Quartermass

Thanks for keeping us up to date with the blog. Your posts conjured up a few ideas in me, which may or may not be useful.

1) Add a new checkable box to the General tab that allows the designer of an object to specify the item as Wearable (or other term) or not.
[ ] Wearable

If someone attempts to "Wear" a freebie box of fireworks, a pop-up will come up saying something along the lines of "This item is marked as non-wearable. Would you like to drop it on the ground? [Yes ]or [No]"

This would have made my life a bit easier for the first week or so as a newbie equipping boxes on my head. To make things easier, certain objects will of course be checked and greyed out (skin, hair, clothing etc) to ease this transition.

2) Selectable Newbie packs that allow people to walk into the game not feeling so 3rd class. They don't have to be exceptional, but a "trendy", "business", "relaxed", etc outfit selections would be cool.

You pick one as part of the tutorial for clothing and appearance maybe..

Eh.. I'm digressing. Anyway keep up the good work, and BTW, I definitely agree P2P is very helpful to the newcomers.

Luciftias Neurocam

Ben, I think HTML on a prim will go a long way to satisfying the "new features" crowd. And if Havok2 actually happens soon, they'll love you forever. Any news that you can tell us on either front?


It's very nice of you to share your thinking with us on a regular basis. Thank You and Happy New Year.

Now, please consider this solution to your dilemma. The "early adopters and long time creators" have been steadily requesting a client (UI) API/SDK, open communication protocols, and mono for the past two years.

If Linden Lab facilitates any one of these major development tools, you'll have instantly adopted a stable full of feature developers that will gladly entertain the population while most of you tweak and rewrite the infrastructure.

Just assign one small team for tool maintenance and development and everyone will be happily working for years to come.

Oskar Lissheim-Boethius

Seems like 2006 will be the tipping point for a great many areas. Will be a very interesting year for everything collaborative, cultural, digital, personal and social. Interesting times indeed...

Gwyneth Llewelyn

Worrying thoughts, Ben, but I'm glad you're not afraid to share them with us.

I don't think that SL will go to 1 million users in 2 months, although I might be prepared to believe Philip's original plans: 1 million users by the end of 2007 (and not 2006). The current ratio of growth has stabilized at some comfortable 650-700 new users per day, and just do the math. It always peaks to twice that value with enough PR and media coverage, so it's a question to keep the media happy if you wish to get a million users by the end of 2007.

What worries me now is LL being fully concentrated in "scalability issues". These should simply not exist; the original paper by Philip & Cory that defined the layout of the grid and how it would be specifically implemented to address scalability issues gave me confidence that this model could be employed "indefinitely".

So, what went wrong? A few things are obvious, others not. For instance, because three avatar areas are horribly rendered — hair, feet, and hands — a whole industry on attachments was created overnight to address those limitations. If we had avatar 'hair growth groups' like on Poser, or normal-looking feet, LL might get away with much less attachments. But sadly this is currently impossible. And, of course, the same applies to lots of prims being used on attachments to compensate the lack of extra meshes for clothing (we just have the skirt mesh... which I understand was an example for future mesh-based attachments... another abandoned project).

Another whole area that completely went haywire in terms of unpredictiveness was the way LSL is employed. Looking backwards, it seems that LSL was deployed to create "touch-me-and-I'll-give-you-a-notecard" scripts, and not much more. When I teach my meagre skills of LSL to a newbie, I tell them that grasping the basics of LSL is simple, but that they'll spend only 10% of their time developing code, and 90% on workarounds due to all silly limitations on the LSL code. We just have 16 or 32K of memory per script. No problem — we create script farms. We have lots of delays on key and essential functions. No problem — we use those script farms to launch several things at the same time to cut down the delays. To give the silliest example possible, just because some permissions have changed when giving objects from Inventory, I've created a very simple object that gives a cigarette to a user when attached. To do it properly during one of the releases when permissions were broken, what the "pack of cigarettes" did was to send an email to a web server, requesting a cigarette, which sent a XML-RPC message to an in-world "central server", which in turn sent the cigarette to the user. The resident 'thought' that they were getting the 'cigarette' from the attached object. But not so. It involved half a dozen of in-world, complex LSL scripts; an email parser; a MySQL database to keep track of active in-world servers; and XML-RPC to glue it all together. All this because from one release of SL to the other the permission system changed! Think on how CPU-time-consuming this approach is for an item that costs L$3, just because a proper llGiveInventory() suddenly stops working!

Thus, the complexity of dealing with avatars, LSL programming, prim torture, all things employed creatively to overcome simple limitations of the SL platform, generate an enormous stress on the whole infrastructure. And then LL has to concentrate on their efforts to make the platform deal with this extra stress — when, as a matter of fact, most of it (90%, I'd say) are just workarounds for things that don't work as they should.

Let's see another area. For ages, other platforms like ActiveWorlds, TSO or even Virtual Universe (http://www.3dchat.org) have allowed text-on-a-prim (or its equivalent). We just have llSetText, and, well, textures. We have waited for a simple way to do the same others have been doing for ages; we didn't even demand what OpenCroquet does with HTML. Instead, we got HUDs — but texture-based HUDs. If we wish to write things on a prim, we have to use XyText or a similar clone.

Now I don't know if you're aware what XyText needs to do its magic. Hundreds and hundreds of prims, dozens of textures, a script for each prim, a very complex master script, all in all a fantastic piece of software... but that consumes an extraordinary amount of resources (textures, prims, scripts) just to give us in-world what people need: a way to present dynamic, textual information, that can be seen by all.

So what will happen in this year of 2006? The population grows steadily, and with it, the desire to engage in projects well beyond 'nice builds'. The phase of the designers doing purely artistic constructions, for aesthetical purposes, is over. Now design has to have a function — be it in-world commerce, entertainment, social functions; or to support the emerging applications that use SL as a front end. This "push" towards SL-as-a-metaverse-integrated-into-the-Internet has started timidly in 2004, became important in 2005, and will be at its climax in 2006. From merchants that are not happy with the 'click to buy this object' model of past years and wish wholly integrated systems that allow them to track sales online; from rental systems that automatically handle all the income; encryption systems for authenticating documents; well... you see the point: SL is not used any more just for "pretty buildings" and "designing clothes". We demand much more from it!

Thus, the 2003 SL was adequate for those types of projects, and could grow from that; the 2006 SL is much more demanding, as its population has grown beyond the uses given to SL in 2003. So "scalability" is not only "getting more people inside the grid"; scalability means now a wholly different concept.

Perhaps an analogy can help here. The original Web started to be simple HTML, static pages. Then someone very clever thought it would be nice to create a system that allowed people to use a backend server to generate pages dynamically, and to input data using forms :) The WWW exploded since then... and web servers became more complex... they adopted "frameworks" to enable better integration with backend servers... and well... these days, I think that perhaps half of all written software is in some way Web-related.

And, of course, both Web server software and client browsers had to adapt to the changes. People simply don't wish to have 'static content' any more. 'Scalability', in the context of Web servers, meant simply an adaptation to new models and new uses being given to the technology.

I think that the same applies to SL in 2006. We don't simply wish for sims with more prims, a better renderer, and more than 40 avatars in the same place without lagging. All these are of course very important. But LL has opened a window towards a much more interesting aspect of the use of Second Life: not only as a self-expression medium, not only a social tool to develop relationships online, but as a whole platform to enable a second revolution, transforming the archaic 2D Web into a true virtual world, where a 3D, human-centric interface replaces "abstractions" like coloured rectangles on 2D "web pages".

Allowing this "second revolution" to become reality is the big challenge for 2006. It might succeed, if the proper tools are in place — rethinking about the purposes of Second Life beyond "entertainment", "self-expression", and a "social online communication tool". For these, the available technology is more than adequate and just needs a few tweaks here and there; to go beyond that, a lot has to be changed, both in internal orientation at LL (what is your focus?) as well as in pure technology that has to be redesigned/rethought. The keyword here is offloading SL-based applications to external servers; it means open APIs, XML-RPC and web services, in-world HTML browsing, a huge revamp of LSL as a scripting language (due to happen with Mono, I hope), better communication tools, better group tools...

It's the only way a cartoonish renderer with Poser 2 avatars that need primmed hair to compensate the lack of good meshes/hair growth groups, or shoes to hide the ugly feet, is able to "survive" — by focusing on another completely different focus where we can say, in 2007 or 2008, "oh the avatars are ugly, but we can do e-Learning and e-Business in SL — which is impossible in other platforms".

The challenge is up to you :)

I can only sincerely wish you all a good 2006 with a solid growth and enough inspiration to fully extend SL's "framework" into areas where you simply have no competition!

Koz Farina

Fantastic post and especially the comments! And oddly I found myself reading the very thoughts I have been having recently, since immersing myself back into SL, after a dabble back in October.

Even down to the various solutions to RL textdata being rendering in SL you mention. I havent found any yet in SL, but I have been considering how it might be done. (I have been wondering if it's possible to set a texture as a web hosted image - therefore I could just generate the .jpg and the texture would pick that on the next rez.)

But the really exciting thing, I think, is the XML-RPC and HTTPRequest stuff that I hear is on the way.

RSS/Atom feeds pumping data and content onto SL objects? Oh yes please! ;) SL APIs talking back and forth to RL APIs? Yowza! SL-RL eCommerce. Aiee!! SL Flickr galleries. SLiPods? - wearable MP3 players which can tune in to podcasts via RSS delivery of MP3s? yes! yes! yes! Video podcast SL fli-in cinemas...

etc. etc. etc. .. once these things become available for createc datadev junkies like myself, you'll be well over 1 million users in no time!

I can't wait!


ps: then I want the Logitech webcam avatar technology to control the SL avs...

pps: oh.. and then fullon VR headsets.

ppps: and SL 'webcams' === SL CCTV
- The ability to place a 'camera' on your land which can send/mail an image to the landowner after a motion-detect/intrusion...

hmm.. sorry for long comment! ;)

The comments to this entry are closed.