Modding the Bastion

I will use this site temporarily to host my blog entries until I get my site up running.

I'm a big fan of Bastion, a game that will probably end up the best one I've played this year. I even bought the game twice; on Xbox Live and Steam, not to mention ordering the soundtrack CD. Believe me that what I do with the game is out of nothing but pure love.

When I installed the PC version of the game, the installation process revealed something to me on how the game was built, something that would allow me to easily decompile it.

So I did.

It's better than a disassembly, but there were few bugs left around due to discrepancies in the translation process that I've built. The majority of fixes needed to be done were simple mistakes, but others required me to look at the assembly. Eventually I was able to build a working copy, but there maybe some bugs that I'm currently unaware of. I would like to talk more about the process of getting working code, but my purpose isn't to give out the code or tell anyone how to get it. The reason why should be obvious.

Instead, what I will do is make modifications to the game and develop tools that help with modification (which is more likely to be released). This can range from creating a map editor and setting up a simple way to launch custom maps, making some roguelike mode, coop multiplayer, etc. The very first thing I would like to do is make it Mac and Linux compatible.

On the Super Giant Games site, they have an FAQ where they address releasing it to either platform. They left it kind of open ended, but I don't know if it is likely to be done. The game is built using XNA 3.1 and not in a way that can be easily abstracted away (but that might just mean I don't have a keen eye on architecture). It'd take some effort to get it to other computer platforms for, let's be honest, little gain. I think they would rather start on their next game than work on getting this to other platforms.

Some of the work is already done. Mono is an opensource implementation on the .NET framework, which supports all of the .NET stuff Bastion uses just fine. The more difficult part is MonoXNA. To this date, the project is nowhere near finished and has little activity. Some of the 2D support is already there, compared to the 3D portion of XNA, but one of the leads of the MonoXNA project has decided to skip implementing XNA 3.1 and go straight to XNA 4.0. Unfortunately, XNA 4.0 axed some redundant things in 3.1 which Bastion made use of. I have to get Bastion moved over to the 4.0 version of XNA, after which I will try to compile against MonoXNA and contribute any changes to that project up to the point where Bastion is fully playable.

Right now I'm looking into the bloom component; more specifically the use of the function ResolveBackBuffer, which was axed as RenderTarget2D makes it redundant. ResolveBackBuffer is a little weird to understand but I think it doesn't do anything too different from RenderTarget, though RenderTarget2D is being used not far from where ResolveBackBuffer is being called. I'll look into some example code between the two functions to decide how to best replace ResolveBackBuffer.

Addendum:

You can already make some changes yourself to Bastion. There are many XML files that modify various things like weapons and the such. I plan on researching what each parameter does and posting about it later.

The Last Addendum:

Derp, saw another implementation of XNA called MonoGame which seems more complete but geared towards portable devices. The big thing is that it doesn't seem to be switched to XNA 4.0, but I don't know if porting to XNA 4.0 would be a complete waste of time neither. I'll look more into MonoGame but regardless of what I decide I'll probably still keep a branch that supports XNA 4.0.