{"id":47821,"date":"2019-08-29T06:00:12","date_gmt":"2019-08-29T10:00:12","guid":{"rendered":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=47821"},"modified":"2019-08-29T13:57:37","modified_gmt":"2019-08-29T17:57:37","slug":"game-programming-vexations-part-1-five-years-later","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=47821","title":{"rendered":"Game Programming Vexations Part 1: Five Years Later"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

<\/p>\n

Jai<\/h3>\n

It’s been five years since I wrote about Jon Blow and his mad scheme to create a programming language for games<\/a>. 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.<\/span>, 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.<\/span>.<\/p>\n

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.<\/p>\n

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<\/span> these problems.<\/p>\n

This series was originally going to be about Jai, but:<\/p>\n

    \n
  1. The introduction kept growing and growing as I set out to explain WHY we need a programming language for games.<\/li>\n
  2. I found myself caught in many digressions filled with long pent-up gripes about C++.<\/li>\n
  3. Jai isn’t out yet. It might possibly see a limited-public demo of some sort in 2019, but it hasn’t happened yet.<\/li>\n<\/ol>\n

    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.<\/p>\n

    Domain is Everything<\/h3>\n

    I'm sure this dude is good at whatever it is he's doing, but I wouldn't ask him for advice on how to run a restaurant.<\/div>
    I'm sure this dude is good at whatever it is he's doing, but I wouldn't ask him for advice on how to run a restaurant.<\/div>
    \nAs 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!<\/i><\/p>\n

    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.<\/p>\n

    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<\/a>. 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.<\/p>\n

    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<\/a> to each other. The field is full of dogma and online discussions are a mess of peacocking<\/a>, condescension<\/a>, and arrogance<\/a>.<\/p>\n

    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.<\/span>. 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.<\/p>\n

    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<\/a>:<\/p>\n

    “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.”<\/p><\/blockquote>\n

    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.<\/p>\n

    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<\/b> of programmers they are.<\/p>\n

    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<\/i> 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.<\/p>\n

    What is a Game?<\/h3>\n

    <\/div>
    <\/div><\/p>\n

    Before we go any further I should make it clear that as far as this series is concerned, a “game” is a program which:<\/p>\n