Kitbash’s Origin Story

Development has been a bit slow lately because we’ve taken on another foster dog — a clever but timid pup who’s being trained and prepped for a new shot at life. I was chatting with him this morning, trying to take his mind off his recent de-sexing, and he suggested I write a post about the origin of Kitbash.  Good idea, pup!

This post will be a bit rambly and disjointed. I just wanted to give some background before jumping into posts about the game’s current state.

Going back 30 years: Six-Gun Shootout

I had an Atari 130XE when I was about ten years old. It was an amazing little beast, with a huge library of games and lots of opportunities for a young kid to figure out how it all works. One game in particular kept me occupied more than I’d care to admit: Six-Gun Shootout, by SSI (Strategic Simulations Inc).

Six-Gun Shootout

Six-Gun Shootout was a turn-based strategy game based on the gunfights of the Wild West. The graphics were simple, but there was more going on under the hood than you might expect. Initiative for shooting and movement were tracked separately, and damage was based on hit location — there were tactical considerations for aiming for someone’s legs or arms. Stance and cover affected line-of-sight. For example, lying prone behind cover wouldn’t hide you if the enemy was standing directly on the other side. It worked really well, and even though the game only included 10 scenarios, you had the option to customize the unit names and stats each time.

At some point I got my hands on a hex editor and figured out how to edit the scenario files. I don’t remember how it happened… Suddenly I was surrounded by custom maps drawn on graph paper, with a master sheet containing the legend for converting tile types back into hex. Entering each custom map into the game using a hex editor was a gruelling process, but the payoff was thrilling.

Six-Gun Shootout struck a chord with me, the same way the original X-Com would a decade later. The turn-based tactics, the customizable units, the replayability… These are the core elements I want to see in my own game.

Turn-based tactical Sudoku?

In 2007, I was living in China and spent a lot of time either sitting in an airport or sitting in an airplane. I turned to Sudoku to help pass the time, and it got its hooks in deep. At some point (probably prompted by Puzzle Quests’s match-3/RPG genre mashup), I started wondering how a turn-based tactics version of Sudoku would work. Many pages of scribbled notes followed.

It was a fun design exercise, but the problem with Sudoku is that at first glance it appears to be someone’s leftover math homework.  (Silly arithmophobes! There is no math in Sudoku.)  My gut feeling was that bringing Sudoku too far into the mix would scare away a significant chunk of potential players. And in the end, I didn’t really want to make some sort of “Sudoku Tactics” game. It seemed too gimmicky and took focus away from the most important aspect: turn-based tactics.

The ghost of Sudoku can still be found in the current design for Kitbash. It’s there — you can see it in the early screenshots — but its role has very little to do with the gameplay.


One of the drawbacks to working on games in your spare time is that it can take a long time to get things done, and the world keeps turning in the meantime. Gaming trends rise and fall, new games are announced daily, and every now and then the wind can get knocked out of your sails.

Kitbash was always going to feature heists of some sort, taking inspiration from Firefly and older games like Shadowrun (the Sega Genesis version). In 2009, I was making slow but steady progress on a Flash version that centered around sneaking through dynamic 2D lighting from a top-down perspective. Nothing fancy — just the early stages of something I was really excited to be working on.

Early Monaco screenshot

Then Andy Schatz announced Monaco, releasing a couple of early screenshots that instantly made me feel like what I was working on was no longer necessary. Ack. It seemed impossible to continue my hobby project without it being branded a Monaco clone. I (foolishly) let this kill my motivation and Kitbash was more or less shelved for a few years. So much easier just to sit back and wait for Monaco, which looked brilliant!

These things happen. The lesson I took from this is that you should always assume someone is feverishly working away on a project similar to your own, and use that to keep yourself motivated. In the end, Monaco and Kitbash have both evolved along separate paths and no longer seem similar to me at all.

Fulltime Indie

After years of poking and prodding at this game from various angles, I decided it was time to take a chance and start developing it “for real”.  Earlier this year I set up a little office, left my day job behind, and dove in.

A few important decisions had to be made before development could really begin:

2D or 3D graphics? 

There are a lot of indie developers out there who — despite pouring blood, sweat and tears into their game — fail to reach their intended audience because the game just looks bad. It’s an unfortunate reality that if you want to make a living by creating and selling your own games, they’ll probably need to be visually appealing.

I’m not much of an artist, and unfortunately don’t have the budget to hire one. I can’t draw, but I can fumble my way through 3D modelling. My worst attempts at 3D graphics would probably look better than my best attempts at 2D. This made the decision pretty easy: Kitbash would be rendered in three glorious dimensions.

Kitbash (early Flash prototype)

Flash or Unity?

Once I’d settled on 3D graphics, the next decision was the programming platform. Flash and I have had a love/hate relationship since its “FutureSplash Animator” days. ActionScript 3 and FlashDevelop are a joy to work with and I was sure that’s what I would be using for my game. However, after spending time reading up on Stage3D and Away3D, I was dismayed by the lack of decent examples of 3D in Flash. It felt like Flash was going to be a very risky choice for a project that was already full of risks.

Unity has become a very popular choice for game developers and it didn’t take long to figure out why. It’s been very easy to get things up and running, and even my dopey placeholder objects look nice. After playing around with it for a few days, I grabbed a Pro license and haven’t looked back.

Single player or multiplayer?

There have been lots of decisions to make over the past few months. The last one I’ll recap today really boils down to deciding who the target audience is. The big question I had to ask myself was: Will this be a single player game or a multiplayer one?

This game is going to be a massive undertaking — I’m just one guy and I can only do so much each day. This means I need to be very careful about managing the scope of the project. I can’t treat this as a dream project that includes every feature I’ve ever wanted in a turn-based tactics game. Lines must be drawn, and that’s why I had to choose between single player and multiplayer rather than attempting to include both.

The biggest mark against multiplayer in a small indie game is that it can quickly fall apart if there aren’t enough players. With a game like Kitbash, where I’m only expecting to attract a small segment of a niche market, multiplayer sounds like a terrible, terrible gamble. Some exceptional games can pull it off (e.g. Frozen Synapse), but others don’t fare very well (e.g. Fray).

In the end I suppose this decision was an easy one. My favourite tactics games have all been single player: X-Com, Silent Storm, Jagged Alliance, Gladius, etc. I also think a game without a single player component would be a much tougher sell than one that lacks multiplayer. (It’s the only thing keeping me from buying Dungeonbowl, for example.)

Having said that, I’m going to do my best to keep a multiplayer skirmish mode in mind while coding the game. Just in case things go better than expected and I’m able to expand upon the base game.

Kitbash (as it looks today)


Okay, now that this self-indulgent post is out of the way, I’m going to try to post more regularly about the latest Kitbash developments. It takes real effort to drag myself away from the actual work in order to write a blog post about it, so please rattle my cage if this blog doesn’t get updated as often as you’d like. Thanks!