It's not about technology for its own sake. It's about being able to implement your ideas.
I've spent most of my career working on games, either programming or designing them or both. Games are weird, because everything comes down to this nebulous thing called fun, and there's a complete disconnect between fun and most technical decisions:
Does choosing C++14 over C++11 mean the resulting game is more fun?
Does using a stricter type system mean the game is more fun?
Does using a more modern programming language mean the game is more fun?
Does favoring composition over inheritance mean the game is more fun?
Now you could claim that some of this tech would be more fun for the developer. That's a reasonable, maybe even important point, but there's still a hazy at best connection between this kind of "developer fun" and "player fun."
A better argument is that some technologies may result in the game being more stable and reliable. Those two terms should be a prerequisite to fun, and even though people struggle along--and have fun with--buggy games (e.g., Pokemon Go), I'm not going to argue against the importance of reliability. Think about all the glitchiness and clunkiness you experience every day, from spinning cursors, to Java tricking you into installing the Ask toolbar, to an app jumping into the foreground so you click on the wrong thing. Now re-watch The Martian and pretend all the computers in the movie work like your desktop PC. RIP Matt Damon.
The one thing that does directly make a game more fun is decreased iteration time. Interactive tweaking beats a batch compile and re-launch every time, and great ideas can come from on the fly experimentation. The productivity win, given the right tools, is 10x or more, and I can't emphasize this enough.
And yet this more rapid iteration, which is so important to me, does not seem to be of generally great importance. It's not something that comes up in computer sciencey discussions of development technologies. There's much focus on sophisticated, and slow, code optimization, but turnaround time is much more important in my work. A certain circle of programmers puts type systems above all else, yet in Bret Victor's inspirational Inventing on Principle talk from 2012, he never mentioned type systems, not once, but oh that interactivity.
I realize that we're heading toward the ultimate software engineer dream of making a type-checked change that's run through a proven-correct compiler that does machine-learning driven, whole program optimization...but it's going the exact opposite of the direction I want. It's not helping me in my quest for creating fun.
For the record, I just picked those buzzwords out of my mind. I'm not criticizing static type checking or any of those things, or even saying that they preclude interactive iteration (see Swift's playgrounds, for example). They might make things harder though, if they necessitate building a new executable of the entire game for every little change.
Interactivity, I may have to grudgingly accept, is not trendy in computer science circles.
(If you liked this, you might enjoy You Don't Read Code, You Explore It.)
permalink July 26, 2016
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?