Backburn Devblog: Origin Story

My father often despairs at my career choices- I wanted to make a game that he'd understand and hopefully enjoy.
Right now it's really just an adaptation of my Tower Beefence code, but the experiment is teaching me about "random" expansion and subtler recursion than what I was taught at uni.


Fire's a tricky critter- it definitely follows some basic rules and is predictable in defined cases; we know how to hold a matchstick to have it grow or shrink. But in the bush your intelligence of the situation is imperfect, the rules are a little looser, and firefighters have to compensate for a certain degree of unpredictability. If fire in 'Backburn' moved on an obvious algorithm, it'd lose some of that character as a ravenous unpredictable monster.

So what does the algorithm look like? Well, loosely in pseudo-code-

  1. Test the ferocity of the fire- if ferocious enough, and with enough loose vegetation to throw around as embers- attempt to spread to adjacent tiles at random.
  2. Test the randomly selected tiles for 'resistance'- a combination of available fuel, altitude difference and favourable/unfavourable wind direction.
  3. Test ferocity against resistance, if successful, spread the fire. If unsuccessful, give up. 
  4. Wait a random amount of time to try again!


So it's more of a random growth tempered by real-world limitations than a "correct" model with a random element introduced. A variation of this also defines the vegetation spread during terrain generation.

Given that I'm keeping track of the fire's ferocity, I'll use this to modify the fire particle effect- this still needs a lot of tweaking, but for now it does a good job of representing this variable visually.


For anyone having difficulty animating fire- particles or by-hand, there're some main rules I follow every time I'm drawing/animating fire-

  1. Fire is comprised of 'flame' and 'particles/embers' which should be modelled acting individually to the same forces. I consider smoke a separate effect, as fire doesn't always emit smoke, and smoke can come from embers with no fire present!
  2. Colour through time/space- white, through yellow, orange, into reds and maybe even purples. Think about colours of molten metal cooling. Particles/embers will tend to hold onto heat/colour a little better than individual sheets of flame that change colour and extinguish in just a few frames!
  3. Fire moves fastest where it's hottest- That means sheets of flame, particles/chunks of fuel, everything is whizzing upwards from the base of the fire before being cooled by the air and starting to slow down. Think of a big fan sitting under an origin point!
  4. At the base of the fire, everything's forced pretty directly upwards, but once the particles/flames escape that 'fan force', they can spread laterally and float around a little.

That's it for now, obviously there's a lot more to do- I'm hoping to have a player firefighting mechanic working in the next few days, but the way my progress with code moves in inspirational jumps and starts, who knows!

I'm mostly writing this for my own edification, but if there's anything here that folks would like to see more of, I'd love to hear about it! I can take a few moments to include some full-resolution assets or downloadable test-builds if folks would like? Leave a comment, or bug me on twitter!

Tower Beefence Devblog: Baby Steps

Well, tower beefence "works" I've got the absolute bare minimum mechanics playing. That doesn't mean minimum viable product- that's still a long LONG way off!
But there're towers that shoot critters which walk a path, and that's the core of what you want from a game like this. My tower defence baby has finally been born, it's just a matter of figuring out what to teach her as she grows into a full adult game*.

If you were curious, the pathfinding works because every tile has entry, (middle) and exit points- every exit point uses an overlap-circle to hunt for the nearest entry point on a new tile, etc. etc. It works fine so long as I feed it a path, but I'll probably need something a little more robust if I'm going to include live dynamic pathing- eg. player puts towers on the road to redirect critters.

(*Probably not an *adult* game, except possibly for those with formicophilia.)

It's taking all the self control I've got to not just get bogged down in graphics/visual concerns- if I'm going to get anywhere with this game, it's going to have to go through the proper channels- that means getting prototyping done before making everything gorgeous.

My current To-do list:

  1. UI and user control. Make it 'playable' without relying on weird keyboard shortcuts and console readout.
  2. Tower variations+upgrades.
  3. Enemy variations+upgrades.
  4. Economy!
  5. Rounds/Game win/lose conditions.
  6. Character/text pop-up to talk to player. "Hey there, looks like you're trying to play a tower defence game!"
  7. Placeholder music/sounds
  8. Some quick+dirty promo art
  9. Reassess, blog about progress, move forward!

And in case you were wondering, yes, making a game because of a bad pun STILL feels ridiculous.

Tower Beefence Devblog: Origin Story

So I was making puns one afternoon and then I accidentally talked up a bad one too much and now I'm making a game, I guess!

This is something that's been coming for a while- after uni there was the inevitably doomed team of ill-fitted overconfident newbies. (I think we managed two meetings before it dissolved!) Later came the simple jam games that were always tantalisingly close to completion before being discarded forever.
And now I make games for work, but that's long-term projects where my rent is at stake- has to be taken very (mostly?) seriously.

This is my first ever game. I will work diligently to make it the best game I can make, but it'll still be my first game. I'm going into it with my eyes open, and no delusions of glory. Good code teaches us to fail often and learn from our failures, and I've already accepted that in a broader sense this project will be an informative failure that may not even be finished.

So let's talk about this failure!
Tower defence games are a super duper well-explored space- there's a lot of research material available, and pretty much everyone who's played mobile games can pick one up and be confident about how to interact with it.


All I really want is to do something fun with the bee theme and enemies, and create an attractive space to play a halfway decent TD game.


I've snagged a handful of evenings and one or two coffee breaks to pick away at this game. I've painted a custom tile set to play with, I use Grids Basic to create a hex-grid. My code lets me customise, store and read its tile states from a txt file, so now I can save and load custom maps.

This is likely laughably basic to most mid-level programmers, and a lot of the people I hang out with (at least on social media) are expert programmers and game devs. Entering into something with a complete lack of confidence makes it very difficult to be disappointed with my progress.

Anyway, the adventure has begun, and after every jump in progress, or batch of shiny new art assets, I'll make a post here and try to share it around.