Video games work like magic in their ability to let us move and feel objects that don't physically exist. We can turn a ball over in our hands, experience the thrust of a jetpack, or get the sensation of riding on horseback, all through a mass of circuits and resistant materials. It's obvious how controllers representative of real-world items achieve this effect. Nintendo Labo simulates stomping around a city as a hulking kaiju by having us control the game through a cardboard mech. House of the Dead convinces us we're shooting our way through a zombie stronghold by placing a phoney gun in our hands.
Where it gets uncanny is when the character or item we're controlling is nothing like the input device under our fingers. We can be sitting down but, in some sense, believe we're running down an alley. We can keep our hands clamped to a gamepad but experience pushing a crate. Games achieve that illusion, in no small part, through output devices: speakers, screens, and vibrating motors. When a TV shows us an apple, we feel like we're looking at an apple. When our headset makes the sound of mooing, we think we're hearing a cow. Yet, the role of controllers in creating this illusion is more mysterious. Input devices provide less sensory feedback, and when they're intelligently designed, we don't even think about them; we treat them as an extension of our bodies.
I want to dial down into each component of our input peripherals and think about how hardware designers fashion controllers, how game designers map controls to inputs, and the consequences of each professional's decisions. The headers I'll be using in this essay are not academic categories. Instead, they're titles designed to simplify discussing and digesting the information. Let's start our exploration with:
Signals
Every button, knob, and stick on an input device is a point of communication between ourselves and the computer. Remember, consoles and phones are also computers. The design of each individual component on the peripheral determines what we can or cannot communicate to the game with it. Steve Swink's book Game Feel is an invaluable resource for studying this communication and many other aspects of game design. There's a chapter in this text just dedicated to the role control devices play in games.
Swink categorises input components by the type of signal that they send to the computer. For example, a face button can only send a boolean signal: either a "true" or "false". The switch is either pressed or not pressed, on or off. The same applies to a mouse button, a keyboard key, or a bumper. These are what Swink calls "standard buttons". Even the quadrants of a D-Pad can function as standard buttons. Modern triggers, however, are highly granular in the data they communicate. They usually output a decimal value between 0 and 1 with a lot of different numbers possible between those two poles. "0" typically represents the completely released state, and "1" represents the trigger being fully depressed.
Video games "listen" to our inputs by taking a snapshot of all signals from our input device many times a second. Each of these snapshots is an "input frame". On a given input frame, the value from a trigger could look something like "0.262061" or "0.644285". A value from a standard button will represent "Pressed" or "Released." Swink doesn't linger on what these buttons and triggers might effectively communicate, but we can deduce this for ourselves.
Just as buttons output different types of data, video games also store different types of data in computer memory. Some of the variables in memory are text strings like your character's name. Some are numbers that fall somewhere within a relatively small range (e.g. 1 to 70) like the current level. Other numbers exist within a vast range (e.g. -2147483648 to 2147483648) like your avatar's current Y coordinate on the map. Others still are boolean true/false values, like whether your "ultimate" is active. Many competing pressures push a game designer towards assigning a certain input to a certain action. However, a crucial factor is ensuring the signal relayed by a component matches the variable it's modifying and how the designer wants it modified during any given frame.
Imagine you're a developer on a game in which the player carries a flashlight, and imagine you have to select a controller component that they'll use to turn the torch on and off. What component should you pick, and how do you justify that choice? We can start by observing that the computer will have a variable in memory that indicates whether the light is powered up or not. That variable will only ever contain a "Yes" or "No", a "1" or "0"; it is boolean. The flashlight cannot be "0.1624355" on or "0.7777" on. Therefore, we can't tell the computer to add, say, "2.718" to the flashlight value or subtract "0.3" from it. We can only ever ask the game to flip the flashlight value from one state to another. If it's off, make it on, and if it's on, make it off.
The standard buttons (our face buttons, keyboard keys, etc.) also communicate "on" or "off" signals, whereas other components like joysticks and triggers communicate those granular values like "0.1624355". So, from a purely signals-based perspective, it wouldn't make sense to have the player use anything other than a standard button to set the flashlight variable. A sensitive component like a control stick would be wasted on a per-frame declaration of whether or not the player wants to flip a variable. Therefore, it's preferable for you to bound the flashlight to X or B rather than LT or the Left Stick.
Standard buttons also find a home when there is some sliding value that the designer wants the player to change, but they only want the user to be able to modify the value a set amount on a given frame. For example, there's a minigame in Mario Party 4 in which players hammer a target. The winner is the player to bring the hammer down the most times within the time limit. Mario Party keeps a number in memory for the number of times you've hit the panel, and each hit of the A button adds to it.
Many action games, such as No More Heroes or Going Under, feature charged attacks in which we must hold down a face button and then release it to unleash a powerful strike. There is a "charged" value in memory that holding the button adds to each frame. Once that value hits some prerequisite limit, we will execute the move. In the charging example, there would be no point assigning the action to a trigger. At least, as long as we're only talking about signals. The player wants to add the maximum value to the "charged" integer per frame. So, to charge their weapon, they would just hold down the trigger all the way on each frame and would not capitalise on the component's full range. Therefore, the developers assign the charge to a face button instead.
While both the hammer and charged attack actions use standard buttons, note that the games in each example modify their values differently. The Mario Party designers have us tap a button to permanently increase a figure, while the designers of that charged attack only increase the number if we hold the button. Should we release the button while winding up an attack, the "charged" quantity reverts to 0. The lesson is that just because two buttons send the same type of signal does not mean we operate them in the same manner. In other circumstances, a creator may map the on/off state of a standard button directly to a boolean variable. In Job Simulator, you keep ahold of an item as long as you have the "grab" button held down. When you release that button, you let go of the object. In Returnal, as long as you keep L2 fully pressed, your weapon stays in alt-fire mode. The weapon returns to its default fire pattern when you let go of L2.
Surprisingly, this principle of matching input signals to variables in memory also applies when entering text. If you're inputting into an on-screen keyboard with a gamepad, then it's often pressing the face button while your cursor hovers over a character that adds that character to some string of text. On a keyboard, in any input window in which we have a key held down, that key's letter will enter into the active text field. Select an empty textbox, hold down "A" for four beats, and we'll get "aaaa". You can refrain from adding the character on a given frame or add it, but never half-add the character, so the boolean signal of the standard button suits it.
The numbers in memory we've talked about so far, we can only modify by a fixed amount in a given window. However, there are also values in memory that the designer wants the player to modify by some amount the player chooses each frame. Certain horror games allow us to hold doors in many positions between "open" and "closed" and let us decide whether to transition between those positions swiftly or slowly. That way, we can both fling a door open in the thick of danger or cautiously crack it to see if there are any monsters outside. If we had to put numbers to it, we might say that on one frame, we may want to push the door 1% more open, 10% more open, 25% more open, or come down anywhere between those values. So, the designer must give us an input that could express one of many values on a frame: a "0.01" or a "0.1" or a "0.25". A standard button cannot fill this role; instead, designers assign it to a trigger, as it will send a decimal number.
Playing a flight sim, we'll find that any one plane has a wide range of velocities at which it can travel. Not only can we choose whether to change the vehicle's speed on a given frame, but we can choose how much we change it by. And assuming we're playing with a gamepad, that's what the triggers are for. If we were tuning the aircraft's speed using a standard button, then each frame, we'd only be able to add to it or subtract from it by a value predetermined by the designer. With the triggers, we provide the acceleration or deceleration speed which the program adds to the overall speed of the vehicle.
We can further use this lens of signal analysis to explain how a control stick allows for finer movement than a directional pad. Roughly speaking, the control stick and D-Pad are like the navigational equivalents of the trigger and face button, respectively. However, each sends multiple values instead of one. A D-Pad outputs four values per input frame: one for each direction. One snapshot of D-Pad signals could look like "Up = Pressed, Right = Released, Down = Released, Left = Pressed". That combination of inputs would typically move an avatar up and to the left.
The control stick sends two values per frame: a number from -1.0 to 1.0 for its X-axis position and another in the same age for the Y position. 0 marks the middle of each axis. So, on a given frame, a stick would communicate something like "X = -0.4752, Y = 0.7825". That would be, roughly, down and to the left. As the D-Pad is confined to boolean communications, we can only use it to tell the game what direction we want to move it; we cannot directly specify a speed through it. But with the control stick and its higher input sensitivity, we can inform the game what direction we want to move in and how quickly we want to move that way.
The D-Pad and Control Stick also respond very differently when we employ more than one of their axes at a time. We can only use the D-Pad to navigate in one of eight directions. We also cannot use it to switch between directions smoothly and immediately. You'll notice that in many games that use D-Pads for movement, we get this swift lurch when we shift from Left to Up-Left diagonal movement or Down-Right to Down. We effectively snap to one of eight directions. It's desirable in some situations but twitchy and janky in others. Developers can smooth this motion by having the character gradually change from one heading to another when we press different parts of the D-Pad. The drawback is that this slows the game's reaction to our inputs. The approach could work in say, having a Ferrari drift, but that sluggishness is often frustrating in most movement contexts.
However, on the control stick, the sensitivity across the X and Y axes combine to create an emergent fluidity that the D-Pad lacks. Not only do the sticks allow us to select from a wider range of angles to move at than the D-Pad, but because each angle is adjacent to the next, we can also move smoothly from one heading to another, hitting all the intermediate angles in between. We can freeform draw curving paths through the space where the D-Pad only allows us to trace straight lines in one of eight directions. As input methods that communicate granular X and Y coordinates, mice and touch screens send signals comparable to control sticks, and like sticks, allow us to micromanage navigation. Control sticks and mice received wide implementation during the rise of 3D games because higher fidelity environments demanded higher fidelity movement.
While above, we've inspected games that map one component to one function, we're all familiar with "contextual" inputs such as the generic "interaction" button in Assassin's Creed. The contexts which alter input elements' functions include what entities we're standing near, what equipment our character has equipped, and what stance our avatar is in. But we often overlook contextual controls when the relevant context is the game mode. For example, Shenmue has the same buttons perform different jobs depending on whether we're browsing a menu, driving, fighting, or free-roaming on foot. Menus in games generally have us use one button to accept or access an option, but when they have tens of options, that's tens of actions effectively assigned to one component.
Context-sensitive inputs let us communicate more with the same control elements, but they have disadvantages. Contextual inputs become troublesome when it's unclear what context the player is currently in or when they may spontaneously jump between contexts. In Assassin's Creed V's bounty hunt missions, the Circle button both escorts targets and enters vehicles. If you're simultaneously near a target and a vehicle, you can press Circle, meaning to escort the target, and have your protagonist jump into a carriage instead. Games misinterpreting our inputs is annoying as we lose agency over the signals we send. This miscommunication is particularly frustrating when software identifies us as having made stupid requests that we didn't.
Resistance
It's worth noting that your ability to communicate precisely with high-sensitivity input elements depends on the resistance behind them. If you push a button inwards or tilt a stick across a surface, you'll feel some pushback from a soft membrane or a spring inside the input device. When we release these components, springs and membranes also return these components to their default positions. Should the manufacturer make these springs or membranes tauter, they exert a stronger counter-force against our digits. However, if they make them looser, it reduces the pressure the components exert on us.
If the resistance behind a button, trigger, or stick is too high, the player cannot press it into position speedily and easily. They will feel that using the controller is a struggle and that the device is not a natural extension of their body. If these components are too loose, however, it's difficult to match the force of your finger to the force of the spring and hold the trigger, stick, etc. at the position you intend. When the controller parts fold under your hand like flower petals, they also fail to provide a sense of impact and bite when you interact with them. It doesn't feel like you're pushing against the solid physical objects that the game implies you're interacting with. The designer must find a balance between responsiveness and solidness, although there's a lot of room for taste on that spectrum.
Bounding
If we looked only at the signals that the control stick and mouse send to the computer, we would conclude that they are identical input elements. They both transmit X and Y coordinates to games. But we know in reality that they fulfil different functions. Steve Swink distinguishes the control stick from the mouse through these components' bounding or lack thereof.
A control stick can't move outside the circular plastic walls that contain it. As it has a limited range of movement, the player can only use it to send one of a limited set of positions to the computer. When comparing control sticks, a less spacious bounding means that it's faster to push them to their "1" or "-1" positions but harder to hold them at precise points in between. A wider bounding gives the player more freedom of movement but means it takes longer to push the part to its edges. A mouse, meanwhile, can move theoretically infinitely in any direction, and therefore, you can communicate a broader range of positions with it than even a liberal control stick allows.
The superiorities of the mouse over the control stick are demonstrated when games have us use a stick to move a cursor. You can experience this setup in Destiny's menus or in Twelve Minutes, among other play spaces. When operated with gamepads, these titles have lethargic pointers. When moving them from one side of the screen to another, you contend with a lengthy pause between forming the intent to interact with an element and executing on that intent. Their designers could amp up the sensitivity of the cursors, but then they might end up slippery, able to scale a whole screen responsively but frequently sliding past UI buttons nearer their starting location. Fundamentally, the issue is that when screens are so large and pixel-dense, the player needs the capability to choose new cursor coordinates multiple times a second if they're to move briskly and surgically. They must also be able to pick from a vast set of possible locations. As covered, the control stick is no help there because it has a relatively small set of positions it can communicate per frame due to its bounding.
However, when we wield a mouse, we have a larger space within which to manoeuvre it, and so, we can select from a more generous menu of coordinates in a frame. As with the control stick, we can nudge the mouse slightly and see the cursor inch in one direction in response. However, we can also rush a mouse right to the edge of its mat, bringing the cursor with it. The control stick can only do one or the other. Therefore, cursors controlled by mice can be both sensitive and precise, while those piloted through sticks cannot be.
Once the player has an input device they can quickly use to zero in on any clump of pixels, the designer can jam the UI full of tiny on-screen buttons and know the player can promptly access them all. The developer is able to place more buttons on-screen than they'd ever fit on a controller and perfectly design those elements to suit in-game tasks. These busy and application-specific on-screen UIs enable games that are complicated to interface with at a surface level and ask the player for highly deliberate interactions. Examples would include RTSs, management sims, and MMOs. Therefore, we can use our knowledge of bounding to produce one explanation of why complex game formats have thrived on PCs, which can be operated with a mouse and keyboard, but not on consoles, which we almost always control with gamepads.
Now, there is an easy trap to fall into here. Looking at the benefits of having an unbounded directional input, we might start thinking bounding = bad and no bounding = good. In gaming discourse, there is a widespread opinion that the mouse and keyboard are strictly superior to the gamepad. But just as the mouse has its strengths over the control stick, the control stick has its strengths over the mouse. Something the stick is quite effective at, which the mouse and D-Pad aren't, is allowing the player to rotate it quickly. It's possible to twiddle the control stick precisely because of its circular bounding and free motion within that bounding. The console versions of Saint's Row have the player rotate the control stick when cracking safes to simulate the feeling of turning a tumbler. During the boss fights in Mario 64, we can use the same component to spin Bowser around by his tail. Neither of these experiences, nor many others in which we rotate a stick, can be replicated with a mouse.
Bounding doesn't just exist for sticks and mice, either. It also applies to buttons and triggers. There are hard limits to how far these components can push into or lift out of their respective input devices. Standard buttons tend to be set shallower into controllers than triggers. You generally want the player to be able to input any action fast, and having a wide bounding between "pressed" and "released" for a button that only registers two values is needlessly slowing player expression. However, a voluminous bounding is necessary for granular inputs like the triggers that the player needs to be able to hold at a lot of places between 1 and 0. Comparing triggers to triggers, those with tighter bounding are more responsive when you want to press them into their fully activated position, e.g. to fire a gun or press the pedal down all the way on a car. However, those with looser bounding allow players to take exact positions between the totally pressed and released pinpoints more easily.
Convenient Access to Abilities
When thinking about signalling, bounding, and resistance, consider this: Sometimes, there's an ability that a player might be able to use over an extended period, and they get a say in how long that period lasts. We explored examples of this when we looked at the flashlight and the alt-fire. The flashlight button toggled its respective ability, whereas the alt-fire button was directly linked to whether the ability was active or not.
Designers set up these schemes with respect to accessibility and responsiveness. In Returnal, your battles could change states at a moment's notice with a high price for failure. Therefore, the game needs you to be able to switch firing modes in an instant. If the game gave us a button to toggle between primary and alt-fire, we could end up having to press and release the button (although not necessarily in that order) when we wanted to make that change. Whereas, the way Returnal does it, we only have to press or release to change gun effects, which is faster.
A game with a flashlight could make itself more responsive by enacting the same policy, but you don't usually need to turn your torch on and off in a split second. Instead, you tend to spend long periods with the device on and long periods with it off. Asking the player to hold a button to keep it in one state would mean instructing them to exert physical force on the controller over an extended period when they don't need to. That would be frustrating.
The names given to buttons and the symbols on those buttons can further clarify their uses. Some designers assign actions to buttons bearing the first letter of those actions' names. In many menus, we use the A button to "Accept" and the B button to go "Back". In plenty of PC shooters, you'll see schemes like the C key "Crouching" while G throws "Grenades". Unfortunately, language barriers can hamper the implementation of character-based control schemes. The French word for "Back" is "Retour", but there's no R face button. The German word for "Crouch" is "Hocken", but the H key is nowhere near the C.
Common Practices
Developers may also assign inputs pursuant to standards in the medium. When they stick to tradition, it reduces the learning required from the player. If games generally use the left bumper for sprint, the player will find it more intuitive if your game uses the left bumper for sprint. If A is jump in most existing games, it minimises friction if upcoming games use A for jump. Such mapping doesn't usually clash with what would be best from other perspectives like signals and bounding because standards develop with those factors in mind.
Size and Shape
To increase the ease of hitting an input component, and to signal their relative importance in play, controller designers often think carefully about their size. On most controllers, the face buttons are larger than the "Start" or "Select" buttons. This is because the player will quickly need to move their thumb between the face buttons during real-time action. The player cannot spend time locating an input they need immediately. Whereas a button that pauses or brings up the map, you usually don't need to be able to reach within a few hundred milliseconds. Making a component smaller and lighter can also make it feel more discrete and precise when pressed, while larger and heavier buttons have a meatier, chunkier feel. Compare the looser, breezier shoulder buttons on the Xbox 360 gamepad to the broad, weighty ones on the Nintendo GameCube controller.
The shapes of controller components also ease the process of interacting with them and create the feeling of a natural fit between hand and input device. Left and right mouse buttons bend downhill, matching the curve of our fingers as they move in from the top. The circular shape of most face buttons and control sticks suits the footprint of our thumb. For an example of fitting going wrong, I don't like the tiny + and - buttons on the Nintendo Switch. They require that bit too much precision to hit, and they cover little of the surface area of my thumb.
One detail it's easy to lose here is the 3D element of a controller part. Note how sticks, triggers, or buttons can be flat, or slightly convex or concave. Each characteristic adds to the tactile feel of a component, and in the case of sticks, can affect grip. A control stick that dips slightly inwards holds more securely under my thumb than one that curves outwards. Sometimes rubber protrusions on control sticks or characters etched into buttons also affect touch sensation and secure them under player digits.
Colour
Occasionally, the colour of a button gives us some clue about its function. E.g. On the GameCube controller, the A button is often used to accept options and the B is used to reject. The A is green, and the B is red, making that assignment feel intuitive and neatly matched. Some keyboards use a tint for the WASD keys to mark them as directional controls. Of course, assume too much about how a game designer wants their inputs presented, and you box them in, which is why most controllers are very abstract in their design.
Simulation
So far, we've mainly assessed the efficiency of controller components. However, the designer's role goes beyond facilitating precise and speedy input. All games aim to embody particular aesthetics, and many serve as roleplaying exercises and aspire to realise a world. Input components and control schemes have a part to play in that embodiment and realisation. Where applicable, designers construct aesthetics, characters, and worlds by assigning inputs that feel comparable to the in-universe actions they control. The direct sensation of communicating through input devices also conjures aesthetics.
Think about the difference in feel and energy between hitting a button once, rapidly tapping it, and holding it. Having a player press a button to perform an action gives maximum responsiveness; it feels like a jab or a flick of the finger. Think taking a photograph in Pokémon Snap or throwing a shuriken in Ninja Gaiden. When the player has to tap a button rapidly, it can give a sense of hurried and chaotic physicality, like wailing on your enemies in Clicker Heroes or hammering away on a switch in Mario Party. Holding a button creates the feeling of putting focus or physical effort into a single action over time. We saw that with winding up the bat in No More Heroes and holding objects in Job Simulator.
Tactile simulation is not just about how designers ask us to use inputs, but also the components they map to tasks and what inputs controller manufacturers make available. A software designer may even choose to give the player sub-optimal controls to communicate with a game because those controls better realise the tactile experience they're going for. Take, for example, all the games that let us detonate an explosive with a trigger. You see this control assignment a lot in the Battlefield, Far Cry, and Just Cause series.
On any frame of these games, whether you're activating the explosive or not is boolean. Looking at it through the signals and bounding lenses, the designers should be assigning the detonator to a standard button, not a trigger. Nonetheless, many players still appreciate the decision to map the explosives to a trigger because the component looks and feels like the detonation switch the in-game character presses. The similarity between the diegetic object your character is interacting with and the physical component in your hands may also makes it easy to learn the controls and recall the button you need to press in the moment. It's trivial to remember that you hit the trigger by hitting the trigger.
For another example of coherent, realistic, but technically inefficient control design, consider popping tricks in Skate. Where the Tony Hawk's Pro Skater games let the player execute moves by hitting a couple of buttons on the controller, Skate has the player hastily draw patterns with the right stick. Cyberspace shredders often have to trace those shapes while the board is moving and with a head for timing. The patterns players etch mimic their avatar's movements as they perform the trick. Additionally, the complexity of inputting the moves causes a lot of bailouts for a newbie player, reflecting the rough entry to the hobby green skateboarders experience. The control scheme makes the player leap over unnecessary hurdles, but it's all for the goal of more realistically simulating the feel of the sport.
Difficulty
In Skate, we can see that making an input inconvenient to use can also be a way of fabricating challenge. Throwing off the player's most fundamental sense of control over their character can be divisive. Plus, by themselves, a lot of controller components don't require that much dexterity to move into a specific position. However, you don't have to go as far as Skate to challenge players through inputs. And there are other ways to create difficulty through interaction with a single input element. Our Mario Party example had the players hit one button frantically. Most of Rhythm Tengoku is just pressing the A button to different beats, and it's genuinely taxing.
Texture
If your brain feels like it's reaching capacity, you'll be pleased to know that a lot of the other elements that go into creating controller parts are easy to understand at a basic level. There's texture: some components are made from rubber or a rubber-like material, and others are made from plastic which affects their feel. Among rubber and plastic analogues, there is also a lot of variation. Swink notes that some plastics are cheaper to the touch than others. I'd add that some rubber analogues feel tackier than their alternatives and that plastics often range from a coarse feel to a glossy one. The buttons on the Switch, for example, feel rather rough, whereas the Game Boy Advance's feel smooth. Neither of these is necessarily better; they're just different.
Clickiness
Some plastic buttons attain a "clickiness" if they hit a solid surface when pressed. Others are stopped from hitting the base of their housing by a spring or membrane. So, you have one type of button that feels soft and comfortable, and another that is snappy and impactful. Like many other characteristics, there's no correct amount of clickiness, but talk to PC anoraks about their favourite keyboard switches, and you'll soon discover everyone has their preferences. Clickiness isn't just down to the texture of button materials either.
Look at how the Cherry MX Blue keyboard switches have this carriage suspend the key until it is depressed completely. Once it is, the key suddenly slams into place, sending a vibration through the user's finger and the air. Clicks are not just tactile but also sonic, meaning a speaker isn't the only way that a control device can generate sound.
Angle
The angle at which input elements are set affects feel and whether the parts conform to the user's hands. There's usually not a lot of analysis to do in this regard, as most input components tend to be flush to the input device. But there are exceptions. You may notice that the Xbox One's triggers are hinged at the top and so rotate slightly into the controller. The Gamecube controller's triggers, however, press in along a straight line. The effect is that the One's triggers feel more like squeezing the trigger of a gun, while the Gamecube's feel more like lowering a weight onto a platform.
___
You might be wondering where motion controls fit in all this, but they're a beast of their own. They deviate so wildly from many of the more tactile input components' design features that I'd have to go off on a long tangent to incorporate them into this article. Maybe I'll make a blog about them in the future. I also didn't discuss many more dated or specialist input components like knobs and joysticks. If you want to test your understanding, try working out how they relate to the concepts discussed, like signalling and simulation.
Further, I have to stress that we can only learn so much by analysing input components in isolation. We can't understand controls just in terms of how designers map single inputs to actions. Controllers are not just parts; they are also wholes, and by arranging the same parts in different configurations, you can create incomparable peripherals. I'll be back discussing the interplay between components next week.
Hopefully, however, we've got a better idea of what makes the individual elements of a controller feel the way they do and what input components can do what jobs. The intentions a part can express to a game depend on the signals it can send, and the player's freedom to change that signal depends on the bounding and resistance of the part. The character of parts is additionally defined by their texture, clickiness, colour, size, shape, and angle to the user. Game designers assign components to actions with convenience, difficulty, and tactile simulation in mind. Once you start thinking about controls this way, you'll never look at games the same. Thanks for reading.
Sources
- Cherry MX Blue Animation by Lethal Squirrel.
Log in to comment