Skin Deep: Skin Deep BuildPackager

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Skin Deep BuildPackager

Today I’ll be writing about the Skin Deep BuildPackager tool. Here’s what it looks like:

Yes, this is yet again a tool that has one button.

To set expectations: the general concept of the BuildPackager (package up a build ready for players) is widely applicable. But the particular details of this tool apply specifically to Skin Deep, as this tool is only for Skin Deep’s particular file structure and folder setup.

Goals

I wrote this tool to package player-facing builds of Skin Deep. Example: a build of the game that gets uploaded to Steam.

This generally means:

• Removing ‘source files’ for assets.
  • This is stuff like: Blender .blend files, Photoshop .psd files, intermediate model format files like .FBX and .OBJ, reference image files, map backup save files, and other development files.
  • A large majority of our assets have multiple source files. In Skin Deep, roughly 80% of files are development files that can be removed.
• Removing developer test maps.
  • Oftentimes when we add a new feature to the game, we’ll make a “test map” that just has that one object in it. Example: map “test_healthstation” just has one health station.
  • These test maps allow us to quickly revisit, test, and verify things with the feature during development.
  • They end up adding up to a relatively large amount of space, so we remove them during packaging.
• Ensuring necessary files are present.
  • Making sure that the .exe executable file exists.
  • Making sure that the .pdb debug file exists.
  • This is just a basic check to make sure we’re uploading something playable.
• Compiling the maps.
  • In the game engine, maps need to have their collision data and pathfinding data built.
  • When packaging a build, we opt to just re-compile every map every time.
• Upload.
  • The tools upload the files to wherever they need to go, i.e. Steam.

This is all stuff that can be done manually. But, it’s quite a lot of steps and is very tedious, so it made sense to make a tool to automate this.

Why GUI

This uses a GUI interface. The BuildPackager would definitely work well as a command-line tool, and would probably be faster to build with that approach.

I personally like to use GUIs for my tools (instead of command-line). The main reason: I had some command-line processes in the past, and yes, they did work great. The problem was:

• When I later needed to revisit the project a number of years later (i.e. 5-10 years) it was sometimes a bit tricky to re-learn how the command-line tools worked.
• Whereas a visual GUI interface tended to be more immediately intuitive/useable years later.

Now, crossing my fingers that functionality/support for these GUIs don’t disappear anytime soon… 🤞

How it works

First, I compile a new executable in Visual Studio. I didn’t automate this, because I just never got around to it.

Then I click the giant Start button:

Here’s a step-by-step of what the tool then does:

1. BuildPackager verifies all the files it needs actually exist, such as the game executable.
2. BuildPackager rebuilds collision data and pathfinding data all of the game’s maps.
   • This is done by running the game with some specific command-line parameters.
3. BuildPackager deletes all the files in a “staging area” folder for the build.
4. BuildPackager copies the game files to this “staging area” folder for the build.
   • During this step, the tool curates which files to copy. It only copies over the files that we want players to have/see.
5. BuildPackager then calls the Blendo Steam Uploader tool with a command-line parameter, to make it automatically upload the fresh build to Steam.

That’s it. It’s very straightforward stuff!

Nuts and Bolts

Skin Deep BuildPackager was made with Winforms. It was written in C# with Visual Studio 2015.

This tool is extremely specific to Skin Deep, and is also extremely specific to the needs and file structure of this project. So, just to set expectations, this will probably not be immediately useable to anyone, without a lot of changes.

But at any rate, please feel free to adapt it to your own project:

• Binaries download
• Source code download

Et al

Older titles from the Blendo games catalog still get updates!

• Atom Zombie Smasher / Aug 2023 update - 12 years after release
• Flotilla / Sep 2023 update - 13 years after release

I think it’s worth spending time making a basic build packaging tool and writing some internal documentation on your build processes. Mainly because the person you were a decade ago is probably not the same person you are now, and it’s possible you’re going to wish you had some help from your past self in learning how to re-package a build of your game.

I can uhhhh say this from personal experience 😅