Steam offers open platform Virtual Reality (VR) headset compatibility

The team behind the Open Source Virtual Reality (OSVR) consortium has detailed news of a forthcoming Steam update that will accommodate for open platform Virtual Reality (VR) content.

The result of the new openness should mean that all games on Steam that are presented with the OSVR compliant logo will be ones that work with any VR headset.

Steam itself is a digital distribution platform primary designed for games. It offers multiplayer gaming and social networking services — its games are supplied over an Internet connection and are therefore automatically updated on the user’s machine. Other features include in-game voice and chat functionality.

The ‘problem’ that exists right now in the VR headset wars is that we have a handful of major manufacturers (including Oculus Rift and PlayStation VR) who each operate with a dedicated storefront but, crucially, their user options deny access to players who visit the store while using competing headsets.

The result is that software application development pros working to produce VR games have to end up porting releases to several platforms — a practice that, very arguably, does not push for the greater good in terms of games quality and development.

As reported on Gamespot by Jason Imms, “The backbone of OSVR is its software development kit (SDK), which allows developers to build support for all of the VR headsets on the market into their games. The intention being to reduce the hardware fragmentation that is forming around the big three.”

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Is your development team testing applications for code vulnerabilities?

There can be testing and testing.

I once done a quick assessment of a critically important software used in a government infrastructure. It was scanned for security vulnerabilities with an enterprise class tool; the architects reviewed the findings and deemed them as low impact and risk. The Product Owner agreed.

It didn't take me long though to identify form submission loophole and save a document "legally signed" in "Galaxy Far Far Away". By "Emperor Palpatine" as a judge.  All I did was overwriting items in the dropdowns using just built in browser tools (press F12). Any user could do that.

The Product Owner was shocked! The architect was confused. And the tool was not to blame. Identified vulnerability was indeed in the tool's report but looked harmless disguised by technical terms.

It's important to put the security concerns in a context to identify the problem and it's threat level. We teach this skill in testing.

How about a better question.  Is your development team including code security scanning as part of their build and deploy process? Do they scan dependencies for known vulnerabilities they may need to mitigate?
Do we perform these kinds of tests? Yes. Have we closed the loopholes on all of the findings we have? Nope. Part of the reason is the fact that there is a continuum for code vulnerabilities. The more serious and obvious ones definitely get fixed, but many of the reports and findings turn out to be line noise, or deemed not important or severely low probability of ever being an issue. It's an ongoing conversation.