Hi folks! My name is Chris Pruett, and I am the Director of Ecosystem for Content here at Oculus. I joined Oculus in 2014 and have spent the last four and a half years helping developers build better VR apps and games. Before that I ran a game studio, worked on Android at Google, and even further back, shipped a bunch of games for consoles. I'm a big fan of horror games.
I'm happy to answer your questions about VR engineering, game design, or market success. Please only post a question once, we'll see it!
Just tried posting a question but it kept simply refreshing. Finally i noticed it flashed up something about approval. Sorry if you got about 10 copies of the same message.
A lot of the language for Quest has been around gaming and high quality game content. What % of the Quest ecosystem is Oculus planning on being non-gaming? Additionally are paid applications more favorably viewed for Quest compared to Free applications?
What kind of materials are we expected to provide for the Quest intake process? Since we're in alpha phase for our game that was intended for quest, but don't have any design docs, focusing on rather 'agile' style of development with rapid trying of new ideas and a lot of playtesting. Would build be enough to talk about quest possibilities?
It seems the requirements for Quest will be more stringent - I'm wondering if seated games (something like Moss, for example) will be considered acceptable for Quest?
Could you expand on which signals the Quest application team focuses on the most? For example, my product has fairly few total users, but a really solid group of users with >50 hours logged. This is mostly by design, because we want to iterate more on the product until it's able to support a larger concurrent audience. My main concern is that, because the Quest seems to be more targeted toward a mass market, that our relatively small user base will work against us.
Thanks for asking about cloud saves. The API we have available today is pretty straightforward, but I am sure there are some ways we could improve it. If you have specific feedback I can make sure the team hears about it. If you are specific enough they might even implement your recommendations.
With respect to locomotion, I think it's all about experience design these days. Titles that deal with constant velocity motion, with vignetting on the sides to cut peripheral vision pixel flow and avoid smooth turns seem to do well with a wide variety of players. One analogy that you might find helpful is to think of this like ice hockey: gliding across a surface within a fixed viewport (e.g. the helmet).
I haven't used either of those headsets so I can't really make a comparison.
This spring.
Yes.
The controllers are positionally tracked while within the field of view of the headset, which is pretty wide. As with Rift, we will make an estimation about the position of the controllers when the headset can't see them.
We don't have anything to announce regarding other tracked objects today.
Visibility is indeed a hard problem. What you see in the Store is a combination of algorithmic promotion and human curation. If we see something that is good that isn't getting the attention it warrants, we'll try to make it more visible. One of our goals with our new concept document is to help us get signal on titles that might benefit from increased visibility.
Finally, I would say that marketing and visibility is a constant challenge for any indie developer. My strongest advice is to try to do everything you can in addition to whatever the platform provides to promote your game. I think this holds true for nearly all platforms.
Oculus Studios' goal is to build exceptionally high-quality VR games, and to do that they work with some of the best studios in the industry. Their model is to identify a genre of game that they would like to experiment with in VR and then form a partnership with a developer to build it. That said, we have also supported hundreds of titles outside of the Oculus Studios umbrella. This is another topic you could cover when submitting a concept document to us.
Generally speaking, the APIs and development environment required for Quest are the same as those already used on Oculus Go (our MobileSDK) and Rift (Unreal/Unity integration). You can develop an application and deploy it to a Quest device without any special sauce, and our existing public documentation applies. We've put a lot of effort into ensuring that developing for all our devices is consistent and easy.
That said, folks that make it past the concept approval stage will have access to a few resources that are not public. This may include early access to prototype software, extra documentation, and a channel into the Oculus content team.