The steel battalion controller could fix me. Some company needs to make specialty mech controllers so i dont have to spend £350 on 2003 hardware (so i can spend £350 on 2025 hardware).

Mech game Controllers: Solving the unsolvable

I have put so much time into thinking about this and you've basically asked the perfect question.

I think there are really complex and important questions that nobody really has a good robust answer to but also that nobody is really asking those big questions in the first place either, so we're stuck on this issue.

My take is I genuinely think if we want big mecha controllers we have to think about this stuff deeply and profoundly. Like, why we need them and what they're for.

So… This has been tried many times.

NOK or NextOfKin Creatives did try this.

The Mek-Fu lopped horribly, and I was absoloutely fascinated by this at the time and wanted to understand exactly why it had failed. I think we must learn from this failure, so we don't make the same mistakes again.

The lesson I took from Mek-Fu was this: it didn't take because players had nothing to use it in where it was the best fit.

What does this mean?

1) For other games in the real world, it was inferior to keyboard and mouse in games which do not simulate a vehicle. 2) The design wasn't trying to meet some sort of pre-existing need from other games. 3) Steel Battalion emulation did not exist meaningfully yet, and in turn no equivalent game existed on the PC platform which would need it.

Therefor: There was no special environment where its employment made the best sense.

It had nowhere to excel and thrive.

So where have specialty controllers existed, and thrived?

Digital Combat Sim (DCS)

Star Citizen

Euro Truck Simulator

Farming Simulator

What do they all have in common?

They all have robust modding tools for user-created content

They all have some form of social experience or multiplayer

They all are highly accessible (PC, and are controller agnostic*)

They are all sandboxes in some capacity and let users find their own fun.

No mech game which exists at time of writing meets all these terms that I know of.

So what do these controllers look like?

In the case of real vehicles, you can simply ape the real vehicle 1:1, but for fictional vehicles, something special happens -- you see people approach and try to solve the problem in many different ways.

You see, control design in any area exists to solve a problem. The Mek Fu (a response to the VT controller) was a solution looking for a problem, and no problem existed.

From this, we learn that for specialty mech controllers to exist, you first need specialty mech games. Steel Battallion is limited, because it won't run on general hardware and doesn't network or mod easily so it isn't a good fit for this because it makes the game inaccessible and limited.

Let's actually think about the SB controller for a bit:

Steel Battalion approaches its problem from the standpoint of a robot. You might not realize this but a VT or Vertical Tank intentionally controls very similarly to a tractor.

It is influenced by a real thing. I know that sounds absurd, but let me show you what a modern tractor's task control console looks like:

Yeah, not what any of us would have expected.

If you wanna be a mech pilot in 2025, go drive a tractor. I'm not kidding.

Once you're on the field, your hands aren't on the wheel, they're on this thing:

The big stick controls the course in the computer, the little one controls your tool, the many buttons toggle states (or what the little stick is currently triggering) and through these inputs you drive the tractor.

Steel Battalion is very fun, but it won't hold your attention for more than around 100 hours unless you're a real freak about tractors and just don't know it yet.

What's more, Steel Batallion isn't playable to anybody without the controller which limits how many people will be playing it and it isn't social or moddable like the successful games we talked about earlier.

Okay, so what can we do about this?

I think the one feature here that nobody talks about is that of input-agnosticism: The ability to bind your own inputs to something in the game (directly or indirectly through some middle thing) and get good results… But not in some hugely "okay bind 100 things using our controller, or use a keyboard and mouse" binary.

The binary is still not input-agnosticism, and it still will not work.

It has to be granular.

Input agnosticism results in controller agnosticism:

You can bind as much or as little as you want, and you can pass features you don't want to bind directly to a helper subsystem middle-man like an assistant or instructor which will perform limited tasks for you - while you provide the helpers context by telling them which of a limited set of goals you want to achieve.

Say, face a target, or a direction, or aim at a thing. It saves you mental time, though if you did it manually you might get better results (incentivising you towards experimenting in that direction).

Let's touch on why controller agnostic design is really what's needed here, and why its important:

This is the omnithrottle, and and this is the Sublight Dynamics 6dof joystick.

The Omnithrottle tries to solve 6dof throttle management by adding an extra piece to a joystick at the bottom, turning the yaw z-axis-twist of the stick into a sort of vertical axis for direct up and down movement, ascending and descending.

The Sublight Dynamics 6dof joystick combines all six axis into a single device, and is an interesting experiment. I particularly like the puck switches ahead of the user's fingers, inspired likely by Evangelion which in turn was inspired by Sol Bianca's use of them.

We got great lessons in human factors for space dogfighting from both:

The omnithrottle produces huge fatigue if you use it in coupled mode (software assisted flight), because you have to hold the joystick base forward, fighting the springs. This is fine in decoupled mode (where you coast under newtonian force) but not everybody uses it. Likewise, if you remove that spring, you lose fine movement because you can no longer feel where the middle is anymore.

The SD6DOF creates a conflict in Fitt's law (speed and precision are enemies of each-other, and to get both you need a tool in the middle to help you) where some precision is lost due to the same muscles needing to drive more axis at once.

These are both many years old now, and over time we've seen many many solutions to this problem flop.

Well, VKB announced the Space Throttle Grip a few days ago, which rethinks the distribution of axis and combines the best features of both.

The key thing is, this is an evolutionary space with competing ideas. A healthy ecosystem.

And its only possible because the game's inputs are controller agnostic.

This doesn't just mean that it'll let you bind any input device directly to things, but that there are multiple ways to achieve your desired outcomes even on the software side with the helper middleman we talked about (in this case, coupling modes).

Does your machine turn to face an arbitrary vector which is the thing you actually steer or select (Warthunder)? Do you have direct input control? Do you haven an autopilot?

Here's a lecture by F22 Raptor test-pilot Randy Gordon talking about some of this stuff, giving you a frame of reference with a real vehicle which exists.

When you can pick between those goals them, you have what's called "a software" in human factors. Your two grips become arbitrary and are now called inceptors.

The software drives the machine, and you drive the software. You can override the software and provide a manual input, but the other elements you are not overriding will try to compensate to maintain a desired state. If you know how to manipulate this, it means you only need a small number of axis to achieve a very complex control action.

A great example is how long you hold the A-button in Mario changes how much power his jump has. The action is a versatile verb.

Imagine a person balancing. If their goal is to stay upright, and I push them, they translate across the ground and try to stay the right way up, turning that push force into horizontal force. They are following an instruction: remain upright.

If I make that person carry a very heavy thing, they compensate their body's balance accordingly. If I then use my finger and tell them to act as if I am pushing them with that gentle motion, they will respond but if they go too far they can say "hey, don't do that, I'll drop the heavy thing!" and ignore my pushing instruction -- because my directory telling them to remain upright superseded it.

We need to think of mecha in terms like these, and to do mecha, we need to make a standard of accessible rules like this which input devices can talk to via axis and buttons, with lots of middlemen.

Absolute (mouse-like) and relative (stick like) and accumiulated (driving a mouse with a stick by having a variable over time) and blended (driving a car with a d-pad with a simulated wheel that wants to return to zero all the time, replicating a stick) inputs must be middle-modes processing and digesting inputs in these ways. Curves matter. Biases and preferences must be accounted for.

This means finally solving "how" the giant robot works in software (even if its a design conceit), and then having systems which poke at the "how" to bias it in a direction toward an outcome.

My favourite version of this is a deliberately clumsy mech-game called Robot Alchemic Drive (RAD for short).

Playable on a regular PS2 controller, the triggers and bumpers drive the legs like a tank. The sticks drive the arms.

The robot's body has physics. You are controlling a thing.

There are no helpers to correct your motions other than when the robot stands up and to keep it upright (its otherwise 100% manual, playing back motion planning which gets fed into the physics) but yes, there is a simulated body here.

With helpers, this could get faster and way, way more fluent.

So how might these "helpers" in software work?

Think for example of how a body in motion continues to move. With a robot in a vacuum like space, you'd continue indefinitely. That's hard to control.

Do you automatically slow down and fake aerodynamic drag axially with your boosters to allow curved trajectories and soft stopping with a motion-control-decoupling-mode (as Star Citizen does), or do you have a breaking system a user can activate on a pedal or trigger, to apply those forces on different axis when they want them?

What are those axis bound to, the pelvis, the thorax, the head, the synthetic vision 3rd person camera?

These are really complicated questions, and this is just about how we make a vehicle come to a stop!

Now this might seem niche, but this exact same kind of thought also applies to how a robot balances, and how it digs its feet into the ground, creating torque or not situationally.

This isn't just fine grained motion like "moving our legs manually", but how and when we apply breaking force on the ground.

Do we apply it when we let go of the left stick?

Does the left stick prescribe a preferred velocity?

Does it prescribe input forces?

Do we change between these situationally, or maybe with a button?

Its important to think about these things.

"You're making this too complex!!"

"But why would we do this? What is the value? People are playing Armored Core 6 with a HOTAS!!"

Yeah, and that experience is not great, actually?

You're actually less capable than a keyboard and mouse-player, because Armored Core 6 isn't a game which simulates orientation over time (the body turns instantly as if by magic), so you're just driving relative inputs. You are literally disadvantaged.

Armored Core 6 has no "vehicle": This is an action-game's 3rd person control software. Its Elden Ring's horse, with a jetpack, and the roll replaced with a dash. Everything else is animations.

Its visually impressive, but there's something fundamentally missing:

Fahrvergnügen.

It means "driving pleasure" in German.

The feeling you get when you speed up going down hill, or you feel the give of the wheels against the road and the lean of the car when you take a corner.

When you bank against air in an aircraft, or turn faster than your velocity changes and you drift.

That good feeling, that's fahrvergnügen.

A game which really gets this I think is Armored Core: For Answer. I know many of you might have expected Mechwarrior here but the physics of Mechwarrior games are extremely simple, following an interpolative model.

Interpolative here means, a bit of calculus is used to ensure a smooth arching curve is how you go from zero to a high speed at all times, or a rotation, so on and so forth. This "smoothness" is the same smoothness present in Armored Core 6.

Armored Core For Answer on the other hand, is additive in how it calculates velocity per second, meaning your AC's velocity curve is inconsistent. The game has hidden stats calculating aerodynamic drag per part, it has a simplified model of angular momentum, and it has ground friction and its boosting system is different on each axis.

All of your inputs are analogue, including the angle of your boosters on left stick, and two booster-types: Your main booster handling like a motor-cycle throttle curve, and the other not only having many stages of output for flashes of thrust via contexts (combining motion and direction together to produce an intent) but also combos and even cancels. Its VERY sophisticated!

That's a lot of different factors to control. A lot of fahrvergnügen to be experienced when you master them, and feel ownership of them.

Lots of areas for skill expression.

This, combined with a rich weapon balance and a complex combat geometry (the emergent spatial and pressure rules of motion, aspects, angles and motions similar to the aircraft dogfighting) are why people are still playing this game today.

The match I uploaded was from four days ago, as of time of writing. People are still modding a game from 2008, limited to console by hacking the rom file's patches. Yeah.

I know among many game reviewers, "smooth" and "smoothness" is considered a compliment in game design (its easy to control), but interpolative motion really is the opposite of fahrvergnügen:

Interpolative suffers from feeling "zippy" and "hollow" when its fast, which is why lots of players and designers insist on slowing games down so they recover their fahrvergnügen.

You don't have to do things this way. A good mech sandbox should reward both fast and slow movement in its design!

There should be room for everybody to play!

In interpolative movement games, motion is already solved, to sell you the superficial power-fantasy (that you're good, despite not having learned how to be good) instead of giving you the experience.

Interpolation is insisting the burger you got at McDonalds is the same as the burger on the commercial. Like the burger at McDonalds, its also way way easier to make, and in today's market yeah, you take what's easy and known because you have economic pressures to get things done quickly.

You can't make a five star meal in a McDonalds kitchen, and the AAA games industry is the McDonalds kitchen of gaming.

So, what is a three star michelin meal, in terms of inputs, with additive movement?

You incentivise people with the cheaper stuff on the menu. That's robust helper tools which let keyboard and mouse players, or gamepads interact fluently.

Its affordable, and easy and gets people invested in your experience.

Then when people use fancy controllers, you get better response-rate. Because everybody buys into the mecha fantasy when they play, being beaten by someone who is controlling more complex control factors more directly at once (making them a better pilot) feels fairer.

They are negotiating the machine's limits better than you are.

You both know they more "an char" than you are:

It becomes aspirational, rather than annoying, which is how the culture of space-simming, and flight-sims, and other vehicle sims express this. It also fits the mecha fantasy, because those with basic controls are your grunt units.

We see this if we look at cockpit controls in Gundam: A Jegan's control inceptor is way simpler than say, Unicorn's.

It is just part of the fantasy.

So let's talk about these limits we negotiate.

It means, some kind of vehicle must be simulated in software, even if its a very simple abstraction purely enough so it feels good for players.

Also, I say "a software" or "helpers" what do I mean?

I don't just mean the simulated vehicle, but a robust modular middle system in the "player controller" part of the game simulation which interprets desired outcomes from a pilot user or operator and tries to achieve them.

Here's an example, let's talk about Armored Core's lockon system, which uses a software stack to turn your intention into an outcome in exactly this way.

Your robot's simulated sensors (radar, visual, etc) detects a list of potential targets…

Which uses camera orientation of a synthetic vision system to give you comprehensive 3d awareness to determine which target is interesting to you…

After selecting the target, it passes that information to the fire control system which computes a trajectory from its position and velocity…

This then talks to your weapons which know how fast your bullets go…

and this picks where to lead along that trajectory…

then that location is sent to the arms to execute that command…

Which then sends the state of this command chain to your HUD, so you understand what the body of your robot is currently trying to achieve.

Each step is influenced by ingame statistics and simulated mechanical limits -- meaning, how well you can lock up, or even select a target is very important.

You can't instantly put a cursor on something and bot a game, because everybody already has a deliberately limited aimbot, it came with your robot, to negotiate its deliberately limited body.

The key thing is, this is much much faster and more effective than you could as a human select the target manually and hit accurate than you could with round velocities -- with most videogames hiding this with hitscan (instantaneous bullet) weapons meaning whatever you click on is hit right away.

When the round takes time to get there, things are far more difficult. This is why almost nobody uses manual aiming unless they're throwing explosives at big bulky targets in AC.

From limitations like this, booster performance, turn-rate, and so on and so forth -- the negotiation of limits produces a combat geometry and how well you understand that combat geometry, and how well you understand your abilities to your opponents abilities dictates how the fight will go.

We see something somewhat similar in Steel Batallion with the lockon system but we also have a lot of deep manual control over our VT's orientations which change its balance and so on. Steel Batallion is in fact, one of the few games where your robot can fall over and get back up.

This is exactly how DCS and Star Citizen also work, and very similar principles apply in Eurotruck Simulator and Farming Simulator via the fuel, cooling, air, combustion cycle, and transmission, and shock absorbsion systems of your vehicle.

Okay, so now what?

I've been thinking for a while now about writing what I think would be the mech-game equivalent of the paper Tim Berners Lee wrote for the web (Information Management: A proposal) going into what I think the simulation would really need, what the software would need, what the controller would need and some suggested practical strategies for solving these problems based in real research I and others have done.

The system I've already built solves for fire control, fine arm motion, head movement, independent pelvis and foot motion, the operation of boosters and other similar systems in a 6dof environment which accounts for gravity, aerodynamics, balancing, alignment and full motion control -- all on a standard game controller. Its not modular yet, simply because I am not a skilled programmer, and would need real help to do this.

There's also game-design research here, which would ensure the combat geometry would reward skill expression via investing in that agnostic game design, so the control skill aligns with the power-fantasy through skill expression. This means no one strategy becomes overwhelming.

It likewise, also has the "for gamepad and keyboard/mouse" solve which would be needed to ensure its accessible for those who aren't ready yet for custom controllers.

In turn, it also has considerations and proposals for such likely controller designs and probable strategies of employment which of course translate and map to two big sticks, in a HOSAS (Hands on Stick and Stick) layout.

So what's your ideal controller?

Less a controller, and more a principle:

Key to the proposal is you can scale up the amount of control bindings, or scale it down passing automation to helper subsystems which take your intention and act on it in a useful way.

You could have just two plain sticks with foot pedals, or you could go ham and have some complex force feedback device with tons of inputs -- because of this input agnosticism.

The secret sauce I think to the highest end control is the use of software defined force-feedback not only for the two big sticks, but also four smaller ones: one each for your thumb, and one each for your finger on each hand, and an analogue trigger. I've seen this solved in open source projects, so its entirely doable.

What does this actually mean?

Source: KAIST-HCIL/FS-Pad

The purpose of a force-feedback stick is software defined -- driving the camera, pelvis, upper body, boosters, walking etc variably, with the feedback not necessarily telling you about the environment -- but also by providing what amounts to new input devices.

To explain, force feedback works by providing input to the stick like a robot arm and is not at all like a rumble feedback device. This means the position the stick "wants to return to" at any given time is not defined by springs like it is in a conventional controller, but by active software which can update in real-time.

This means resistance can be different in different directions, or the stick can even hold a position you give it in one axis but not another, replicating a hat switch or a flight throttle.

I've looked at many different open source projects which achieve these outcomes both on thumb-sticks and main sticks with great outcomes, and I think a prototype could be made if I had a team, or other people to work with.

If interest is expressed, I'll produce a specification proposal for what this input agnostic design in software needs to be (eg, how the robot is controlling) in strictly defined terms which can be implemented.

You can already see it on my Tumblr account as TOMINO, NAGANO, etc where I go into some of this -- all of which works on a standard controller, but adapts extremely well to a large HOSAS.

Likewise, I'd (eventually) also produce a proposal for a controller design which meets this specification.

I've been testing this concept on and off for many years now in Unreal Engine (I'm not a skilled programmer, not skilled with CAD or electronics, depression limits my effective outcome returns -- but I'm still getting very promising outcomes).

Ultimately what I'd really want access to is expertise and help, since my background is mainly thinking about and designing solutions for problems not necessarily implementing them -- and I'm essentially on disability, so I have unlimited time to think about this.

I don't want to ask for money, which I figure is the thing everybody is anticipating: I'd rather get this done than make money from it.

Coming away from this:

tl;dr:

For the controller to exist, you first must have something to control.

To be a pilot, you first need a vehicle.

--