Resource Editing Pipeline

Author: thothonegan
Tags: gamedev resources inotify endless

Working on a lot of resources for Endless, so decided to package the structure up for others to use. While not the most integrated or powerful system, it’s very quick to setup and relatively simple to use.

As it uses bash and inotify, its currently written for Linux systems. I’m sure it can be tweaked to work on OSX via a different mechanism, and probably rewritten in PowerShell or something for Windows.

The attached scripts are just examples of how to implement it - they’ll need to be tweaked for your specific project, since you probably wont have the same resource system or format I do.


The goal is to save a file in an editor (such as Krita), and a few seconds later see the changes in the game without having to run build scripts manually. A video of what I mean:

In my game repository, there are 3 main folders that are important for this:

  • Resources/ : Location of all the engine readable assets go. It has a final compile step with WolfRez, but its only straightforward conversions. You can think of it as final assets.
  • ResourceSources/ : The source files for assets. For example, I do all my art with Krita, so the kra files are in here, while the generated PNGs go into Resources.
  • Build-Linux-Clang-CPP11-Ninja-Debug/ (or whatever) : Build directory of the game which can compile, package, install the game.

Now in my case, I also have the ability for my game to automatically reload resources when they change : but thats outside the scope of this setup (since its very engine dependent). If you dont support that, worst case you have to restart the app as an extra step to see your changes.

TopLevel -

This script basically is run once in a terminal and forgotten about. It monitors the path hardcoded inside it using inotifywait. If any files change, it’ll call in the given directory. If that returns 0 (success), it then rebuilds the app. Pretty straightforward.

Directory -

Every directory underneath ResourceSources can have a script. If it exists, its called whenever a change is detected in that directory. The script then does whatever actions are needed to build that file. For example, the one i’m using at the moment for a treasure chest graphics is:



if [[ $1 == "TreasureChest.kra" ]]; then
  ${TEK} convert TreasureChest.kra ${RES}/Entities/Common/Sprites/TreasureChest/TreasureChest.png
  exit 0
exit 1

If “TreasureChest.kra” changes, it runs a helper tool I have (tek convert) to create a png out of the file, and returns 0 to rebuild the app. Otherwise, it returns 1 (nothing changed). Other fileChange scripts do things such as slicing a tilemap up, or converting a song file. This flexibility allows it to basically perform any command when a file changes.

So high level:

  • App saves its file
  • rebuildResourcesOnChanges notices a change
  • fileChange does whats needed to process it
  • rebuildResourcesOnChanges rebuilds the app
  • App detects the file changed, and reloads the resource automatically

Nice and easy.