Story Starter: A Tool for Controlling Multiple Virtual Reality Headsets with No Active Internet Connection

Abstract

Immersive events are becoming increasingly popular, allowing multiple people to experience a range of VR content simultaneously. Onboarders help people do VR experiences in these situations. Controlling VR headsets for others without physically having to put them on first is an important requirement here, as it streamlines the onboarding process and maximizes the number of viewers. Current off-the-shelf solutions require headsets to be connected to a cloud-based app via an active internet connection, which can be problematic in some locations. To address this challenge, we present Story Starter, a solution that enables the control of VR headsets without an active internet connection. Story Starter can start, stop, and install VR experiences, adjust device volume, and display information such as remaining battery life. We developed Story Starter in response to the UK-wide StoryTrails tour in the summer of 2022, which was held across 15 locations and attracted thousands of attendees who experienced a range of immersive content, including six VR experiences. Story Starter helped streamline the onboarding process by allowing onboarders to avoid putting the headset on themselves to complete routine tasks such as selecting and starting experiences, thereby minimizing COVID risks. Another benefit of not needing an active internet connection was that our headsets did not automatically update at inconvenient times, which we have found sometimes to break experiences. Converging evidence suggests that Story Starter was well-received and reliable. However, we also acknowledge some limitations of the solution and discuss several next steps we are considering.

1. Introduction

Location-based virtual reality (VR) attractions are gaining widespread popularity, with installations appearing in various locations such as museums (for instance, [1]), commercial areas, and movie theatres [2]. Before starting a VR experience, users may have questions and require assistance adjusting their headset, headphones, and volume ([3], p. 77). There may be several people needing this ‘onboarding’ at the same time. For reasons of efficiency and hygiene, particularly in the post-COVID era, onboarders (the people helping others to onboard) should not be required to put on a headset between users, for example, to start an experience manually or to help someone new with VR to navigate the interface. Several packages help achieve this, allowing for multiple headsets to be controlled simultaneously and for experiences to be started on demand (see

Table 1. An overview of the features of the different out-of-box solutions for controlling Meta Quest headsets. We have left out: A. solutions that have been discontinued, such as Oculus for Business, which was discontinued in Dec. 2021; B. Android fleet management systems, such as Virtual Reality Device Management by 42 Gears (these are incompatible with Quest devices); C. VMWare WorkSpace One Universal Endpoint Management as it is not out-of-box and requires considerable setup and expertise. Dollar values are USD. Alternate rows have been shaded to aid comprehension.

	ArborXR	ManageXR	Quest for business	Showtime	Story Starter
Works with no active internet connection	no	no	no	yes	yes
Home-screen	yes	yes	no	yes	no
Quest1-3	yes	yes	yes	yes	yes
Other VR devices, such as Pico	yes	yes	no	yes	in development
Start experience	yes	yes	yes	yes	yes
Lock down devices	yes	yes	yes	no	no
Deploy content	yes	yes	yes	videos/photos	yes
Monitor usage	yes	yes	yes	limited	limited
Monitor battery	yes	yes	yes	yes	yes
Monitor storage	yes	yes	yes	no	no
Run app	yes	yes	yes	yes (limited by license)	yes
Number of devices	many	many	many	many	15
Pricing	$7 per device per month ‘starter’ $10 per device per month ‘essential’ $13 per device per month ‘premium’	$7 per device per month ‘essential’ $10 per device per month ‘premium’	$15 per month ‘single user’ $24 per month ‘shared user’	‘local’ no Wi-FI version €1199 for 10 headsets Wi-Fi required version €8–€10 per device per month	model undecided
Remote view	requires ‘essential’ subscription	requires ‘premium’ subscription	yes	yes	yes
Application Programming Interface (API)	yes (unclear if available with all plans)	yes, with premium pricing	?	yes	no

). Unfortunately, however, the packages available at the time and that we were aware of required an active connection to the internet. Here, we outline a solution we developed that bypassed the need for an active internet connection whilst offering a similar feature set to alternate packages. Note that an unforeseen benefit of our approach was that our headsets did not receive automatic updates at inappropriate times; in the past, we have found that such updates can break existing experiences and introduce initially challenging modifications to the user interface.

1.1. Scenario

During the summer of 2022, StoryTrails embarked on a tour of 15 libraries across Great Britain and Northern Ireland, giving thousands of people the opportunity to try a variety of story-led immersive experiences that drew heavily on local stories and National Archive footage. The VR component of the tour comprised six ten-minute experiences, covering topics ranging from punk rock (“Get Punked!” by Visualise) to retro footage of the future (“The Museum of Imaged Futures” by Indigo Storm) to the first transgender adoption in the UK (“Kindred” by Electric Skies). A dedicated VR area was set up at each location where up to eight people could try the experiences simultaneously (see Figure 1) throughout the day (which lasted between 7–10 h). All experiences were run on a fleet of Meta Quest 2 headsets equipped with an Elite Strap + battery, with each headset’s battery life lasting approximately 3–4 h. To ensure uninterrupted usage, headsets were swapped out midway through the day after about three hours of use.

The shape of the space the VR headsets were set up in differed for each of the 15 locations. We briefly detail the procedure we developed here. As shown in Figure 2, there were clear entry and exit regions for the VR region, with people queuing at a designated, well-marked location. Whilst queuing, people were handed a booklet describing the different VR experiences they could choose. When a headset became available, it was cleaned with alcohol wipes, and a person was led to the empty VR station for onboarding. Once in the headset, the onboarder used their tablet to start the person’s experience remotely. Once completed, the person was led to the zone’s exit.

Onboarding

Onboarding has been defined as “the process followed to guide users to understand technically and conceptually how to participate in a VR experience, facilitating their ability to successfully attend to and participate in the experience” [4]. Once the user has taken part in an experience, the reciprocal process of offboarding should then be conducted to help the user remove equipment and ensure the user receives assistance with any arising issues of discomfort (this latter point is often forgotten about but is perhaps even more important than onboarding—a wide range of discomforts may be experienced by the user, ranging from nausea, sensory overload, to violations of personal space; [5,6]; for an in-depth discussion, see [4]). Figure 3 illustrates the various steps that can be involved during onboarding and offboarding for an event such as that detailed here (for the curious, there are various steps in addition to those laid out, ranging from handing out content aimed to make people aware of what happens during a VR experience or to highlight any sensitive themes of the available experiences, to marketing and advertising; [7,8]).

It was important to us to pay particular attention to the onboarding process, as we anticipated that many of the users would be trying VR for the first time. Thus, they would likely have no experience with hand controllers or adjusting the head straps of the headsets. Note that if time had permitted, we would have included tutorials and group instruction/demonstration with an expert during onboarding, as others have advocated [9].

We found that carefully planned onboarding was crucial for various reasons apart from increasing viewer numbers. In a study conducted by [10], it was suggested that onboarding can enhance user experience, engagement, and presence ratings. Moreover, an additional benefit of having a well-designed onboarding process is that it may encourage a broader and more inclusive audience to try an immersive experience (e.g., [4], who discusses the negative impact of inadequate support on user experience in various such scenarios). Streamlining the onboarding process, here, by remotely starting the experience an individual requested (which removes the requirement for them to perform this themselves, reducing user burden) was thus a significant motivator in the creation of Story Starter.

1.2. Related Work

There are many cloud-based solutions available that can control VR headsets (see Table 1), but almost all, except for ShowTime VR, require an active Wi-Fi-based internet connection. Unfortunately, we were unable to use these solutions in our situation because of the lack of access to a stable internet-enabled Wi-Fi connection, or, in the case of ShowTime VR, we did not know it existed before we started developing our own solution, despite a thorough search online. There are also several enterprise-based solutions, including HTC’s Vive Device Management System and the Pico Business Suite Sync. These only work with HTC and Pico headsets, respectively.

Although we considered the option of linking a dedicated Wi-Fi router to the wired ethernet connections available in some of the libraries, we faced several challenges in doing so. First, we would need to secure permission from each of the 15 libraries, which would take extra time. Second, not all libraries had available active ethernet connections in the vicinity, and sometimes they were disabled to prevent unsanctioned use (we considered asking for this to be reverted for a short period; note though that library technicians are sometimes shared over many libraries, making this administratively challenging). Third, even when active ethernet-based connections were available, they were sometimes also not reliable. Retrospectively, a fourth benefit was that isolating our headsets from an active internet connection prevented the headsets from undergoing automated updates, often at inconvenient times, which in the past we have found to break experiences occasionally.

1.2.1. Technical Descriptions

For ArborXR, ManageXR, and Quest for Business, in terms of installation, a headset must be connected to a computer via a USB cable, and the controller app must be installed via an ADB command (Android Debug Bridge, a command line tool for communicating with Android devices) run via software downloaded onto the computer. After installation, the controller app automatically loads on the headset bootup, with a short delay (approximately one second) between the headset bootup and the appearance of the controlling app. The app provides an alternate home screen for users compared with what is offered by the headset. Typically, this home screen is customizable via the cloud-based backend, for example, preventing access to device settings and having the option of providing a list of experiences for an individual to start on their own. Headsets are controlled through a web application (discussed in the next section).

For Showtime VR, an app needs to be installed on each headset via Meta’s Quest Store or installed via software running an ADB command. A custom home screen is shown to users (offering the same benefits as just mentioned above). For the home screen’s customization, however, such as adding a logo or giving each headset its own ID that can be seen in the management app, the headsets still need to be connected to a PC to copy across a config file and images. Headsets are controlled via a management app that can be run on Android, iOS, PC, and Mac devices. The only requirement is that the management app is running (as that acts as the server for the headsets to connect to) and that the controlling device and headsets are connected to the same Wi-Fi router (which does not need internet access after initial set-up).

A closer comparison is warranted between Showtime VR and Story Starter. We have been using both solutions to manage multiple headsets since the StoryTrails festival. The main difference is that Showtime does not require a specific physical server to coordinate headsets, as Showtime runs its server through the management app mentioned above. The second difference is that while Story Starter allows multiple devices to control the headsets (which is very convenient when there are multiple onboarders), initially, we could not achieve this with Showtime. However, this is now possible via recent software updates.

1.2.2. Technical Overview

All of the above solutions let the onboarder(s) control headsets via a web application run on local devices such as smartphones or tablets (Figure 4 shows the front end of a web application from Story Starter). Via the application, experiences can be started and stopped; system settings can also be adjusted and monitored, such as volume levels and battery levels. All of the solutions let you control multiple experiences at the same time. On all solutions except Showtime, the application can also manage software installed in the devices, including the ability to install, update, or remove experiences. To assist users during the experience, the solutions let onboarders see what the user is experiencing. This latter feature requires a more expensive 10 USD subscription for ArborXR and ManageXR or $15 for Quest for business.

As far as we know, Story Starter and Showtime are the only solutions that allow you to attach physical labels to headsets and log the text on these within their respective web applications. This feature has proven useful for onboarders who need to locate a particular headset on the web application’s front end. StoryStarter also lets you assign a colored shape to each headset, as shown in Figure 4, which, by means of the pop-out effect (e.g., a red circle amongst many black circles ‘pops out,’ [11]), makes it easy for onboarders to locate a given physical headset. Showtime also allows you to create a visual representation of the locations of the headsets (on a map), which is perhaps more intuitive.

1.3. Solution Overview

1.3.1. Technical Overview

Story Starter is composed of a FastAPI application (https://fastapi.tiangolo.com/, accessed 12 June 2023) built on top of a Starlette web server (https://www.starlette.io/, accessed 14 June 2023), interfaced to an ADB server (Android Device Bridge, https://developer.android.com/studio/command-line/adb, accessed 14 June 2023); all of which can run on most Windows, IOS and Linux-based operating systems. We chose to run the components that make up Story Starter on a Raspberry Pi 4 for reasons of size—being about the size of a pack of cards—and cost (£50). Raspberry Pi OS 11.3 (bullseye) was installed on the device. A generic Wi-Fi hub is also required to wirelessly link up the Raspberry Pi, VR headsets, and controller devices. Onboarders remotely control VR headsets via the Story Starter HTML front end on their controller devices, such as Android tablets (see Figure 5). The front end sends commands via a FastAPI application to the headsets through the ADB server.

When the Raspberry Pi is turned on, it automatically connects to Wi-Fi and launches Story Starter. After approximately 30 s, the front end of Story Starter becomes available to front end devices. Initially, we hosted our own DNS server on the Raspberry Pi to provide a user-friendly URL for the front end, but later, we switched to using a printed QR code affixed to the top of the Raspberry Pi for the sake of simplicity. Client devices scan the QR code to access the correct URL. We assigned a fixed IP address to the Raspberry Pi on the Wi-Fi router to accomplish this. In the front end, each Quest headset is given a unique label consisting of shape and color combinations, which can be set and changed by the user. Each label is stored in a SQLite database managed by the web server.

The front end interface of Story Starter offered various functionalities to manage the VR headsets during the tour. These capabilities included starting and stopping experiences, controlling the volume, installing or uninstalling apps, and showing battery levels on one or more headsets. A visual representation of these functionalities is shown in Figure 4. During the initial stages of the tour, the front-end interface also provided a live broadcast of the headset screen content. However, we decided to disable this feature later (explained further in the Challenges section). It is worth noting that the full range of ADB capabilities could be implemented for front-end control.

1.3.2. Headset Linkup

Figure 6 displays the linking process required to connect each headset to Story Starter. To begin the linking process, the headset must be switched on and put into ‘developer mode’ [12]. Each time the headset is switched on, the following steps must be followed. The headset must be physically connected to the Story Starter device using a USB cable. Once connected, a request will appear on the headset asking permission to ‘allow USB debugging.’ This request must be accepted (Step 2; selecting ‘Always allow from this computer’)—henceforth, this step is not required in future linkups for this headset. The device will then appear within the Story Starter interface, which can be wirelessly connected to Story Starter with a button click (Step 3). Once connected, the USB cable can be detached (Step 4). After completing these steps, the (now wire-free) headsets are ready to use until they run out of power.

2. Assessment

2.1. Onboarder Focus Group

Four members from the StoryTrails VR onboarding team, whose ages ranged from 19 to 25, participated in a semi-structured focus group led by author LW on 28th November 2022. Individuals had onboarded at between 2–6 StoryTrails events (each event consisting of 2 days of onboarding). Two members had experience with manual onboarding at other events. Two members had experience onboarding with ArborXR.

The session was conducted via video-conferencing and aimed to explore the use and effectiveness of Story Starter, among other topics. Prior to the session, the discussion points were decided upon (see

Table 2. Discussion points for the focus group.

Topics
Did anyone ever comment on the fact that you were starting their experience from the tablet?
Tell me some of the challenges that you’ve had in onboarding people in the past without Story Starter
Were you able to onboard more people because of Story Starter?
What did not work well when you were using Story Starter?
What worked well when you were using Story Starter?
How would you improve Story Starter?

) and introduced by LW in an organic manner. Everyone was encouraged to contribute to the conversation, and the session lasted around 70 min. The entire session was recorded on video for later transcription and analysis using MAXQDA. All the participants agreed verbally to take part in the session and to be recorded. Participants were compensated approximately £15 for their participation. To maintain anonymity, the quotes are referred to using the first letter of each participant’s name.

The transcribed session was analyzed thematically, which involves identifying significant phrases or ideas in data and labeling each with a code to consolidate insights (see [13], pp. 316–321 for more detail on thematic analysis methods). The most frequent codes then formed the basis of the below summary. The lively discussion was insightful and provided mostly positive feedback on the effectiveness of Story Starter. In terms of efficiency:

“I think it reduces the queue a lot because if you do not have to do the initial set-up before putting a headset on, then you can just have the headset sitting on the chair, and they can pop it on. You can press Go, and the tablet is way quicker, probably saves about 20 s a person... 30 s”, J.

One reason was that there was no need to guide people on starting an experience, as this was performed via Story Starter. Since many attendees had little to no prior experience with VR, this significantly reduced the amount of time needed for instruction and allowed them to immerse themselves in the experience much faster. For example:

“Story Starter allows you to skip the part where you have to ‘mansplain’ stuff to them, sorry to the men in the room”, L.

On this topic, if someone was stuck or did not know what to do, being able to see what they were seeing…

“...really helps to assist them, especially if they’ve got a problem”, J.

Without the use of Story Starter, manual onboarding of users for VR experiences poses a challenge due to the need for onboarders to be in the exact position the user must eventually be situated to comply with restrictions put in place by the guardian system of each headset. Onboarders may need to be physically close to users, which is a COVID risk, can cause discomfort, and make the onboarding process less efficient. By using Story Starter:

“...I can just sit them down, talk about experience, get them calm. And that’s the magic of technology. ‘Your experience will start in just a second. Let me know how the sound is,’ etc. So I think it just removes a lot from the dialogue, calms the viewer and just feels a lot more professional”, J.

Onboarders liked using the tablets as:

“It made it so much easier”, D.

“It just felt a lot more professional”, J.

Encouragingly, when Story Starter was functioning well, it was invisible to users:

“no one actually really … noticed the tablets or noticed the technical side of it”, N.

Onboarders noted that having less than one tablet per onboarder added stress due to needing to locate a tablet or interrupting another onboarder to use their tablet. To accommodate this, midway through the tour, we increased the number of tablets so each host had their own.

The discussion also revealed several ways of improving Story Starter. For example, there was initial worry about not being able to set up the hardware:

“ I remember the first day [another onboarder] pulls out the router and stuff, I’m like, Oh God, I need to pick [this]... up”, T.

It was pointed out that changing the volume of one device on one tablet was only updated on that tablet, leading to some confusion for onboarders using other tablets. Onboarders were also worried about accidentally changing the icons representing a given headset:

“[I was worried] I would change the different shape instead of the one that I wanted to. But I think you just get used to it the more that you do it”, N.

One issue during the tour was that the ADB server linked to Story Starter would occasionally crash, requiring users to be manually onboarded, which was awkward to explain to users. This caused some inconvenience and delays, and the interim manual onboarding reminded hosts how helpful Story Starter was.

“When you put them in the headset, go to start it, and it’s crashed in that transition period, going back over to them and telling them you have to take the headset off them and do it [manually] is so awkward”, J.

A software update released midway through the tour addressed most of the causes of these crashes, improving the system’s overall stability.

2.2. Tour Visitor Feedback

During the StoryTrails tour, we collected qualitative measures of user opinion through various methods. These included surveys, video-booth automated interviews (also known as the ‘StoryBooth’, as described in Levstek et al., in prep), and observational research. Although we did not directly test its effectiveness, the evidence we gathered suggests that Story Starter successfully simplifies the onboarding process.

People were invited to provide written feedback via a short paper survey (these were inputted into MAXQDA for analysis). Out of the 535 responses, no one specifically commented on issues relevant to Story Starter, with the overwhelmingly positive comments focusing on topics such as the enjoyment of the experience (9.5% of all comments) or that it was interesting (14.0%) and that the staff was helpful (13.1%):

“The staff were incredibly helpful, polite and had brilliant customer service skills. The VR headset section was brilliant in that there were no glitches, it was all fully immersed, and the detail was incredible!”, Blackpool, 25 (location of the tour when data collected, age of person providing feedback).

“I really enjoyed today’s experience, particularly my first ever taste of VR! The team were all brilliant—friendly, helpful and patient. Thank you!”, Bradford, 67.

“Everything was perfectly organised, and technology worked all the time”, Slough, 43.

Negative VR-related comments focused on the experiences or headsets themselves, not Story Starter, for example:

“[The experience] stopped working (froze?) quite early on, but the staff got it going again quickly”, Bradford, 67.

“Sound problem with headset, soon rectified by your staff”, Slough, 62.

2.3. Limitations

It would have been ideal to interview both the individuals who were onboarded and the organizers of the library events to gain a better understanding of their perspectives, specifically on Story Starter and on onboarding and offboarding processes. Additionally, conducting observational research over multiple sessions on the entire system (onboarder + story starter + and user) would have been insightful. Unfortunately, it had not occurred to us at the time to take these steps.

3. Discussion

Story Starter played a significant role in streamlining the onboarding process during the StoryTrails tour in the summer of 2022. It allowed us to start and stop experiences and control volume remotely without requiring onboarders to put on the headsets themselves. This was achieved without an active internet connection, preventing us from using other solutions for controlling experiences described in Table 1.

The Story Starter system connects headsets to a local Wi-Fi network. A Raspberry Pi 4 device running Story Starter lets us control the headsets via an HTML front end. Commands received through this front end are relayed to headsets via an ADB server that also runs on the Raspberry Pi.

We evaluated the effectiveness of the Story Starter system through a focus group conducted with onboarders who used the system and also through feedback from those who tried a VR experience during the tour. The feedback revealed several benefits of using Story Starter over a manual onboarding process that lacked a controlling system. These benefits included faster onboarding, easier debugging of issues, more time to make people comfortable, and reduced risk of spreading diseases such as COVID. We found it encouraging that participants trying VR experiences paid little attention to how their experiences were controlled, indicating that the controlling aspect was unobtrusive. During the tour, we also implemented several enhancements to the system, such as providing each onboarder with their own controlling device.

The Story Starter front end is currently basic, and there is potential to add various features to enhance its functionality. Some onboarders have suggested adding features such as displaying the amount of time a person has been in an experience and enabling alerts when physical volume buttons are pressed. To improve the user experience, we plan to introduce wizards to assist with headset linking and walkthroughs to guide onboarders through the essential elements of the interface. We also aim to start using WebSockets to enable real-time updates to all controlling devices whenever changes are made to system settings.

Challenges

The Android system controlling the Quest devices was significantly locked down, requiring extensive trial and error to determine the available functionality. One example of this was the automatic disconnection of Quests from Wi-Fi after a few minutes with no active Internet connection. Although several methods to prevent this on stock Android exist (e.g., [14]), they did not work with the Quest. To maintain a Wi-Fi connection despite the absence of an active Internet connection, we implemented a procedure that every 30 s via an ADB command checks whether Quest device screens were powered off (adb –s <device_serial> shell dumpsys power|grep \’Display Power: state=OFF\’) and, if so, woke them (adb –s <device_serial> shell input keyevent 26). While we also explored simulating the endpoints that the Quests pinged to check for an active internet connection, we ultimately opted for the more straightforward “repeated wake-up calls” approach.

We originally streamed headset content to the front end, one frame every 10 s. We used the ADB screencap command to capture 3664 × 1920 pixel screenshots of the binocular content on display in the headset (adb –s <device_id> shell screencap– p), which we scaled to 192 × 108 pixels on the Raspberry Pi (after discarding pixels from one eye; transforms were performed via the opencv-python package, version 4.5.5.64). We have not found a way to request lower-resolution screenshots, although if this were managed, a worry would be that such downscaling would interfere with rendering on the headset. Due to processor limitations of the Raspberry Pi, presumably linked to this computationally expensive downsizing, we could only screen capture for seven headsets concurrently, at approximately a 5-s delay. Midway through the tour, we turned off viewport streaming as we found it affected ADB stability. A plan is to offer a live feed of a single device, but only upon request. A better way of capturing screen content may also exist (e.g., [15]).

After 4+ hours of usage, the ADB server sometimes crashed, forcing us to reset the Raspberry Pi and reconnect all devices. We are currently testing whether periodically restarting the ADB server would prevent these crashes. Additionally, we are exploring the possibility of automatically reconnecting devices by keeping track of connection information.

ADB is hardcoded for a maximum of 15 device connections at a time, which limits the number of headsets that can be controlled by Story Starter simultaneously. However, adapting the source code could potentially overcome this issue, although it is uncertain whether this would affect the system’s stability. Additionally, the team is exploring running multiple ADB servers concurrently on the same device as another potential solution.

We have found that different versions of ADB have their peculiarities, which can differ over operating systems. In Raspberry Pi OS 11.3, ADB version 28.0.2-debian is available, whilst for Windows and Mac at the time of writing (November 2022), version 33.0.1-8253317 is available, which seems more resilient to crashing (adb-server for both environments are currently version 1.0.41). It is worth pointing out that we found that an earlier version of ADB could not detect Quest headsets.

The process of physically connecting the headsets to the Raspberry Pi on each startup is not convenient. As the device needs to be plugged into a wall socket, headsets must be brought to it each time they need linking up. Adding a battery to the device and making it portable (at least for a few minutes) could help with this issue. Another option we explored was creating a device named the “StoryLinker” dongle (see Figure 7). The dongle, which consists of a Raspberry Pi Zero and a battery pack, can be used instead of the Raspberry Pi during the initial headset linkup process. When the dongle is plugged into the headset, it instructs the headset to enter the correct mode and then ping the Story Starter server, enabling remote operation. The dongle takes approximately 45 s to boot up and 10 s to connect a headset to the Story Starter server. We are exploring an alternative approach to eliminate the need for a physical USB linkup by running an Android app on headset startup that can automatically connect the device to Story Starter. In addition, we are investigating the feasibility of removing ADB entirely from the Story Starter system and controlling the headsets via an app that (again) launches at startup. However, to make the app a ‘system app’ (allowing us a full range of control of other applications) probably requires access to platform keys provided by Meta [16].

4. Conclusions

Story Starter was created to simplify onboarding VR experiences in areas without internet connectivity. Its development was challenging, as it required accounting for the different customizations of the Android system that Quest headsets run on. Despite being relatively minimal in features compared with other software (Table 1), Story Starter has been demonstrated to improve onboarding efficiency and minimize hygiene risks associated with headset sharing. We have outlined several potential future steps that could further enhance the utility of this tool.