My programming posts are always popular, which is strange because it seems like they shouldn’t work at all. I don’t know where I got the idea to write about the fussy details of programming in casual, non-technical terms. It seems like non-programmers would be bored by all the stuff that has no bearing on their lives, and programmers would be irritated by all the entry-level explanations for things they already understand. But for whatever reason, both kinds of people show up for these articles.
Whichever group you belong to, buckle up. I expect some of this to get pretty controversial by the standards of programming flame wars, and I think I’m going to need to be more technical than usual.
It’s been five years since I wrote about Jon Blow and his mad scheme to create a programming language for games. At the time, I half-expected that this would be the last we heard about the idea. Not because I don’t have any faith in Blow specifically, but because the internet is awash in grandiose projects meant to solve herculean challenges, and the vast majority of those projects never make it out of the design phase. It’s easy to explain why something is a problemThat’s pretty much what I do here., and it’s not that hard to make suggestions, but it’s murderously difficult to solve those problems with code. In the programming world, talk is cheap and working solutions are hard to implementActually, I hear this holds true outside of programming as well..
Making a new programming language is like getting a puppy. It seems like a lot of fun, but it also turns out to be a lot of responsibility. You can daydream about all the magic features you’d love to have in a language and how cool your syntax will be. But eventually the novelty wears off and you realize you’re now obligated to take care of something that no longer delights you. The fun goes away and the work doesn’t, which is when the daydreaming programmer will fall in love with a new idea and abandon the old one. Statistically, betting against new languages is the safe thing to do.
Despite my pessimism, Blow has made some amazing progress over the last five years. He’s building the language, while also using the language to build a game. This series is going to look first at what problems we have in game development, and – later when I have a chance to try it – what Jai does to addressor fall short of addressing these problems.
This series was originally going to be about Jai, but:
- The introduction kept growing and growing as I set out to explain WHY we need a programming language for games.
- I found myself caught in many digressions filled with long pent-up gripes about C++.
- Jai isn’t out yet. It might possibly see a limited-public demo of some sort in 2019, but it hasn’t happened yet.
So instead this series is about the vexations of games programming, with the understanding that maybe in some distant future I’ll write a series about Jai and see how well it addresses these concerns.
Domain is Everything
As soon as game developers start talking about climbing over the wall around C++ and running off to find a new language, people start evangelizing their favorite languages. X does everything you need for game programming! Y is the best language for all projects! Z meets all the criteria you’ve listed!
Without fail, the people giving this advice have never shipped a game and in fact aren’t game developers at all. They’re usually coming from some other field.
I don’t know what the deal is with this particular discipline, but everyone presumes to know everyone else’s business. I don’t imagine most auto mechanics would casually attempt to tell an airline mechanic how to maintain a turbine. I don’t think the airline mechanic would tell a structural engineer how to construct a tuned mass damper. I would hope the structural engineer wouldn’t go around lecturing NASA engineers about how to construct launch vehicles. We understand that even though all of these professions involve engineering and using tools on machines to some degree, they’re all highly specialized fields with very limited overlap.
Two coders might use different languages to solve different kinds of problems using different hardware at different scales, but they’re not shy about advocating languages and coding practices to each other. The field is full of dogma and online discussions are a mess of peacocking, condescension, and arrogance.
Maybe we tend to treat all programming disciplines the same because they look so similar. You can tell an auto mechanic from a carpenter with a glanceAssuming they’re working, obviously.. But coders working in web development, video games, embedded systems, machine learning, and driver maintenance are all superficially the same. They all sit in chairs and type code on a computer. Maybe this tricks us into thinking these people are all doing the same job.
Some programming projects don’t care about performance as much as code clarity. Others are optimized for a low memory footprint. Others are worried about maintaining code for decades. Others have to sacrifice development time to safeguard against the possibility of errors. As John Carmack once said:
“Now, a great deal of stuff that goes on in the aerospace industry should not be emulated by anyone, and is often self destructive. Most of you have probably read various popular articles about the development process that produces the space shuttle software, and while some people might think that the world would be better if all software developers were that “careful”, the truth is that we would be decades behind where we are now, with no PC’s and no public internet if everything was developed at that snail’s pace.”
Different problems have different solutions, and programmers outside of gaming are often trying to explain to us that their hammers are excellent tools for driving our gaming screws. And to be fair, I’m sure game developers are just as eager to find a non-gamedev programmer and lecture them about how gaming’s screwdrivers are the perfect tool for digging their trenches.
I don’t know. Maybe I’m wrong and auto mechanics really do lecture HVAC engineers about how to maintain their hardware, and I just don’t see it because I don’t hang out in those circles. Still, it seems like engineers who operate on physical hardware are more likely to identify their domain during a discussion, while programmers are more likely to get in arguments without any of them ever making clear what kind of programmers they are.
Domain experience is everything. Game development and systems programming have about as much in common as plumbing and VCR repair. While we’re having this discussion on languages and programming methods, I’d encourage everyone to keep the issue of domain experience in mind. Maybe all developers in domain X are dum-dums for not using your awesome language / tool, or maaaaaaybe there are a bunch of details to X that you don’t know about. Maybe the language / tool that you think is dumb and broken is actually designed for a completely different job than the one you’re doing.
What is a Game?
Before we go any further I should make it clear that as far as this series is concerned, a “game” is a program which:
- Runs in realtime.
- Is interactive.
- Renders some sort of 3D sceneEven if the gameplay itself is 2D..
- Is targeted at modern gaming hardware like PCs and consoles.
For this series, when we talk about games we are not talking about text-based games like Hammurabi. We’re not talking about strictly narrative experiences like The Writer Will do Something. We’re not talking about classics like the original Myst or King’s Quest.
This is obviously a very narrow definition. It excludes a lot of simple 2D sidescrollers but might include some non-gaming simulations as well as 3D modeling programs like Blender. I’m not trying to change the definition of game on you, and I’m not trying to claim that Peggle and Cooking Mama aren’t games. I’m not using this definition to be a gatekeeping jackass. I fully admit these experiences are actually games and they have just as much artistic merit as anything else with the label “video game” slapped on it.
I’m excluding these things because – from the standpoint of a modern game developer – they’re fairly trivial programming problems and won’t benefit from any of the language stuff I’m going to be talking about. I’m just trying to avoid saying “realtime interactive 3D software for PCs or consoles” every time I’m talking about the challenges of AAA game development. If I make a claim like, “All games need to worry about framerate”, remember that I’m talking about a game with polygons and moving images. I don’t want to get dragged into pedantic arguments over Zork et al.
When programmers wish for a better tool for doing game development, they’re usually working in the AAA space and wishing for a way to escape C++. This is not really a problem for bedroom programmers working on small-scope projects in Unity. The small teams have lots of languages and tools to choose from, and they’re usually worried more about money and less about pushing the hardware to the limits. So for the rest of this series, I’m going to assume that any language intended to displace C++ must therefore be useful to projects on the AAA scale. I’m not promising that Jai will do that, or even that Jon Blow has made that promiseAlthough it is apparently one of his goals.. I’m just saying I think that’s what a challenger language would need to do.
We all have challenges to deal with and things that make our particular domain difficult, and I get that claiming that no existing tool is “good enough” for your domain smacks of arrogance. Everyone will think you’re bragging about how hard your job is, which carries the implied insult that everyone else has it easier. Other programmers will not let this sort of claim go unchallenged.
(For the record, I’m not saying game development is more difficult than other domains, I’m just saying its difficulty takes a different form.)
Hopefully I’ve placated you enough and you’re at least willing to entertain the notion that games programming has challenges you don’t seeOr that are present to a lesser degree. in other kinds of programming. Over the next 12-ish entries, I’m going to talk about some of the major problems that I hope Jai will address.
 That’s pretty much what I do here.
 Actually, I hear this holds true outside of programming as well.
 or fall short of addressing
 Assuming they’re working, obviously.
 Even if the gameplay itself is 2D.
 Although it is apparently one of his goals.
 Or that are present to a lesser degree.
The Best of 2015
My picks for what was important, awesome, or worth talking about in 2015.
Diablo III Retrospective
We were so upset by the server problems and real money auction that we overlooked just how terrible everything else is.
Could Have Been Great
Here are four games that could have been much better with just a little more work.
Silent Hill 2 Plot Analysis
A long-form analysis on one of the greatest horror games ever made.
Secret of Good Secrets
Sometimes in-game secrets are fun and sometimes they're lame. Here's why.