I came across Runtime Compiled C++ some time ago and also Handmade Hero, which have some form of automatic reloading of game code whenever there is a change in the source file. Even Unreal and Unity3D engine supports some form of reloading game code while the game is running.

So, I am going to implement this functionality into my game engine which I am writing from scratch (again). I was thinking of splitting the game engine into two parts, the core engine and the game logic parts, where the core engine parts are written in C++ and the game logic portion will hopefully use C#. The two parts will hopefully support run-time compiled so that the programmers can write code and see the results almost immediately.

So far I have been able to reload my core engine code while the game engine is running, and I will explain how I achieve this using the DLL loading method. Before diving into the code, you might want to check out CodingLab's Runtime Code Reload and also Handmade Hero video series (specifically Day 21,22)</a> . This are the pages that helped me understand how to implement this form of reloading using DLL.

The brief explanation of this technique is that we have a few separate projects, one of which is the main executable that is in charge of reloading the DLLs and the rest are game/engine libraries which are to be loaded by the main executable. Additional feature that I added is the watching of file directory for file changes and recompiling the project when there's a change, but I will not discuss the file watching process in depth (maybe in a future post).

Firstly, we need to set up a visual studio solutions with multiple projects (for this example, we will create only two) and make sure one of the project is a dynamic link library. Once that is set up, go to the DLL's project properties and C/C++ &gt; General &gt; Debug Information Format and change it to Program Database (/Zi). Now we can move on to write code that will be loaded by our executable. (Note: Remember to set the project dependency so that our executable will always build after the DLL).

There are few ways that we can write code for our DLL to be picked up by our executable, but the way that I am using is having an interface that is exposed to the executable to call into and that interface will not expose my internal DLL's code. This way, I do not need to export all my classes and functions, only those in the interface files will be exported and those wrapper functions will call my internal functions.

To expose functions/classes from the DLL, you need to add extern "C" __declspec(dllexport) to the start of the function so that the compiler knows that this function needs to be exported into a table which is inside the DLL, note: the extern "C" part is so that the names do not get mangled when it creates the DLL file. Inside the functions we can call other functions which are not exported so we can change the internals without affecting how the executable call into the DLL.

In our executable program, we need to call LoadLibrary and GetProcAddress to be able to call our game code. LoadLibrary simply loads the DLL file and GetProcAddress allow us to look for the symbol in the table that was generated by the compiler, if this call succeed, we will have a pointer to the interface wrapper function in which we can call.

I have attached a simple project that demonstrate the ability to reload the DLL after changing the code. To test the code, press P to print out the message that is in the DLL and you can change the code in the GameCode project and  press R to rebuild the code while the executable is running.