Whenever people get talking about the things you need in a game development language, we usually end up with a handful of features like manual memory management, pointers, low-level code, the lack of safety features like bounds-checking, and so on. One of the big items on this list is the ability to use external libraries.
Being able to use libraries is indeed a good thing. I certainly wouldn’t want to attempt to use C++ without access to a good set of libraries! At the same time, I think we often overlook the fact that importing and integrating external libraries is enormously expensive. A game developer will complain that they don’t want to have to roll their own sound library and someone will dismiss them saying, “Bah. There are lots of free sound libraries out there. Just pick one and start coding!”
While it’s true that there are free libraries all over the place, people are really bad at factoring in the cost of using them.
The Utility Belt
In gamedev, a vector is a variable that stores 3 values: X, Y, and Z. These are used constantly. Every 3D object in the scene is made up of triangles, every triangle is made of 3 points, and every point has a vector to keep track of its position in 3D space. The player’s velocity as they double-jump over lava is stored in a vector. The imaginary line from (the muzzle of the protagonist’s gun) to (the point where the player is aiming) is stored in a vector. Things like mouse and joystick input are often stored in a vectorSometimes the engine you’re working with has 2D vectors for this, but if not the programmer might store the input values in X and Y and leave Z unused.. The position of the camera is a vector and the direction the camera is pointing is another vector. Every light in the scene uses a vector to store its position, and directional lightsLike a flashlight or a searchlight. will use another vector to keep track of which way the light is pointed.
Nearly every system in a game either contains or manipulates vectors. Sounds come from a location, so they need a vector. Physics involves spatial calculations, so physics objects definitely need vectors. Loading geometry like characters and level data will need vectors. So will particles. Animations. Rendering code. Collision detection. Camera placement. Lighting.
Even if you’re just making a 2D side-scroller, you still need 3D vectors. You need 2 dimensions for the left-right and up-down movement within the game, but you’ll use the Z axis for depth, which you’ll need if you want a parallaxingThe background scrolls slower than the foreground to give the scene a feeling of depth. background. Even if your game is played on a pure 2D plane with no attempt to create the illusion of depth, you’ll still need some vectors for manipulating the camera because the graphics hardware communicates in vectors and you need that thing to draw the scene.
The thing about vectors is that they don’t come with the language. Without a vector data type to handle these values, you’d be forced to juggle the individual X, Y, and Z components:
player_position_x += offset_x; player_position_y += offset_y; player_position_z += offset_z; distance_to_origin = sqrt (player_position_x * player_position_x + player_position_y * player_position_y + player_position_z * player_position_z);
That’s a lot more verbose and error-prone than this:
player_position += offset; distance_to_origin = player_position.Length ();
That’s a trivial example. The problem gets completely out of control once you start doing real work. I don’t want to say that nobody has ever made a game without vector data types, but I feel confident in saying that doing so would be extremely cumbersome. Everyone making games has to write or import their own vectors. You can’t begin working on a project until you have these.
If you’re going to have vectors, then you’ll also need to be able to manipulate them. You need to be able to add them, subtract them, measure their length, compare them to each other, scale them, copy them, reflect them off each other, and a host of other things.
In addition to vectors, a proper game development environment ought to have a bunch of other stuff. Here are several, in order of descending need from “you can’t do anything useful without this” to “it would be nice to have this”.
- 3D Vectors. Every game above trivial complexity will need these.
- Matrices. A Matrix is a grid of numbers used to manipulate vectors. Let’s say you’ve got the zombie model in Minecraft. By default it will be positioned at 0N, 0W, at the bottom of the world. But perhaps for gameplay purposes it needs to be at 150N, 2503W, 64 meters above the bottom of the world. That location would of course be stored in a vector. Let’s say also that the zombie model needs to be turned sidewaysMaybe the player just killed it.. The programmer would then set up a transformation matrix. Multiply all the vertices in the zombie by this matrix, and it will be moved to the desired location.So we need a bunch of code to create a matrix, move it, rotate it, compare it to others, and use it to transform vectors.
- Color values. When you talk to the graphics card, it often wants to know what color things are. Sometimes you need to know the color values of individual pixels or polygons. It’s really nice to have a variable with red, green, blue, and alphaUsed for transparency. color values that can be easily stored, compared, and manipulated. Actually, we should probably have two different types of color values. One which stores color channels as real numbers between 0.0 and 1.0, and another that stores each channel as a whole number in the range of 0 to 255. The former is useful for manipulating color values mathematically, while the latter is how you need to store the color values to be used in texture maps.
- Bounding Boxes. These cubic volumes are handy for figuring out what needs to be drawn or if you should bother doing expensive collision checking on two objects. A bounding sphere isn’t quite as common, but still nice to have.
- Quaternions. A 4-dimensional variable for performing various feats of dark sorcery. Don’t ask.
- 2D Vectors. Sometimes you just need an X and Y value. Good for mouse movement, joysticks, map positions, positioning HUD elements on the screen, and lots of other random stuff.
- Textures. Nearly all games deal with texture maps. Texture maps are made up of those color values I mentioned above. It can be really useful to have a specialized container for holding texture data.
- Triangle groups. Triangles are defined by three numbers, each number referring to a specific vertex, allowing your graphics card to draw the triangle by playing connect-the-dots. It’s often convenient to have some sort of container for storing these lists of numbers.
- Integer Vectors: This is like a vector above, except it can only store whole numbers. Really useful for passing over multidimensional arrays and doing stuff with grids. And game designers LOVE grids.
Basically, every game needs vectors and their attendant types. For convenience, let’s refer to this collection of types as the gamedev’s Utility Belt. Batman carries around shark repellant, and game developers carry around vectors and matricesSee? I told you that Batman image would make sense later.. If every single game needs them, then why not make them part of the language?
At this point someone will suggest we just take an existing languageBy some strange coincidence, it always ends up being their favorite. and add the Utility Belt to it through a library. That’s how we’ve been doing things for decades.
Vexation #3: Shopping for Libraries is Not Programming
Libraries are fantastic. One programmer comes up with a solution to a problem. Maybe they make a physics engine, a particle engine, an audio engine, or whatever. They offer this code as a library that you can drop into your project so you don’t need to implement all that stuff yourself.
That’s the platonic ideal, anyway. What actually ends up happening is that someone releases a library, but their code uses some dated language features. The documentation is poor. Importing a library is rarely a drag and drop operation, and sometimes you might need to burn an entire day of productivity just getting it to compile with the rest of your project and figuring out how it works. And then once you finally get it working, you discover it doesn’t really solve your problem. Maybe it’s too slow, or missing a key feature. It probably has tons of code dedicated to doing stuff you don’t want or need. Is that unwanted code being executed? Should you modify this library to suit your project, or should you go back to Google and look for another? It’s going to take you several more hours of work to answer that question.
I’m not saying libraries are useless or that we shouldn’t use them. I’m just saying that library integration is difficult and time-consuming. The more libraries you have, the greater the odds that you’ll run into conflicts between them.
I think the cost of library integration is vastly underestimated in the field. Everyone has lost a day and a half to a library that turned out to be useless, and the typical response is to assume you just got unlucky. Well, that library was a bust, but things would have turned out differently if I’d tried a different one! And maybe that’s true, but part of the cost of importing a library is finding a library. The more libraries you need and the more you need those different libraries to exchange information, the more difficult it gets.
Nothing is Turnkey
So if all games need the Utility Belt, then do we really want to force every single developer to shop around for libraries to get this feature?
But Shamus! This Utility Belt isn’t THAT big a deal. You can write your own version in a couple of days and importing one shouldn’t cause conflicts. You’re being a big baby!
The problem is that if the Utility Belt isn’t part of the language, then everyone will be faced with this same problem, including people making libraries.
Let’s say that we’re very lucky and we find ourselves in a universe where there are only two competing Utility Belt libraries. DasVektor is a robust and full-featured library and it still gets regular updates. On the other hand, the DasVektor documentation pages (and even some of the classes) are in German. Even if reading German isn’t a problem, the docs are a bit of a patchwork and bits of them are way out of date. So DasVektor doesn’t get a lot of use. There’s also VectorBox, which is missing some features and hasn’t been updated in five years. On the other hand, the documentation is really good and it’s all in English.
At this point you’re probably nodding your head. “Yes Shamus. This is not news. Everyone knows about the problems of competing standards. This is going to be a problem no matter what language you use.”
Except, that problem feeds into the difficulty with libraries. Let’s say I make my project and I choose VectorBox as my Utility Belt. I import that. No problem. Great.
But now I need a library for doing positional audio. That requires the use of vectors. Since the language itself doesn’t provide them, the person who wrote this sound library had to make their own. So now my program has two different kinds of vectors. They work in similar ways and do roughly the same things, but they’re just different enough to be incompatible.
Then we have this physics library. It uses DasVektor for its vectors. So now I’ve got both DasVektor and VectorBox in my project. The standards war isn’t taking place on forum threads out in the wild, it’s taking place inside my project.
Next I import a particle library. Particles need vectors, which means this library will also come prepackaged with yet another vector solution. As it turns out, this one is based on an older version of DasVektor that’s not really compatible with the newer version. Do I search for another library, or attempt to update this one?
Shamus, you’re thinking about this all wrong. What you’re looking for isn’t a language, it’s a game engine. Go download Unreal Engine or Unity and it already has all the Utility Belt crap you’re looking for, along with all the other stuff for audio, particles, physics, AI, and so on. You don’t implement game engines at the language level!
I’d argue that the language ought to support types that are common to all problems in its intended domain. If someone made a language specifically for generating web pagesPHP is one such language. that doesn’t include a variable for dealing with text strings, then the language isn’t doing its job. Sure, it’s not that hardAssuming you’re just using English ASCII text. If you decide to do things the Right Way™ and have your strings to support Unicode, then you are basically doomed. That project will be monumentally bigger than whatever silly web page problem you’re supposedly working on.. to make your own data type for manipulating strings of text. But if it’s not part of the language then every single programmer will need to do that. Aside from the problems of integration I discussed above, this results in a tremendous duplication of effort.
There is no such thing as a game that doesn’t need vectors. It seems really unreasonable to require an entire game engine just to get access to basic data types, but next week I’m going to explore this idea and talk about the problems of using game engines to turn C++ into a language for games.
 Sometimes the engine you’re working with has 2D vectors for this, but if not the programmer might store the input values in X and Y and leave Z unused.
 Like a flashlight or a searchlight.
 The background scrolls slower than the foreground to give the scene a feeling of depth.
 Maybe the player just killed it.
 Used for transparency.
 See? I told you that Batman image would make sense later.
 By some strange coincidence, it always ends up being their favorite.
 PHP is one such language.
 Assuming you’re just using English ASCII text. If you decide to do things the Right Way™ and have your strings to support Unicode, then you are basically doomed. That project will be monumentally bigger than whatever silly web page problem you’re supposedly working on.
Game at the Bottom
Why spend millions on visuals that are just a distraction from the REAL game of hotbar-watching?
Dead or Alive 5 Last Round
I'm not surprised a fighting game has an absurd story. I just can't figure out why they bothered with the story at all.
Stop Asking Me to Play Dark Souls!
An unhinged rant where I maybe slightly over-reacted to the water torture of Souls evangelism.
In Defense of Crunch
Crunch-mode game development isn't good, but sometimes it happens for good reasons.
The Dumbest Cutscene
This is it. This is the dumbest cutscene ever created for a AAA game. It's so bad it's simultaneously hilarious and painful. This is "The Room" of video game cutscenes.