The Drax Files Radio Hour interviews: Emily Short

radio-hourEpisode #23 of  The Drax Files Radio Hour was posted on Friday June 13th. With the “live” podcasts currently on hiatus until August 2014, this is the second of a series of more in-depth interviews with people from across the metaverse and beyond.

As usual, and as well as being available on the show’s website and on Stitcher, episode #23 is also on YouTube, and embedded at the end of this article.

The featured interview with this show is with none other than interactive fiction writer, narrative design consultant, co-founder of Little Text People, co-developer of Inform 7, the interactive fiction system, co-developer of Versu – I could go on and on, such is my admiration for her – Emily Short!

Given the above, you might be able to guess that this is an interview I’ve been looking forward to, and while time wasn’t the best, I tried to assist Drax in getting ready for it (although even then, some of the planning went out the window as we were overtaken by events!), so my thanks to Drax for the shout-out at the start of the show,

Emily Short on the IF panel, PAX East, 2010
Emily Short on the IF panel, PAX East, 2010

The interview, which commences at the 3:44 mark, is extremely wide-ranging, covering topics such as the creation of Little Text People, the time Emily and her LTP colleague, Richard Evans spent at Linden Lab, the nurturing of Versu, Emily’s own background and how she came to be interested in interactive fiction (IF) via the work of games design pioneer Scott Adams (not to be confused with the creator of Dilbert!) and moving forward from there.

Since the announcement that Versu – albeit is a slightly different Versu to the one initially marketed by the Lab – would be able to continue under its own banner, there have been musings as to the deal struck between Linden Lab and the Versu team. Had the IP been fully released by the Lab? Had an agreement on revenue sharing been achieved? Were there other strings attached?

Obviously, such questions may not be the easiest to answer; commercial arrangements between companies tend to be saddled with NDAs and the like, and the Versu / Linden Lab arrangement is certainly one of those. As such Emily has to be circumspect when answering such questions. However, she does indicate that there may potential for some of the titles from the “app version” of Versu to reappear, such as the Office Politics titles by Deirdra Kiai. Whether these will be direct ports or will see anything added to them, should it come to pass, remains to be seen.

The Office Politics titles, by Deirdra Kiai, were written for the original Versu app, and might appear with the new Versu in the future
The Office Politics titles, by Deirdra Kiai, were written for the original Versu app, and which might appear with the new Versu in the future

It’s important to note that the Versu we see with Blood & Laurels is somewhat different from the Versu which first appeared under the Lab’s banner. As Emily notes, the “first” Versu was more an app into which IF games could be plugged. Versu as we see it now is geared more towards developing self-contained titles – as Blood & Laurels is, and just as Bramble House will be. Packaging titles in this way offers the ability to build much more involved games – as has been noted, Blood & Laurels has some 240,000 words of interactive content, only 7% of which is liable to be encountered in a single play.

Author and Linden Jake Forbes (via Amazon)
Author and Linden Jake Forbes (via Amazon)

With the original Versu, much was made of the potential for people to create their own IF games for use on the platform. Whether this is still the case is unclear. The system itself would apparently need more work to support this, and the agreement with the Lab may limit what can be achieved in this area. Currently, story development remains confined to the Versu team and select other authors such as Bramble House’s Jake T. Forbes (himself a Linden as well as an author in his own right) and, possibly as noted, Deirdra Kiai.

An interesting aspect of Versu’s modularity is that it needn’t necessarily be limited to a text-based front-end. but could be embedded into something else or skinned by an alternative front-end. This means it could, for example, potentially be used in other game types or in business training or in education. These latter areas were somewhat upon in May 2013, when Versu co-creator Richard Evans presented his paper Versu: A Simulationist Interactive Drama, at the Games and Media Event at the Imperial College London, which prompted Douglas Heaven to write AI makes social game characters all too human for New Scientist Online, and which I wrote about at the time.

Whether this flexibility with the Versu components means it might see use in support of better AI-driven NPCs within Second Life, as many have speculated in the past, remains to be seen. This is another area Emily is not in a position to comment upon – which shouldn’t necessarily be taken to mean something is being worked on.

Another interesting aspect with Versu is the potential for it to be used in a multi-player format. While there are no plans for it to be used in this way at present, Emily offers some intriguing speculation on the matter:

The Versu engine is capable, under the hood, of doing multi-player as well as AI characters. And something that we talked about a long time ago, in the early days of the project … you would be able to play in the multi-player, and you would actually be able to add new content to the story. So if you got to the point where you were playing with somebody and you wanted to say something that wasn’t already coded into that scenario, you would actually be able to, right at that moment, write a new piece of content…

It’ll be interesting to see if this does come to pass down the road, as the team hopefully develop the resources they need to enhance and develop Versu, and as opportunities of perhaps working with third parties arises.

There is so much more to this interview than can be covered here. Where AI may go in the future; cautionary notes on how governments or private organisations might employ AI technologies alongside the huge amounts of data (social and otherwise) we’re allowing to be accrued on ourselves; caveats about tests used to determine whether or not the conditions of the Turing Test really have been met; have been met; even dreams of holodeck-style IF are explored!

All of which makes this a fascinating conversation, one well worth taking the time to sit down and listen to, whether or not you’re directly interest in interactive fiction (and you likely will be by the end of it!).

congrats to Drax on his Best Machinima award at the New Media Film Festival

SL projects update 24/2: viewer, LSL materials functions

 Server Deployments Week 24 – Recap

  • There was no new deployment to the Main (SLS) channel, although it was subject to a grid-wide restart following schedule maintenance on Tuesday June 10th
  • BlueSteel returned to the Sunshine / AISv3  inventory update, which requires the use of the Sunshine RC Viewer
  • LeTigre once more had the server-side group ban project updates deployed to it. See the release notes for details
  • Magnum returned to the Experience Tools project.

The RC channel updates were essentially the same updates as deployed in week 23, but subsequently overwritten following a grid-wide security issue update.

SL Viewer

The Snowstorm code contributions viewer appeared as a project viewer on June 12th. Version 3.7.9.290788 includes some 20 code contributions to the viewer, including:

  • STORM-68 Allow setting of default permissions on creation of objects, clothing, scripts, notecards, etc.
The new floater for setting default permissions for created items as it should appear in the Snowstorm viewer
The new floater for setting default permissions for created items as it should appear in the Snowstorm viewer
  • STORM-1831 Obtain LSL syntax table from simulator so that it is always up to date: this update allows the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to, eliminating issues with using manually updated syntax files within the viewer falling out-of-synch with the simulators as new LSL syntax as new functions and parameters, etc., are added
  • STORM-1966 Block installation on old and unpatched versions of Windows: this updates causes the viewer’s Windows installer to check to see Windows XP systems have the latest patches installed (i.e. Service Pack 3 for 32-bit XP and Service Pack 2 for 64-bit XP). Any XP systems not meeting these requirements will be unable to install the viewer until such time as they are updated. Additionally, Windows Vista and Windows 7 systems  lacking a Service Pack update will receive a warning, but installation of the viewer will not be blocked

For the full list of OPEN and STORM updates, please refer to the release notes.

LSL Functions for Materials

The Server Beta Meeting on Thursday June 12th included tests to see whether the new LSL functions for materials might offer griefing opportunities. Maestro Linden had created two 256 prim linksets using default prim cubes, one of which was scripted to use PRIM_NORMAL to continuously set a unique material on each of the 6 faces of each prim, and the other was scripted to continuously set PRIM_TEXTURE on each face to a different alpha-blended diffuse texture.

Two sets of four of these objects were rezzed in turn, and meeting attendees asked to monitor their viewer performance (FPS and UDP bandwidth) while the Lab watched the simulator.

Server-wise, performance was largely unaffected by either type of object, with the load being largely controlled by the built-in LSL performance controls. Throughout both tests, and with no  objects rezzed, script spare time remained almost constant around the 14-15ms mark.

Viewer-wise, both types of object impacted FPS, with most people reporting around a 50% drop from the materials-enabled objects, compared to around 40% with the texture changing objects.

Both tests saw an increase in UDP information being sent to the viewer, with bandwidth use increasing by a factor of around 3.5 to 4 (e.g. 180-200kbps to 700-800kbps) with the materials objects and a factor of around 5 to 5.5 for the texture changing objects. As indicated by Maestro, the lower bandwidth use by the materials objects was due to the throttles already in place for how quickly the viewer will look up materials properties.

The takeaway from this (and other tests Maestro has performed) is that scripted materials controls are unlikely to be a major source of griefing. The simulator seems to handle excessive use of script materials in its stride, and impacts on the viewer’s frame rate can be mitigated by using Develop > Show Updates to Objects (CTRL-ALT-SHIIFT-U) to block the offending object.

There are still concerns over potential bandwidth impacts, such as by combining the materials LSL functions with other scripted controls, and concerns how the viewer might be affected by peculiar uses of the materials functions (such as combining them with the already laggy animated mesh tails that are available). However, it seems that for now, the Lab will continue to monitor things to see what happens and whether anything unexpected does crop-up, rather than moving immediately to apply throttles to the functions.

In the meantime, the arrival of these functions has prompted people to start putting together feature requests to be able to animate diffuse (texture), normal and specular maps on an object / object face independently to one another. The Lab has previously indicated that trying to do this via llSetTextureAnim() would be “pretty ugly to implement or would need some careful design …” and that as such they have no plans to try this at present. It’ll be interesting to see if any feature request(s) put forward persuade them otherwise.

Have a favourite SL location? share it with the Guardian, Lab suggests

Forgotten City
Forgotten City, click for full size

On Tuesday June 10th, and spotted by Ziki Questi, the Guardian Online in the UK carried an article about how modern urban design is influencing city game design in computer games – and vice versa. As a follow-up to that piece, the Guardian has invited readers to share their favourite virtual cities, and the Lab suggest this is the perfect opportunity for Second Life users promote their favourite Second Life locations.

The Guardian asks readers to upload screen shots of their favourite urban locations via a Guardian Witness page (user-generated content pages curated by the Guardian), which explains:

We want to hear about your best-loved virtual places – from a beautiful view in GTA V to that 20-million-strong SimCity megalopolis you’ve been building (or possibly destroying). What would be the best video game cities to live in? The worst? Perhaps you’ve designed one you think would be better than your own city? Share your screen grabs and we’ll feature the best on Guardian Cities.

To contribute, readers can log-in to the page using either a Facebook or Google + account and then upload a screen shot of their own with some descriptive text, and / or recommend those uploaded by others. There are several locations from Second Life listed on the page already,

Caelestivm, Palau, March 2014 Caelestivm, Palau, March 2014, click for full size

Quick to spot a promotional opportunity, the Lab has suggested, via a Featured News blog post, that more SL users should submit their own favourite locations to the Guardian’s page, noting:

This is a great chance to share some amazing Second Life locations with The Guardian’s readers. Whether it’s a place you created personally, discovered (maybe through the Destination Guide?) and love, or just a spot you always find yourself returning to, the Second Life locations that ‘wow’ you are great ones to share to help show off Second Life to the uninitiated.

Assuming the Guardian doesn’t get overwhelmed by images from Second Life and feel a little narked as a result (and keeping in mind they’re asking for city-like images, which the lab’s blog post tends to brush over in referring for “locations”), this might be a way to shine a little light on some SL builds and get a message out about the user-generated nature of SL.

As well as the pointer to the Guardian, the Lab is inviting users to share their favourite SL locations (city or otherwise) via a forum thread, and to submit any which aren’t already listed to the Destination Guide.