He has a unique cooking show called Good Eats. In addition to showing how to prepare a recipe, he explains what each step of preparation does, why it's important, how it works and what happens if you omit it or get it wrong.
Typical scenario for me:
- I find one of his episodes, maybe about leeks.
- I think "I'm not a huge leek fan. Maybe I'll skip this."
- I watch the episode anyway.
- By the end of the episode I want to go buy a bunch of leeks and make stuff.
My reaction, among engineers, is typical.
Sometimes, instead of an ingredient, Alton focuses on a tool (like knives) or a technique (like the Muffin Method -- "just walk away").
The key to Alton Brown is that he teaches tools and techniques; his recipes are just exercises and homework.
Recipes provide specific details for how to solve a specific problem (which has already been solved).
Tools and techniques are abstraction of recipes -- the common elements that help recipes succeed.
Tools and techniques relate in that technique is the practice of using a tool.
Most game programming books out there focus on recipes, whereas we need books and curricula that focus on tools and techniques.
I have spent much of my career as a game developer preaching the virtues of having engineers develop tools and engines -- not end-user-facing features. As software engineers in game development companies, our emphasis should be on giving designers the power to author their vision -- in an environment as robust and forgiving as a word processor is for writers.
Recently, I presented to a skeptical engineering colleague a toolkit my group has been working on for about a year. The skeptic kept bringing up problems they previously had to solve, using a different system, and asked repeatedly how the new toolkit solved those problems. I answered, it doesn't. In frustration he said "then I don't see what this system buys us". I said "that's because the system isn't meant for you; it's for designers."
The toolkit isn't meant to solve problems for programmers; it is meant to let designers author solutions.
Engineers already have C++ and Visual Studio and other authoring and diagnosis tools. Designers don't have that.
Designers need more power.
The Pendulum of Power
At our studio, a ponderous pendulum oscillates between granting, then removing power.
We engineers tire of having to hand-tune or hard-code things.
So we make scripting languages and data-driven systems.
Then, artists and designers author bazillions of features...
...and break the game...
...over and over and over.
So we engineers decide we gave away too much power, and then we either cripple the system or author the data ourselves or go back to using C++.
And the cycle repeats.
How do we break the cycle?
Identify the problem, then solve it.
Problem: With great power comes great responsibility. If we grant authoring power, we must also grant the tools, and foster techniques, for how to wield that power responsibly and effectively.
Solution: Facilitate diagnostic and profiling techniques to accompany the authoring tools.
Our new toolkit includes the key ability to diagnose and profile:
Designers can view, at an instruction level, every single time a variable changes, going back in time. If a designer reaches some point in the game and notices something wrong -- maybe some score is too high -- they can literally rewind the simulation, find the moments in time when that score changed, find the precise machine instruction, evaluation stack and machine state when that occurred, what subexpression of what line of script that corresponds to.
In other words, something engineers have been able to do for decades.
It provides the best of breakpoints and printf debugging. No need to set breakpoints, and no guessing which variables to print, when. It provides everything; unprecedented quantities of information, carefully organized and displayed.
Our toolkit presents this information in a visually digestible format that requires relatively little specialize knowledge of arcana (but also provides excruciating detail for those brave designers who dare venture into the realm of virtual machine instructions).
Likewise, our testbed provides resource and performance profiling metrics, along with budgets and notices of overages.
(I wish I could show screenshots, or better yet, movies. It's a spectacle.)
Put all that together, along with rapid iteration tools like one-button-export-and-restart, and we systematically eradicate excuses for disowning bugs the author created.
Designers can author everything to arbitrary detail and they can diagnose everything in arbitrary detail.
Much as tools and techniques go together, so do authorship and diagnosis.
Without one, the other is useless at best, or dangerous at worst.
Together, authoring tools help create, and diagnosis techniques help execute, awesome recipes.
No comments:
Post a Comment