# Designing tools for live performance in social VR

David Gochfeld, Roman Miletitch

► To cite this version:

David Gochfeld, Roman Miletitch. Designing tools for live performance in social VR. Journées d'informatique théâtrale, Oct 2024, Avignon, France. hal-05136964

HAL Id: hal-05136964

https://inria.hal.science/hal-05136964v1

Submitted on 30 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# DESIGNING TOOLS FOR LIVE PERFORMANCE IN SOCIAL VR

David Gochfeld

Royal Central School of Speech and Drama

London, UK

Roman Miletitch

ThirdPlace Lab

Paris, France

## ABSTRACT

Since the introduction of consumer-oriented virtual reality headsets a decade ago, a number of online platforms have become available that support multi-user telepresence in 3D-rendered environments, also known as social VR. A growing group of artists have embraced social VR as a medium for creating and presenting their work, including theatrical creators presenting live performances. Theatrical productions, and live entertainment more generally, rely on the ability to trigger cues: events that change the look or sound of the performance as it happens. Creators of theatrical performances in VR need similar capabilities, but these are not readily available in most social VR platforms. To produce live performance events in social VR, artists must implement programmatic extensions to enable real-time changes to the environment or the performance. We outline the key features and structure of a show control system for theatre in social VR, in the hopes of reducing the duplication of effort among artists building these tools from scratch, and as a suggestion to designers of social VR platforms who aim to make better tools for theatrical artists in virtual reality.

## 1. INTRODUCTION

Since the introduction of consumer-oriented virtual reality headsets a decade ago, a variety of online platforms have become available that support multi-user telepresence in 3D-rendered virtual environments, also known as social VR [3]. Some of the more popular examples are *VRChat* [1], *RecRoom*, *Mozilla Hubs*, and *Meta Horizon Worlds*. By providing the sense of embodied presence with other people, regardless of real-world location, they afford a different experience than videoconferencing [23, 25]. And they have proven irresistible to theatre-makers and performers as spaces in which to create and perform together.

Theatre artists have been experimenting with the use of interactive, computer-generated 3D environments in performance for over forty years, and with virtual reality for nearly as long [9, 8, 21]. Theatre is an art predicated on illusion, but is nonetheless constrained by the physics of the real world. Computer generated visuals escape these constraints, enabling creators to render anything they can imagine. The advance of networking technologies enabled real-time remote collaboration, leading to experiments in telematic performance, a new opportunity for

theatre which has historically been dependent on local coexistence [2, 26, 14].

Virtual reality is unique among other media because it affords the experience of embodied presence in a virtual environment [16]. It shares this with theatre, which, at its most essential, relies on the corporeal presence of the actor and the audience in the same space [4, 11]. Because of this link, virtual reality researchers and theatrical artists often collaborate on research or creative projects, for example [8, 24, 22, 10]. There are many examples of theatre artists adopting multi-user virtual environments and social VR to rehearse and perform work, such as [19, 17, 14, 7].

For artists, the advantage of working with an existing social VR platform is that they already solve many of the challenging engineering problems: the underlying networking and replication of objects and actions across all of the clients; avatar systems, inverted kinematic animation and player locomotion; and audio and in-world voice communication. With existing communities of users, it can be easier to build an audience [13]. However, current social VR platforms have not been designed with live performance as a primary use case, and present significant challenges to creators who want to present performances in the virtual world using theatrical techniques.

Theatrical productions rely on the ability to dynamically trigger changes to the look or sound of the performance as it progresses. These may help frame the theatrical event: before the show starts the stage may be in darkness while the audience seating is illuminated, and when the performance starts the house lights go down and the stage lights go up. They are also essential to telling the story. Sets, lighting and sound help establish the setting and atmosphere for the play. Because a piece of theatre progresses in unbroken, contiguous time, and in a single place, a great deal of theatrical art and technology has developed (over the past 2500 years) to help denote changes of location and jumps in time: backdrops may fly in from above, or set pieces slide in from the wings; the lights on the stage dim or brighten; music and sound effects play at specific points to underscore events on stage [20, 5, 6].

Each of these changes is called a *cue*. A typical theatrical production onstage today might use hundreds of individual cues for lighting changes, sound and music, projections or scenic changes [18, 12]. These are controlled by computerized systems that allow a stage manager or operator to trigger each cue at a specific time during the performance [15]. This kind of tool is missing in current social VR platforms. Instead, creators working in social
<table><caption>**Table 1:** Non-exhaustive comparison of the complexity of tasks in VR versus the physical world.</caption><thead><tr><th></th><th>Easy in Physical World</th><th>Hard in Physical World</th></tr></thead><tbody><tr><th>Easy in VR</th><td>Actors moving objects<br>Actors moving themselves</td><td>Flying an actor<br>Moving objects while unseen<br>Objects appearing/disappearing<br>Resizing actors or objects</td></tr><tr><th>Hard in VR</th><td>Costume changes<br>Gravity & mass<br>Audience seating<br>Actors positioning for the show<br>Script-in-hand rehearsal<br>Sound & visuals synchronization</td><td>Modifying audience appearance<br>Moving the audience<br>Silencing the audience</td></tr></tbody></table>

VR have to implement custom solutions for every type of cue they might need, and build an interface to control them. These have to be engineered from scratch for each social VR platform, as the underlying software and the programming interfaces are completely different. Usually, the complexity dictates that a developer with specialized experience of a given platform is needed to build the system. As creators move from one platform to another (often because a platform shuts down, c.f. *Altspace*, *Neos*, and *Mozilla Hubs*) they have to build the tools all over again. This can be costly, time consuming, and creatively limiting. It is also a significant barrier to entry for new artists.

As both technical and creative contributors to several of these projects, we have observed different groups of artists solving the same problems repeatedly, reinventing the wheel for each new production. With this paper we hope to shortcut some of this duplicated effort, by identifying the common features required for VR theatre and presenting a simple taxonomy, as a guide to designing a show control system for live VR performance. While we focus on social VR platforms, the points we will discuss are not limited to virtual reality. The design considerations presented below apply generally to live performances using 3D virtual environments, regardless of how the audience is viewing or participating in the experience.

## 2. SHOW CONTROL SYSTEM FOR VR PERFORMANCES

Designing for the virtual stage comes with both flexibility and challenges. While there are fewer physical limitations, everything needs to be deliberately programmed, as there is no default layer of tangible objects or expected interactions. In real-world theatre, actors naturally interact with props, but in VR, those interactions must be explicitly designed. Ensuring a smooth, bug-free experience across different devices adds another layer of complexity. At the same time, VR enables effects and transitions that would be difficult or impossible in physical theatre. Table 1 provides a non-exhaustive comparison of the com-

plexity of various tasks in VR versus the physical world. Note that some things are easier or harder due to design choices of the platform you're working in, rather than being an intrinsic property of VR.

The aim of a control system is to allow both actors and their stage manager to have control over various elements of a VR performance by triggering specific cues. In this article, we define a cue as an action that impacts controlled elements of the virtual world, set off by a trigger and initiated by people in a specific role.

Different members of the production team will need specific ways to trigger cues, stemming from both their needs and their input device type. A virtual actor will most likely be using a VR headset and either controllers or hand tracking. A stage manager or stage crew may also be in a VR headset, or could be in front of a computer, with a 2D interface, using its keyboard and mouse, or an external controller such as a game controller or MIDI keyboard. Lastly, the creators can program behaviours, pieces of code that affect virtual elements in response to environmental cues such as time, proximity of avatars, the press of a virtual button, the end of a video, etc.

A cue management system must provide flexible and precise control over cues, ensuring smooth execution of a virtual performance. At its core, it should allow users to trigger individual cues as needed or advance to the next cue in a predefined sequence. However, performances are rarely linear, and stage managers may need to jump to a specific cue, either by playing through intermediate cues or skipping directly to the desired point. Additionally, a rollback function is essential, especially for rehearsals, enabling users to revert to a previous cue if an adjustment or correction is required. This requires a system that can not only store a history of activated cues but also implement reversible actions, ensuring that any triggered cue can be undone or modified when necessary.

In the following sections, we propose a taxonomy for the active elements of a show control system (summarized in Table 2): the elements that need to be controlled, the different user roles, and the triggering methods. We then
<table><caption>**Table 2:** Proposed taxonomy for a show control system.</caption><thead><tr><th colspan="3">Show Control System</th></tr><tr><th>Triggers</th><th>Roles</th><th>Controlled Elements</th></tr></thead><tbody><tr><td>2D Interface</td><td>Audience</td><td>Scenic Elements & Props</td></tr><tr><td>Gear</td><td>Performers</td><td>Lighting</td></tr><tr><td>In-World Interface</td><td>Stage Crew</td><td>Sound & Music</td></tr><tr><td>Diegetic</td><td></td><td>Avatars</td></tr><tr><td>Automated</td><td></td><td>Audience</td></tr><tr><td></td><td></td><td>Physics elements</td></tr><tr><td></td><td></td><td>Behaviours</td></tr></tbody></table>

finish by presenting a small example and discuss the constraints encountered when developing such a system.

## 2.1. Controlled elements

In VR theatre, we can classify the kinds of things that may need to be controlled by cues as follows:

* *Scenic elements & props* - in VR, those would be graphical elements, either static (e.g. 3D object, text, pictures) or dynamic (e.g. videos, animation of 3D objects). They are often integrated inside a physics engine.

* *Lighting* - from spotlight to ambient light with everything in between.

* *Sound & Music*- character (performer) voices, sound effects, music, and ambience.

* *Avatars* - performers may change costumes, size or location, or switch characters by taking control of different avatars. The audience may be given specific avatars, or transported to different locations.

* *Audience* - cues might affect the audience in other ways, such as disabling everyone's microphone, or giving them a new ability at a certain point in the show (for example, allowing them to "fly" after previously constraining their movement to the ground.)

* *Physics elements* - these are features of the platform's physics engine, such as colliders, cloth or fluid simulation, wind, or gravity. They are not always linked with a visual element. For example, a collider can act as an invisible wall blocking the way, or deactivating a collider could allow actors to pass through a set piece that was previously impassable. Switching gravity on or off in certain areas of the world would change the dynamic of objects dropped or thrown in that location.

* *Behaviours* - by default previous elements are either static, or with a simple dynamic (videos, 3D animations). Behaviours are ways to give them some form

of autonomy, and allow them to react by themselves to an evolution of the environment. For instance, a prop could remain invisible to the audience, until an actor grabs it. Behaviours can be as simple as reacting to specific triggers such as proximity of an actor or audience member, a button press, or the end of another event, and as complex as an artificial intelligence behaviour, like a dog following an actor on stage, or a character connected to a large language model.

## 2.2. Roles

In theatre, there are three distinct classes of participants: the audience, the performers, and the staff or crew (encompassing, for example, front-of-house staff, stage management, board operators and stage crew.) They have distinct roles or responsibilities during a performance, and different degrees of access to parts of the theatre. Virtual reality theatre has a similar division of roles, which we will refer to as *audience*, *performers* and *stage crew*.

As in any access control system for a digital service, different groups of users need to be able to do different things, and shouldn't be able to do other things. Each user role can have different sets of permissions (or privileges) which control what they can do in the world, including what they can see, where they can go, and what they can interact with. A permissions system is essential for maintaining creative control over the audience experience.

In real-world theatre, certain kinds of cues are the domain of each role. For example, crew members will run lights and sound or move set pieces, while actors may move their own props or change their own costumes. In virtual theatre cues are no longer inherently tied to specific roles. This makes it possible to distribute the workload more flexibly, empower performers with new possibilities, and even allow the audience to trigger specific cues, enhancing interactivity.

The *stage crew* oversee all show cues, and are primarily responsible for those that affect the entire environment, such as lighting, sound cues, and set changes. They may also operate cues that affect the performers or audience,
online performances to provide a more tangible alternative to 2D interfaces. So, rather than clicking onscreen buttons, the stage manager could trigger cues using hardware, such as drum trigger pads on a MIDI controller.

Actors in VR usually perform with a headset and either controllers or hand tracking. Controllers can trigger cues via button presses, but on some platforms this may require overriding default button assignments. With the rise of hand tracking (as on the Apple Vision Pro or the Quest 3), actors gain more expressivity through full-hand motion capture but lose a discreet way to interact with the world. Without controllers, triggers must be redesigned using gesture-based inputs, a virtual wrist menu, or other unobtrusive controls. This shift highlights a broader challenge: as VR moves toward a one-to-one mapping with reality, even subtle movements like eye tracking could impact performance, making actions like checking a virtual prompter more difficult.

**In-world Interface** - Instead of relying solely on external controls and traditional 2D menus, interfaces can exist directly within the virtual world, providing an interactive control system (such as the button seen in Figure 2). These interfaces are not part of the performance but serve as operational tools within the environment, which may be used by stage crew or actors during the performance. For example, a floating control panel could allow the stage manager to trigger cues using 3D buttons, sliders, or dials arranged in space. A more advanced version might be a virtual control room, where different elements of the performance (lighting, sound, and set changes) are managed through a scaled-down 3D model of the stage, letting the crew visualize and manipulate cues dynamically. This approach blends the flexibility of 2D interfaces with a more spatial and intuitive way to organize show control, and allows the operator to be in the virtual environment along with the performance participants.

Many social VR platforms don't permit modification of the user interface to add onscreen buttons (as discussed above), so additional functionality for users must be implemented within the game world. *OffRail*, performed in VRChat, used several different kinds of in-world controls. For cues which would always be triggered at a specific point in the show, buttons were placed in the locations of those scenes (see Figure 2). Because the show was highly interactive and improvisational, the actors needed triggers they could activate at any time: these were available on a floating control panel they could summon as needed. In both cases, the controls were invisible to the audience, and could only be activated by specific authorized users.

**Diegetic** - A diegetic interface is a special type of in-world control where interactions occur naturally within the environment. Instead of pressing a floating button, an actor might cut an object in half with a virtual knife or open a door by turning its handle. While these actions would be intuitive in real life, they must be deliberately designed in VR. Though more complex to implement and often case-specific, diegetic interactions create

a more natural and immersive experience for performers. When mimicking real-life behaviours, they also contribute to a greater sense of realism within the virtual performance.

<figure><img src="image_2.png" /><figcaption>**Figure 2:** Example of an in-world interactive button integrated directly within the virtual scenery, taken from the performance *OffRail* (2022). This button allows an actor to teleport the audience (and other actors) to the next area of the performance.</figcaption></figure>

**Automated** - Triggers can be activated based on predefined conditions, such as an actor entering a trigger zone, a change in sound levels, or any other modification of environmental conditions. For instance, in *Brecht Into The Metaverse*, a platform within a house was designed to move up once an actor stepped on it, allowing for easy access to the upper floor.

These are especially useful for making the environment responsive to the audience, such as triggering a door to open when they approach, or activating a pre-recorded NPC sequence when they enter a room. They can also create seamless transitions triggered by a performer's movement; but this requires careful design. Since actors in VR may struggle with precise movement, automated triggers must be calibrated to avoid accidental activation.

In most cases, actors may prefer direct control over their cues rather than relying on automated triggers. A clearer interface, such as pressing a button, can offer more predictability, even if it feels less seamless within the performance. Additionally, automated triggers may need to be enabled or disabled at certain points in the show, to ensure they function only when needed, preventing unwanted disruptions in the performance.

In the climax of *OffRail*, the villain delivers a dramatic speech until they are suddenly sucked into a tornado and disappear. Because the speech was improvised, the actor needed to control the moment when they are whisked away; but it would undermine the surprise if they had to stop to press a button on their control panel. An automated trigger was placed directly behind them, so stepping back would seamlessly trigger the sequence that pulled their avatar up into the sky. This trigger had to remain inactive until this particular moment: it was only armed when the twister appeared.
<figure><img src="image_3.png" /><figcaption>**Figure 3:** Exploration of various control methods for a radio element during the production of *Brecht Into The Metaverse* (2024) in VRChat. Different interactions were tested, including diegetic controls (using buttons integrated directly into the radio), automated triggers (radio activated by proximity), and in-world interfaces (3D button above the radio). The latter was ultimately selected as the most accessible of the three.</figcaption></figure>

## 2.4. Practical case: opening a door

Combined together, *roles*, *triggers* and *controlled elements* allow for a wide variety of controls over even a simple action, such as triggering the sound of a radio (Figure 3). Often, the correct approach depends on the intended outcome, audience perception, the technical expertise of the creators, and practical implementation considerations. For example, a door-opening sequence could be designed in several ways:

1. The door could open automatically when an actor gets close enough, which is convenient if the actor is holding props but limits control over the action;

2. The actor could manually interact with a doorknob, allowing for varied performances, such as opening it quickly, slowly, or cautiously;

3. A stage manager could trigger the door opening remotely to time a reveal or coordinate with another event;

4. The door could follow a behaviour such as opening at random intervals to simulate external forces like wind, requiring actors to react accordingly.

These approaches illustrate the range of design choices available, from realistic interactions to effects that would only be possible in a virtual environment.

# 3. DESIGN CONSTRAINTS

Designing a show control system for VR performances requires careful consideration of the specific constraints

that come with working in a virtual environment. In traditional theatre, stagecraft relies on physical infrastructure and well established practices, whereas VR performances are entirely software driven. This means that every aspect of the show (lighting, sound, set changes, audience interaction) must be deliberately programmed and controlled. A robust show control system is essential to ensure smooth operation, maintain consistency, and provide reliable tools for performers and stage managers.

Design constraints vary significantly depending on the chosen platform: different social VR platforms have different design philosophies, which determine what kinds of things show creators can do and how to do them. They will also impact reliability and usability, key factors in the audience experience. Keeping these constraints in mind from the outset helps create a system that is both functional and adaptable.

**Synchronization constraints** - Platforms differ in their underlying implementation for multi-player networking, which has implications for how changes in the environment are replicated among the audience clients. In a system which uses a central server to host multiplayer sessions, the geographical location of that server could impact latency. In extreme cases, if the server duties are distributed across different data centers and there is a fault somewhere in the system, different groups of clients could see very different things. On the other hand, many social VR platforms do not offer a centralized server (per room or event) to manage triggers, interactions, and the overall world state. Instead, they often rely on a peer-to-peer model, where the first client to enter the space may act as the server, or any client could become the owner of some element in the environment, and thus the only authority on the state of that object. These may seem like esoteric considerations, but they can cause problems in a performance where control over the state of the world and synchronization among players is essential for a coherent narrative experience.

Network latency is an issue whenever information is shared in real time during the performance: the position of moving objects, starting or stopping a video or animation, set changes or character entrances. All of the participants in a social VR event are remote, with differing quality connections to the internet. For any given event, some audience members may experience it several seconds later than others. For creative teams and performers, this means we can't count on simultaneity at any point, and we may need to allow intervals for clients to catch up.

If a spectator's connection drops a few packets (or if they join the performance late) they may miss the signal that triggers an important cue, so their experience falls out of sync with the rest of the audience. If inconsistencies become too pronounced or persist for too long, they can shatter the illusion of a unified experience and disrupt the sense of immersion and suspension of disbelief. While we can't account for all breaking circumstances, a cueing system should include fallback mechanisms to resynchronize the audience. For example, it could locally retrigger
all cues from the beginning to bring any desynchronized
client back in sync.

**Audio constraints** - Sound design for multiplayer VR is difficult. Streaming audio, especially when coming from different sources spread around multiple locations is hazardous. Different microphones have different sound quality, sensitivity and levels. Network latency is notoriously troublesome for audio streaming, and harder to manage when you try to sync multiple streams together. Round-trip latency between performers can derail fast-paced dialogue and comic timing, and singing together is practically impossible. Audio elements like music or sound effects may suffer doubly: the cue trigger may be received at different times for each client, and the audio stream itself may be degraded or interrupted. If the platform allows for preloaded audio assets, that can improve reliability but increase initial load times.

**Hardware constraints** - One of the key challenges in designing virtual theatre is balancing high-fidelity visuals with accessibility across different hardware. Social VR performances must accommodate a wide range of devices, including smartphones, laptops, and VR headsets, with varying processing power and levels of immersion and interaction. High-end graphics and complex simulations can enhance immersion but may exclude viewers with lower-end machines, and break completely on standalone VR headsets (like the Meta Quest.) Some platforms offer scalable graphics settings, allowing users to adjust performance based on their hardware. Show designers should take into account how the essential elements of the show will render at lower settings, to ensure a consistent experience for all users. While this won't necessarily affect the design of the show control system, it is a consideration in the design of the cues themselves.

**Object permanence** - Unlike physical theatre, where the stage and set naturally persist over time, virtual theatre lacks an inherent sense of permanence. Every element of the performance (lighting, sound, props, character positions) must be actively maintained. As such, the state of the virtual world is a representation of its current conditions, allowing the show control system to track and restore key events.

Most platforms have some sort of implementation of a state of the world (if only the position of the elements in the scene), but can never encompass all different possibilities. For instance, a change in texture of a specific 3D object may not be automatically replicated. Or if the show involves teleporting the audience to different parts of the world, then someone arriving late, or disconnecting and re-joining, may find themselves in the wrong place and miss part of the performance.

A state system that encompasses the whole state of the performance is essential for audience continuity. If a viewer disconnects, they must be able to re-enter the experience at the correct moment. Additionally, state tracking ensures logical sequencing; certain events should only be triggered if prior conditions have been met. This is cru-

cial for implementing functions like jumping forward or back in the performance timeline, enabling scene resets, or adapting to real-time disruptions such as those mentioned above. Without this structure, maintaining coherence in a complex digital environment becomes nearly impossible.

## 4. CONCLUSION

The taxonomy presented in this article is not exhaustive, but it provides a framework for the design of show control tools for live performances within multi-user 3D virtual environments. More broadly, we hope that this article will open a discussion about how to craft better tools for artistic performances in virtual reality. While the metaverse has lost its buzz, the use of metaverse platforms will continue to grow, providing exciting opportunities for artists to find new collaborators and new audiences, and for them to create new kinds of work that take advantage of the affordances of virtual reality.

While our focus has been on performances taking place entirely within virtual spaces, the proposed architecture can also support hybrid settings where physical and virtual performers and audiences coexist. Rather than expanding the taxonomy to introduce new elements reflecting the physical world, a more promising approach lies in enhancing interoperability. Many established tools already exist for managing cues and devices in physical performance environments. Interfacing show control systems for virtual performances with these physical control frameworks would enable creators to synchronize events between real and virtual, fostering truly mixed-reality experiences.

Many of the challenges facing virtual performances today are not due to hardware limitations but rather a lack of established design practices and accessible tools. Too often, we assume that future updates will solve current problems, but in reality, much of what is needed already exists; it's just a matter of developing better workflows, refining interaction design, and ensuring creators have the right frameworks at their disposal. Instead of waiting for better tools, the focus should be on improving how we use the ones we already have.

While large companies dominate VR, independent creators are often the ones pushing boundaries and reimagining how these tools can be used. Historically, artists have driven innovation by repurposing technology in ways that later influence mainstream adoption. However, current platforms often favour corporate interests, making it harder for smaller creators to experiment. Supporting independent work through open tools and flexible systems could help ensure VR's evolution isn't solely shaped by big tech.

As such, there is a clear need for an open platform designed specifically for virtual performances, with fully featured tools for show control. As long as creators are required to build their own tools and work around the limitations of existing platforms, the technical complexity and costs of software development will be an obstacle to artists with limited resources or technical expertise. To enable
a broader diversity of creators to bring their work to the medium, and give them access to the global audiences for virtual content, the platforms must be designed to facilitate this kind of work.

When a new art practice emerges, it is often with respect to another one, or at least using another one as a reference point. Here for instance, virtual theatre emerges as a branch of theatre, growing into its own practice. In creating shared experiences with live performers in virtual reality, it is invaluable to draw on tools and techniques derived from centuries of stage practice. But we must adapt these to the novel affordances and particular constraints of the technology to take full advantage of the expressive possibilities of the new medium.

## Acknowledgement

This research was partially supported by the XR Stories project, funded by UK's Arts and Humanities Research Council [grant number AH/S002839/1].

## 5. REFERENCES

[1] Wagner James Au. VRChat Reach 105,000+ Peak Concurrent Uses During New Years. 2024. https://nwn.blogs.com/nwn/2024/01/vrchat-nye-concurrency-2023.html (accessed on 8 February, 2024).

[2] Ghislaine Boddington. Virtual physical bodies-serious play. In J. Birringer, T. Dumke, and K. Nikolai, editors, *Die Welt als virtuelles Environment*. Trans-Media-Akademie Hellerau, 2007.

[3] Alice Bonasio. *Social VR: Who Is Going to Get It Right First?* 2016. https://uploadvr.com/social-vr-whos-going-to-get-it-first/ (accessed on 1st March 2025).

[4] Peter Brook. *The Empty Space*. MacGibbon & Kee, 1968.

[5] Rita Kogler Carver. *Stagecraft Fundamentals Second Edition: A Guide and Reference for Theatrical Production*. FOCAL Press, 2018.

[6] Jane Collins and Andrew Nisbet. *Theatre and Performance Design: A Reader in Scenography*. Taylor & Francis, 2012.

[7] Alex Coulombe, David Gochfeld, Brendan Bradley, Kevin Laibson, Robert Long, and Roman Miletitch. Virtual reality live theatre on no budget: A model for independent theatrical productions using open-source social vr. In *ACM SIGGRAPH 2021 Educators Forum*, SIGGRAPH '21, New York, NY, USA, 2021. Association for Computing Machinery.

[8] Steve Dixon. A history of virtual reality in performance. *International Journal of Performance Arts and Digital Media*, 2(1):23–54, 2006.

[9] Steve Dixon and Barry Smith. *Digital performance: a history of new media in theater, dance, performance art, and installation*. Cambridge, MA : MIT Press, Cambridge, MA Cambridge, Mass., 2007.

[10] Joe Geigel and Marla Schweppe. Theatrical storytelling in a virtual space. In *Proceedings of the 1st ACM Workshop on Story Representation, Mechanism and Context*, page 39–46. Association for Computing Machinery, 2004.

[11] Jerzy Grotowski. *Towards a Poor Theatre*. Odin Teatret, Box 118, 1968.

[12] Rob Halliday. Lighting cues are increasing. but how many is too many? *The Stage*, 2022.

[13] Ian Hamilton. VRChat Live Theatre? 'Welcome To Respite' Performers Explain Why It Works So Well. 2021. https://www uploadvr.com/vrchat-acting-vr-theatre/ (accessed on 2nd February 2024).

[14] E. B. Hunter. Social vr and the continuing reinvention of local in theatre and performance. *International Journal of Performance Arts and Digital Media*, 19(1):83–97, 2023.

[15] John Huntington. *Control Systems for Live Entertainment*. Control Systems for Live Entertainment. Elsevier, Burlington, 3rd edition, 2007.

[16] Konstantina Kilteni, Raphaela Groten, and Mel Slater. The sense of embodiment in virtual reality. *Presence: Teleoperators & Virtual Environments*, 21(4):373–387, 2012.

[17] Ana Levordashka, Jamie Eastman, Eleni Anna Skoulikari, Anca Salagean, Darren Cosker, and Dana Stanton Fraser. An exploration of theatre rehearsals in social virtual reality. In *Extended Abstracts of the 2023 CHI Conference on Human Factors in Computing Systems*. Association for Computing Machinery, 2023.

[18] Nick Mason. *How Many Cues are in a Musical?* 2022. https://everythingbackstage.com/how-many-cues/ (accessed on 6 February 2024).

[19] Zachary Mckendrick, Lior Somin, Patrick Finn, and Ehud Sharlin. Virtual rehearsal suite: An environment and framework for virtual performance practice. In *Proceedings of the 2023 ACM International Conference on Interactive Media Experiences*, page 27–39. Association for Computing Machinery, 2023.

[20] Joslin McKinney and Philip Butterworth. *Technology as performance*, pages 126–148. Cambridge Introductions to Literature. Cambridge University Press, Cambridge, 2009.

[21] Mary Anne Moser and Douglas MacLeod. *Immersed in technology : art and virtual environments*. MIT Press, Cambridge, Mass., 1996.
[22] Jean-Marie Normand, Bernhard Spanlang, Franco Tecchia, Marcello Carrozzino, David Swapp, and Mel Slater. Full body acting rehearsal in a networked virtual environment–a case study. *Presence: Teleoperators & Virtual Environments*, 21(2):229–243, 2012.

[23] Philip Rosedale. *Seven Reasons Why Social VR is Better Than Skype*. 2015. https://www uploadvr com/seven-reasons-why-social-vr-is-better-than-skype/ (accessed on 1st March 2025).

[24] M. Slater, J. Howell, A. Steed, D-P. Pertaub, and M. Garau. Acting in virtual reality. In *Proceedings of the third international conference on Collaborative virtual environments*, page 103–110. Association for Computing Machinery, 2000.

[25] Jeremy Sostmann, Philipp; Dalton. *Virtual reality vs video conferencing: could remote work be better?* PricewaterhouseCoopers, 2023. https://www pwc ch/en/insights/data-analytics/virtual-reality-vs-video-conferencing.html (accessed on 1st March 2025).

[26] Douglas L. Williams, Ian C. Kegel, Marian Ursu, Pablo Cesar, Jack Jansen, Erik Geelhoed, Andras Horti, Michael Frantzis, and Bill Scott. A distributed theatre experiment with shakespeare. In *Proceedings of the 23rd ACM International Conference on Multimedia*. Association for Computing Machinery, 2015.