Some questions about building a VR game with Babylon

Hello all, been awhile:

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.

  1. 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.

  2. 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?)

  3. 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.

  4. 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

For context, it’s a 4v4 game in zero gravity, where you fly around and punch people, and work with your team to throw the disc into a goal. Rendering wise. I don’t think it’s anything crazy graphically. Physics wise, it’s pretty physics heavy and needs to be fairly precise/fast, it’s really more of a sport than a game. I don’t know if existing javascript physics libraries would be up to the task or not either.

cc @RaananW

Hi! Love the questions :slight_smile:

  1. 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.
  2. 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.
  3. Well, why not? :slight_smile: 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
  4. 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 :slight_smile: . 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 :wink:


Right. There are a few issues open for this. Someone is trying to make it work from the community, but it’s still a WIP. Perhaps you will be interested in helping?

1 Like

For getting it on to the store, there is option as well which I am hoping to try down the road.

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.

If you wanted to stick with web/webxr anyways

1 Like