So my favorite VR game announced today it was shutting down its servers. I have some questions about whether building a clone in Babylon is viable.
Is it possible to build a full on app that can be put on the oculus store with Babylon at the moment? I was looking at Babylon native, which made it sound like it is, but I don’t see anything about building for quest on the repo.
How to develop for headsets, like for the sake of testing things, i.e. how to test things with controllers? Is there some other way than having to run a local server of some sort to serve up a page, and having to go to that in the quest browser every time. (and does anyone know if there’s a way to pair controllers to computer?)
Is attempting to build a large scale vr game with babylon a good idea at the moment? Like, is WebXR, Babylon, and Babylon Native, far enough along that this could be more than a pipe dream, or are unity/unreal probably a better option.
Are oculus specific API’s accessible via Babylon Native? For instance, they have voice chat/party specific api’s for their platforn. I’d probably just be concerned about releasing on oculus, not worried about targeting other platforms
AFAIK it is not YET possible. @bghgary will correct me if I am wrong. Even though the quest is practically android in disguise, there is still a different build process.
The general answer to that is - you don’t develop to a specific headset. WebXR won’t tell you what headset you are using. You can technically know that using different methods (resultion, type of controllers used), but it is not recommended. WebXR abstracts it all for you and let you interact with everything using a single API. if something is wrong in a specific headset, it is usually the headset’s vendor that should solve the issue. Having said that - if you want to force a specific type of controller, you can do that. this way you can see how the application will work with different controllers. I wouldn’t recommend it though, as the data received from the headset (webxr) will collide with the data needed to run a specific controller. The WebXR emulator allows you to do that as well, but it is sadly not being developed further, so you are stuck with relatively old devices.
Well, why not? WebGL (and soon WebGPU) is well established. WebXR, though in draft mode, is very stable and TBH works great. And I am biased towards Babylon, of course. If you want to create a native application, and you know unity/unreal, I can totally understand the will to use them. If, however, your main target is the browser, and you think that web is an important medium for your game, then Babylon is the perfect choice for that
Same as 2 - we use web standards and do our best not to communicate directly with vendor’s APIs. Under the hood, Babylon native will act as a proxy between the Web API calls and the native system, but usually won’t expand the API because one system has a nice-to-have function. Again, @bghgary will correct me if I am totally wrong here . On the Web I can say that we use web standards only, especially in WebXR. No vendor-specific functionality is implemented (unless it is required, like a lack of functionality in a specific browser).
And regarding physics - great things are coming! The web is not a bad place to run physics experiments
For PWAs published to the Oculus Store, users can discover your app through Oculus’s many discovery surfaces, like the Explore Feed, Quest Store app, and the Oculus mobile app. For PWAs published to App Lab, you can distribute your app via direct links or platforms like SideQuest, without requiring store approval and without sideloading.