I am concerned about the reliance on 360 controllers..

"raidho36" wrote:
Good points. Half of them are what I said though. But I can't just pass by without noting that #4 is completely irrelevant, adding or removing feature is only a matter of consideration of end user experience, not your programmer experience.

Also, the Hydra went out of sale, and STEM is much more expensive and isn't even on the market yet, so yeah.

Yeah, I had a similar opinion. I figured it was worth weighing in another vote for them.

But yeah - #4 is almost entirely user experience oriented. But to say that it is irrelevant is fool hearty for two reasons:

-Consistant API/feature exposure means that I can have a truly plug-and-play solution and implement consistent control schemes. I don't have to try to identify the game controller and auto-configure the input device, nor do I have to get the user to go through a potentially complicated configuration process. Because the API accurately reflects the controller and not some janky abstraction meant for joysticks, I can deliver a very polished, consistent out of box experience.

-Having a guaranteed, consistent feature set that is directly exposed by an API allows me to craft a good gameplay experience around it. If I know that a controller has to support, say, two analog triggers it allows me to do things like the Left-Trigger-Cover system from Rainbow Six: Vegas. Guaranteeing that the controllers had two bumper buttons, for instance, allowed Gears of War to do the active-reload system, or left-bumper to sprint. Or Halo's super-optimized FPS control scheme (and two weapon inventory system, grenade usage, etc). A lot of the more interesting control schemes in the last decade have come from consoles, and it's primarily because they have a fixed input system that they can use as a foundation.

Both of these can greatly enhance the user experience.

And I threw Hydra under the bus, but the reality is the STEM system will have a lot of the same ergonomic issues when it comes out. Motion controls are cool, but automatically exclude a lot people with physical disabilities. If accessibility is one of your goals, it makes sense to either prioritize a gamepad or at least ensure full support for one.

I'm getting my guts around building a VR Hydra boxing game, and it won't support any conventional controls, that's for sure. If you can't box in real reality, you can't box in virtual reality, obviously. Getting your character to jab and punch your opponent by pressing buttons isn't the same as actualy jabbing and punching your opponent. This is also the big reason why I seriously prefer 1:1 hydra firearm aiming to mouse aiming - compared to Hydra, mouse controls are dull and... well, so dull that you could use many words, but you only got one to actually lay. After all, I'd be playing a shooter game, not "click this pixel" game.

The choice of Hydra as a controller is dictated by desired game experience, because just gamepad isn't enough.

That game sounds cool. And just so we're clear, I'm not saying one kind of experience is better than the other.

What matters to me is that it's a good experience. Choices like which input device you support/focus on can have huge impacts on the quality of experience. It's important to understand why you're making those decisions and the trade-off's associated with them.

(side tangent: I used to be heavily involved in tactical shooting. Compared to that, the hydra feels... dull. And uncomfortable.)

I've been shooting as well, and yes, the Hydra does feel dull compared to that. But it's better than the mouse anyway, it gives at least some feel of the weapon. Maybe there's someone out there on kickstarter to come up with a plastic weapon controller with pistons and weights that would simulate the kickback and whatnot.