Apparently I really broke the last beta build. There’s two new fixes in this hotfix build.

Changes for beta 1.0.4 Build 141003

  • * Fixed mods not showing up on the toolbar.
  • * Fixed crash when loading save games saved with 141001.

There might be some weirdness with roads if you saved a game with 141001 and now load it – roads might have disappeared until you build more of them. The joys of making mistakes in code!

There’s a new mod kit that you can download.
And here’s the new patch: Download it here.


Beta Bug Fixes

I’ve fixed some bugs in the beta that dealt with mods, and some other game breaking bugs as well.

There’s a new mod kit that has some changes for mouse cursor handling.

As always, you can get the updated beta on Steam. Or you can download the patch here, and overwrite the game exe, dll, and some data files with this patch.

If all goes well for the next week or so, 1.0.4 will leave beta go out officially next week.

Changes for beta 1.0.4 Build 141001.

  • * Fixed a crash when disabling mods that had new map types.
  • * Fixed the toolbar showing empty buttons in certain cases.
  • * The trade UI now dynamically resizes to make sure all items can be shown at once. This fixes crashes when the general merchant comes with many mods that add resources enabled.
  • * Fixed a rare crash that was caused by closing tooltips in a particular way.
  • * xWMAEncode now uses the /bin parameter to located it.
  • * Fixed a bug that allowed combo box drop downs to stay up if the parent button went away.
  • * Added an option to draw the mouse cursor in software in cases where DirectX fails to display the cursor properly.
  • * Moved ‘clip mouse to window’ option from Game options to input options.
  • * Added a cursor option that allows the resource to specify the hot spot of cursors. This also facilitates the software cursor.
  • * Added a Reset All option to the game launcher. This allows the game to reset to default settings if a setting is causing a game crash. The command line option /reset also does the same thing. Note this will unset achievements in non-steam versions.
  • * Adding an option to the game launcher to disable use of DirectInput. This should allow systems where the mouse doesn’t move to work properly, however only the left, right, and middle mouse buttons will be available.
  • * Roads will now always draw roads no matter how many there are on the terrain.
  • * Misc fixes for rare crashes.

Steam Workshop Beta

Steam Workshop
Steam Workshop support is now ready for beta testing!

There’s a new Banished Kit required for using the features of Steam workshop. Version 1.0.4 Build 140925 Beta. If you’re not using steam, you can still update to the latest patch and download the new mod kit. You can get it all here.

If you already own Banished, then you can view the workshop here: You need to be logged into steam to be able to see and use the workshop website. Until beta testing is complete, the workshop is private to Banished owners.

To use the workshop beta you’ll have to opt into the Steam beta, by right clicking on the game in your Steam library, selecting properties, picking the BETAs tab, and picking the 1.0.4 Beta.

I’ve tried to make Steam Workshop integration pretty easy to use. In the Mods menu in game, there is now a browser where you can see the latest and popular mods, as well as search for specific mods.

Mod Browser

From the browser you can subscribe to mods and they’ll download pretty much immediately. If you use the workshop website to subscribe to mods, the mods will download immediately as well. After they download, the game will notify you that you need to reload the current assets for the mod to show up in the installed mods list.

Mod Ready

For mod authors, getting mods on steam workshop or updating them in the future should be fairly painless. By viewing mod details in game, you can upload a new mod to workshop, or updating an existing one.

The main change authors need to deal with is adding a large icon for display in the steam workshop. A new field has been added to PackageFile resources to specify a jpg or png preview image that is larger than the 48×48 icon that the in UI uses.

Check the mod documentation for more details.


If you curious as to what’s changed in this version, the details are below.

  • - Updated to latest FBX sdk. This required moving x32 and x64 builds into their own folder since the dll name is the same for both 32 and 64 bit versions.
  • - Added support for a cmd.txt file that contains command line parameters. cmd.txt must be in the same folder as the executable.
  • - Added command line parameter /bin that tells the game where the main /bin folder is located relative to the executable. This allows a single bin/WinData folder to be used along side the x32 and x64 versions of the game.

  • - Added a new variable to PackageFile resources, ‘String _preview = “pngOrJpgPath”;’ This is a square preview image that is used when uploading mods to steam workshop. If not set, no preview image will be uploaded to steam.
  • - Added Steam Workshop support. Mods can be created, updated, downloaded, and browsed in game. Any updates to subscribed mods will download automatically. A reload is required once downloads are complete.
  • - Fixed tooltip text going outside the background boundaries.
  • - Fixed combo boxes not displaying correcly after being enabled, disabled, then re-enabled.

Mod Kit Beta

The first beta of the Banished Toolkit is now available!

If you’re playing on Steam, you’ll need to opt into the 1.0.4 Beta – to do this, right click on the game in your game library, select properties, then the BETAs tab, and pick the 1.0.4 Beta. No password is needed.

If you’ve downloaded the game from elsewhere, you’ll need the 1.0.4 Beta Patch. You can download it here: You’ll have to extract it into your game folder, making sure to preserve the directory structure of the archive.

1.0.4 Beta mostly adds functionality for mods. While some potential crash bugs were fixed, there shouldn’t be any game play changes.

For either version, you’ll need to download the mod kit here:

Extract it to a folder where you want to work on Mods, preferably not the same folder as your release version of the game is in. There’s a README.html inside the archive that has some basic instructions on how to use the tool set.

The mod kit has a few examples that show how to add buildings, professions, new crops, animals, and trees, as well as most of the original game configuration data.



Forward Compatiblity

Since Banished was shipped, when I go through the process of adding to or changing the game, I’m usually thinking about what might happen in the future. Will I add DLC? What form will it take? What are the implications of the mod kit? Will future changes break mods? Can mods break future DLC? Am I going to ship OSX and Linux builds? How do my current code and data changes effect those future desires?

So I find myself at a point where the mod kit is (sort of) close to complete. I need to make a few more code changes to really have good support for user changes and additions, but the overall ability of users to provide binary compiled assets to other users poses a problem.

The problem is that if people start making mods, and I then release an OSX or Linux version, those mods aren’t going to work on those platforms without the mod being recompiled.

Resources in Banished work a little bit like writing a program. When writing the code, usually you write some C or C++ code, compile it, and give end users a binary executable.

Resources for Banished are similar. If you make a model, a texture, an audio file, or general resource, you have an FBX, PNG, WAV, or text file as the user created resource. Those resources are compiled by a tool into a binary format that is fast to load and ready to use – the difference in load time between the game using the compiled version vs raw version is several seconds compared to several minutes. So shipping the raw resources really isn’t worth that wait time.

So what’s the problem? There’s currently a lot of binary graphics and audio data that is Windows only. OSX and Linux will use OpenGL, and there are no GLSL shaders stored in the game binary data. There’s only compiled DirectX byte code. And audio? It’s compressed and stored in XMA – XAudio’s format – similar to WMA.

If I were to just ship Linux and OSX at future date without the mod kit existing, I could patch the game data to be more cross platform, or even ship separate data – and no one would know a difference. But since there will most likely be mods out there – and in binary form, they won’t work on those platforms since key data doesn’t exist. The audio is in the wrong format, and there are no GLSL shaders.

Solutions? I know some companies are parsing compiled HLSL byte code and outputting GLSL. While this is a possibility, I’d like to use the actual features of GLSL and not be locked into what I can parse out of compiled byte code. Plus it makes sense for future projects to support it properly.

The audio side could be hard to deal with as well. Decoding XMA and reencoding to another audio format at load time isn’t something I want to get into.

I could just ship the mod kit, and new platforms just won’t work, and it will be up to mod authors to recompile their mod – and it may not just be a recompile. What if in implementing OpenGL, its better to modify some data for better compatibility? I’d probably do that. I like good code with good performance, instead of hacks to make things work. If the resource format changes, then mod authors will have to update any new materials they built. This really isn’t ideal.

I could have mods include the source data, and have newer releases include the entire toolset to recompile resources as needed, but again, that locks me into not drastically changing any file formats. Plus the raw data is a lot bigger. The Banished resource folder before compilation is around 700 megabytes – the shipped data is just over 100. Mods would have similar data bloat.

I could also put out a beta of the mod kit, let people get used to it while I take care of these cross platform issues, and then deprecate all binary mods. The mods would have to be recompiled and redistributed. This isn’t ideal for end users – especially if an author of a great mod stops maintaining it.

The best solution is really to make sure GLSL shaders are part of the data, and use an audio format that is usable on all three platforms.

So this weekend I’ve been looking at the feasibility of doing that.

I’ve been experimenting with OpenGL 3.2 and trying to get a sense of how long an implementation will take. It’s partially done already. If nothing else this will make sure I can build GLSL shaders using the material system and shaders already in use. Ideally the windows version will have a new OpenGL renderer that will be selectable just like DX9 and DX11.

On one hand this is great – From my graphics programmers background perspective, I’ll finally have a great test bed to really see which API runs the fastest (since this has been a debate from the beginning of time), since I can pick a scene and switch between rendering APIs at runtime. On the downside this increases development time before the mod kit appears. Although the DirectX implementations are only 44K(DX9) and 65K(DX11) of platform specific code so I assume GL will be similar. That little code shouldn’t take too long, right?

On the audio side FMOD seems capable of playing XMA samples, so switching over to that might not be so bad either, and if I do a little research to make sure it’ll work, it may not have to be done right away. Once I do port though, the API is available for all the platforms I want to support. Other cross platform audio libraries are out there – really i just have to decide on what format the audio will ship in.

On the upside of the extra development time to make sure mods work in the future, having OpenGL and FMOD (or other cross platform audio library) implemented will certainly bring me closer to having ports done as well. There’s not too many other platform specific parts of the engine. There’s file I/O which should be super easy, the math library, which is currently written in SSE – I just need a C++ port of it – also easy(ish), and input handling – reading from mouse, keyboard, and game controllers.

Now if I can stop falling asleep reading the OpenGL spec while trying to get the right triangles displayed on screen…