If *you* had to design Secondlife 2, what would it be like?

If *you* had to design Secondlife 2, what would it be like?

SecondLife 1 has and is evolving a long way, but time moves on, people change, and everyone likes to try new things.

Imagine that *you* are the designer for the next generation SecondLife: SecondLife 2. What would it be like?

What would you call it?
What would you keep from SecondLife 1.x?
What new features would you add?
Are there any features you would cull?
What lessons can we learn from SecondLife 1.x?
What would the world look like? Would you keep grass, sky and air, or.... ?

So here are some thoughts on the topic, fwiw.

From a high-level perspective, things I'd like to achieve in SL2:
- make scripting really easy
- make persistent gaming possible
- attract gameplayers

Things that are totally amazing from SL 1.x:
- streaming world; just brilliant
- scripts almost never crash, great bounds protection built-in
- ease of creating objects and selling them to other players
- chat-system is damn good

Things I'd cull from SL 1.x:
- physics engine. It's hardly ever used, it's probably expensive, it places severe restrictions on building and prims, and it's basically a sledgehammer to crack a nut (obviously, removing physics implies adding a SetVelocityFunction)

Thoughts on details:

Scripting

- Scripting needs to be tons simpler
- Ideally it'd be based on a language designed to be easy to read, understand and program in, something like Basic (it's just syntactic sugar, this doesnt change execution or compilation speed)
- make Linden commands object-oriented, and incorporate automatic command-completion. I want to be able to type:

Me.Texture(0) = "Some texture name"

and actually after doing Me., I'd automatically get a list of all possible methods and properties of Me.
- use the object-oriented nature of Linden commands to streamline them massively. Remove the ll prefix.

Persistent Gaming

SL is such a totally brilliant potential platform for persistent gaming. It's crying out to be used for this!

Two things need to be done to make it possible:
- provide very precise control over what can and cant be done whilst participating in the persistent game-within-a-game
- provide built-in funcionality to make building persistent games easy and fun

Control over gaming participants

It should be possible to decide exactly what someone participating in one's game can and can't do.

Examples of functionality that comes within this scope:

- ability to decide exactly which objects and scripts are allowed on one's land
- ability to decide function by function which avatar, scripting, building and debug functions are allowed on one's land:
--> ideally, be able to define this on a per-group basis; all members of that group will receive these restrictions/permissions (and anyone not a member of the group simply isnt allowed on the land)
--> could also make it so the functionality restrictions extend beyond one's land, as long as one is wearing a certain attachment

Provide built-in funcionality to make building persistent games easy and fun

- It should be possible to just point and create a monster at that location, or a monster spawn point
- We need a flexible generic system to be able to create armor, weapons and monsters
- Some thought would need to go into this. I'm not going to do that here, though I could do it for a fee (Lindens: I'd be very interested in doing this)
- The system would need to be sufficiently flexible to ensure that each game created can have its own look-and-feel ... but at the same time it needs to be easy to use, and it needs to run fast

Attract Gameplayers

SL needs to attract Gameplayers. These are after all a huge market segment: somewhere in the order of tens of thousands up to hundreds of thousands of people, maybe millions.

To attract gameplayers, SL needs to contain at least one thoroughly done, detailed, challenging-but-playable, entertaining professional game.

SecondLife 2 should incorporate a full professional game, ie the SecondLife 2 creators will employ content creators as a significant part of its development budget.

With a gameworld in place, SL 2 will potentially attract hundreds of thousands of players into the world. Those that enjoy the game (hopefully most or many) will play the world. Those that like it but think they can contribute to it will do so, and the world will naturally develop.

In parallel, with technology in place to make developing games within SL pretty simple, other subgames will spring up, some of which could potentially become bigger than the initial professional offering, and ideally one of these will become the CounterStrike of the persistent gaming world. At least, that's the plan.

Conclusion

SL 1.x is a revolution. SL 2 as described here will continue the revolution:

- simply its usage by allowing non-scripters to easily script things themselves
- provide very precise control over what can and cant be done on one's land to allow persistent, non-supervised games to be created
- provide built-in functionality to make building persistent game worlds easy
- provide a complete online game-within-a-game sufficiently well done to draw online gaming fans from across the globe

Random thoughts:

- maybe ditch the ground, sky, air, connected sim model and replace it with....

You can buy an isolated region, of arbitary size, which is not physically connected to anywhere else

By default, this would be just a blank, bounded 3d space of the size you choose. SL2 could group several/many of these within one sim server.

You could define LinkPoints between your region (world?) and other regions. LinkPoints are basically instant teleporters, so users can get between your world and other areas within SL by clicking the LinkPoint.

You could probably make LinkPoints something like Portals that you just walk through (think StarGate), and of course you could decide exactly how the Portals look.

What doing this achieves is:
- reduces handoff processing
- facilitates gameworld creation because you can make it look exactly how you want, and dont have to worry about people SitHacking into the Sacred Shed of Sanan from a nearby sim
- adds a whole lot of flexibility to what you can create.

I disagree with just about everything you mentioned, and I think for the most part LL does too. But I dont want to get into a flamewar

Well dont tell me what you dont like. Tell me what you want! I seem to remember you saying the other day that SL lacks flavor. How would you add flavor?

Azelda

Well I would just like to see a back story. It could be like an officially sanctioned SL history project, mixed with a little fiction to make it more palatable.
Like, for instance, one of the first tests Philip made was water, with realistic waves and stuff (they were removed due to being computationally expensive). So you could say, in the beginning the gods created the seas. They threw a stone upon them and watched the waves propagate across the sims. They then created the primitive shapes from which all things would be formed. But the world was empty and felt lonely. So they took these primitive shapes and created Primitar, a man of wood from which all other avatars would derive.
I dunno. It's not THAT important. I think SL is pretty good already, but way too commercialized. It was nicer back when it was more of a game, when L$ had no RL value, there werent so many permissions, and you could buy all the land you wanted without shelling out RL cash.
And we could teleport anywhere, but had to pay for it.

> I think SL is pretty good already, but way too commercialized. It was nicer back when it was more of a game, when L$ had no RL value, there werent so many permissions, and you could buy all the land you wanted without shelling out RL cash.
And we could teleport anywhere, but had to pay for it.

Yeah, I agree actually. Well, you may find that ironic since I seem to charge for everything, but actually no, that's just cos the MMOGToolkit isnt something I intrinsically want to do, it's something I want to have done, to exist, if you see what I mean?

One of the cool thing about MMOGs and stuff in general is the concept that everyone starts at the same level in the game. Sure you have an RL barrier-to-entry which is the subscription fee, but it's the same for everyone and doesnt affect your standing in the game.

Now, I do think that it's important for people to be able to buy or rent sims in SL if they have a particular project that they need one for, but I dont think that this should be a general rule. I think the general rule is that everyone should start equal in the game.

Personally, I'd put back the RL barrier-to-entry (no more Basic accounts, put back a monthly subscription), and ditch the RL$-for-land. Sure GOM can continue (I kindof like the idea of GOM to be fair), but it should be possible to buy land within the game; there shouldnt be an explicit link between RL$ and land within the game.

Where am I going here? Well, when I first started, you had to get L$ to play for prims and land. I though that was a fairly neat idea; it forced you to find ways of generating that L$. Well, I felt like a prostitute sticking huge advertisements all over the place, which I didnt like actually, but still it was kindof challenging.

I'd kindof like to see that challenge back AND y'know what we could do? We could have it so you have to earn the ability to use different scripting and creative abilities! Like, to start with you can just make boxes, and scripts can only contain Touch events and Say functions. Then later on, after doing... something... you earn the right to create a sphere, and then after a really long time (seasoned player) you finally get the right to rez a torus!

Also, scope for player economy here, cos the experienced players can rez toruses to sell to newbies

This is kindof stream-of-consciousness, but I do think there could be some sense here. Maybe.

Azelda

[/B]

God, no. PLEASE!!!

If you bring levelling to SL, you'll destroy it just as surely as if you bring "needs."

I realize you're a gamer, Az. And I have, at times, fought on the side of trying to get more respect and options for those that are interested in in-world war gaming.

But, I don't want "gaming" to become the definition of SL. That's exactly the reason I LIKE SL, because there's no levelling and no "kill or be killed" mentality.

Just checking but you do realize that 'no physics' means everything is phantom and don't collide with anything including the ground right?

Every collision with anything is part of the physics engine, that is physics.

I like many of the suggestions you posted Az, however, I do feel that there is a need for a physics engine.

Things I'd keep, but seriously revamp:
The permissions system. Its plainly unintuitive to use in its current form. I mean, who wants to go through object inventorys clicking EVERY SINGLE OBJECT to set permissions on them.

The physics engine. Im hoping by SL 2, Havok can support ropes, ponytail physics, strings, ragdolls, all that good stuff. Heck, the physics engine is what makes SL feel like RL. Imagine RL without physics... its impossible

The scripting language. It needs an overhaul. We all agree on that

Things I'd add:
The ability to colonize space. Three-dimensional land ownership, where people own volumes of space, rather then just flat land, needs to be implemented. It would totally encourage people to build in ways unimaginable.

For the above to occur, we need better primative alottments. This is a real problem... er, so Ill drop it for now

Dynamic script editing, where two (or more) scripters can share the same view of a script at the same time, editing the script, and seeing the changes on each other's screens in realtime. This would be uberly cool, and would encourage scripting to become as interactive as team building.

Demolition of the offworld barrier. That would mean faster travel for everyone. People can create travel services with the simplest of ease.

Killing of the telehubs. I just dont like them. They really changed my experiance with SL negatively. Plus, I honestly liked riding around in a Car more then I do poofing from place to place using telehubs now. It was a more personal experiance, you met people and saw things.
When you have both telehubs and vehicle transport services, of course the telehubs win out, always, since the people who use the telehub will get there faster then the people who use a vehicle.

Simulator resource sharing. I think Justice Monde was right in recommending this for SL's future. There are just too many sims out there just sitting, idle, empty.

Ill think of more soon!

==Chris

[/B]

I'm a bit confused about this point. When we lease land in Second Life don't we already have the ability to build as high as we want to? Or is there a limit to how "high" our land boundary goes?

Thanks,

Salazar

Yes and no.

Your land extends upward to Infinity And Beyond.

But you can only build up to a few hundred meters above the ground. Anything higher gets deleted server-side.

You'll break everyone's vehicles and jetpacks, including mine. Screw that. HAVOK 2 UBER ALLES.


I programmed in BASIC for about ten years. When all I knew was BASIC, I loved it. Then I learned assembly and C, and I never looked back. BASIC is lame. Macromedia had the same thought that you did about making the Flash scripting language "easy." The result was a horribe, overly-verbose incarnation of ActionScript that no one liked. Made my carpals flare up just reading it. In the following version they switched to ECMAScript (AKA JavaScript) and they haven't gone back on that decision ever since.

The trouble with "making a scripting language easy" is that you may wind up hamstringing advanced functionality in order to do so, and/or make it so coddling and brain-dead that experienced coders will find it repulsive. Right now, a computer programmer thinking about joining SL can ask around and find out that LSL uses C syntax. ANY programmer worth their salt knows C syntax - it's all over the place. If we change it to some froo-froo cutesie language (like old ActionScript), they may think twice.

The World

1. Preserve the current grid and all assets therein.
   
2. Ditch the "Dark City" paradigm in favor of a global supersimulator with regular simulators snapped in place wherever it is desirable to have people build with any kind of density. It should be possible to fly IN A STRAIGHT LINE between any two regions in the world, EVEN ISLANDS. Private islands could be placed outside the supersimulator.
   
3. Build BSPs of finalized objects. An object would be finalized by checking a box and could not be modified until the box was unchecked, which would delete the BSP tree. This gets into a ton of complex issues, i.e. how objects inside (but not linked to) a large building are handled. I think zone portals would handle that problem.
   
4. Give us a user SQL server. I recommend MySQL because I am lazy and prefer using auto_increment. Notecard databases pale in comparison.
   
5. Show Updates is pretty cool. SL2 would have an option to show objects running scripts. They would have a halo around them - dark blue for barely using resources, interpolating to bright white for resource hogs. There would also be options to draw halos around listeners and sensors.
   

Linden Object-oriented Language

1. LSL would remain as a language option for those who are A) working with old scripts or B) don't want to bother with a new language.
   
2. It would be splendid if we could get an object-oriented language. They could call it Linden Object-oriented Language.
   
3. It would be C-syntax-based.
   
4. We'd get an actual IDE, including a debugger, rather than two textareas and a few buttons on a panel.
   
5. /*
   
6. * Block comment support instead of just //.
   
7. */
   
8. All existing datatypes would be preserved. int would be added as a pseudonym for integer. A new datatype called array would be added, which would extend the functionality of lists.
   
9. An array would be a hash. Array handling would be built into the syntax, i.e. myString = theArray[5] or myString = theArray[5][2] or myString = theArray[customers[5]] or theArray[customers][5]. (This is PHP and I think perl syntax, minus the $ before var names, which I never liked.) Arrays can contain data types, other arrays, and objects.
   
10. C-style structs. I don't like emulating this with classes, it seems like overkill.
    
11. Built-in array iterator, i.e. while(list(key, data) = each(theArray) {}.
    
12. Arrays can be defined with curly braces ({}). Or with brackets ([]), as now, but not if it means breaking the C-standard list indexing syntax.
    
13. Still strictly typed, requiring you to declare variables, and requiring you to cast in order to convert from one type to another.
    
14. string llJoin(list, separator), llSplit(string, array discardSeparators, array keepSeparators) and array llSplit(string, separator). These would replace llDumpStringToList() and llParseList2String(), which would be kept anyway.
    
15. Polymorphism. Defining the same function multiple times but with different arguments.
    
16. Compiler forward references - a function at line 10 can call a function at line 50.
    
17. llWhisper, llSay, and llShout are polymorphic. llSay(string) uses the last channel or 0.
    
18. Better memory management. A two-liner doesn't need 16K, whereas a complex application may need a lot more than 16K and wind up having to be split into multiple scripts. Put a memory model spinbox in the script window that allows the user to select the best model for their script. For example, 1K, 4K, 8K, 16K, 24K, 32K, 48K, and 64K. Set the default model to 4K or something.
    
19. Java-style try {} catch() {} finally {} exception handling.
    
20. PHP-style @doSomethingBad(); exception ignoring. (the at-sign makes it just go on)
    
21. Use of & to pass something by reference instead of by value, i.e. myFunc(&theData, &theString);
    
22. LL function names would be standardized. You wouldn't have llStringLength, you'd have llGetStringLength. You wouldn't have llListDeleteSublist, you'd have llDeleteSublist. Things that set or get lots of parameters (viz. vehicles, primitive parameters) would use arrays keyed by parameter name.
    
23. Private and public declarations of variables and functions, regardless of whether they are encapsulated in a class. Default = private outside a class, public inside.
    
24. Cross-script function calls for those who don't want to bother with actually creating classes.
    

OK, now on to the actual OO stuff. One script would contain one class. Class variables and methods (i.e. functions) would be public by default, but could be declared private. OO-specific syntax would be C++/Java in nature.

/* Each class gets its own memory allocation according to
 * the memory model selected in the editor.
 */
class TestClass extends Otherclass implements YourInterface {
    string myName;
    vector startPos = llGetPos();
    integer originalMemSize = llGetMemSize();

    // This is the constructor
    classname() {
        // In case someone copies & pastes into a new script
        llRequestMemoryAlloc(4096);

        // Read config
        MyConfig theConfig = new MyConfig("notecard name");
        theConfig.addSetting(new array(
            [name] => "Bob",
            [country] => "Canada")
        );
    }

    // This is the destructor
    ~classname() {
    }

    // Polymorphism
    classname(integer a) throws SomeException {
        llSay("The number is "+(string)a+".");
    }

    // Other functions go here
}

// Declares but doesn't initialize theClass
TestClass theClass;

// Creates new class, runs the default constructor
theClass = new TestClass();

// Creates new class, runs the other constructor we wrote
theClass = new TestClass(5);

Agree with most of your points, with the following exceptions:

Variable typing

This is something that newbies hate, and that adds dubious value to programs. It does speed programs up, but many people would prefer to be able to write a slow script that works than a fast script that doesnt.

One of the main differences between a "scripting" language (eg Javascript) and a "development" language (eg Java) is typing. Typically a scripting language will have untyped variables and may not even require variable declaration (eg Python). Development languages tend to be much more rigorous for various reasons, but LSL is almost never used for large development projects (I think MMOGToolkit has to be up there as one of the biggest actually).

I understand you're very keen on C, and C is a good language. You should probably know I did C/C++ professional dev for a couple of years, so I know what it is and isnt capable of. I've also done a couple of years of VB/vbscript/Python so I know those too. What I'd say are the differences are:

- C/C++ runs very fast
- Python, VB and VBScript have very fast compile/run/debug cycles

C and C++ have their place. They're certainly the language of choice for game development. I agree that C does almost everything C++ does (you can use modules like classes in most situations, since many classes tend to only get instantiated once). However, someone needs to take a stand and not be afraid to choose a language that could be considered "pansy" as the basis for LSL.

LSL doesnt need to run particularly fast. It needs fast compile/run/debug cycles and it needs to be easy to understand and use by non-programmers.

Azelda

Az, no matter WHAT language you choose, the VAST, OVERWHELMING majority of people will STILL not understand it.
I speak this from my experience as an RL programming instructor.
If you take away the semicolons and parenthesis and all of that, the language does not get any simpler for the average joe, because its not the syntax people have difficulty with, its the LOGIC. People arent logic, and go through most of their lives acting on emotion, and programming is just another branch of math, you know, that thing everybody flunks?
Someone with the intelligence required to program anything will be able to adapt to ANY syntax.
Moreover, by changing to a 'pansy' language you will be ALIENATING those of us who DO program.
I, for one, refuse to code in anything that doesn't let me neatly organize my code by way of semicolons, curly braces, and parenthesis-contained comma-separated argument lists.
Trust me, I spent about a year coding ASP and it was a pain, definitely not 'productive' or 'enjoyable'.

> Moreover, by changing to a 'pansy' language you will be ALIENATING those of us who DO program.

Just so you know, I've been programming since I was 8, thats like 23 years. Started on Commodore Pets.

Azelda

secondlife 2

--random thoughts

- portals - Entry way to completely separate "worlds"
Space, Under water,Fantasy, ancient, futuristic, whatever one can imagine

- a grid of heaxagon plots that can be relocated

- an opt in system - your land completely inaccessible to others if you wish

- enhanced notecards:
-- dontlike some one - place their card in a "blocked folder" and they cannot locate you or IM u ..yet u can see their dit now red on your map
-- group members too are colour coded on your maps

- pooled inventory
-- an inventory available to all players with all items full mod.
-- users can add their items to this pool
-- users still have their own independent Inventory

- AV to AV interaction :
Hold hands - if each AV agrees
Hug

Inventory
Preview items in a window for selection

Waves
flowing hair
profile pics in IM windows

im form website to ingame players in an optin chat window like messenger.
-- players in game can turn this off to avoid spam

Chris wrote:

> Dynamic script editing, where two (or more) scripters can share the same view of a script at the same time, editing the script, and seeing the changes on each other's screens in realtime. This would be uberly cool, and would encourage scripting to become as interactive as team building.

This is important.

I love those kind of stories! Tell us more old one!

What a coincidence, I've been programming since I was 8 as well. Granted, that's "only" 16 years, but still
Started on a Timex Computer 2048. It was a 99% compatible spectrum clone, meaning that most games wouldn't run, so I spent entire afternoons typing them in, and then I started hacking the variables to give me 99 lives, stuff like that
I devoured the manual in 3 days and then started writing my own code
Later I moved to Qbasic, then Pascal, assembly, C, and finally Java.
I never said you didn't code. You are a great coder. The point was that the people who usually do the most coding are C-syntax aficionados.
C is pretty much the de facto standard in syntax nowadays... it has a cult following. VB, much like anything related to microsoft, has a cult hatred

*grabs his cane*
Gather round, little ones, and let me tell you of the Days Before Avatars.
A long, long time ago, in a distant land, there were no people. Right after the gods created the primitive shapes, and before avatars were born, there was a people known as The Orbs. The Orbs soon discovered how to use the primitive shapes and started using them as adornments, to improve their appearance. The gods took notice of their little orbs playing with primitives, and the looks they created, out of sheer discontent with their initial appearance.
And so they created the Primitar, a being made to resemble the gods, and they imbued the Primitar with the orbs' spirit.
But the little Primitars were still not content with their perfect bodies, they still wanted to wear primitives as adornments. And so it came to pass that the gods bestowed upon the primitars their holy powers of attachment, and there was much rejoicing.
Little primitars were often found frolicking in their corral, gleefully wearing chairs and tables on their heads.
Until one day, a primitar came about who was different from the others. He had mastered the rite of the holy sliders, and joyfully altered his appearance to resemble everything but a primitar.
The gods looked down upon the grid, and rejoiced in the wit of their creations, granting them a boon:
From that day on, all Avatars would be born with the ability to change their shape, and to a greater extent than their forefathers, including the much anticipated ability to grow long hair and mold it in different styles.
It was the dawn of a new age, the Age of the Avatar, people just like you and me, sons of the Primitars, descendants of the Orbs.

Urgh, we do not need an SL mythology. Adding fiction is as bad as needs or levels or all that other gamey stuff. There are plenty of game games out there if you want to game. The appeal of SL is that it doesn't have that kind of extraneous baggage, which frankly is almost invariably lame and hokey. If they want to improve scripting to the point that you can create that for yourself, great, but don't apply it to the whole world.

Add a creation myth to SL and I'll become a Second Life atheist. The Lindens are not gods. *waits for the lightning*

I like the idea of the supersimulator. I want more wide open spaces, fewer zigzag borders and "holes" in the map. I want a system of roads and highways that don't suck. I want to be able to build anywhere on my land including a million kilometers above (the sky looks very cool in SL space).

There aren't many macro-level changes I want. Overall I'm pretty happy with SL as it is. I want SL 2 to be exactly the same as SL 1, only better.

What fiction? What I said was merely a romanticized version of what actually happened during the development of SL.
And the Lindens really DID create the world for christs sake. In second life, unlike the first, there is no darwinian evolution. The world was created, and so were we, whether you like it or not

Heretic!

Other than blatantly hijacking this thread, fun stories haven't yet caused any harm. I promise if Eggy's SL mythology turns into a religion/cult that grows to control SL and oppresses people, I'll join the rebels and topple the Holy Hippo Empire.

As far as SL 2 goes, the biggest change I'd make is to remove the responsibility of social management from the Lindens' shoulders. Abuse reports would be gone, and Lindens would only respond to genuine software problems. While a poor business decision, it would be a far more interesting if we could find in-world solutions to our own dilemas. The Lindens would still be around much like they are, but as engineers of the environment; fixing bugs, adding features, keeping the SL wheels turning. I dunno, its a pretty radical change, but I think it could work... I mean the SL populace is a pretty clever bunch, I have confidence that we could survive ourselves even if the "gods" went silent.

The End.