PIDs: Creating Stable Control in Games

For every PID write up that reviews the theory we need an equally length follow up on the practical aspects of PID tuning and problem modelling.

There is a cool sandbox game on steam called “Plasma” that offers a graphical programming environment which includes a basic PID controller. I was really impressed with how easily I was able to make a cube float almost perfectly in 3D space within that game by only using 3 of these controllers (mainly the P and D portions) and some thrusters by monitoring the pitch and roll angles, and how high above the ground the cube was. I was even more impressed when adding some weight to one side of the cube and seeing the system compensate for it automatically.<p>The process of tuning the gains on the different inputs of the controllers, then seeing how the system responded made me think about how this is a similar yet much simpler process to training ML models.<p>I’ve always been a bit skeptical of how easily one would be able to make changes to something as complex as a large ML model, but looking at it like tuning a very complex PID controller kind of made it seem less like black magic to me for some reason

The site explains the three parts of PID&#x27;s very well.<p>On one hand I like PID controllers. It&#x27;s a reusable concept which you can apply to a loot of stuff. On the other hand, in my experience it can be very tricky and cumbersome to tweak them.<p>In the given example, a PID makes perfect sense. There&#x27;s a single, static target location you need to approach. Adjust velocity with a PID and you&#x27;re done.<p>But what if the target location is not static? Imagine that the character needs to move to your mouse pointer? Do PID&#x27;s still hold up? How do you handle the I and D term then?<p>It gets even trickier if you move to 3D. You maybe say, hmm, let&#x27;s use a rigidbody this time instead of a kinematic body for the player character and use PID&#x27;s to adjust forces to steer velocity and rotation.<p>But I never found a good way to do that, because in those other cases the error depends on the goal you need to reach, and if the goal constantly changes, I and D are kinda useless...

If you&#x27;re learning about PID controllers, do yourself a favor and watch Brian Douglas&#x27;s video series on the topic:<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;wkfEZmsQqiA?si=50WWz4kuber56JIU" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;wkfEZmsQqiA?si=50WWz4kuber56JIU</a><p>Brian has great videos on other control theory topics as well.

PID get real fun when you model physical systems, like say filling a tank while trying to maintain liquid depth and temperature or maintaining a constant reaction rate. You get to start taking laplace transforms. I had a ChemE professor who’d tell stories from the 30’s when chemical engineering was forming as a discipline. Common practice back in the day (before the theory) was to manually adjust parameters until things went unstable, then back off 5%. Turns out the optimum point is the inflection between stable and unstable behavior.

The most bang-for-the-buck feature of PIDs I&#x27;ve seen yet is to smooth out game camera movement so that the camera feels less &#x27;mechanical&#x27; (works both for the 3rd-person camera behind a character, or the overhead camera in a strategy game which needs to jump between positions).<p>Just implement the camera positioning and lookat-pointing in the dumbest way possible (including non-continuous, sudden jumps), plug a PID into the position and look-at point, tweak the parameters a bit and voilà, pure magic :)

Feels like PIDs are the wrong tool for this problem. Stuff to do with matching animations up to physics is usually better solved with inverse kinematics.

Using only PD (no I) when tracking also works well. Might be worth adding a short section about that to compare against the full PID.