In my final year of my Computer Science degree I interned at Johnson Controls in Milwaukee, a company that deals in HVAC (i.e. heating and air conditioning) for large buildings. During my time there I learned about feedback loops. Here's the simplest possible diagram:
You've got some process that's running -- input coming from the left, output going to the right. But the final output of the system is branched off into a feedback loop that educates the system and alters the next cycle of output. An example would be your thermostat. You set it at 70degrees -- a setting called, oddly enough, the "setpoint" in HVAC parlance -- and the furnace blows hot air to bring up the temperature. In your house you've probably got a single sensor mounted in the thermostat that reads the ambient temp and informs the system that it's now hotter than 70 so it can turn off the furnace. The thermostat is the process, the sensor provides feedback, the furnace air is the output -- altered in accordance with the feedback and the desired setpoint.
Let's look at another example, this one from Scrum. In simplest terms:
Running a sprint for X weeks, the team's production is the process -- everyone's making textures, anims, code, etc. The current version of the game is the output. Your review at the end of the sprint provides feedback in accordance with the setpoint, which is set at Fun degrees. I could talk quite a bit on this loop since it's where I do a lot of my specialization, but let's move on to:
Here we step back from the work, and observe the game's start-to-finish creation as a process. Game idea is the input, shipped title is the output. The setpoint is probably still Fun degrees. But what result is generated from the feedback? In years past, the only answer was "a sequel" but these days you have other options such as DLC and updates to live games (e.g. WOW, League of Legends, etc). This feedback loop is where a lot of the luminaries in our industry like to operate -- the realm of game design. If you know the name of a developer who doesn't work at your company, he or she is probably a game designer. Think Will Wright, Sid Meier, and the like. To be honest, this is my least favorite arena in which to operate. Let's move on to my final loop, the one on which I prefer to focus my efforts:
Here, the process is the continuing operation of your studio. How you do what you do. There are projects being shipped throughout this process, people being hired, fired, and laid off...that's the process. The setpoint is -- let's be honest -- money. If you're lucky, maybe you work at a studio that has a publicized mission statement aligned with great goals and a fun culture, but that's a wrapper around the real setpoint. Or perhaps, the $etpoint. As passionate developers, though, we prefer not to get hung up on that notion ("No way, you cynic! My studio is all about making fun games!" Of course it is. That's how you pay your rent, right? You hand the landlord a fun game?) so I'll bypass that topic and go on to the feedback portion of this loop.
When does your studio collect feedback about its process?
What does it do with the feedback? Does the feedback result in change?
Is there good logic at work to determine if those changes bring you closer to your $etpoint?
Want some answers? I know I do. Tweet 'em if you got 'em.
@someproducer on Twitter
