Monday, May 14, 2012

A Simple Bridge Solution for a Mobile Second Life and OpenSim Client

I was on Second Life this morning from my iPhone. It was fast, easy and cheap. Here's how:
  • Installed Splashtop Remote Desktop on my phone, on sale for $0.99 today
  • Installed and launched the free Splashtop Streamer program for my Mac.
  • Launched Imprudence and sized the window to 800 x 600
  • Logged into Second Life and started interacting via my phone
The desktop client isn't designed for small screens so it was very clumsy to move around or access other options. But would be relatively simple for Linden Lab or a Third Party Viewer team to optimize the UI to better support remote phone and tablet users; certainly much easier than building an iOS or Android client from scratch. So how about it? Maybe a Kickstarter project?

I shot a quick video just to give a sense of the frame rate and the look of Second Life on a small screen. 

8 comments:

Yoshiko Fazuku said...

I have done that a few times with a rdp client to my linux machine

Bozwell said...

You could do it for free using teamviewer ;)

Botgirl Questi said...

Thanks. There are quite a few remote desktop solutions, like Team Viewer. Others I've tried include Logmein and Desktop Connect.

What I like about focusing on a desktop SL client rather than something native, is that it could be used with any remote solution, and require only an interface redesign rather than building a codebase for each mobile OS.

Katharine Berry said...

On the flip side, you need a computer capable of running the viewer, connected to the internet, remotely accessible and on a fast, low-latency uplink. You need an equally fast, low-latency connection on your phone, as well as potentially non-trivial data usage. So that rules out using your phone on a phone network, using a computer with a poor internet connection, and anybody not particularly technically inclined or who has issues with allowing direct remote access to their machine, for whatever reason.

There have been a couple of shots at the modified-remote-SL-client, all of which were from companies that have subsequently seemingly completely vanished. Given the rise of services like OnLive and Gaikai I could imagine that more feasible technology exists at this point – but the latter usually fails and the former is frequently barely usable over an 802.11g connection, let alone a mobile network. And, again, data usage.

Beyond that I do think it's questionable how valuable it really is to have access to a graphical SL on a 3.5" screen, a significant fraction of which is covered by any interactions. This approach also makes e.g. autocorrected input (vital on touchscreen keyboards) either awkward or impossible.

In short I think that if you're going to do this you may as well do it well. Especially if you're trying to get it funded. I'd go for a custom client application on the device and a very specialised SL viewer that simply exposes access to a render of the world (and only the world) and the ability to control it over a network connection. Then build most of the UI natively on the device. Definitely more work (and you partially lose the OS independence), but the resulting experience might actually be worth the effort.

Botgirl Questi said...

Katherine: I agree with you that the best quality solution would be a native client. I used the phrase "bridge solution" because I saw this as a just a step step toward a full-blown solution on par with the best 3D mobile games that are out there.

My thinking was that a team that's already developing an SL client could crank out a first release of a slightly modified UI in a three or four man-weeks The initial changes would just be modified navigation (arrow keys) and chat window, and a default to low resolution graphics in the preferences.

As for the technical requirements, I think that people with a computer and connection that can run SL at full screen and medium graphics could handle the smaller window at a low setting, plus the upload. The additional bandwidth would be like a video chat. From my limited testing on the phone side, if a 3G connection can stream YouTube it seems it would suffice for this purpose.

As for the demand, I have no idea. I'd sure love to have that option and would be willing to contribute to a Kickstarter project if someone would take a shot at it.

Katharine Berry said...

I can reasonably say from experience that my home connection cannot do that (upload speeds are 200 kb/s (25 kB/s) or less). It also can't reliably upload a screenshot without dropping the connection partway. I don't think this is all that unusual in the ADSL-using world, really. As for downstream bandwidth – I can't actually stream YouTube videos over 3G with anything resembling reliability (thanks, AT&T). I'd love to do more tests in terms of latency but am currently out of the country and can't afford to enable a data connection. As far as I remember it's "not bad", and would probably be passable.

As far as navigation, I would venture that SL 3's default of single-click-to-move would actually be perfect for this use case. The UI is, of course, far too large to be usable.

All of that said, as an interim solution it seems… plausible, and perhaps even something I'd consider taking a stab at. I will note that it seems that someone has already done it natively on Android, potentially rendering the whole exercise moot. I do not have an Android phone/tablet and can't really test it.

As a final point, since I was just playing around with it – you don't need an awful lot of development work at all. I configured – entirely through the user-facing preferences – a fairly phone-friendly UI – see here. Logic: communication at the bottom, inventory/appearance on the left, navigation on the right. Click-to-move and double-click-teleport are both enabled. Full movement controls are available at the lower right and camera controls at the lower left. Did I miss anything important?

Katharine Berry said...

And since I forgot to specify, it's at the exact resolution of an iPhone 4/4S – 960x640.

The world is viewable and the text is legible, but the buttons are impractically tiny targets at that size, so it may be worth dropping back to the standard 480x320 resolution. At this point movement and chat is still viable but we're below the minimum size for everything else, so some UI fiddling becomes necessary. This also handily transmits four times fewer pixels than the other approach.

Botgirl Questi said...

Katherine: What took you so long. :) That looks great!

The biggest frustration for me trying to use a touch-based small screen was camera control. So I was thinking that a redesign of the camera control interface would be one of the priority changes. I have no idea if it's technically feasible, but ideally you could choose a fly cam mode and have gestures be interpreted like a 3D mouse.

The lower resolution option makes sense. It would also be nice to have the higher quality option for screen shots.