The following notes were taken from the Sansar Product Meeting held on Thursday, January 17th. The meeting was chaired by Stanley, the Director of Product for Sansar at Linden Lab and who was marking his first time leading a product meeting. Also in attendance (who I noted) were Cara, Aleks, Leslie, Nix and Stretch Linden.
Stanley has been with the Lab for some six months, and has been working closely with the Product team with a focus on improving the consumer experience, particularly the integration with Steam.
Sansar Dollars To US Dollar Conversions
On Wednesday, January 16th, 2019, Linden Lab published a Sansar blog post outlining Sansar Dollar to US dollar conversions. The post follow-on from changes announced in December related to Sansar becoming available on Steam – specifically the closure of the SandeX, which has been replaced by a flat-rate exchange rate for S$<>USD transactions.
The latest blog post outlines the key points of the new exchange process. In short:
- Sansar dollars can be converted to USD at the rate of S$250 to $1.00. However, anyone who created their Sansar account before December 31, 2018, can exchange at the legacy rate of S$143 to $1.00 through until December 31, 2019, after which the conversion rate for all accounts will be S$250 to $1.00.
- The Process Credit page has been re-enabled for moving USD to PayPal accounts. However, to allow for processing of funds that may come via Steam, processing may take up to 30 days to complete a request.
However, there is more – and it has been somewhat negatively received.
- Only “Earned Dollars” can be cashed out. That is, only S$ obtained via the sale of goods / services. S$ that are purchased or received as a gift / tip cannot later be cashed out (although all S$ held before the January 16th blog post have been converted to Earned Dollar Status).
- It has been calculated that, even allowing for easements elsewhere in the system, creators are losing some 60% of potential income when cashing out.
This latter point was of particular concern at the Product Meeting, but the Lab’s hand is forced on the matter due to Sansar now also being provisioned through Steam, there is also concern as to whether the S$ > USD exchange rate might undergo further adjustments other than that planned for the end of 2019.
There are currently no plans to introduce adjustments to the cash-out exchange rate beyond those indicated in the blog post, which amount to anyone cashing-out paying around 60% in commissions. To help offset this, the Lab no longer takes a commission on any store-based transactions between users; they only take a commission on the cashing-out of S$.
Even so, and not unreasonably, creators feel that the shifting of fee payments to the cashing-out process means they are effectively subsidising the Steam integration, particularly given that – by the Lab’s own admission – the majority of users in Sansar are still coming directly into the platform, rather than via Steam, yet Steam still take a cut of the cash-out transactions.
The Lab acknowledge this is currently one-sided, but given they have no means at this point in time to accurately judge how much of an impact Steam will have on Sansar’s usage, they have erred on the side of caution. But whether in time the commission percentages could be adjusted, very much depends on how traffic flow through Steam develops over time, with changes to the cash-out process liable to be considered very carefully before being implemented.
It was asked whether Sansar could be provisioned through Steam “without the money part” in order to simplify matters. The problem seen with this approach is it would exclude Steam users from any economic engagement in the platform (as their transactions must come via the Steam wallet), reducing their interest in using the platform (no ability to buy avatar accessories, good, etc.).
The Future With Steam and Other Providers (e.g. Oculus)
Linden Lab see Steam as the “industry standard” for accessing games and for using VR with games. As such, they are unlikely to move away from the current partnership. However, if over time the relationship with Steam does not prove beneficial to Sansar in terms of growth, use, economy, etc., the platform is not in any way locked-in to Steam on a permanent basis, and so a future separation is not impossible.
The Oculus store has also been looked at as a potential channel for Sansar, and talks have been held. However, because of the relationship between Oculus and Facebook, this had proven a lot harder, but is still being worked on.
New User Experience
New User Experience Steam “versus” Sansar
There still seems to be a perception that users coming to Sansar via Steam have a different new user experience to those coming via Sansar.com. Aside for the sign-up process, this is incorrect. Sansar as provided through Steam is no different to Sansar accessed via the website / direct client download: all users go through the same on-boarding experience with their Home Space and the client tutorial, and the new Social Hub.
Enhancing the New User Experience
There are internal discussions at the Lab on further enhancements to the new user experience, such as adding some form of achievements / cosmetic awards system or similar, in order to encourage engagement (particularly among Steam users).
One of the issues Sansar faces (like Second Life) is how it should be pitched, simply because the potential use-cases are so vast and different. Creators, for example, have different reasons to try the platform to consumers; even gamers with an interest in modding view things differently to those purely interested in game play. Thus, the Lab is still juggling with approaches.
In terms of Steam, one of the most basic areas in determining how the appeal of the platform could be improved is via the constructive feedback offered through reviews, given that when provided, these most frequently involve comments on the “non-standard” approach to how control options are laid out on the hand controllers.
In keeping with previous Product Meeting summaries in these pages, the Sansar Team is working on various game-style Sansar templates (e.g. shooting games). It is hoped that when these become available, they will encourage creators / users to utilise them within their own experiences, further helping to drive engagement in Sansar.
These templates have also seen the Lab considering issues such as scoring mechanisms, persistence of scores / progress between sessions, etc.
Upcoming R29 Changes
The upcoming R29 release (the first for 2019) includes some further VR updates related to a user’s “connection” to their avatar.
- One of these will be for the avatar to be more in sync with a users body movements, rather than lagging behind, as can be the case at the moment.
- Another is to provide better control of arm movements (although this wasn’t clear to me, I assume this is related to keeping the arms more naturally in line with the avatar’s body when moving the hand controllers around).
R29 should also see the removal of the height calibration menu and storing a person’s height when using VR. There will still be options for setting it, if required (such as when a headset is being used by two different people); but where the headset is only used by the one individual, it shouldn’t be necessary to re-calibrate between sessions.
Sansar Roadmap: High Level
A high-level listing of things on the Lab’s roadmap for Sansar includes the following. Note that time frames for these – including whether or not they will be developed and deployed in 2019 – have not yet been determined.
- The introduction of the aforementioned achievement / cosmetics awards system to help encourage engagement among new users.
- A sense of “history” for users as they spend time in Sansar. This could be experiential, social, awards based or some other mechanism or combination.
- The ability to transfer / “gift” objects / creations from one user to another (thus opening the door to things like event prizes, game rewards, etc.).
- Encouraging exploration, possibly through things like scavenger hunts, and underpinning mechanisms to support them.
- Applying a velocity to an avatar: Being able to apply a velocity to an avatar for thing like running faster or jumping different distances (jumps themselves will be added as a native part of the avatar capsule) etc., is seen as an addition to the avatar agent API. This is in order to prevent any native animation (jumping, running), all of which currently drive avatar movement, from overriding any applied velocity provided through something like a custom animation. This is something that can at least be investigated.
- Greater application of custom animations: custom animations in Sansar are possible, but are limited to utilising the current native animation “slots”. This limits how unique animations can be (a custom walk, for example, will still use the same native “slots” for walking – some 16 in all – resulting in the stride, foot placement, etc., being the same as the default walk). Changing this to be more responsive to a broader range of animations (and things like animation overrides) is seen as a major piece of back-end and UI work. While not something the Lab does not wish to tackle, it is seen as something that needs to be approach carefully.
- Avatar rig updates and Animations: it is likely the avatar rig will be changed in the future. If this happens, the Lab plan to use a built-in real-time capability to re-target animations to match the updated rig. This capability is actually one of the reasons the use of fully customised animations has not as yet been added to Sansar.
- Face slider support: this is still seen as something the Lab would like to add, including the potential for entirely custom heads.
- Avatar Customisation: this is seen as being in two parts: the first is custom resizing of the existing avatar selection (making it taller, fatter, shorter, thinner, etc), as a whole; the second being individual joint / bone deformations (e.g. lengthening the arms, repositioning the arm joints, etc). Both are seen as capabilities the Lab would like to have in order to achieve a wider range of avatars and avatar types in Sansar.
- One issue to be solved with this is animation: if the arms or legs are altered or joint positions changed, how will the re-targeting of animations work? One solution might be to provide a mechanism for entirely customised (and dedicated) animations sets to be uploaded for / with specific avatar models.
- Avatar blend shapes: again, something the Lab would like to support within Sansar, although how is open to question. So consider this as being more “on the radar” than anything at present.
The following are also either still being worked on or under consideration:
- Grouping objects together as a “linkset” (to use the SL terminology).
- Run-time joints (linking objects to avatars (e.g. sitting an avatar in a car that can be moved, etc).
- Scripted movement of elements that do not have physics (e.g. scripted control of animations, objects that don’t have physics assigned, etc.).
- Automatic LOD (level of detail) rendering – this will likely first come for avatars, and then progress on to include in-scene objects.
- Possible addition of a user-defined client draw distance.
Experience Load Issues
The changes to how experiences are loaded – including the addition of the cancel button – have been seen as mostly positive. There are still some instances where loading can freeze, which are hopefully being bug reported. One particular freeze seems to be right at the end of the experience load process (with the progress bar almost complete), when avatars are being loaded. Cancelling the experience load and then re-selecting the experience from the Atlas seems to both clear this and results in the experience loading almost instantaneously.
Camera Movement and Presets
Camera movement (both VR and desktop) is still seen as awkward and could be improved, particularly the camera not tracking your own avatars movement when focused on it. The lack of adjustable pre-sets for the camera in VR is also seen as problematic (e.g. the 3rd person camera position in VR is fixed, which can result in the camera being on the wrong side of a wall). Currently, the Lab does not have any work planned that has a major focus on camera control or movement.
Avatars Blocking Object Selections
The avatar capsule tends to extend beyond an avatar to a noticeable degree. This means trying to click on an object that’s behind and slightly to one side of an avatar can result in selecting the options to friend/unfriend / IM / mute, etc., the avatar, rather than selecting the object.
One possible fix to this could be to make selecting an avatar a right-click, while selecting objects remains as a left click (mouse and hand controllers). This would also resolve a problem where attempting to shoot another avatar with the left click can also bring up the friend / mute, etc., options for tat avatar, rather than firing the gun.