Posted 19 May 2013 - 09:34 AM

Quote

Is a mouse more accurate then a joystick? Is a joystick superior to a mouse? Well… yes to both. Aaaaand no to both. The real answer? It depends. It depends on what type of movement/inputs the application was engineered around, and the nuts and bolts of how an input device tries to comply...

G

Control Types: -attributes (common examples; notes)

zero-order control – manipulates target position. (mouse, touchpad; single input action required)

first-order control – manipulates target velocity. (most joysticks, vehicle throttle; one or two actions required)

second-order control – manipulates target acceleration/rate of velocity change. (car steering wheel, ailerons of larger aircraft)

third-order control – notable lag between control input and perceived action (steering a tanker, trim systems)

Isotonic: cursor moves as a result of movement of the joystick handle. (my mech joystick. other?)

Isometric: cursor moves as a result of the force applied to the joystick handle, which does not move or moves very little (force sensing joysticks -Saitek X65F or Warthog with FSSB R3 mod)

Spring-loaded: resistance is proportional to force applied. Displacement produces proportional inputs, but hands off returns to a neutral position. Offers proprioceptive and kinesthetic feedback. (standard joystick)

reetings Mechwarriors, this is my attempt at organizing my musings on controls into a single entry, doing my best not to sound like a douche. This is the second edition of this, dubbed v1.2. Its is a WIP that represents my *current best understanding of the underlying issues, and no doubt there will be refinements as I move forward. I have a lot of respect for members of MWO and gaming community, and highly value any feedback, corrections, or oversights you want to share. There are no stupid questions, and I welcome scrutiny too since without external pressures to do this better, I’d still be stuck on my partial correct v1.0 (bottom). My intention is not to tell anyone what type of controls are better or worse (hint-they’re all better and they’re all worse! but rather to hopefully clear up some of the persistent myths that have clouded the issues beyond useful discussion in many cases. In addition to needing a basic understanding of the underlying mechanics for our own benefits as users, its also important we know what we’re talking about in case we decide to lend potentially influential opinions on the subject..What got me going on this was trying to fly my sailplane flight simulator (Condor), between flights in my real glider. Problem is a sailplane cockpit feels and looks nothing like sitting in a chair at a computer, and immersion eluded me despite the rather high fidelity of the simulator. Through experiments conducted while being able to purposefully jump back and forth from RL flying to my evolving glider simpit, I was able to put my finger on what I feel are the key elements necessary for immersion and the list of non-negotiable items was much shorter than I expected. I have found that removing or half assing any of these baseline pillars is pretty much a dealbreaker though. It’s actually not that difficult in many cases to adequately fulfill these minimum requirements, but it may require knowing more about the controls than is common in some cases.I’m not saying there isn’t a lot more to it, just that these are the bare minimum items I feel need to be taken care of first or else the rest of a simulator project runs the risk of becoming irrelevant. From my experiences, most of what immersion there is to be had comes from these 4 things, and the better they are done the more believable the effect, and like Pareto’s Principal 80% of the result comes from the first 20% of the work. Going beyond these in most cases is an exercise in diminishing returns as far as I can tell, and likewise failure to sufficiently meet the requirements of this list can break the magic of even the most visually detailed cockpit. These are the key to getting to what I call the ‘saturation point’, the subtle point at which one can effortlessly suspend their disbelief and become fully engrossed in the virtual task at hand. To me, this is the whole point of a simulator of any type.Sounds simple enough, right? Well, maybe not. Number 1, 3 and 4 can potentially be easy since plenty of perfectly acceptable solutions exist, but number 2 is where it can fall apart since controls can be a complicated subject when you examine them more closely, and also I feel the most important item on this short list. I didn’t specify head tracking here, since it’s kinda a cross between lines 2 and 3, but if there is any view panning function in-game, this really should be done with head tracking and almost warrants a entry of it’s own. The interface you use to experience a simulator is not merely there to augment or facilitate the experience, it IS the experience! Failing on any of these, especially controls, is the bonerkiller of immersion and for me killing immersion = killing fun. I’m pretty sure no one reading this needs a screen/monitor lecture and more than likely could lecture me on the subject and its not so hard to come up with good seating or audio; leaving only the topic of controls to expand on.When it comes to peripheral controls even in the gaming community there seems to be a lot of partial understandings of what is going on, leading to a lot of confusion on the subject since many people are usually at least partly correct in their assertions, however rarely for the right reasons and nearly always only accounting for a small part of a larger and more complex issue. If your happy with your mouse, keep using it. If your happy with your joystick, keep using it. Is a mouse more accurate then a joystick? Is a joystick superior to a mouse? Well… yes to both. Aaaaand no to both. The real answer? It depends. It depends on what type of movement/inputs the application was engineered around, and the nuts and bolts of how an input device tries to comply. While people can use whatever controls they like and can call it whatever they want, from an objective standpoint different types of control schemes are not arbitrarily interchangeable and do not yield equal results, and it’s important to understand the nuances of these issues..Up until recently, I’ve mistakenly referred to the input types in layman’s terms, identifying them as either being, or. While correct on some levels and possessing enough bits of truth to make most people understand what I’m talking about and generally accept my previous explanations, in reality its over-simplification coupled with incorrect nomenclature. For flight related projects, I never needed to know this stuff and I wasn’t trying to learn this much on the subject but through being (rightfully) challenged on my assertions while chiming in on periodic threads that joystick != suck, after making a custom stick just for mech piloting ( http://imgur.com/a/ixi64 , descriptions in album) and it forced me to look deeper into the problems and solutions in order to back up my claims.This falls under the engineering field of what are called Human Factors. There’s numerous types of inputs that are recognized in this field which further subdivide into more specific types, of which all control schemes fall into but for the subject of gaming peripherals we really only need to consider a few of the lower order controls. This is an attempt to clarify some facts in the ongoing battle between mice vs joysticks in regards to gaming. Basically, the lower of an order a control is, the easier it is for a human to utilize it for precision tasks, and the orders are loosely based on how many actions are required to achieve the desired effect when used in their native application (things get wonky when you swap as outlined below) or how or how complex it is in general. It’s important to differentiate between these inputs, because they are not particularly interchangeable design criteria and substituting one for the other predictably yields less than optimal results. Identifying the control scheme that any given game or system is engineered around is step one for coming up with viable control schemes beyond the standard options.Joysticks further subdivide based on their mechanical and electromechanical properties:As you can probably gather by now, MWO is engineered around zero-order inputs, as are most if not all other shooter games, and many other types and titles. As such, a mouse really is the easiest input device to use, since it offers very high precision, ease of use, and is the most common form of this type of controller so everyone is already set up to utilize this input type.Well, there are, but a normal off the shelf joystick is simply not one of them. The ubiquitous joystick is a spring-loaded first-order control input device (second-order in some cases, sometimes isometric), and is engineered around very different principals than a zero-order device, and likewise my zero-order mech joystick is engineered around very different principals than a normal first-order joystick. Below I will outline the differences, and why they matter when trying to substitute a first-order controller like a *normal joystick (or just *joystick) for an application designed around zero-order mechanics such as MWO.(effects)(unnatural range of motion, not reflexively intuitive)(fights inputs, negative interactions across the axes center’s)(distracting, imprecise, disconnected feeling between inputs and in-game reactions, wasted range of motion, lag)( ie relative inputs, movements wind up either too slow, or too uncontrollable; difficult not to overshoot past target, requires 2 precision actions to complete one positional change)(natural range of movement of the cursor/reticule)(nothing fighting inputs, unrestricted movement)(always in control, precision across centers no different than any other point in x/y, no lag)(obvious and easy to control, very precise, requires a single action to complete a positional change)(pitch/twist -natural range of movement of the mech)(nothing fighting inputs, smooth damped movement, always maintains physical orientation related to on-screen state)(always in control, precision across center no different than any other point in x/y, no lag)(obvious and easy to control, very precise, requires a single action to complete a positional change)For anyone that doesn’t yet understand the significance of zero-order vs first-order controls, here is an analogy. Picture a 12″ square sheet of glass and a marble sitting on it:Using a first-order controller is like trying to move the marble by picking up the sheet of glass with the marble balanced on it and tilting it front/back and side/side to move the marble, then quickly leveling it again when it’s where you want it to be in x/y coordinates. The more you tilt it, the faster the marble moves and the harder it is to make it stop exactly where you want. Your actions generate directional velocity reactions, proportional to the amount of deflection, which must be quickly brought back level to discontinue the input reaction. Controllers made for this task are specifically engineered to facilitate these inputs with ease. Springs hold it level, obvious centers, deadzones etc, and every convenience feature built into it for this mode becomes a hindrance the second you press it into service as a zero-order.Using a zero-order controller on the other hand, would be like placing the same piece glass level on a desk in front of you and using your hand to reach out and directly move the marble wherever you want on the plane, and for this reason are also called direct inputs. There is only one action required, and it’s very easy to perform this single action very quickly with very high precision. Just like above though, the mechanical features engineered into these devices produces quite a very specialized form factor to make this easy. Just like above, all the things that make it easy to use for it’s native applications work against you the moment you attempt to use a mouse as a first order controller as I will show.Working it from the other direction to further demonstrate the importance of using the right control type for a given application, lets examine what happens when you use a zero-order controller like a mouse or my fancy mech stick for a first/second-order application such as Newtonian flight physics.(effects)(natural range of movement of the aircraft/spacecraft, reflexively intuitive)(proportional feedback to mechanically gauge inputs, easy to find and hold neutral position)(allows a safe area free of inputs, easy to fly straight, no spamming the axes)( ie relative inputs, perfectly suited for the dynamics of flight, realistic input>reaction, intuitive control, takes single precision action to perform)(unnatural range of movement, not reflexively intuitive)(no feedback to mechanically gauge inputs, difficult to find center/neutral position)(no safe zone to keep from spamming the axes, very difficult to fly straight)(awkward and difficult to control, requires two precision actions to complete a single maneuver)(unnatural range of movement, not reflexively intuitive)(no feedback to mechanically gauge inputs, difficult to find center/neutral position)(no safe zone to keep from spamming the axes, very difficult to fly straight)(awkward and difficult to control, requires two precision actions to complete a single maneuver)This all said, it’s a lot easier for designers to work with higher-order applications such as flight mechanics to be adapted to lower order devices like a mouse, than it is for lower-order application like shooters to be adapted to higher-order controllers like a typical joystick or X-Box controller. Mouse flight can be made to work pretty well, but there is little if anything that can be done to make a first-order joystick better for a zero-order application. I’m sorry to inform those of you waiting for some magic moment with MWO where all the sudden a normal joystick will compete with a mouse, it will never happen, but it has nothing at all to do with analog ‘support’ or anything on PGI’s end like most people assume and some are even holding their breath for. The problem is that MWO is already engineered around zero-order mechanics, and those simply can not be manipulated with a first-order controller to the same degree of precision or ease as a zero-order device.You can either use a zero-order controller or suffer with sub-optimal results, although one should be careful to use the correct terms when explaining this, unless they’re prepared for a 3000 word essay on why their wrong. To simply say a joystick sucks for MWO is not correct. However to say a first-order joystick even under the best conditions is less than optimal with MWO, is objectively true. The real comparison is not between a mouse and a joystick, but between zero-order and first-order controller, and the first-order controller always loses in a zero-order application. I’m not saying you can’t play MWO with a regular joystick, just understand you really are playing in hard mode if you do. Sure some adapt to it, but mostly by piloting s l o w heavies or assaults since you have to balance reaction speed vs accuracy, usually achieving neither in the process. You can get away with it in an Atlas, but not a Commando…controls are complicated, but very important to understand. One can adapt control devices to non-native applications, but results will be suboptimal. While less than optimal, its worth noting its easier to manage lower-order devices in higher-order applications, but not the other way around.Some of you may have seen my v1.0 rant on this ( http://www.reddit.co...trols_worth_it/ ), or not. I’ve been talking about this a lot lately, and with the efforts in my mechpit projects ( http://mwomercs.com/...440-my-mechpit/ http://mwomercs.com/...57#entry2198157 ), most notably my mech stick, its no wonder. A little background. I’m an engineering student and I also fly sailplanes as you may have gathered. I’ve been dorking out on sim projects since 2004, and have had the luxury of comparing real sailplane flying to sailplane simulator (Condor) flying over a period of time to develop a basic outline for immersion as well as to help nail down realistic motion control parameters for Ian at builtforfun ( http://bffsimulation.com/index.php ), who is an instrumental character in the world of homegrown motion control simulator platforms and is the source of most motion platforms extraction parameter software and realistic dynamic motion cuing if you look close enough into most functional motion control cockpits. I’ve worked on other aspects of motion control and control loading projects with RolandVanRoy (simprojects.nl), and designed an analog servo circuit ( http://i.imgur.com/gXlN0wu.jpg ) that can be used in both control loading (force feedback) as well as motion control applications. It has been tested to good effect, and although not incorporated into any of my own projects as of right now there is a 747 motion platform with FF controls somewhere in Spain based around it and I think Roland has since replaced his LED/LRD (light emitting diode/light dependent resistor) circuits that served the same purpose with them as welledit: fixed broken picture links...

Edited by Loc Nar, 27 May 2015 - 06:33 PM.