Yes, the celebrations are at an end. The regions will be closing their doors on Saturday June 29th, and will forever vanish shortly thereafter.
That leaves but one question to ask: was it good for you?
To help understand where the team got things right or wrong, or where things might be improved, everyone who participated in or visited this year’s SL10BCC celebration is invited to provide feedback. Please take a couple of minutes to complete the form below and let the organisers know your thoughts. It won’t be possible to respond to every comment received, but do feel free to leave your email. Rest assured, however, that every comment received will be read.
“Second Life is not a game.” How often have we heard that claim? And it’s true in many respects. Second Life doesn’t by default have any of the mechanisms associated with games. There are no levels to achieve, no goals to attain, no objectives to meet, and so on. So to simply dismiss it as a “game” is to both underestimate the potential of the platform and demonstrate a lack of understanding about it, and we’re right to point out that it isn’t, of itself “a game”.
However, there are times when “Second Life is not a game” can be used as a rolling-pin with which to thwack Linden Lab because of changes they bring to the system which appear to be focused on gaming or because of initiatives the Lab takes to reach out to potential users. When I come across this latter aspect of the rallying-cry in forum threads blog comments, etc., I’m actually surprised and not a little disappointed.
True, Second Life may not itself be a game – but that doesn’t rule out the fact that it is a very legitimate platform for game play in a wide variety of forms (of which role-play is perhaps the largest, and possibly the reason why (leaving the sex aside) a good proportion of SL users keep logging into the platform. It’s also a more than capable platform for game development and offering people many and varied means of game-like entertainment.
The fact is that Second Life is a platform which allows you to log-in and say, “OK, today, I will be a pirate!” and go off and sail the high seas,” or, “Time to go dogfight over the trenches of World War 1”, or don a period costume and explore some of the history of 18th Century France where yesterday you logged-in a followed the clues to solve a mystery (and gained some nice prizes and trinkets along the way) before engaging in some combat with friends, and tomorrow you might set-out to kill a few zombies before sitting down and enjoying a few rounds of a board game.
One team of people who perhaps best exemplify the ability of Second Life as an environment which can enable and support games are MadPea Games, the subject of the eighth segment of The Drax Files.
Started five years ago by Kiana Writer (Mari Mitchell in real life), MadPea Games has become synonymous with the provision of immersive, imaginative and genre-leading games in Second Life and stands as a shining example of something Rod Humble recently pointed-out in an interview with the San Francisco Chronicle: that while it may be true that “big business” initially jumping into SL and then deserting SL, this didn’t leave the platform dead. Rather, it left the way clear for “amateurs” and “specialists in it” (the platform) to establish very successful business presences in Second Life – and in some cases, extend their reach well beyond SL.
MadPea Games is an international team. With Kiana leading the operation out of Finland, other team members are based in France, Germany, The Netherlands, the UK and the USA. Over the years they have created a broad range of games in Second Life, spanning the genres of mystery, adventure, horror, cartoons, hunts, role-play – and more.
“I really don’t know why more people are not using virtual worlds like we do,” Kiana states at the start of the video. Looking at MadPea’s résumé, she makes a fair point. Not only have the team produced some of the most memorable games in Second Life, they’ve also worked on a number of SL / real-world cross-over projects as well. In 2009 they produced The Kaaos Effect interactive adventure in collaboration with Orange. A second collaboration with Orange in 2012 resulted in Firefly, described as a “haunting love story”.
MadPea have also worked with Nature Publishing Group and MacMillan Publishers to produce Notes from the Voyage, an educational game about the travels of Charles Darwin, and with Sigma-Aldrich to create Reaction, an interactive means to learn about chemistry. All of these demonstrate the sheer power of Second Life as a immersive medium – and the value in allowing gameplay and game-like mechanisms within it.
Kiana was not herself a “gamer” but more of a storyteller, and in Second Life she immediately saw a new potential, “I came to Second Life and I was, ‘Hey! This is a great place! I could actually bring my stories to life here!'” In describing the uniqueness of the platform compared to other games, she observes, “Immersive storytelling is when you get so lost in the story that you become the hero of the story; you’re feeling the whole environment. This is why our games are working … because with a lot of console games you become a totally different person, but in Second Life, so many people identify themselves as their avatars, so they get to play as themselves, and that’s really huge.”
Of course, there are limits to what can be achieved in Second Life; as a dynamic environment where so much is open to the users themselves in terms of how they develop their avatars, there has to be a number of checks and balances to keep gameplay in line with some of the more limiting factors of the platform, as Kiana notes, “I don’t think many people actually realise how much work it is to make sure the island is smooth. Everything is so optimised that there is absolutely zero lag. And then the crowds come in, (laughs) and then they start complaining, ‘there’s a lag! there’s a lag!’, and it’s like, ‘Yeah, because you are, as an avatar, taking most of the resources of the sim!'”
Throughout their time in SL, MadPea Games have constantly pushed the boundaries and repeatedly raised the bar on what they strive to achieve. In keeping with this – and as teased during the show – their next project Unia, promises to do so again, as they work to implement an action game within SL.
Fittingly, this segment of the show is itself a rich piece of storytelling, demonstrating not only the power of creativity within Second Life, but also the way in which it can bring people from around the globe together both as colleagues engaged in collaborative efforts and as friends. It is also one which dives into the complexities of creating immersive, interactive environments not so much by what is said, but by what is shown – kudos again to Drax for bringing together an ideal mix images and scenes to perfectly underline Kiana’s words and views.
And I have to say, I really like the role-reversal!
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (Main) Channel
On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds the new pathfinding property CHARACTER_STAY_WITHIN_PARCEL to llCreateCharacter() and llUpdateCharacter() – see my week 19 report for details – and the object return functions I reported on in week 23.
While not intended to fix issues of diagonally adjacent regions not being visible to one another (SVC-8130), there are reports that at least some of the regions which have suffered from this issue for a considerable time can be seen from one another once more – although Maestro Linden isn’t entirely convinced the underlying cause of the problem has been corrected.
Release Candidate (RC) Channels
On Wednesday 26th June, all three RC channels (Magnum, BlueSteel and LeTigre) received a new server maintenance package, comprising:
A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
added to avoid changing the behaviour of existing scripts which may rely on llXorBase64StringsCorrect()’s current output
Added max_materials_per_transaction flag to /simulator/features cap
This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.
Speaking at the Server Beta meeting on Thursday 27th June, Maestro Linden described the max_materials_per_transaction flag thus:
It limits how many materials the viewer can request details for or set (POST, PUT methods) in a single message. By default, the limit is 50. The reason for the limit is that we don’t want the simulator to hang if a malicious viewer requests the details of 2 billion materials at once.
So, the capability for materials is called RenderMaterials [and] it has 3 HTTP access methods:
GET: get the full list of details of all materials in the region
POST: get the materials details for a list of material_ids (the server will only parse the first max_materials_per_transaction in the post data)
PUT: set the materials properties of up to max_materials_per_transaction object faces
GET is used when you first connect to a region and want to get the materials of everything [in the region, not just within draw distance]; POST is used if, for example, a new object is rezzed with a new materials type, and the viewer needs to resolve what the normal map is, etc; and PUT is used for object editing.
[So] if the viewer needs to edit 80 faces at once, for example, it will know that the server limit is 50, and POST in 2 messages (one for the first 50, the other for the other 30). [The] ‘max_materials_per_transaction’ flag in the features cap will be a way for the viewer to know if the server limit changes from 50 per message. I’m not aware of any plans to change that limit in the near future, though.
Deployments for Week 27
There will be no server-side deployments in Week 27 (commencing Monday July 1st), as US Independence Day is on Thursday July 4th. The next scheduled deployments will be in week 28, commencing Monday July 8th.
Elijah Linden has discovered a bug within the pathfinding code, wherein certain regions have continuous navmesh rebaking, which causes some annoying UI effects, hurts simulator performance somewhat and causes memory spikes. Regions can be affected even if pathfinding is turned off.
The bug arose as a result of the recent CHARACTER_STAY_WITHIN_PARCEL property added to the pathfinding capabilities. Commenting on the bug at the Server Beta meeting on Thursday 27th June, Voidpointer Linden, who implemented the new CHARACTER_STAY_WITHIN_PARCEL property, said:
As part of the STAY_WITHIN_PARCEL changes, I needed to change the way the navmesh is constructed. This involved making sure that every region did a rebake once. Unfortunately, the criteria that I used to test whether a region needed rebaking had a flaw – it can’t see parcel edges underwater [possibly because the navmesh doesn’t include areas below sea level]. So if a region has more than 1 parcel and has no parcel edges above water, then it thinks it needs to rebake. So it does.
And does so repeatedly, as Elijah Linden reported in BUG-2975 (Regions continue to requests rebake after rebakes have been performed).
There is a fix for the issue, but it currently requires testing, and may not appear for a while. In the meantime, there is one assured workaround: if your region is suffering from the issue and has a parcel which is completely submerged, subdivide / raise one part of a boundary for that parcel (and which is not also a region boundary) above water so it can be found by the navmesh rebake process.
This bug is unlikely to be resolved before week 28 due to there being no deployments scheduled for week 27, as mentioned above.
The SL release viewer updated to version 188.8.131.528007 on June 27th, containing the fixes from the 184.108.40.2067611 beta release. This contains some updates related to the viewer being available via Amazon, and fixes for occlusion culling being less effective than it should be, legacy Shiny being too strong in ALM with materials,light function sampling is incorrect in advanced lighting model and a viewer compilation error.
The beta viewer updated to 220.127.116.117824 on June 26th, with the release notes listing the same updates as 18.104.22.1687611 and 22.214.171.1248007 – so these appear to be work-in-progress fixes.