Creating a Rust Game Engine: Part 1

Welcome, to the second part of my series where i create game engine from scratch using rust. In this part we will tackle linking in rust.

Subhro Acharjee

10/13/20244 min read

What is a Linking Library?

A linking library is a collection of pre-written code that helps programs work together. Think of it like a set of tools or instructions that a computer program can borrow instead of writing everything from scratch. When the program runs, the computer connects, or "links," your code with the linking library so it can use those extra pieces to function properly.

For example, imagine you're building a car. Instead of making every part by yourself, you can get some parts (like wheels or engines) that are already made. Similarly, when you're writing a computer program, you don't need to write everything yourself. A linking library gives you some "ready-made" pieces of code that your program can use.

Why do we need to compile our game engine as a Linking Library?

Game engines are built as linking libraries so that developers can use powerful, pre-made tools and focus on creating fun and unique games, without reinventing the wheel each time. But in case you want a big explanation, here are 3 reasons why game engines in general are built as linking libraries.

  • Reusing common features: Most games need the same basic elements, like graphics (how things look), physics (how things move), sound, and controls. Instead of every game developer writing these parts from scratch, the game engine provides them as pre-built tools or "libraries." Developers can just "link" their game to the engine and use these features.

  • Efficiency: By using a game engine as a linking library, game developers can focus on the unique parts of their game, like story, design, or special features. This way, they don’t have to worry about how to draw graphics or manage the game’s physics. The game engine handles those.

  • Customization: Even though a game engine provides a lot of tools, developers can still add their own code for unique elements. The linking library allows them to combine their custom code with the engine’s tools.

Types of Linking Libraries

There are two main types of linking libraries when we talk about low-level programming languages: Static and Dynamic linking libraries. The difference between them is quite simple: Static linking libraries are added to the program (like a game) during compilation, when the developer’s code is turned into binary, meaning the static libraries are directly included in the program’s binary file. In contrast, Dynamic linking libraries act more like pointers. Instead of being included during compilation, the program is given instructions via a linker about where to locate these libraries, and when the program runs, it searches for and loads the dynamic libraries from memory.

In summary, static linking increases the size of the program’s executable but offers better performance because everything the program needs is already included at runtime. On the other hand, dynamic linking keeps the executable smaller, but the program must fetch and load the necessary libraries during execution, which might slow things down slightly and can introduce errors if something goes wrong during the process.

What are we choosing for our game engine?

The main tutorial video by the cherno which i am following, he is using Visual Studio Editor (Not VScode) and setted up and automation to build dlls (Windows dynamic linking libraries) into his sandbox as cpp has a good features related dlls and also during building we dont have build the sandbox again when he is changing any code in code engine. But given I am using neovim and rust, it was a tricky thing to decide on my part. But here is what i have decided when i will be building i will link as dll to get all the features such as Hot reloading and wouldn't need to run build in another time, But during release I will build my game engine as static library which will make my game much faster and less prone to error.

Code structure

On the right you can see the initial folder structure of the aloy-engine. So whenever we built there will be a new libaloy_engine.dylib (as i am using macos). And below you can see the folder structure of the sandbox where we are building an executable. There is unique file called build.rs that tells compiler about all the linking stuff such as which library to search our dynamic linking files. Please check the references for more details.

Folder structure of aloy engine
Folder structure of aloy engine
Execution

So the code execution is simple we create functions in aloy-engine in lib.rs which basically has no-mangle macro enabled, which is basically telling the rust compiler to use the same name of the function in the function map as the one given by developer and do not change it. And in sandbox we link that dynamic file simply by using link macro. By default link macro links with dynamic libraries so if there is a folder containing two libraries with same but different type it is better if we devs let the linker know type of linking we want. Below I have attached screen shots of the buffers and the output of the execution.

Code screen shots
Code screen shots

in buid.rs i.e right bottom buffer, we can see a cargo build flag rust-link-search, this tells Cargo to add a directory to the compiler’s library search path using the -L flag, with an optional KIND for specifying the library type, while paths within OUT_DIR are added to the dynamic library search path, though relying on this is discouraged.

Note that when we are linking we are not using the name `libaloy_engine` but rather using `aloy_engine` that is because linker always assumes that the name given will have the lib as prefix and searches accordingly in the linked folder.

Thats it for this blog i guess nothing much to explain, hope you have liked it. I have added references below.

References

Execution result
Execution result