Tag Archives: gameplay

Jetboard Joust Devlog #100 – Die and Try Again!

This blog should really have been Configuring Things Out pt. 2 but I thought ‘Die and Try Again’ was more appropriate really.

Now all the enemies and weapons are finally done I’ve been going back over the game worlds, playtesting and (re)adjusting all the various character/weapon stats and levelling rates. The only way of balancing the weapons is to simply play the game a lot, and if I feel I’m either avoiding particular weapon because it’s too weak, or that I’m constantly gravitating towards a particular weapon because it’s too overpowered, I tweak the stats as appropriate. It’s been a very time consuming process and I have to say I’ve been at something of a low ebb whilst doing it.

Unlike fixing a bug, you don’t ever get to the point where you think something is ‘done’, and I know I’m going to have to go through this whole process again at least one more time to refine things further before the game is complete. It’s really getting to me now.

The thing that’s made this phase so much tougher than the first configuration ‘pass’ is that I’ve been through every single boss and mini-boss fight in the first four worlds and attempted to adjust the difficulty for each. There are over fifty of these and, by nature, they are supposed to be tough, so this entails a *lot* of failure both in terms of dying in-game and in terms of setting the difficulty level either too easy or too hard.

Most of these challenges are mini-boss battles featuring the Guardian enemy and a new weapon unlock or upgrade. To maintain a certain amount of narrative ‘flow’ (and to stop me being lazy) I’m having the enemies guarding the unlocks armed with the same weapon they are protecting. The strength of the enemy is heavily dependent on the strength of the weapon, therefore a tweak to the stats of said weapon (because I think it’s too weak or too strong in-game) has a knock-on effect in every single battle that features it. It’s a cyclical process and one that I’m starting to think could go on forever, like painting the Forth Bridge. On a good day though I see it more as a kind of gradual ‘whittling down’ with every pass getting me nearer to the ideal balance.

It also makes a difference what weapons are available to the player during these battles. I was choosing these weapons completely randomly (but based on a consistent seed) though towards the end of the process I realised this wasn’t working and I needed a better balance of weapon choices. Consequently I’ve divided the weapons into four categories – long range, short range, wide range and explosive, and I make sure a balance of weapons from each category is chosen. I think I may ditch the consistent seed as well so each time you enter a level the weapon choice is a lottery, albeit a balanced one.

There’s also been a myriad of bugs and other gameplay tweaks I’ve made along the way though at this stage I’m trying to restrict myself to fixing bugs/tweaks that actually affect the balance of gameplay and noting everything else down on Trello cards for later attention. There’s currently around fifty of the Trello cards (groan) and there’s at least another ten things I haven’t noted down yet!

I’ve also been back through the first four major boss fights and made a proper attempt to balance the difficulty of these with the (rough) stats the player should have achieved by that point in-game. If you’ve been following this blog you’ll remember how much time I’ve spent on these boss fights already, so it’s been doubly demotivating having to go back to them, debug them again, run through the fight procedure again and again AND again whilst discovering yet more bugs and issues that need fixing. On a positive note though, it’s been nice to revisit them in different colour palettes.

Lastly, and I know this is going to sound like archetypal first-world moaning, I’ve been surprised how physically exhausting this process has been. Basically playing (often ludicrously difficult) boss fights for eight hours a day for eight or nine days straight takes its toll. I try to be as careful as I can be about posture but my shoulders ache, my wrists and elbow joints ache, and my back is fucked. Yes, I know it’s not exactly working down a mine, but being physically in pain doesn’t do wonders for one’s motivation. I can’t wait to finish this game and take a break from this shit.

Oh yeah – one thing that’s kept me going through this process is the fact that I can just turn the game sound off and listen to music. I’ve finally succumbed to subscribing to Spotify and have been listening to a lot of Tangerine Dream. Strange coincidence – I finally got round to watching Netflix’s enjoyable Bandersnatch interactive movie at the same time and what does that feature? A ZX Spectrum game developer slowly going insane trying to finish a game whilst listening to lots of Tangerine Dream! Weird…

Right, on to those Trello cards…

Dev Time: 8.5 days
Total Dev Time: approx 268 days


The ‘Spinner’ Boss In Colour

The ‘Squirmer’ Boss In Colour

R.P.G. Guardians. Die and Try Again – and Again, and Again…


Jetboard Joust Devlog #95 – Configuring Things Out pt. 1

This is one of those devlog entries that seems kind of dull because there’s been a lot of ‘under the hood’ type goings on and not a lot of eye-candy to show for it.

But, it’s taken time and it’s really important to the game’s development so I’m going to blog it anyway, boring or not!

What I’ve been focussing on is the overall structure of the game world and how difficulty progresses throughout the game. At this stage it has been very much a first pass at this, as much about providing the tools to allow me to tweak gameplay efficiently as it has been about balancing the gameplay itself.

I’ve broken down what I’ve been doing into three key tasks:

1. Code Refactoring
As with any game of significant scope, there are multiple interconnected parameters that affect gameplay difficulty in Jetboard Joust and it’s a hell of a lot easier to tweak things if the code that manages these parameters is in one place rather than split across a myriad of individual class files. Consequently I’ve set up a static ‘Config’ class that contains all the algorithms and configuration parameters for pretty much anything to do with rewards and difficulty throughout the game. This has involved a lot of tedious cut and paste but I know it’ll be worth the effort in the long run (it already has really). I’ve set up generic parameters here for the amount things like enemy health and weapon damage/difficulty scale throughout the game so at least I have a baseline to work with and can tweak individual scaling from there if necessary.

2. Mapping
I’ve created a template in InDesign for mapping out levels in each of the game worlds and have been through this with a first pass attempt at placing weapon unlocks and new enemy ‘reveals’ in each. There seems to be enough content to fill four level ‘pyramids’ of around twenty rows each with a reveal rate of a new enemy or weapon every couple of rows. I need a couple of different ‘non-jetboarding’ enemy types but was expecting that anyway, I added an additional jetboarding enemy to span the difficulty gap between the ‘minion’ and ‘master minion’ which was fairly simple to do. I may make the fifth and final world smaller, probably ten rows, with the final boss right at the end.

3. Auto-Levelling
In order to be able to arbitrarily test game difficulty I need to be able to jump to a particular level and have an idea how the player might have ‘levelled up’ at that point. What weapons will they have unlocked and how powerful will they be? What will their base health be? It’s not straightforward to figure this stuff out so I ended up writing an algorithm that takes a destination point within the game pyramid, figures out the location of each treasure chamber before that point, then does a mock play though of the game to unlock each treasure item. On the way I collect the cash that would be awarded for defeating enemies, rescuing babies, and completing ‘sectors’ (rows of the pyramid). Once cash is earned it is spent on the most expensive upgrade available.

It took quite a while to test this code and get it working but it’s going to be invaluable for testing as I can now start the game at any point and have the player ‘levelled up’ as appropriate. Using this code I can also monitor things like how long it will take to level up a particular weapon, how much a player might earn for completing a level at the point weapons are unlocked (hence what a sensible starting price for updates might be) and all sorts of other stuff I haven’t even thought of yet!

4. Basic Gameplay Testing
Using the code above I began going through the game to check and tweak parameter scaling at key points (i.e. the ‘reveal’ level for each weapon and enemy) to make sure things seemed sensibly balanced. Unsurprisingly they were way off to start with but after much fiddling I’ve reached the point where relationships at least seem workable, haven’t done the treasure chamber guardians and bosses at all yet though.

One thing that became apparent was that weapons that are unlocked earlier in the game need to have a greater number of upgrade levels than ones that come later on, otherwise they either ‘max out’ too quickly and end up becoming useless on high level enemies or they cost far to much to upgrade in the early stages. This was particularly apparent with the default weapon (the pistol) so I ended up adding a new default weapon (the .45 magnum, essentially a pistol on steroids) which is unlocked about halfway through the game and has enough grunt to take the player through to the end of the game.

I also ran into a shedload of bugs, it’s been ages since I looked at many of these enemies/weapons so there’s a ton of small issues created by various changes I’ve made. Fixed a bunch of them as I went along (partly why this phase took so long) but I’ve still got a very long TODO list in Trello!

Dev Time: 6 days
Total Dev Time: approx 247.5 days


Mapping Out The Levels

Debug Output From The Auto-Levelling Code

A New Type Of Minion Enemy