The follow-up to the Westerado Flash game, which was published by Adult Swim Games and released through Steam and the Humble Store.

Westerado: Double Barreled is a full remake of the original Westerado, with a lot of added content and polish. The entire game was rebuilt from the ground up. This time we decided that I would be the lead programmer and would be responsible for the basic systems as well as the parts I made last time.

The main concept of the game remained the same. This meant I could focus on improving the systems we were using to get content into the game. My focus this time was to try and automate as much of the process as possible, since on the original version any asset that was added to the game still had to be referenced in code somewhere, which led to an “” file of about 1500 lines just referencing assets in compiled file. In the new version we wanted to just be able to click something to make it go.

While searching for solutions I found a tool that could automatically package a folder containing assets into a neat little SWF. This tool alone would not accomplish what we needed, but with a little more searching I found a way to “scan” a SWF for different types of assets and organize them into a database that could be used by the rest of the systems automatically. As long as the file was packaged it could be used in the game immediately without touching any code.

There was one side-effect to this change. The game was able to use these files immediately, but initially we were still using the Ogmo level editor, which required every asset to be defined separately. This was when we decided we needed our own level editor that should at the very least match the way the game handled its assets. The level editor would be named Mapographer (INSERT LINK) and it would scan the asset folder itself for any images, that could then be placed in levels without having to first define what it is and what it does.

This move away from Ogmo then led to another part of our old system being compromised, the in-level scripting tool. To combat this problem I created another tool called BloXcrypt (LINK HERE), which replicated all the functionality of the Ogmo system, but it was a standalone program. This led to a lot of incremental interface additions that would streamline the process way more than the initial Ogmo system could have ever been.

The final big part was the World Builder (LINK HERE). This was the tool used to patch the world together, simply by dragging and dropping a single level on a world map and connecting the exits/entrances on a level to the exits/entrancs on other levels. After doing this the designer could then export these connections to the game and the editor would also generate an updated world map for the game’s interface. This map was created to be drawn over by the artist, but was directly usable in game.

Other small ways in which I streamlined the process was with a PNG recolor tool and a hitbox drawing tool, both of which were as basic as possible. The PNG tool could recolor entire folders PNGs based on a palette image containing the base color for every part and the colors it would be recolored to in a grid, the most useful moment for this tool was when we decided that there would be rivers in all biomes, where all the biomes had to have different grass colors and the rivers were made up of about 30 different tiles, which took about 30 seconds for the tool, where it would have probably taken a few hours of tedious photoshop work. The hitbox drawing tool was essential with the system we’d setup, because with this tool we enabled the artist to just plug an asset in there, draw a hitbox and then he would be able to immediately place the asset in a level to test it.