You’ve probably heard of Jon Blow. He’s the designer of Braid and The Witness, and one of the first of the new-wave indie auteurs that began this whole indie craze a few years ago. Back in September he posted a two-hour video where he talked about the need for a new programming language designed specifically for games. He’s certainly not the first to notice this need, and I’m sure he won’t be the last, but I’m bringing this up because he’s yet another important voice pointing out the awful situation our industry is in.
All AAA games are written in the programming language called C, or its descendant C++. (Or nearly all. If there are any exceptions to this rule, I can’t think of them.) Yes, other languages are sometimes a part of game development. Minecraft is written in Java, and lots of AAA games use various scripting languages on top of C. But the C language is still the cornerstone of AAA game development.
(For the rest of this article I’m not going to bother making a distinction between C and C++. Most games are actually written in C++. The difference is pretty important to programmers, but those differences don’t matter to the average non-coder. Broadly, C++ is a newer, hipper version of C. And by “newer” I mean it came out in 1983.)
We use C to make our games, our game development tools, the graphics drivers, and even the operating systems that run the games. To understand how strange this is, we need to look at what C is and what is was designed for.
In this discussion, there are two broad areas of programming: Applications programming, and systems programming. Applications is making software for you to use directly: Games, word processors, web browsers, MP3 players, digital delivery clients like Steam or Origin, and basically anything else you launch on your computer by clicking on an icon. Systems programming involves writing the software to support all of that stuff: Your operating system, your device drivers, and that sort of thing. If you’ve ever opened up task manager in Windows and looked at the long list of crap that’s always running, most of that stuff qualifies as “systems”. It only exists to make the application stuff go.
C was designed to be a systems programming language. It was supposed to be a language for writing stuff like operating systems. It was devised in a world before personal computers. It was made in the age of Big Iron, and in a time where computers had a million times less memory than they do today. There are lots of fussy details in the language designed to save a few bytes of memory that, in today’s world, simply do not matter.
It was created in a world where software was less complex than it is today. Your typical AAA game of 2014 will be thousands of times more complex than entire operating systems of 1972. Consequently, the language is focused on saving memory and CPU cycles, and not focused on helping the coder manage terrifying levels of program complexity. John Carmack has said in the past that modern graphics programming is more complex than rocket science. And to be clear, he might be the only person on earth who has done both professionally.
By using C, developers are making programs that are more complex, harder to manage, more likely to have bugs, and take longer to write, and in return they’re saving CPU cycles and memory which are now relatively plentiful.
The language was invented for a completely different kind of computer, in a different time, for a different purpose. So how did we end up building an entire industry of complex entertainment software on top of a language designed for writing operating systems in 1972? The obvious answer is the same problem that afflicts a lot of other areas of technology: Legacy infrastructure. People use C because people know C. People study C because all the jobs use C. And the jobs use C because that’s what everyone knows. It’s a self-perpetuating cycle. Moving to a new language would mean giving up the various graphics engines, AI systems, interface tools, and coding tricks we’ve built up and starting over with a clean slate. It would mean trading in your experienced veterans for fumbling newbies (even if you’re still using the same people) and having those newbies re-write your large expensive C libraries.
More pressingly, a newer language would likely be a little slower. The whole point of using a language like C is that it’s pretty raw and close to the hardware. While your typical word processor or MP3 player isn’t going to push your computer to the limit, the recent controversy surrounding games that can’t maintain 60FPS or can’t reach 1080p can attest that speed is still very much a big deal in videogames. Indies are free to dabble in other languages (and indeed, a lot of them do) but if you’re making a big-name AAA game targeted at modern consoles, then you still need to worry about every processor cycle.
Part of the problem is that only parts of our games need to be designed with an eye towards efficiency, and other parts of it don’t. The graphics, character animation, AI, and physics systems have a voracious appetite for CPU cycles and will eat all the power we throw at them. On the other hand there’s a lot of other mundane crap that is complex to design but isn’t nearly as demanding, performance-wise. Stuff like the interface, game logic, networking, and processing of player input. That stuff can take up a lot of lines of code and a lot of hours of programmer time, but it doesn’t need to be written in something hardcore like C. It would be easier to write in dozens of other languages and the performance impact would be negligible.
There have been a lot of efforts to tackle this two-path nature of game development. For years Unreal Engine had UnrealScript, a lighter-weight language designed to handle the game logic while the underlying engine did all the heavy lifting. Other approaches have been tried, but there hasn’t been a silver bullet answer yet.
Which means most developers are still painstakingly building large ambitious games on top of this ancient programming language.
The console wars aren’t helping. Sony, Microsoft, and Nintendo are each in charge of the development tools for their respective gaming platforms. If any of them invented a really great language or system to solve this problem, they would make it exclusive to their platform. If one of their rivals created one and offered to share, they’d refuse because they wouldn’t want any part of their console development to be controlled by the competition. This means that any innovation needs to come from outside of the big three. But nobody else has the kind of clout it takes to introduce a new language and make it popular enough that the big three would want to adopt it. It could happen, but a process like that could take years. It would require one language or idea to gain such a massive mindshare that at least one or two of the the big three would feel obligated to adopt it.
Will Jon Blow invent that language? Statistically, I wouldn’t bet on it. Innovation is a risky uphill battle and even fantastic new ideas can often lose against entrenched bad ones. I liked what he had to say in his presentation and he echoed a lot of my own frustrations with C, but I’ve never written a compiler and I don’t feel qualified to judge his language proposals from a technical standpoint. Language authoring is tricky business.
At the same time, I’m really cheering for him and his efforts. Assaulting the status quo is hard work and just keeping the conversation going is a valuable thing.
Shamus Young has been writing programs for over 30 years, from the early days of BASIC programming in the 80s to writing graphics and tech prototypes today. Have a question about games programming for Shamus? Ask him! Email [email protected] and your question might appear in a future Experienced Points column.
