I understand that game developers type thousands of lines of code for a single game such as any version of a game anyone of us plays every day. How could their source code stored in many files of the game can be executed through a single application and I can play the game itself? What is their code’s journey to our PCs?
In: Technology
Explaining this fully in an easy to understand way is tricky, as games are fairly complex as far as going from 1’s and 0’s inside the computer to the game you see on screen. I’ll try instead to describe the sort of layered complexity (called ‘abstraction’) used when developing a game or any other program, as I think it helps develop an intuition for how things are put together.
So at the bottom level you have the machine hardware and the code that runs directly on it. This is in binary and how it works is hard-wired into the computer. The general idea is that you have numbers that represent some value (like memory addresses or literal numbers or whatever) and instructions. For example, in the old 8085 processors there’s an instruction called ADD C, which takes two numbers that are in the processor already and adds them together. It’s hard-wired into the processor so it happens when it sees the code 10000001. This is the first layer of abstraction. We can write down in human-readable language (called assembly code) the instruction ADD C. We can also write a program that converts that string of text into the computer code 10000001. For assembly language this is called an “assembler”, though for higher level languages we call such a thing a “compiler” or “interpreter” depending on exactly how it works.
Writing a game in assembly is tough (though it can and is done) because you’re dealing with a lot of very basic level stuff like manually moving around stuff in memory. So we can instead think of a language that deals with actual logic you might want describe. These are the high level languages like C++, Python, etc. This is the second layer of abstraction. We can do what we did before and devise a way of naming variables like “player_health” and then a compiler that turns that variable into a memory address in assembly code. So you write a line like “player_health = 100”, which makes a lot of sense to a human and the compiler then goes something like “LDL 100, STA (some memory address)” and that assembly gets turned into binary.
Often for making games we add another layer of abstraction: the engine. An engine is itself a program that has tons of built in code to help developers easily create the kinds of logic and objects used in games. It often has toolbars and graphical objects built into a window that allow the user to quickly create a bunch of reusable code. This code is generally in some higher level language like the ones I talked about in the above paragraph, which get turned into assembly, and hopefully you get the idea of what’s going on here. At the level of the engine this stuff gets pretty intuitive for people. Some engines you can just drag an object onto a screen and fill out a name for it and some basic properties you want it to have and the engine does a huge chunk of the coding for you. When coding it’s similar. You’ll often see code like “new player node_3D {a list of properties here}” which is code that the engine uses to create a new player object with the list of properties inside of the {}. If you’d like to see how people do this, you can look up a tutorial video on Youtube for popular engines like Unity, Unreal, or Godot and just watch someone create a basic game. Even if you don’t fully understand what’s going on you can get the gist of it.
If you have a lot of time to kill and want to learn about the basics of how a computer functions at the hardware/assembly level there’s [this playlist](https://www.youtube.com/playlist?list=PLowKtXNTBypGqImE405J2565dvjafglHU) by the awesome dude Ben Eater demonstrating how to build a basic 8-bit computer from scratch.
EDIT: I just remembered a cool video you can [find here](https://www.youtube.com/watch?v=Kalmryn9_sE). It demonstrates a few basic ideas for writing a game directly in assembly code.
So the other answers seem to all be talking about compilers. At the end of the day, all a compiler does is translate code people can read into code computers can read. It doesn’t really explain what the code is doing.
Imagine each file is a person with a specific set of tasks and skills. When you start the game, you tell the “boss” to start working. But he doesn’t do everything himself. He goes around assigning work to other people. “You, play the opening cinematic.” “You, load the assets for the start screen.” “You, go look for the save data.” “You, find out if they’re using keyboard/mouse or controller.” “You, start tracking control inputs.” Etc, etc. It’s all these workers passing information around and delegating work that allows you to play the game.
Less ELI5 answer:
While the code is separated into many files, the programmer can reference other files and the code inside them. Each file has a unique name and each distinct section of code (a “function” or a “method”) will also have it’s own name. So using these names you can jump from file to file.
As a simplified answer, the source code is written in a specific computer language. Tools called compilers take the source code and translate them in to binary files that the computer can actually execute. It is those files that are distributed for the specific game.
Again, this is a wee bit simplified and I’m sure there’s going to be some “yes, but…” responses. Lol
So the source code is put into an “engine”, which compiles the code and runs it. The engine will have a set of native programming modules to translate the source code instructions into what you see and experience on the screen.
While there are publicly available game engines that you can yourself program, such as Unity and Unreal Engine(the engine Fortnite is built on), most AAA video games will have their own bespoke game engine, for example the Gamebryo engine that was used to create the Fallout and Elder Scrolls games.
As you said, it starts with thousands of lines of code and also other assets, like images and data files that the program needs.
Then the code is compiled. Think of the compilation process as what a translator does when communicating between two people who don’t know the same language. The compiler takes the written code (typically in English sorta) and then translates it to the what the computer understands, which is called machine code.
Then, the code is tested. Then bugs are fixed, code re-compiled, then tested again. This loop happens hundreds if not thousands of times during game development. Actually, many companies do night builds with automated build systems, so that the testers can test fresh builds of the code every morning when they come into the office.
Once a company feels that the quality is enough for release, they take all the files that have been tested, and publish it on the service and/or burn it to a DVD or whatever type of media they are going to use.
programming languages are compiled using a special program which translates code that humans read and write into machine code that computers can parse
sometimes you use an ‘interpreted programming language’ which means instead of using its own compiler because that is a lot of work to make — it translates from one language into another as an intermediate step, and then uses that languages compiler to translate into machine code!
The code is compiled into binary or byte code, and then deployed onto the target platform (that could be download to your PC or run on a server, depending on the architecture of your game). That final set of deployed files is generally managed by the game’s main executable file, which would grab the image files or sound files or whatever that it needed as you got to that point in the game.
A program called a “compiler” takes the source code and translates that to machine code…binary codes that the computer hardware actually understands. This includes pulling in other files of code, references, etc. The output of that process is an executable program for a particular hardware and OS. So the binary file will be different for an Mac or a PC or PS4.
You download that program, as well as all the “game assets” to support it (graphics, textures, maps, data, etc.). The assets are usually a lot more of the size of the game than the program.
When you go to run the program, the operating system copies the first part of the program into RAM (random access memory) then looks at the first entry and does whatever it says. And now you’re running the game.
They use a compiler and this compiles the code into an application and a set of libraries so that you can play the game on your PC.
Most are then packaged up into installers which actually install it to some location on your computer.
Latest Answers