The Odin and Raylib template reloads game logic without restarting the window

The trick is a shared library the running process reloads

The architecture is a two binary split. The hot reload build script produces game_hot_reload.exe at the project root and game.dll inside build/hot_reload, and the gameplay code lives in source/game.odin. When you rebuild, only the shared library changes, the running executable notices the file on disk has changed, and it reloads it without restarting the window. The example in the README is deliberately small: change rl.ClearBackground(rl.BLACK) to use rl.BLUE, save, rebuild, and the running game changes colour. The author used this approach while building the game CAT & ONION, and a companion repository, The Legend of Tuna, shows the template with Box2D added.

Game state survives the reload, and that is the whole design constraint

The important detail in the quick start is what does not change. The running executable keeps the same Game_Memory, a struct defined in source/game.odin, across the reload, so the game continues with your new code but the old state. That is what makes the loop feel smooth rather than jarring, and it is also the constraint you have to design around. Anything you want to keep across an edit has to live in that struct, because a reload replaces the gameplay code wholesale. The template does not document a serialization layer for that state, so a long-running session of accumulated progress does not obviously survive a reload, which matters more for a game with save systems than for a prototype.

Four build scripts cover hot reload, release, debug, desktop and web

The repository root is a set of build scripts rather than a build system of its own, with bat and sh variants for Windows and the other platforms. The set covers hot reload, release, debug, web and desktop. The release script produces a build in build/release and, by design, drops the hot reloading machinery, importing the source folder as a normal Odin package instead of using game.dll, on the reasoning that you do not want that machinery in a shipped game. The debug script is the same idea but produces a debuggable executable for the non-hot-reload path. The desktop script ends up in build/desktop. Assets are copied on release and web builds, but not on the hot reload build, because the hot reload executable lives in the repository root next to the assets folder.

The hot reload script skips rebuilding the executable if it is already running

There is one behaviour of the build script that matters for the loop. build_hot_reload.bat does not rebuild game_hot_reload.exe. It checks whether the executable is already running, and if so it skips compiling it. That check is what makes the second rebuild fast, since only the shared library needs to change. The trade-off is that the running process keeps whatever state it was launched with, and any change to code that lives in the executable rather than in the gameplay library will not be picked up until you restart. On Windows the debugging story is handled by writing a new PDB each time the DLL is built and cleaning those up on a fresh start, and the details live in build_hot_reload.bat.

The web build needs Emscripten and a local server to dodge CORS

build_web.bat produces a release web executable with no hot reloading. Its requirements are specific: Emscripten installed on your machine following the emsdk instructions, and a recent Odin compiler, because the build uses Raylib binding changes made on January 1, 2025. You point EMSCRIPTEN_SDK_DIR inside build_web.bat or build_web.sh at the install and run the script, and the output lands in build/web. The README then warns that you cannot open build/web/index.html directly because of CORS policy javascript errors, and gives the workaround as a small python server started with python -m http.server from the build/web directory, after which you open localhost:8000 in the browser. If you have no python, Emscripten ships one, in the python folder of its installation directory. A wrapper for read_entire_file and write_entire_file from core:os in source/utils.odin lets the game read files from the assets directory on the web as well.

Your editor drives the build, in three documented flavours

The template supports Sublime Text, VS Code and RAD Debugger, and in each case the editor is what triggers the rebuild, which is why the template ships an editor project file and a VS Code directory. Sublime Text users open project.sublime-project, choose the build system named Odin + Raylib + Hot Reload template from the Tools menu, and compile with F7, Ctrl+B or Cmd+B, then hit the same keys again to hot reload. VS Code users open the folder and launch the Run Hot Reload task, then press Ctrl+Shift+B to rebuild and reload. Debugging in VS Code needs the C++ build tools on Windows and CodeLLDB on Linux and Mac. RAD Debugger works by attaching to the game_hot_reload executable, editing code and re-running the build script.

Zlib licensing, a single author, and a last push in August 2026

The licence is Zlib, which is permissive and allows the template to be used as the starting point for a commercial game without obligation. The primary language is Odin, and the repository has no GitHub releases, so there is no version to pin and no changelog to read; the template is a repository you clone and adapt. The last push was on 2026-08-08, and the project is not archived, so it is being worked on but not on a dated release cycle. The author documents his work in a series of demo streams, including a 48 hour Odin holiday game jam where every minute of development is recorded, and the resulting gamejam entry is The Legend of Tuna. An atlas builder tool that packs a folder of png or aseprite files into an atlas texture is designed to sit alongside the template.

Editorial conclusion

Adopt this template if you write Odin with Raylib and your iteration loop is dominated by restarting the game to see a change, since the hot reload build recompiles only the gameplay library and swaps it under a running window. Do not adopt it if you are starting a new project without Odin experience, since the template assumes you already know the language and the Raylib bindings, and remember that the release path deliberately drops the hot reload machinery, so the shipped build is not the build you test with. Verify first that the Odin compiler is on your PATH, that your editor can call the build script, since the template leaves that to Sublime Text, VS Code or RAD Debugger, and that the game state struct you rely on survives a reload, because that struct is carried across the swap.

Frequently asked questions

Official sources

1. Issues
2. karl-zylinski/odin-raylib-hot-reload-game-template on GitHub
3. License: Zlib
4. README