2 Ideas for Earning $: Courier Service and Distributed Computing

I have two ways money could be made by people that would help make SL be more interesting and are way better than "camping", but the SL developers would have to impliment them as part of the server because they would have some specialized characteristics:

One would be a courier serice... you have to drive a vehicle accross SL some long distance on major roads to deliver some goods... with no flying or teleporting allowed. The point of this would be to make more people driving around and give us all someting more interesting to look at than barren roads (we'd see vehicles driving on them! Wow!). These couriers would be paid to drive from place to place, and all those cars and trucks we have stored in our inventory would stop going to waste. (There really should be a optimized driving mode when you're in a car - your view is through the forward window and the vehicles' polygons are reduced as much as possible while keeping it looking the same way. I remember how you could import a 3D object file to some 3D-editing programs years ago and it gave you the option of reducing the number of polygons when importing, but the object still looked the same. We could have this happen temporarily with objects in a number of cases.) The number of jobs of this type avalable would be limited to some number in order to keep too much processing power from being used (until more is available in the future anyway.)

The other thing people could be paid for wold be to allow ther own computer's processing power to be used, in some small degree, to do calculations neccesary for SL to function better: distributed computing (they do that on the Internet with the SETI project and some other stuff, and supposedly Kazaa was doing it but people didn't like the fact that it never asked permission). If SL uses %5 of your computers processing power, you could get a certain amout of money for the amount of time you allow this, and SL would run better and faster and more interesting things could be going on. Of course this would mean changes to the server, but it would be worth it!! (the socket/connection for this could be seperate from the main SL socket connection).

(I posted this as a reply in another thread but since it's actally a major suggested change to SL, I decided to make it it's own thread here.)

The idea of distributed computing was already posted and discussed in this thread:

/130/fe/82684/1.html

I see. The problem is, the way you described it.. you didn't seem to really believe in the idea and were rather unenthusiastic, and you made it sound complicated and unworkable and clunky. I don't think you were a very good idea salesman, from looking at what you said of what you showed me. (If you'll pardon the expression.)

In my version, it's pretty simple... you are online, you go into the preferences and click a button.. bingo. Every time you log in SL (or maybe when you're not on but you're still on the net) you're sharing some of your computer's calculating power to help SL do stuff. You can assume that a certain percentage of people would always have it on because they get L$ in return for doing it, and you don't worry about "selling" crunching time or "banking on it" or whatever... you just use whatever is there... if you have lots of it, SL runs faster and does more.. if you don't, it runs slower and does less (but we're used to that) ... what's the big fuss?

I mean, when I watch someone launch the nuclear missile package, the missiles slowly shoot up in the air over the clouds and then a little later come back down.. and usualy just sit there stupidly with their noses touching the ground doing nothing. If they do manage to explode, it's all choppy and it pisses lotsa people off. Well, that would be less of a problem if you had thousands of people sharing some CPU clicks. What are you gonna do with a 3+ GHz machine anyway?

But congradulations for thinking of the idea. I have a whole bunch of ideas and I'm just dropping them in this forum to see what people like and what's already been thought of and either accepted or rejected. (It's a good idea to make sure that a thread has a title describing the idea, since I skim the titles but don't read every one of the older messages, and I'm sure other people do the same.)

The idea actually comes up quite often - but always stalls because of one big problem - the internet.

Until we have internet latency (including international links) down to the single digit millisecond range - and until we all have enough bandwidth to peer-to-peer while running SL - until then the only sort of distributed computing that'll be done is block-based, like SETI, in which your machine downloads a bulk chunk of data, processes it off-line, and then uploads the results minutes, hours or even days later.

I don't really believe in it because I happen to know a thing or two about grid computing... i.e. it is not really taking off like wildfire even in much more secure/robust systems (like a corporate intranet) despite having major players backing it up (Oracle and Apple, for example).

So even if any technological hurdle could be cleared given sufficient resources, you still need to find customers interested in "off-shoring" computation to a third party... which in turn will offload that to a group of players in a MMPORG... a business case I find less than compelling with corporate would-be customers. Would you like have your company's economical data travelling to a third party and then to hundreds of unaccountable PCs, for example?

Apart from feasibility doubts, you seem to err in favour of being too optimistic in you typical usage scenario, too.
You make it sound wonderfully simple, you just push a button, you say... problem is, if you want real-time effects relocated to clients (like your explosion example) you need to be sure that the client you "selected" has a very fast upload connection to LL, and must guarantee that it will not:
a) disconnect while "playing" the effect
b) go under heavy load (traffic or cycles) during the same time.

(Try googling for the hard realities that Sun discovered when they decided to go with their "the net is the computer" initiative, for examples of what could go wrong after you have "pushed the magical button".

So, to sum it up:
1) Distributed computing makes sense for batch computations that may be subdivided in discrete "workloads". You distribute the workloads, wait for a response, redistribute anything not coming back after a set time limit, credit the clients which have completed a subtask in time.
It is an extremely poor choice for real time animations like you seem to suggest.

2) Linked to 1. In order to make (economical) sense, you either need to identify batch computations used by LL themselves (like the dwell example I proposed in the thread originated by me) ... or find someone who could be interested in buying the service from LL. At best I can think of rendering farms for digital animations. Note that this is something you can process in batch (i.e. have 1000 PCs render scenes for LOTR type movies) because you are not doing this in real time, and the movie industry already uses grids to work on these kind of problems. That and scientific simulations are the main example of succesful uses of grids, in fact.

I may be poor at "selling ideas" but you don't seem very thorough when analyzing the cost/benefits of yours, sorry.

Yes, you're right... after reading over what you said, and what other people said,. and thinking about it, I can see now how unfeasible it is, because of the way the Internet is unreliable wen it comes to "immediate response' expected in communications (the packets can take any amount of tiem to get from one place to another). .. I was too enthusiastic about this one.

What about the other idea? The one where people are paid to drive long distances? I guess that is similar to camping, just a little more fun. (espeically if SL could somehow optimize the dirivng process a little more... but you would still have to control the car.)

I have heard of people hunting down textures for others and objects in-world and stuff that they need. The whole driving thing doesn't really make any sense in SL because now we can just teleport anywhere we want.

You are looking for something, find it, and teleport back home to try it out. That and with the lag and texture problems everyone seems to be having these days need I mention the fact that driving isn't very fun, epecially across sims.

Driving around SL is made much harder because they don't let us rez our vehicles on Linden-built roads. That means wandering around trying to find some land next to the road that has rez permission. This gets old really fast.

Also, it would help to have some mechanism to help keep cars on the road, especially when driving across sim boundaries. Falling through the ground and then popping up again is another thing that gets old fast. Try driving along the top (or interior tunnel) of the Great Wall and see what I mean.

If Linden roads (and railways, canals, airways etc) were supported directly in the SL system, the handover and rendering mechanism could be optimised to make fast travel work along these routes, as the system would know where we are going and could predict when we should arrive at each boundary on the way, so the receiving sim could be ready and relevant textures already pushed to the client.

Some simple LSL APIs to build road-following vehicles for this would make for a much more interesting infrastructure that might actually get used.

There's several standard "follower" algorithms in the robotics literature, and a follower is a fairly typical "hello world" project for robotics students.

In this case, the scanner makes it easy.

You could script your vehicle to do a scan for objects owned by Governor Linden ahead of it, and assume that the largest one it sees is the roadbed. If the roadbed isn't directly ahead, have it tweak the angular motor a notch to keep it on course.