The Daily Click used to be a powerhouse of a site, a bustling hub for hundreds of talented
and enthusiastic game developers. Back in 2003, I wanted nothing more than to win Game
of the Week, but was intimidated by the scale of the scene there, and by the fact that everybody
was older and better at making games than me.
The site is still going, but its popularity has waned over the years, and the Klik scene
isn’t what it used to be. Well, it sort of is- lots of platformer games and half-finished
mega projects. But the site is still one I like to visit from time to time, just to know
it’s still there and to be reminded of usernames I would have otherwise long since forgotten.
Back at the start of August this year, Joshtek asked the community what they wanted from
the site. I was a little disappointed that none of the options in the poll involved making
games, so my brother proposed… a game making competition, featuring restrictions to channel
the devs’ efforts and to keep them from never finishing anything.
2 days later a GAME MAKING COMPETITION was announced. Its theme: Time Trial By Fire.
It needed fire, a timed element, and had to be skill-based, rather than luck. Well, I
looked at that and thought ‘that doesn’t fit my style of game making at all!’. And
while I’d have loved for it to be a ‘Competition to make a shooter game with awesome physics
and AI’, it’s always been best for me that I’m forced to make something I wouldn’t
normally work on, as the result is typically a lot more unique, fun to play… and finished.
Because, when left to my own devices, my game making ideas always start epic and then balloon
in size further. And I never finish them. But my brother wasn’t done yet! Joshtek
asked for further advice on how such a competition should be rated. One of them was for it to
be a popularity contest, which my brother said was a bad idea and that it should be
rated by judges, and scored on the quality of the game rather than the number of upvotes
it can acquire. Damn, foiled again! So I got to work on the game. I allocated
3 days to making it. But first, I spent a week just thinking about it. Planning it all
out, and coming up with an idea that would work. I didn’t bother with specifics- the
moment you start on the project, you immediately gain a better knowledge of what will and won’t
work. So this week was spent simply forming a rough outline of what the game was to be.
I pictured the player’s character spontaneously combusting, with the goal being to put himself
out by jumping into a trough of water before his health runs out. BUT: here’s the catch-
your score is determined by how much damage you can cause before doing this! This was
adequately silly, horrific and fun sounding. I pictured numerous, idyllic locations just
waiting to be set alight, with one being a city street full of highly flammable people,
just wandering about… but would the Klik community be ready for such a game?!
As expected, problems with my plan became immediately apparent once I commenced work
on the game. For instance: having water as a limited resource, found in just a few spots
around the level felt too limiting. The appeal of the game comes from setting things on fire,
NOT from having to rush to the water to put yourself out with before you die, and for
so much of the experience to be spent making a beeline for the nearest water bucket…
‘dampened’ the fun I was having from the game.
It was a stroke of luck that I had this vision of a flaming person plummeting off a cliff
into the water below, because this worked a lot better! Firstly, it was much more fun
to end the level with a dramatic-looking free-fall… and secondly, this naturally resulted in more
water, and thus, giving the player more freedom to focus on the destruction. And, I could
dictate how difficult the worlds were by changing the size of the islands- I could place the
most valuable stuff to destroy in the centre of the bigger ones, thus making it riskier
to traverse in case you time it wrong and die before you can leap off the side again.
So cliffs became an unexpected, must-have feature for me to feature for me to include!
But having these adds 2 new problems I have to deal with. The first being ‘height’-
rather than it all being on the flat, my character now needs to fall if they’re off the side
of these cliffs. And secondly, it complicates the ‘ordering’ of the sprites. Remember-
this is a 2D game trying to represent 3D islands. When everything’s on the flat, it’s easy
to order these sprites by their Y value, so that things further down the screen are shown
as being in front of stuff above them. But now there’s height as well to contend with,
so if things are flying up in the air or down off the side of the cliffs, this confuses
the ordering. And the grass tiles- which used to be simple
backdrop objects behind everything else- now ALSO need layering: they might end up being
shown in front of stuff that’s big enough to straddle more than one grass tile, like
an oil spill or something like that. There are just lots of things to be aware of when
you’re integrating an extra mechanic such as this into a game.
And I exacerbated any problems with this layering when I doubled the height of these islands,
for no reason other than because it made it funnier to watch the player fall off them.
I could almost taste all those flaming civilians plummeting into the water below!
I think the proper way to represent it would be to give everything a Z and Y value, and
to fiddle with the ordering based on these numbers until it all worked. But this, again,
would be an extra layer of complexity I’d have to contend with for the rest of my project-
so I instead settled on a more botched solution. The level would have 2 separate ‘layers’
to it- the one in front would have everything APART from the cliff faces and water, which
would be on a ‘separate’ layer, directly behind everything else. The botch comes from
the player, who will be transported to this background screen should he fall off the side
of the islands. It’s botched, because this transition is inelegant and I don’t think
you can get it fully working in all instances without a slightly jarring ‘jump’ where
he suddenly goes from being in front of the grass to being fully behind it.
BUT, it keeps things simple- the grass can return to being a background object, without
requiring layering. So that’s one big problem avoided! And, with a deadline of just 3 days,
I need to keep life simple, and this botched approach does just that, in exchange for just
the tiniest bit of jank the moment the player falls off the side of the cliff at the end.
That’s a fair trade in my opinion. Especially with his body being shrouded by the fire he’s
going to be engulfed by.
For a while, when it was all on one layer, I had the fall triggered when your character’s
position overlapped the water. But this runs the risk of people finding a way of escaping
the level if they can somehow bypass the water surrounding the level. There’s not a big
risk of that happening, but it’s far more elegant to have the player constantly falling,
only for it to be ‘stopped’ whenever he’s overlapping the grass instead, because then
there’s no way a player can escape the level’s confines without quickly falling far enough
to end the round. Next, to add the fire. But the big question
was: HOW LONG should you be on fire for before you die? This is impossible to know at this
point, because it depends on so many factors- the size of the levels, the amount of stuff
to be set on fire and so on. I decided on 30 seconds as a placeholder amount of time
per level, but it felt too long. A torturous amount of time for the player to be on fire
for! And I wanted there to be a sense of urgency, so quickly shortened that to 20 which it remained
at for the rest of the project. I CONSIDERED having powerups placed about
to extend this length of time. This would have been a really cool way of extending the
game’s replayability! BUT, at a terrible price- it’s a bit like the buckets of water-
you don’t want the playtime to be spent ‘avoiding death’ by making it into a beeline
to the powerups- you want the time to be focused around destroying stuff, so I decided to keep
the levels a strict 20 seconds long, meaning I could tailor a music track to that exact
length of time, allowing players to subconsciously know how long they had left without needing
to look at the health bar across the top of the screen. All this wouldn’t be possible
if I added time-delaying powerups to the mix. And what about before the player spontaneously
combusts? If it’s instant, there’s no strategy, but if it’s too long then too
much of the playtime would be spent ‘preparing’ for the run. So I settled on there being 3
seconds before spontaneous combustion kicked in, just to add a slight element of strategy
to those first few seconds. Having to make blind decisions like these
has become my favourite bit of game development. Here I am, developing a game type that I’ve
never played before! And yet I’m being forced to make long-term decisions about how it’ll
play before I’ve even played the game myself! It’s thrilling- like I’m pioneering something
completely new, and battling problems which never even existed until this very moment!
I must be basing all my decisions about these things on something- relying on my experience
as a game developer, perhaps. And it’s not necessarily to make the right decisions- but
just about avoiding the wrong ones. A constant assessment of time invested VS payoff.
At this point, I had been working on the game for about 2 hours, and it felt almost finished!
Just add the stuff to burn, throw in a couple of levels and I’m about there! But don’t
be fooled- game development ALWAYS slows down, and at an alarming rate. I can’t really
say why, but the first thing you add is always the fastest and easiest, I guess cos you’re
not having to battle against the other things you’ve already added into the game. And
because you haven’t yet started the time-consuming (but rewarding) process of playtesting.
But now it was time to add the scoring system. This meant adding the stuff your player’s
going to set fire to, and to give them all a score value. I started with the flammable
barrels that can be tipped over to spill their flammable liquid in a particular direction,
cos that seemed cool and I thought had deeper gameplay than I could perhaps appreciate at
this stage. I wanted wooden, flammable structures to be
the focus of the destruction, but this never came to be and I had to settle on bushes instead,
which would in turn ignite nearby bushes, setting off a chain reaction. I think these
are the most boring to set fire to. They remind me of the wood harvesting mechanic from Assassins
Creed Odyssey- when you’re going from A to B, you’ll find trees and rocks dotted
about, and you make slight corrections in your path to harvest the optimum amount. It
doesn’t give you much, but it just makes those boring bits of your journey that little
bit engaging, and rewards perfection. So that’s how I see the bushes in this game as well.
Add to that their long burn-time and they feel like a long-term investment of sorts.
The bridges are similar to the bushes, but I thought should score the most highly because
by burning these, you’re literally burning bridges that you might later want to cross
again! So that’s their unique gameplay mechanic. It’s amazing how much you forget over the
course of several days- I thought I had come up with this, but this was a suggestion from
a friend.
So all of these flammable things have something in common- yes, they burn, but they all behave
a bit differently, to help add variety and strategy to your flaming carnage-spree.
I was imagining dozens of different things for you to burn in each level. I guess because
variety’s cool? But due to time constraints, I was limited to just a few flammable object
types in this project. And I don’t think it suffered for it. In fact, it forced me
to be more creative with the ones that WERE added. For instance, the oil drums would explode,
but WOULDN’T IT BE COOL if this also launched your player up into the air? I had already
gone to the trouble of programming in islands and a falling mechanic- all I had to do was
to make the explosion add a negative falling speed to the player and suddenly I had an
island-hopping mechanic!
Almost like it was meant to be! If you play the end result of this game, you’d think
this island hopping mechanic was fundamental to this game’s development. It’s what
the game’s all about! But it was all borne out of luck, a product of many unrelated decisions
leading up to that moment. It’s so easy to look at the final game and to be like ‘well
it’s obvious a player-launching mechanic was needed’, but having approached it from
the start, it wasn’t to me! But the moment it was added, it felt like I had slotted in
that missing jigsaw piece that made the rest suddenly make sense.
Again, there is probably a ‘proper’ way of adding all of these mechanics to the game,
but I rushed through it all, botching the implementation of each without a care of how
it would interfere with the rest later on. I am a big believer in quantity over quality.
It is always better to rush to completion and to spend the remaining time ironing out
the bugs at the end, than it is to get bogged down with perfection and never to finish something.
Which is the alternative, whether you like it or not.
For instance, for a while the bridge would ignite even if the player wasn’t yet on
fire. This was due to my botched approach to the programming in the first place, but
it was quickly -and easily- remedied once discovered.
How do I go about ‘scoring’ a game about a man on fire who’s running about, setting
fire to other things? Should the points rack up as things are burning? Or just when they’re
destroyed? Both have their merits. Gradual point accumulation as things burn means the
score could tick up like the spinning of a roulette wheel, with more things on fire being
represented by a faster and more frantic clicking. But I decided against this- such a sound could
be annoying, and I don’t really want my game associated so directly with gambling.
So I instead settled on the point scoring coming from the eventual destruction of the
objects, and treated the delay leading up to that moment as being a gameplay mechanic
that the player would have to factor in when planning their route of destruction, and how
closely they wanted to cut their leap into the water at the end of the level. Scoring
the points in a final, large, lump sum like this, especially when accompanied by a memorable
sound effect, felt like the most rewarding pay-off. I considered a video-gamey ‘one
up’ sound, but never got around to it so sounds of destruction would have to do.
I mention gambling for a reason. I hate what money-based transactions in CS:GO have done
to the game. On one hand, it has earned a multi-billion dollar corporation a HUGE amount
of extra money. But on the other hand, I feel it’s got a lot of children into gambling,
has lost a lot of poor people an embarrassing amount of money, has made a lot of people
less happy, and has devalued a game series that I’ve been following since my childhood.
But as the developer of games, I’m aware of how closely related the reward structures
of gambling and gaming are from one another. When I look at the games I enjoy, I’m aware
that it’s engaging in risky behaviour that I find most enjoyable. So it was only a matter
of time before companies made the direct connection between these two things, but for me, I want
gambling in my games to be reserved to an addictive gameplay mechanic, as opposed to
being used to milk my playerbase dry. Rant over.
What’s the difference between fire, and explosions? There is obviously a difference,
but it wasn’t something I had thought about for this project until it was staring in my
face. Thanks to me foolishly rushing through development up to this point, I now had to
backtrack and define where and when ‘fire’ and ‘explosions’ would be used. Explosions
were to be easy ways of igniting stuff, but they themselves needed to be difficult to
ignite. So by having them come from barrels, which can only really be ignited once tipped
up and by having their spilt oil ignited, helped solve that problem, and added an element
of strategy to the plan of destruction. But this meant I had to give everything a
degree of fire resistance so that things wouldn’t just instantly combust upon contact with the
player, or other fires. Getting this balance just right was key to having this game feel
‘rewarding’ rather than ‘frustrating’ or from being too easy.
Suddenly, having to strike a balance between explosions, fire and flame resistance presented
me with a load of essential new gameplay mechanics to implement that I hadn’t planned for,
and yet more things to balance off against each other! And to add to that, a load of
new bugs had been added to the mix following the newly added ‘launch’ mechanic, like
where I was igniting bridges and knocking over oildrums even when flying high over them
in the air. I fixed these things… in the name of realism. But I backtrack in some ways
later on in the name of fun gameplay. I had to compromise on the shadows in this
game. I normally have a layer dedicated to them, since they’re an easy way of making
the graphics look better. But it detracted from the gameplay for them to be at an angle-
it was much easier to represent the player’s position when the shadow for him was at ground
level, directly below him. Gameplay came first and foremost - but it meant sacrificing shadows
for this project. Which I am sad about. As I neared the end of the first day of development,
I had myself a working game. But it wasn’t really a game- it was just a man on fire,
running about wildly, setting everything on fire before plopping into the ocean before
his health ran out. I was blind to this project’s future- would this be just a silly idea that
people would immediately tire of? How could I go about making it a game with replayability?
I’d sleep on it, and tackle problems such as these tomorrow.