‘The Gallery: Call of the Starseed’ Launches April 5th, New Trailer Revealed

By
Paul James
-
8

After 3 years in development, Cloudhead Games are finally set to bring the first instalment of their made-for-VR series The Gallery to the HTC Vive, with release set for April 5th. To celebrate, they’ve released a trailer which reveals more of the title.

It’s been a long road for the developers Cloudhead Games to find a suitable platform fit for their ambitious dedicated virtual reality project ‘The Gallery‘. Arguably that ambition outstripped the technology available back in 2013, when The Gallery: Six Elements, hit Kickstarter and successfully raised over $80,000. That might not sound like a lot, and it isn’t. But, for a game built on technology that quite literally didn’t exist in consumer form, with no guarantee said hardware would ever actually materialise, it was an impressive feat.

the-gallery-call-of-the-starseed-00014

Now, Cloudhead are triumphantly nearing the finishing line, having found their natural fit in VR hardware with Valve’s SteamVR platform and the HTC Vive. A system that was designed to enable exactly the sorts of intuitive, physical interaction The Gallery has in its DNA. A far cry from it’s humble beginnings, team Cloudhead comprises talent pillaged from AAA studios such as Bioware, Relic, Riot and EA.

The Gallery: Call of the Starseed on Steam

See Also: Cloudhead Games’ ‘Blink’ to Bring Nausea-free VR to HTC Vive this Holiday
See Also: Cloudhead Games’ ‘Blink’ to Bring Nausea-free VR to HTC Vive this Holiday

“So many of the things we’ve done in The Gallery are completely new. There were no pre-baked solutions, no standards when we started this adventure in 2013,” says Cloudhead Games CEO Denny Unger. “What we’re striving for is to give consumers a great introduction to VR and to build their excitement for the future of the medium as a whole. VR done right can make you feel like a kid again and it can give you all the excuses you need to lose yourself in the moment — to simply play!”

SEE ALSO
Pimax Changes Payment Structure to Make Flagships More Affordable, But Less Refundable
1 of 4
The Gallery: Call of the Starseed is a good example of a game encouraging physical exertion

The first instalment in The Gallery‘s episodic run, subtitled Call of the Starseed, and remains true to it’s origins as an adventure game with puzzle elements. Cloudhead are describing The Gallery as “the Future of Narrative VR”, so expect a strong emphasis on story and characters as Alex, who embarks on a quest to find his missing twin sister Elsie.

We’ll be bringing you much more of The Gallery in the coming weeks, stay tuned for more and don’t forget to check out the game here. The game is coming to Steam and Viveport online stores.

This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. See here for more information.


Paul James
Based in the UK, Paul has been immersed in interactive entertainment for the best part of 27 years and has followed advances in gaming with a passionate fervour. His obsession with graphical fidelity over the years has had him branded a ‘graphics whore’ (which he views as the highest compliment) more than once and he holds a particular candle for the dream of the ultimate immersive gaming experience. Having followed and been disappointed by the original VR explosion of the 90s, he then founded RiftVR.com to follow the new and exciting prospect of the rebirth of VR in products like the Oculus Rift. Paul joined forces with Ben to help build the new Road to VR in preparation for what he sees as VR’s coming of age over the next few years.
  • mareknr

    Will the Steam version of game run with Oculus Rift DK2 or CV1?

    • Bryan Ischo

      I would be surprised if it didn’t. OpenVR, the technology that games written to run on the Vive use, works on both the Vive and the Rift.

      This is opposite to how Oculus has done things, where games written to their VR API (Oculus SDK) only works on the Rift … until someone implements a shim library to adapt the Oculus SDK library to OpenVR, that is. Which I am sure will happen. If no one else does it, I will :).

      • mareknr

        That would be great. But at first I hope I setup correctly my DK2. :-)

      • The game relies on hand controls, and OpenVR/SteamVR doesn’t support any hand controllers other than the Vive’s, so don’t get your hopes up for *playable* day-1 DK2/Rift support. In a way, SteamVR is nearly as closed-off as OVR, despite Valve’s rhetoric:
        OpenVR: An interface specification that technically supports nothing
        SteamVR: Oculus headset (with poor performance), Vive headset and controllers
        OVR: Oculus headset and controllers
        That’s 3v2.

        Interestingly enough, Oculus has recently revealed (or perhaps reiterated) that they want other hardware to work with their SDK. From a software standpoint, they’ve got some good reasons to stick with what they’ve already built instead of using OpenVR. OVR is a much nicer API (in my opinion) with great maintainability features. OpenVR (again, my opinion as a dev who’s worked with both extensively) suffers a bit too much from YNGNI – being overly abstract and tedious.

        There’s also ideological reasons for Oculus sticking to their own software. Isn’t it understandable that leaving the API up to another company would make Oculus nervous? They care a lot about things like Timewarp and consistent reliability – both things that SteamVR/Vive lacks right now.

        Both sides ultimately want an agnostic SDK, because both sides want people to use their app store. Oculus has hardly anything to gain from hardware exclusivity, but a lot to gain from people using their store over the other one. If they’ve wavered on that, I think that’s unfortunate but understandable. Perhaps, though, their PR has done a bad job at making their HW-agnostic aspirations clear, which would suck, but doesn’t really matter in the long-run.

        Why doesn’t OVR support Vive yet, then? That would take a lot of time and collaboration between the companies – getting their respective products out the door is the main priority for the next several months. Maybe HTC will refuse to work with Oculus on OVR support, and maybe Oculus will drag their feet and leave SteamVR with subpar Rift support. Either way, unifying abstraction layers are already being built into all of the major game engines. OpenVR vs OVR will be much like DirectX vs OpenGL very soon – the game engine hides the difference to the developer and the consumer.

        I think the competition is good. SteamVR has more features, which will push Oculus, and OVR has better ease-of-use and overall polish, which will push Valve. The worst that happens is temporary store exclusivity, but inevitably the competition makes VR better for everyone.

        (I guess I should have posted this on something more related to the SDKs, or in response to someone actually being zealous about it, but you got me thinking!)

        • RawrSoft

          Good read, thanks for the insight.

        • Bryan Ischo

          Interesting perspective. Since you are developer who has actually worked with the APIs (instead of just browsing them briefly as I have done), I will take your words as relevant and truthful.

          Is SteamVR just an implementation of the OpenVR APIs? I don’t quite understand the relationship.

          I think that an open standards maintaining group should propose and manage a true open VR API. We don’t want OpenGL vs. DirectX all over again.

          That being said, I’m guessing that the APIs are small/thin enough at this point that supporting both via a wrapper layer in your game/program isn’t all that hard at the moment. It will get harder as these APIs become richer.

          Also regarding OpenFL’s over-abstraction and over-tediousness … is there any degree to which this is necessary given that there are anticipated to be so many upcoming tracking systems? Or is it really just overly and unnecessarily complex?

          Finally … why do you say that the Oculus headset has poor performance under SteamVR? I have used my DK2 with SteamVR and it seems fine. What am I missing?

          • Poor performance in comparison. This could be less of an issue now than it was a few months ago. Actually, it could be more of a difference now that OVR has just introduced async timewarp to desktop (though inevitably it will only become less of an issue).

            On the idea of a standards maintaining group, I think you’d find these interesting:
            https://github.com/ValveSoftware/openvr/issues/8
            https://github.com/vrpn/vrpn/wiki

            An example of OpenVR’s over-abstractness is providing a unique FOV per-eye. What headset has different lenses on each side!? Not really a big deal, of course… I think my main problem is the way they handle backwards compatibility. OpenVR’s convention involves getting an interface instance (you have to do this separately for different components, such as tracking system, display, chaperone) using a string-based version key that returns an intptr that you pass into all calls to that interface. Things are expected to be lined up juuuust right, and supporting different versions of those interfaces means exponentially expanding the already 5000 lines of DLL interfacing. To practically implement any sort of backwards-compatibility, you’d have to check numerous string values for the version of the interface, and yet the SteamVR package for Unity/Unreal have these interfaces and strings hard-coded to the newest version anyways (probably because it’s already at a massive 5000 lines!).

            With OVR, there’s a handy Caps (“capabilties”) bit-flag that tells you which features are supported on which peripherals, and a version number that is *read IN* letting you know which functions are available on the interface (there’s only one!). That single interface, by the way, is cascaded, so the whole OVR DLL interface file lands at around 600 lines of code. Sure, OVR doesn’t have Chaperone, but it does support backwards compatibility, and if it were to match SteamVR’s featrure-set, it certainly wouldn’t balloon to as many lines as even the non-backward-compatible OpenVR file.

            In essence, backward compatibility is done at the interface level in OpenVR in a messy way that I think requires a lot of work on the game engine end and that, as far as I can tell, doesn’t explicitly account for a difference in headset feature capabilities. OVR does backward compatibility at the feature level, which translates better to actually accounting for featureset in game code.

            Forward compatibility, BTW, is a non-issue for us since that must be done at the driver level (or rather, forward compatibility in the game is really a matter of backwards compatibility in the driver).

  • ZenInsight

    Shut up and take my money.