Show HN: A collection of useful items for building SteamVR titles in Unity 5
github.comGreat stuff. I'm hopefully setting my HTC Vive up tonight, so I'll be giving this a shot very soon.
There seems to be a significant lack of simple starting points for common scenarios in VR (and yes, I know it's very early). I'm just trying to work on something for a field that is very outside of gaming (so there's no help for me locally), and ramping up on all of this on your own is pretty dang time consuming.
I've been working on prototyping some stuff for the Rift in Unity and, while it's fairly easy to do, there's also a ton of outdated info out there already. And I can't tell if I should just be spending more money on some basic assets and prefabs or if there's a better route. Especially since I'm not looking to make games.
The ecosystem is still evolving very rapidly. Additionally, the vocal majority of the existing Unity community aren't the most technically inclined. The result is something akin to the front-end web development community before Stack Overflow; essentially, lots of copypasta, not much published innovation.
I'm not sure how much of this linked library is even original; much of it seems to be just copied from Valve. The concept of dependencies is not present in much of what I have seen, so this isn't surprising.
Having not read any formal writing and coming from what I consider to be more traditional systems (web dev), game dev has a lot of peculiarities. Adjusting to the concept of the execution frame (a literal video frame) as a point of reference for state, for example. The 10ms frame recommended by Alex Vlachos helped me quantify this and comprehend what the frequency were programming for, which makes something like the way keypresses are handled more sensible.
I've built two small projects in Unity, but am looking for another engine for my next project. Today, it still probably stands as the best choice, but Lumberyard, though riddled with bugs, is moving quickly in the right direction. Using an alternate stack for simulation (though not necessarily client-server) to get outside of the game loop has a lot of appeal. However, latency and the corrective prediction techniques do not look like fun to me.
My next project involves heavier simulation, which, after programming very simple AI in C#, has me looking to keep that codebase simple, specific and flexible; outside of the game loop. It's likely that I'll start with the simulation code only and add a graphical "front end" later. I can see this being justifiable on simpler experiences, too: loading any content from the internet will likely be less painful and faster if you pre-process it externally.
It's still the wild west out there. The real smart people are employed by AAA studios building proprietary engines writing really dense C++. Indie devs are not primarily software people and Open Source gaming is a pretty sad effort. But, since we're see more people like you and I getting interested due to the general appeal of VR, I'm sure the shared knowledge will grow at an increasing rate.
Also don't miss the Valve OpenVR SDK, here's their "hello world" sample: https://github.com/ValveSoftware/openvr/tree/master/samples/...
if you want something a bit more low-level than Unity. There was one tiny change I had to make, change "LoadTexture" to "LoadTexture_Async", there's a couple of pull requests with the details.
I can't wait to start making vr stuff.
I wish to see other alternatives, Unity is not my editor of choice but it seems like the new standard :(
What engine do you prefer?