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…

56 Comments

Development Continues…

The last few weeks I’ve been devoting my time to working on adding mod support to the game. It’s been nice to stretch my coding legs by doing something other than bug fixing.

When initially writing the game engine for Banished, allowing users to modify the game wasn’t something I thought about. It just wasn’t in scope – I was more interested in finishing the project in a reasonable amount of time. Hence mods, multiplayer, and a few other features that could have been great additions were off the feature list before it was even written.

Luckily, the toolset I wrote for the game to help speed development is suited fairly well for mods – it just needs a few more features.

modimage

There’s a single tool that compiles all resources into the binary format that Banished uses. There’s a version of the game that has extra debugging features in it, and it can compile resources as the game loads, and additionally it detects resources file changes at runtime, so textures, models, and other resources can be reloaded without shutting down the game (most of the time). The tool also can pack all the resources into a single package for easy distribution.

That sounds good so far.

What’s missing is the ability to have multiple people make additions to the game without having to patch each others raw data to combine them. I think it will be typical that many users will use more than one mod at a time – such as a translation mod, a mod that adds some pretty objects, like trees, shrubs, statues, and fences, and other mods that add buildings and professions to the game.

So what I’ve been mostly working on is support for multiple mods at once. The game can now load multiple packed data files, and new resources can be overridden or added. Mods can be loaded and unloaded at anytime, so if you’ve started a game without mods and want to load one, it’s possible (although slightly dangerous if the mod drastically changes things…)

I’ve still got some details to attend to before mod support is complete. The major one is that I built all the game data thinking that if it was expanded, it would be by me. So there are a few static lists in the data, such as professions, inventory, and the toolbar that need to become dynamic. If two different mods change the toolbar and profession list to add new placable objects, then there’s a conflict – since both mods modify the same resources. Only one will take effect.

The mod interface lets you know when this happens (all the red in the image above), but once I finish, this problem should be minimal if mods are built properly. But clearly you can’t load two translations or two UI changes at the same time without conflicts.

Save games also need to record which mods are in use, and reload them – this way you can have multiple save games using different mods if you’re wanting to try out different mods while playing different towns.

I’ve also got to decide what to do about achievements. Some mods, like translations shouldn’t change the difficulty in getting achievements, but other mods can allow placing buildings for free and adding resources and citizens with the press of a button. That clearly nullifies the achievement process.

There’s also Steam workshop support, but the mods will be the same regardless of where they come from. They’re just dumped in the data directory and the game will find them.

The mod kit will ship with most of the original game data, to show how things are put together, and to allow game rebalances or full texture and model changes. I guess I also need to make some example mods and write some basic documentation.

Lots to think about… so I’m going to get back to it!

66 Comments

Banished 1.0.3

Version 1.0.3 of Banished should be available soon. If you play on Steam, it will auto update shortly. Those that bought from gog.com, the Humble Store or direct from the website will have to download the new version from whichever sales portal was used. It may take a few hours for the builds to go live – they were just sent a few minutes ago.

If you used humble bundle or direct from the website and can’t find your original download link, you can use the humble key resender to re-request the download link.

Whats changed in 1.0.3?

  • * Fixed a potential crash that could occur if two buildings overlapped.
  • * Fixed splitting or emptying herds from pastures. This will no longer cause small pastures to become overfull.
  • * Added an option to set the scale of status icons. This is useful in ultra wide resolutions where the icons become large.
  • * Fixed a bug that caused large population cities to randomly unassign workers.
  • * Fixed a pause/lag that would occur as the game reassigned workers to new professions.
  • * Fixed a bug that allowed the edges of tunnels to overlap other buildings.
  • * Fixed an infinite loop that occured using the path tool when a citizen couldn’t get from home to a workplace.
  • * Citizens without a workplace will once again do any job on the map. Citizens that have jobs will generally still stay near their workplace unless work to be done has been around for several months and no general laborer has done it.
48 Comments

Laborer Update…

I’ve been working on the mod kit, and also some tools to make it easier to roll out patches to all users simultaneously. However as many people have pointed out, laborers are waiting a long time to walk long distances in the current build, so I decided to start some fixes for version 1.0.3 sooner rather than later.

In this new beta build, laborers don’t have any constraints on when they’ll go to do work or how far away it is. However, all other professions will still stick closer to their home and job unless a job is fairly old and no laborer has done it.

You can opt into the BETA on steam by right clicking on the game in your library and picking properties, then BETAs and then picking the 1.0.3 beta.

Or you can download new exe’s (Banished_1.0.3_Beta_140531.zip) for non-steam builds. Non-steam builds will still read 1.0.2 – but the fix is in the exe. You’ll need to have downloaded 1.0.2 for these exe’s to work properly.

I’d love to hear some feedback on this change, or if you think other professions need tweaking for how long they take to do a job not in their own profession if it’s far away. The idea is to keep farmers, tailors, etc from walking across the map needlessly to pick up a single item so they get back to work quickly should work become available.

Thanks!

110 Comments

1.0.2 Available!

So, after several bugs, mystery crashes, multi-monitor issues and an annoying period of time without internet access, Banished 1.0.2 is ready to go.

The build has been uploaded to all the distributors and should be live very soon, if it isn’t already.

Thanks to everyone who tested and gave feedback on the beta patch – it helped me track down some additional crashes and problems, save game issues, and start up problems.

88 Comments