Facebook announced back in June that it planned to offer developers a way to distribute Oculus Quest apps outside of the official, curated, Quest store. Now the company indicates it has “high confidence” that the feature will be deployed in Q1, 2021.
Since the launch of Oculus Quest, Facebook has opted to ‘curate’ the Quest store by selectively permitting apps based on factors like quality, presentation, and scope. After backlash from some developers, and the burgeoning Quest ‘sideloading’ platform SideQuest, Facebook said it would offer an official avenue for developers to distribute their apps outside of the Quest store.
New Quest Distribution Path
In a video posted by the official Oculus Developers page on Facebook, Clorama Dorvilias, product manager at Facebook Reality Labs, explained that Oculus had added a new ‘Roadmap’ section to the developer website which highlights upcoming development features.
In previewing the roadmap, Dorvilias showed that the “New Quest Distribution Path” feature is expected in Q1, 2021. The company had previously said the feature was expected in “early 2021,” and now indicates “high confidence” that it will be available within Q1.
“Developers will have a way to distribute applications to anyone without having to be accepted in the Oculus Store and without sideloading,” the roadmap description says. “Applications will have to meet the obligations of the Oculus Content Policy, but won’t be held to the same technical standards as official Oculus Store Apps.”
Additionally, the roadmap indicated that a beta version of the feature would be made available to select developers in December, before the wider release in Q1, 2021.
Other items indicated on the developer roadmap for December: OpenXR support in UE4, a keyboard overlay for native Android apps, Unity debug symbol upload for OVR Platform Tool, crash analytics in the Developer Dashboard, and Visual Studio code debugging for UE4 and native VR apps.
Unlisted Apps & Keys
Oculus hasn’t offered much detail about how the Quest non-store distribution channel will work, or what, if any, limitations it will include beyond the need to comply with the Oculus Content Policy.
One approach, hinted by Oculus earlier this year, would be to have ‘unlisted’ application pages that can’t be found through the official Quest store, but which can be linked by URL, allowing developers to point users to the application page through a direct link. A parallel approach could be to allow developers to generate and manage ‘game keys’—which could be given away or sold through any channel of the developer’s choosing—which users would redeem through their Oculus app. The latter is already possible, in fact, but only available to applications which have been approved for distribution on the official Quest store.
The Cut
One big unanswered question about the non-store distribution channel for Quest is whether or not developers will be allowed to charge for applications distributed this way and, if so, whether or not Facebook will expect to take its usual 30% cut of the sale.
App stores generally justify taking a portion of app sales because they connect developers with customers by providing a marketplace and provide promotion within that marketplace. But ‘unlisted’ apps wouldn’t see any of those benefits because they wouldn’t appear in the official store, leaving it up to the developer to seek out customers directly.
Side Hustle
It also remains to be seen what this official non-store distribution channel will mean for SideQuest, which has become the defacto non-store distribution channel for Quest via sideloading. Depending upon the structure of Oculus’ approach, SideQuest could become a convenient platform for developers to list their unlisted apps for ‘store-like’ discovery by its community of users. But if Facebook doesn’t want to play nice, they could put policies in place to prevent this.
Recently released on the Quest store, Cubism is a spatial puzzle game with a slick minimal presentation. Designed by a solo indie developer Thomas Van Bouwel as a side project, the game impressively holds the highest user rating among all Quest apps with more than 100 reviews, according to our latest ranking. We reached to Van Bouwel to learn more about his approach to the project and lessons learned along the way.
Thomas is a Brazilian VR developer currently based in Brussels, Belgium. Although his original background is in architecture, his current work in VR spans from indie games like Cubism to enterprise software for architects and engineers like Resolve.
In September I launched Cubism, a minimal VR puzzle game about assembling colorful blocks into complex geometric shapes. It was my first commercial release as a game developer.
I developed Cubism on my own in my spare time, all while keeping my job as lead product engineer at Resolve, a Brooklyn-based enterprise VR start-up. I’ve only recently transitioned into working part-time for the game in the months leading up to its release.
Bootstrapping your first game alongside a full-time job can be a good way to allow for a flexible development schedule and reduce financial risk—but I think it’s only feasible if you design around your limitations and don’t over-scope your game.
In this article, I want to share some lessons I learned on how to stay on track when bootstrapping your first VR game.
1. Prototype & Playtest as Soon as Possible
The first questions you need to answer when starting any new game is: “is this fun?” and “could this have an audience?” A good way to answer these questions is to build a vertical slice—a small but fully playable segment of your game idea—as soon as possible, and put it in front of strangers to gauge their reaction.
I built the first functional prototype for Cubism over a weekend back in 2017. The prototype was pretty bare bones, but playable, and was enough for me to test the concept with friends and colleagues and to share the idea with strangers online to see if a game like this could spark interest.
The first prototype of Cubism had 3 puzzles, but no menu or game logic. Two of those three original puzzles ended up in the final game.
2. Scope Within Your Constraints
Choosing the right scope for a game is the best way to ensure you can actually finish it, and this will be determined mostly by your constraints (budget, skillset, time, etc).
For Cubism, I knew I’d have limited time to work on it, I knew I wanted to work solo to keep my schedule flexible, and I knew that things like 3D modelling, graphics programming and audio design weren’t my strong suit. Cubism’s minimal aesthetic and straight-forward gameplay leaned into these constraints, and helped inform many design decisions along the way.
For example, the minimal environment removed the need for detailed environment modelling or complex lighting, and helped put the focus on the puzzle in front of the player. This lack of environment also meant that having gravity made no sense, since pieces had no surface to fall on other than the floor—so instead, everything floats. This actually made puzzle solving a bit easier and enabled more complex puzzle shapes which wouldn’t be possible if gravity applied.
The lack of gravity in Cubism allows for more complex puzzle shapes.
Adjusting scope is something that will inevitably happen throughout development as well. One instance where I realized I was over-scoping was with my plans to support hand-tracking in the initial release of the game.
When hand-tracking first became available, I quickly prototyped experimental support for the feature and released it in a demo on SideQuest as it seemed like hand-tracking could make for a very intuitive way of playing the game. The reality was that hand-tracking at the time still had limitations, and the quality of people’s experience with it varied highly depending on their lighting conditions and their expectations of the feature. The demo I made did not handle these limitations well.
Linus from Linus Tech Tips struggling with Cubism’s experimental hand tracking input (source).
I realized that properly implementing this feature would require much more work than I originally anticipated, which would delay the release of the actual game. I instead decided to remove the feature from the release scope and plan it for a future update.
This was a difficult call to make, since the SideQuest demo set expectations for the full game to support this feature as well, but I think it was the right call as it ensured I could give the development of this feature the time it required to be done properly.
3. Build Tools That Save You Time
When you recognize that an aspect of your game will require a ton of iteration to get right, it’s worth looking into what tools you can buy or build to help make that iteration more efficient.
For Cubism, I realized early on that I would need to iterate a lot on the design of the puzzles in the game, so one of the first things I built was a simple puzzle editor. It was far from release-ready, but as a developer tool it had a huge impact on how quickly I was able to iterate and find interesting puzzle designs.
An early in-VR level editor tool helped me speed up puzzle design and iteration
Another aspect of the game that required a lot of iteration was the audio design. In Cubism, every puzzle piece is associated with a note, meaning every puzzle forms a complete chord once finished. Completed puzzles and their associated chords form a complete song. When a player presses the play button in the menu, it will play this song as it goes through all the levels they’ve solved.
Pressing the play button lets players hear a song composed of chords associated with each puzzle they’ve completed.
In Unity3D, I built a simple editor tool that would let me modify the notes associated with the puzzles and would save these notes in a separate file. This allowed me to test multiple songs for the game in parallel and made it easier for me to keep the notes associated with puzzles up to date while the puzzle designs evolved during development.
This simple puzzle song editor let me modify the notes associated with pieces of each puzzle and preview what this would sound like in sequence in the game.
4. Don’t Playtest Your Game with Gamers (at first)
If you want to make your VR game accessible for newcomers to the medium, take special care to playtest it with non-gamers during development.
Since Cubism was meant to be a casual game, one of my design goals was to make it as pick-up-and-play as possible for newcomers to the medium. However, about a year and a half into development I realized one of the biggest blockers for newcomers was the game’s control scheme and the onboarding tutorial to teach new players.
Almost every button had a function mapped to it, and the game would start by walking you through each button, which would be very disorienting for people who weren’t used to holding controllers.
Cubism originally used every button on the controller and the onboarding tutorial would walk users though each one.
It took me a long time to realize this was an issue, because I had mainly been testing the game with other developers, gamers, and VR enthusiasts who would tend to breeze through the controller onboarding. It was only during a more family-oriented game event, where I got a chance to test the game with more non-gamers, that I realized input was a barrier to entry for some folks.
After that insight I focussed on simplifying the control scheme by making the entire game playable with just the triggers. This had some design implications as well: the menu moved from being anchored to the player’s hand to being anchored underneath the puzzle. And moving the entire puzzle, which used to be mapped to the grip buttons, now happened by grabbing the puzzle within its bounding box.
These changes greatly simplified onboarding and made the game much more easy to pick-up-and-play. Where some players used to get confused by the original tutorial, they would now breeze through it and be solving their first puzzle within 10-20 seconds of launching the game.
Cubism can now fully be played with just the triggers, greatly simplifying and shortening the onboarding tutorial.
5. Don’t Solo Dev Alone
Even though I made Cubism on my own, I would never have been able to finish the game without the support of various friends and organizations within the VR community. They kept me motivated throughout development and have given me valuable advice when I was stuck.
In most cities I’ve lived in since I started working on Cubism, I’ve been able to find meetup groups for Unity developers, indie game developers, or VR enthusiasts. And even though going to actual meetups is harder these days, many of these groups also have active online communities on Slack or Discord.
If you’re planning on developing on the Oculus platform, I also highly recommend joining their Oculus Start program. Beyond the support Oculus provides to Start developers, they also have a really active and supportive community on Discord.
– – — – –
The choice of whether or not to work solo and/or part-time on a project will likely depend on your circumstances and the nature of the game you’re making. I’ve definitely felt the downsides of solo spare-time development as well: a dev cycle that was probably longer than it needed to be, being confronted with gaps in my own knowledge when it came to actually finishing and publishing a game, or the lack of a creative sparring partner to work through design problems and help make decisions.
But for Cubism, there was a flip-side to each of these downsides as well: not having to compromise between a game I wanted to make and a job I enjoyed doing, being forced to learn new skills, and being incentivised to seek out the wider gamedev community for advice, support and motivation.
In many cases, it will make more sense to work together with others or to seek funding for development, but if you’re planning on solo-bootstrapping your first game, I hope this article will be helpful!
Half-Life: Alyx is likely soon to see an update which would add in-game developer commentary similar to previous Valve games.
Fans of Valve games will likely recall the optional in-game developer commentary first added to Half-Life 2: Lost Coast and in later titles like Half-Life 2: Episode One, Episode 2, Portal and others. Half-Life: Alyx is very likely to get a similar mode in an upcoming update.
YouTube channel Valve News Network spotted a listing for a password-protected branch of Half-Life: Alyx called ‘Commentary Beta3’ that was last updated three days ago, compared to the most recent public version of the game which was last updated four months ago. The channel says the appearance of the branch means the update is likely to launch in the near future.
In prior games Valve’s developer commentary mode would spawn little ‘speech bubbles’ throughout the game world which players could click on to play audio recordings of the developers offering up behind-the-scenes commentary on specific parts of the game. It’s not just off-the-cuff remarks either—in Portal 2 the total duration of developer commentary was around 40 minutes of scripted insights.
Valve News Network suggests that the Half-Life: Alyx developer commentary mode is likely to work a bit differently than prior games. Rather than the ‘speech bubbles’, the channel says that previously data-mined files point to floating versions of the headset—which Alyx wears to communicate with Russell—as the vehicle for delivering the commentary. And considering that this is Valve, I’d say there’s at least a 25% chance that the studio gives the commentary audio a little ‘radio distortion’ filter to make it sound like it’s actually coming out of the headset.
For fans of Valve’s work, the developer commentary would likely be a strong pull to play through the game again to discover the insights shared along the way about how the game ended up in its final form. And if that doesn’t do it for you, maybe some of the game’s mods will.
Unity has long been a public supporter of OpenXR—an industry standard designed to streamline VR development by making it easier for apps to support a wide range of headsets—but the company has yet to deploy support for the standard. As a key figure in OpenXR (owed to it being one of the leading VR game engines), it’s good news today to hear the company affirm its commitment to the standard and say that it’s accelerating work to bring OpenXR to Unity.
OpenXR is a royalty-free standard that aims to standardize the development of VR and AR applications, making for a more interoperable ecosystem. The standard has been in development since 2017 and is backed by virtually every major hardware, platform, and engine company in the VR industry, including key AR players. Earlier this year the standard took a huge step forward by announcing the start of certifications for compliant implementations.
Image courtesy Khronos Group
Facebook, Microsoft, Valve, Unreal Engine, and others have been making progress toward supporting OpenXR in their platforms and now Unity says it’s moving to do the same.
“We have been closely monitoring the development of the OpenXR standard. We’re at an inflection point now, where OpenXR 1.0 has been ratified and OpenXR runtimes by various vendors are reaching maturity. This inflection point has accelerated our efforts to enable OpenXR in Unity,” writes Matt Fuad, Sr. Technical Product Manager of AR/VR at Unity.
The company expects to have a preview version of OpenXR in Unity by the end of 2020 which will focus on platforms already supported by the engine (like Oculus, SteamVR, etc), and in early 2021 it plans to roll out experimental support for any conformant OpenXR runtime. Though Faud warns that wider support will take some time to be battle tested.
“Given the unbounded combinations of possible hardware/software configurations, we cannot test or guarantee that all configurations will work optimally. As issues are discovered with runtimes, we will work to contribute conformance tests and specification changes back to the Khronos working group to help the community as a whole. We will also make sure it’s clear to developers which platforms have been fully tested and thus supported by Unity.”
Faud says that Unity plans to implement OpenXR as part of its existing XR plug-in framework so that developers can continue to use many of the engine’s existing development workflows while still creating applications which are OpenXR compliant.
“We’re excited about the progress that has been made and believe this is a significant step towards supporting open standards,” he concludes.
The latest release of MRTK adds official support for Oculus Quest and can now be managed directly in Unity’s package manager.
MRTK (Mixed Reality ToolKit) is Microsoft’s open source framework for spatial input, interactions, and interfaces. Originally designed for its HoloLens AR headsets, it also supports PC VR headsets and now Oculus Quest.
Its main purpose is to enable developers to rapidly build user interfaces which support interactions from hands and/or tracked controllers. The framework’s design principles leverage Microsoft’s research on spatial interactions conducted for HoloLens.
Oculus Quest support comes by way of Unity Labs engineer Eric Provencher. In late December 2019 he started work on MRTK-Quest, at the time as an extension available from GitHub.
Throughout this year Provencher worked to improve MRTK-Quest support and add new features. With MRTK 2.5.0, this work is now built in, and development of the extension has ceased.
When developers build websites or mobile apps, they rarely build the user interface from scratch. UI frameworks let them use ready-to-go components so they can focus on building the actual experience or game. There are many established web & app UI frameworks, but VR & AR are so new that very few such frameworks exist yet – at least ones mature enough to use in a real world project. MRTK may be able to help.
Facebook and Valve do not yet offer frameworks for VR UI or interactions, instead offering basic samples which developers can copy, as well as best practices.
With version 2.5.0, MRTK can now be installed & updated through Unity’s built in package manager, making it easier to work with and better integrated for real world development use.
Adding MRTK to your Unity Package Manager requires adding a few lines to your project’s package manifest. This takes just a few seconds- instructions are available here.
Oculus Store apps must use Facebook’s payments system for any and all transactions. Bigscreen CEO Darshan Shankar points out how this makes it impossible for some developers to succeed.
That’s because the fee for that mandatory in-app payment system is 30%. For that, users get the convenience of using their existing saved payment methods, and the peace of mind that no card details need to be shared.
Bigscreen loses >100% for every dollar of revenue, while Fandango can make money in VR.
Sucks that I've poured 6 years into building software for the Oculus Platform.@ID_AA_Carmack gets to bring Fandango into VR, but Facebook won't help devs that have been here from day 0
But how do companies sell products or services with a lower than 30% margin? Bigscreen offers 3D movie rentals. Shankar claims movie studios take 60-80%, so that leaves between a 10% profit and 10% loss for Bigscreen- not a sustainable business.
Facebook presumably makes special deals with big companies like Fandango and Netflix, exempting them from the rules it holds most developers to. These companies can be profitable in VR, while small companies simply can’t compete. Worse yet, Facebook offers its own movie rental service.
Taking a 30% cut of a 10GB game can be argued to be a fair exchange for hosting, serving, and promoting it. But these justifications fall apart when applied to in-app-purchases.
Shankar spoke about this a few weeks ago on Twitter, and on our from-VR podcast The VR Download. We’ve clipped out the segment here:
He called attention to the fact that not only does this make digital services unprofitable, but physical retail too. What if a furniture company made a VR app letting you see their offerings in true scale? To actually let you buy, they’d need to fork over 30% to Facebook each time.
Apple has been facing similar criticism on requiring the use of its payments system. Companies like Epic Games, Spotify, and Netflix want to let customers make purchases & subscriptions directly to avoid the same 30% “tax”.
Like Apple, Shankar says Facebook isn’t budging on its position. Developers can distribute apps over SideQuest with any payments system, but that requires a PC and forgoes automatic updates- for now. WebXR apps also have this freedom naturally, but entering details in VR isn’t a great experience. The open standard Payment Request API (which Facebook is contributing to) seeks to solve this kind of problem on the web, so in the future we might see convenient open payments via Oculus Browser.
Oculus Store apps must use Facebook’s payments system for any and all transactions. Bigscreen CEO Darshan Shankar points out how this makes it impossible for some developers to succeed.
That’s because the fee for that mandatory in-app payment system is 30%. For that, users get the convenience of using their existing saved payment methods, and the peace of mind that no card details need to be shared.
Bigscreen loses >100% for every dollar of revenue, while Fandango can make money in VR.
Sucks that I've poured 6 years into building software for the Oculus Platform.@ID_AA_Carmack gets to bring Fandango into VR, but Facebook won't help devs that have been here from day 0
But how do companies sell products or services with a lower than 30% margin? Bigscreen offers 3D movie rentals. Shankar claims movie studios take 60-80%, so that leaves between a 10% profit and 10% loss for Bigscreen- not a sustainable business.
Facebook presumably makes special deals with big companies like Fandango and Netflix, exempting them from the rules it holds most developers to. These companies can be profitable in VR, while small companies simply can’t compete. Worse yet, Facebook offers its own movie rental service.
Taking a 30% cut of a 10GB game can be argued to be a fair exchange for hosting, serving, and promoting it. But these justifications fall apart when applied to in-app-purchases.
Shankar spoke about this a few weeks ago on Twitter, and on our from-VR podcast The VR Download. We’ve clipped out the segment here:
He called attention to the fact that not only does this make digital services unprofitable, but physical retail too. What if a furniture company made a VR app letting you see their offerings in true scale? To actually let you buy, they’d need to fork over 30% to Facebook each time.
Apple has been facing similar criticism on requiring the use of its payments system. Companies like Epic Games, Spotify, and Netflix want to let customers make purchases & subscriptions directly to avoid the same 30% “tax”.
Like Apple, Shankar says Facebook isn’t budging on its position. Developers can distribute apps over SideQuest with any payments system, but that requires a PC and forgoes automatic updates- for now. WebXR apps also have this freedom naturally, but entering details in VR isn’t a great experience. The open standard Payment Request API (which Facebook is contributing to) seeks to solve this kind of problem on the web, so in the future we might see convenient open payments via Oculus Browser.
Oculus Developer Hub is a new PC program with features to make Oculus Quest development more convenient with fewer hassles.
When developing for PC-based VR, testing a new change is near-instant, and by default you can see what the VR headset sees on your screen. Developing for standalone headsets like Quest is more challenging since builds need to be compiled and updated on the headset each time. Testing on PC is still possible, but won’t surface performance and Android-specific issues.
Some of the functionality of Oculus Developer Hub is already available through the 3rd party app SideQuest.
Cast Mirroring, Quick Screenshots & Videos
Developer Hub lets you mirror Quest’s view to your PC with 1 click, using the same technology behind TV & phone casting.
You can capture screenshots & videos too. They’re saved to your PC, not your Quest.
You can also enable Wi-Fi mode, so your Quest doesn’t even need to be connected via USB. This was always possible, but required some setup.
Prox Sensor & Guardian Overrides
The proximity sensor of a VR headset detects when you’re wearing it. When you’re not, the app is paused & eventually suspended by the Oculus operating system. This makes multiplayer testing a nightmare, with devs using whatever objects they can find to trick the sensor.
The Developer Hub finally offers a way to disable that sensor, so you can test networking between Quests much more easily.
There’s also a way to toggle off Guardian. Previously this has to be done inside VR- after the Guardian setup if your boundaries weren’t recognized. Leaving the Guardian boundary also causes the app to pause, so this should also be a big boost for convenience.
Install, Uninstall, and Launch APKs
You can see all your installed APKs (other than store apps) and launch or uninstall them.
Dragging an APK from your PC onto this area will install it on Quest- the easiest way to sideload yet.
Performance Summary
The Hub shows a real time view of FPS, how much RAM is free, and the current clockspeeds and load on the CPU and GPU.
While Facebook already has more detailed performance analysis tools, it’s nice to always be able to see the most important performance metrics in a clean graphical interface.
OpenXR is a widely supported open standard which aims to make cross-platform VR development easier by allowing developers to build around a single API rather than porting their apps to many different APIs. Today the company announced that developers can submit OpenXR applications to be published on the Oculus Quest and Oculus Rift stores.
OpenXR is a royalty-free standard that aims to standardize the development of VR and AR applications, making for a more interoperable ecosystem. The standard has been in development since April 2017 and is supported by virtually every major hardware, platform, and engine company in the VR industry, including key AR players.
Oculus today announced that developers can submit OpenXR apps for sale on the Quest and Rift storefronts which, will run on those headsets as of the v19 version of the Oculus software.
This is a major step for cross-platform VR development because it means that developers building VR applications now have the option to build against the OpenXR standard which will allow the same app to work on other OpenXR supported platforms. Previously, developers have had to build separate versions of their apps for each platform’s API (ie: two different versions for Oculus and SteamVR), which complicates cross-platform development.
OpenXR creates a unified structure between VR engines, apps, and headsets | Image courtesy Khronos Group
Note that OpenXR app support on Oculus stores does not mean that Oculus’ stores will support headsets other than their own. It only means that developers can submit the same app to other OpenXR platforms without needing to specially port the app to those platforms.
Valve is also moving ahead with its OpenXR implementation; the company announced a preview of OpenXR support in SteamVR last month. Once complete, three of the four largest VR distribution platforms (Oculus Quest, Oculus PC, and SteamVR) will fully support OpenXR applications, allowing developers to build a single application which can work across all platforms.
The fourth major VR distribution platform is PlayStation VR. While Sony is a member of the industry group which is building OpenXR, the company has been quiet about OpenXR support on PSVR.
Microsoft has also released initial OpenXR support for both its VR headsets and HoloLens 2.
It was big news back in 2017 when Valve announced that it was working on “three full [VR] games, not experiments.” It wouldn’t be until late 2019 that one of the three was revealed as Half-Life: Alyx. But what of the other two? A new book that goes behind-the-scenes at Valve reveals the fate of those projects.
The Final Hours of Half-Life: Alyx is the latest behind-the-scenes book from game journalist & MC Geoff Keighley. Presented as an interactive e-book available on Steam, the work is an insightful look into Valve’s unorthodox inner workings and the events that preceded the launch of the studio’s first full-blown VR title, Half-Life: Alyx.
As we now know, Alyx launched to critical acclaim, making its mark as one of the best Steam games ever. But if Alyx was just one of “three full [VR] games,” in development at Valve, what happened to the other two?
As recently as March 2019 Valve head Gabe Newell apparently indicated that, indeed, three VR games were still in the works.
The Final Hours of Half-Life: Alyx, gives us some clues about what the games were, but unfortunately also explains how Alyx turned into a much larger project than Valve had originally envisioned, apparently subsuming those other projects in the process.
The book reveals that Valve was working on a game called A.R.T.I, which was built with a Minecraft-like voxel-based game engine that was separate from Valve’s Source engine. It was described as a “fun, light-hearted game—in a similar vein to the Portal series—[which] transported players to a manipulable world with full construction and destruction abilities.”
The game started development in 2013, but wasn’t initially envisioned as a VR game. Well after it had begun development and then faded to the back-burner, the book says that A.R.T.I resurfaced as one of the other two VR games in development at Valve alongside Alyx.
The other VR game in development was called SimTrek. The book provides little detail on what the game would entail, but the project was led by “some of the members of the team behind Kerbal Space Program,” which had joined Valve. Given the developer lineage with KSP (a simulator-focused space flight game) it seems safe to guess that it would a simulator style game, while the name itself seems oddly similar to Star Trek… they would be that obvious though, would they?
But, as The Final Hours of Half-Life: Alyx reveals, “development on both those other projects stopped, however, as Alyx’s team size continued to grow.”
Valve had originally envisioned Alyx as a VR game of just a few hours in length and made largely out of updated Half-Life: 2 assets. But as the project started gaining steam the scope of the game (and its team) ballooned, ultimately swallowing up resources and momentum that otherwise could have carried those projects to completion.
In fact, the development team that came together for Alyx was the “largest single team we’ve ever had at Valve,” the company revealed earlier this year.
That jibes with what we learned in an interview earlier this year with one of Alyx’s lead game designers, Robin Walker. We asked him point blank if the two other VR games were still in development at Valve.
“We haven’t made any sort of long term plans after this. We’re back [to building games] in the way we haven’t in the last few years [which we’re excited about],” Walker said. […] What we do next is something we haven’t decided. We have ideas but there’s no reason for us to commit right now. So we’re just going to wait and see how this goes.”
But A.R.T.I and SimTrek weren’t the only VR projects at Valve. In fact The Final Hours of Half-Life: Alyx reveals a handful of different prototypes and concepts Valve had built over the years, some of which can be directly traced to what would become Alyx, and others that petered out along the way.
One of those VR concepts was called Borealis. Marc Laidlaw, a Valve writer who worked on all of the Half-Life games before Alyx, envisioned a VR game which would be set on the Borealis, the Aperture Science Research ship mentioned in Half-Life 2.
Players would explore the vessel as it ricocheted in time back and forth between the Seven Hour War, the conflict between the Combine and the citizens of Earth, and a time set shortly after the events of Half-Life: 2 Episode 2. There was even talk of a fun VR mini-game where players would fish off the bow of the ship. Ultimately, Borealis never gained much momentum internally and ended up in the pile of shut down Valve prototypes.
There’s lots more interesting behind-the-scenes insights revealed in The Final Hours of Half-Life: Alyx, which is an easy and fascinating read for anyone interested in unique inner workings of Valve.
