{"id":47906,"date":"2019-09-05T06:00:16","date_gmt":"2019-09-05T10:00:16","guid":{"rendered":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=47906"},"modified":"2019-09-05T07:41:29","modified_gmt":"2019-09-05T11:41:29","slug":"jai-part-2-the-four-challenges-of-game-development","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=47906","title":{"rendered":"Game Programming Vexations Part 2: The Four Challenges of Game Development"},"content":{"rendered":"

So why do we need a new language for games? Isn’t the world full of languages at this point? Is it really true that in all the dozens of active languages out there, none of them is suitable for making video games?<\/p>\n

A year ago Blow gave a talk<\/a> where he said he didn’t want to use any of the extant languages because they contribute to an ongoing “general insanity” going on in software development. It’s a long and multi-faceted argument, but if I had to boil it down to a soundbite I’d say that there’s a general desire to hide the hardware away behind abstractions and this is making our software slow.<\/p>\n

I’m not qualified to support or refute that argument, so if you think Blow is wrong then you’ll have to take it up with him. I’m going to come at the argument from a different angle…<\/p>\n

<\/p>\n

Invading Another Language<\/h3>\n

Nice language you've got here. We've just got ten thousand teeny tiny little requests before we switch to it.<\/div>
Nice language you've got here. We've just got ten thousand teeny tiny little requests before we switch to it.<\/div><\/p>\n

Personally, it seems like it would be a bad idea to co-opt the likes of Go, Rust, or D for game development. If you look, you can see these languages are “nearly<\/a>” ready for game development. To date, nobody has shipped a seriousReminder: By “serious” I mean a proper 3D simulation and not something programmatically trivial like a side-scroller.<\/span> game in any of these languagesWe do have commercial 3D games made with Unity, and thus C#. But for the most part I think everyone gets why C# isn’t a viable alternative for AAA game development.<\/span>. Which means the tools aren’t there. Which means the main adherents of these languages are not game developers. At the same time, there must be a reason that game developers haven’t already embraced these languages. We have to allow for the possibility that these alternate languages are missing some features that game developers are likely to need.<\/p>\n

Switching over to an extant language and changing it to suit the needs of game development would be significantly more controversial than just starting your own language. Maybe the C++ refugees would be welcomed with open arms at first, but as soon as they began demanding changes or complaining about limitations it would cause rifts. Maybe the language would be forked, or maybe a bunch of features would be added that existing users don’t like or need. Or maybe the incoming game developers would need to cajole and plead for every feature. If the only C++ refugee was Jon Blow all by his lonesome, the community would probably tell him to go make his own damn language if this one doesn’t suit him.<\/p>\n

Shamus, what are you talking about? What are these special features game developers supposedly need? A general programming language is suitable for general tasks, and that includes games! What is it you think you’ll need?<\/strong><\/p>\n

I’ll come back to this question later in the series. For now just humor me.<\/p>\n

I realize I have to be really careful here, because suggesting that language X isn’t suitable to a given task will quickly rally all the supporters of X against you. Everyone will feel the need to defend the honor of their favorite language. They will gather to inform you that actually, X is FANTASTIC and you’re just bad at using it and maybe you should do some research before running your mouth. If you claim that NO extant language is suitable, then you’ll find yourself at war with the adherents of every language simultaneously.<\/p>\n

This really does put the game developer in a “damned if you do, damned if you don’t, and damned if you compromise” type situation. If you ask for language features to suit the problem you’re trying to solve, then people will just accuse you of being ignorant or entitled. If you go off to make your own language, people will accuse you of being a naive fool. If you stick with what you’ve got, then people will accuse you of being stuck in the past. Your only escape is to pick a language, pay the high cost of transitioning, and then fall in line behind the faithful.<\/p>\n

INT – Video Game Industry – Day<\/p>\n

Game Developer: Man, this job is a drag. I wish there was an alternative to C++.<\/p>\n

Foo Evangelist: You should try the Foo language! It’s amazing.<\/p>\n

Game Developer: I don’t think this new Foo language will do what I need.<\/p>\n

Foo Apologist: You can’t criticize Foo! You don’t know anything about it.<\/p>\n

Game Developer: Okay, I’ve just spent half a year learning the language, adapting libraries, and attempting to build a game. Foo really doesn’t have feature X, and I need it.<\/p>\n

Foo Grognard: X is a stupid feature. I’ve been making web and mobile apps for a decade and I’ve never needed anything<\/b> like that. We don’t need to clutter up the language with obscure features for lazy game developers. Go use C++ if you want those kinds of weird-ass features.<\/div>\n

Rather than try to convince you that alternative languages are insufficient, I’m going to try to sell you on the more general idea that – all other things being equal – a language devised specifically for games would be better than any of those other choices.<\/p>\n

With that in mind, I want to talk about what I think are the four main challenges of games programming:<\/p>\n

1. State Transformation<\/h3>\n

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

All programs change the state of the machine. As a result of running the program and entering input, internal variables change, new data is written to disk, the contents of the screen are changed, and data is broadcast over the network where it will cause further state changes on other machines. If there was a program that didn’t cause state changes, then there would be no point in running it because it would, by definition, do nothing. However, I think games really do face some unique problems with regard to the frequency, intensity, and variety of the state changes. Not only do games change a lot of state very quickly, but the types of transformations and the causes of those transformations are incredibly complex.<\/p>\n

In a game you can have situations where the player shoots a gun that fires a bullet that hits a barrel that triggers an explosion that generates a physics event that knocks over a physics object that lands on a mook and kills them, which results in spawning loot that lands within the player’s pickup radius and is added to their inventory. A single input action caused a state change for seven different objects spanning multiple gameplay systems.<\/p>\n

Even worse, it’s not a linear chain reaction like the previous paragraph suggested. The state changes actually branch outward as they cascade through the system. The explosion also spawned a particle emitter, which will in turn spawn particles. The death of the mook will lead to a new mook being spawned sometime in the next few seconds, somewhere nearby. Shooting the gun creates sound effects, creates more particles, and updates the state of the gun itself to deal with the reduced ammo count and kick. Information on the player’s HUD is changed. Damage floaties will spawn at the location of the mook’s former head. Other AI actors in the area will change behavior. The player earns experience. The physics event shoves a bunch of small objects around, which creates even more particles as the debris kick up dust. That single pull of the trigger expands outward, touching countless gameplay systems and eventually altering many megabytes of memory.<\/p>\n

Not only are the changes myriad and complex, the causes for those changes are also complex. State changes in response to player input, AI behavior, the rules of the simulation, and information coming over the network. This is one of the reasons AAA game devs shy away fromOr openly despise and denounce.<\/span> strict Object Oriented Programming. OOP encourages you to wall off all of your different objects. A bank transaction should not be able to change the name of the customer, and so on.<\/p>\n

Pictured: Some state transformation.<\/div>
Pictured: Some state transformation.<\/div><\/p>\n

But in a game where all of the different systems are tightly connected and interact in complex ways, you can’t treat each system like a black box and consider it in isolation.<\/p>\n

In strict OOP, systems that interfere with the ideal of encapsulationSealing one chunk of code off from other systems.<\/span> are referred to as cross-cutting concerns<\/a>. The problem is that modern game design pushes us towards situations where nearly everything<\/b> is a cross-cutting concern.<\/p>\n

In a game, that dumpster is actually 3 different conceptual systems: There’s the model that needs to be rendered, there’s the collision hull that makes it run into things, and there’s the physics object that gets knocked around (and knocks other things around) once the shooting starts. All three of these things are very different, they’re used at different times and in different places by different systems, and they need to be packed in memory with similar objects for efficient processing. If your collision hulls are mixed in with other types of game objects in a big generic list of random crap, then doing batch operations on those objects will be expensive.<\/p>\n

Somewhere in the chaos, you look at the data and notice that the mook’s body is a million meters outside of the bounds of the gameworld and you have no idea where to look to find the cause of the problem. Literally any of these systems might have caused a change or a side-effect that altered the position of the mook in ways you can’t think of just now. Debugging becomes very difficult. Bugs are hard to reproduce and harder still to track down.<\/p>\n

Here's another picture of state transformation in action.<\/div>
Here's another picture of state transformation in action.<\/div><\/p>\n

Yes, other programming domains have lots of state change. In accounting a single transaction will take some money from one account, add it to another account, and record the transactions in many different places. I’ll bet the error-checking and handshaking between financial computing systems is monstrously fussy and it always has to contend with the Two Generals Problem<\/a>. There’s a lot of state change, but it follows fairly predictable lines. Every state change is an explicit part of the spec. You’re not going to have a weird edge-case deposit that changes the customer’s first name, issues a new credit card to everyone over 18, and modifies the street address of the bank.<\/p>\n

In gaming, having emergent state change is considered a bonus. “Oh look. I broke this wall which released water which put out a fire, even though that wasn’t a specifically coded or scripted event. Cool!” In just about any other domain, non-spec interactions are a serious bug!<\/p>\n

Mass state change is almost a design imperative in the world of games. Designers are always pushing for more complexity, more interactivity between systems, and more reaction to player input. We want fires to burn things, flowing water to displace things, light to illuminate things, wind to shove things, and explosions to destroy things. Characters should push foliage out of the way, leave footprints, trigger sound effects, make sounds, stir up dust, interact with objects in the environment like chairs and doors, and exert force on physics objects. As we work toward making our simulations more interesting, we make them increasingly interconnected and unwieldy. This makes it challenging to keep the program running fast. It also makes bugs more likely, and makes them harder to find when they show up.<\/p>\n

2. Performance Always Matters<\/h3>\n

*nonsensical engine-revving noises*<\/div>
*nonsensical engine-revving noises*<\/div><\/p>\n

Video games are not the only domain where performance matters, but games are rather unique in the sheer complexity of their performance needs.<\/p>\n

Sure, every programmer wants their code to run fast, but in games the user will experience performance fluctuations in realtime. They can both see and feel dropped frames. That 16ms stutter will be infuriating and uncomfortable to a gamer trying to line up a headshot, while (say) a video editor will just accept the occasional stutter as part of the job. A Pixar-style render farm needs speed, but if there’s an optimization that occasionally stalls all rendering for half a second in order to speed up the overall job, then that’s totally acceptable in the world of offlineIn this context, “offline rendering” just means “not realtime”. Like, you start the render process and then go have lunch.<\/span> rendering. Photoshop needs to run its filters as fast as possible, but the vast majority of the time has the program sitting idle and waiting for user input. It’s completely acceptable for the interface to momentarily stutterOr even go unresponsive for multiple consecutive seconds!<\/span> when the user applies a complex filter to a large image. But games don’t just need to be fast, they need to be consistently<\/b> fast. They need to be fast across multiple types of processors running vastly different simulations. Productivity software can get away with exhibiting mildly annoying interface hiccups that would be called egregious and unplayable in a video game.<\/p>\n

Remember that I’m not saying that games programming is harder or that game programmers have it tougher. Other fields have their challenges, but not many of them have this particular<\/b> challenge where performance needs to be both high and<\/strong> uniform. I’m not saying mountain climbing is harder than cross-country skiing, I’m saying mountain climbers will have problems that skiers don’t. Skiers probably have their own unique problems. If so, they’re free to come up with their own programming language to deal with them.<\/p>\n

I think I lost the plot on that last analogy. Whatever. You get the idea.<\/p>\n

There aren't enough rendering resources to go around, so I decided to MAKE MORE RESOURCES.<\/div>
There aren't enough rendering resources to go around, so I decided to MAKE MORE RESOURCES.<\/div><\/p>\n

This problem isn’t going to go away. If you put on the infinity gauntlet and snapped your fingers to make every processor ten times faster, game designers would instantly find a use for all of that power and we’d once again be up against performance limits. We already have technologies sitting around, waiting until we have enough spare power to support them:<\/p>\n