Monthly Archives: June 2018

Jetboard Joust Devlog #88 – No No Fun!

There’s a section in Scott Rogers’ (pretty good) book on game design, ‘Level Up‘, where he talks about removing the ‘no fun’ from games. I’m paraphrasing here but essentially what he says is that if you identify the parts of your game that aren’t any fun and remove them, what you’re going to be left with is pure fun.

It’s a simple notion that almost sounds facetious but it actually makes an awful lot of sense, so this week I’ve been identifying a few things about the gameplay in Jetboard Joust that I don’t find any fun and figuring out ways to remove them.

1. Collecting Pickups
Though it’s an integral part of the game, constantly having to ‘land’ to collect pickups was proving to bit a bit of a chore. It would often lead into crashing into buildings by accident, getting stuck, losing momentum etc, all of which were no fun. Basically the game is generally too fast paced to allow for movements that require a lot of accuracy and I have to keep focussed on the core of the game which is blowing stuff up. This is not a platform game and it is not ‘Thrust‘!

So I have equipped the player’s jetboard with a tractor beam that automatically activates when it detects a pickup is nearby. Now the player just has to hover above a pickup in order to collect it allowing them to concentrate on the combat.

2. Pickup Generation – Ammo and Health
Whilst working on the bosses I realised a fundamental flaw in the way pickups were awarded. Previously they were only really awarded when an enemy was eliminated which meant that tackling a large enemy with an underpowered weapon would almost guarantee that the player would run out of ammo which was no fun at all. A similar issue existed for health pickups (though it wasn’t quite so detrimental to gameplay).

To overcome this issue I’ve allowed pickups to be awarded mid-battle. I have a tracker that tracks the mount of enemies killed, the amount of health deducted from enemies, and the amount of health lost by the player. If either of these passes a certain threshold a health or ammo pickup is generated as appropriate.

Ammo thresholds are based on the current armed weapon meaning that very powerful weapons that can take out a bunch of enemies at once (e.g. the RPG) are treated very differently from weaker weapons or weapons that can only really take out one enemy at a time. I still have to input and tweak these values but the structure is now there.

Lastly I decided to make the default weapon (the pistol) have infinite ammo. Seeing as I can never really have the player run out of ammo, allowing the default weapon to run out and automatically awarding an ammo cache (as I was previously doing) seemed like a pointless chore – it was a distraction from the core gameplay and no fun.

3. Pickup Generation – Rockets
Many people have commented on how much they like the jetboard ‘rocket attack’ and that it should be more integral to the game. Running out of rockets was no fun. Based on this feedback I have made the way that extra rockets are awarded more transparent (it’s based on the number of enemies killed and their difficulty) by integrating a visual indication of when the next rocket is to be awarded into the HUD. Now the rocket icon ‘charges up’ as enemies are killed making it easy to see when a new rocket will be awarded and thus allowing the player to make the most of their limited allowance.

4. Falling Off The Jetboard
Previously, if the player used the rocket attack to jump from their jetboard and the jetboard (but not the player) got blocked by a building mid-flight, the player would fall from their jetboard and lose a life. Losing a life like this was definitely no fun and often left players scratching their head wondering what had happened.

So I have got rid of that mechanic and implemented partially-destructible buildings instead. Now if the player’s jetboard gets blocked by a building whilst they are in mid-air above the building, the section of the building ‘above’ the jetboard will get destroyed. I may even add a few bonus items hidden inside buildings like to encourage this behaviour, destruction in games is generally fun!

5. The Gatling Gun
This weapon was simply too clunky. Even whilst playtesting I always felt slightly annoyed when I picked it up as it was both irritating to use and pretty ineffective, in other words it was no fun! The reasons for this were straightforward – the initial rate of fire was too slow and the recoil was too great. Upping the initial rate of fire and lowering the recoil have vastly improved the weapon handling and now, hopefully, this weapon will hold its own alongside the others.

6. Explosive Affiliation
I was always dithering about whether to allow the player to get blown up by their own explosive weapons (grenades, RPGs etc). Now I have decided that getting blown up by your own weapons is no fun, so I’ve removed it. This is not Call of Duty!

I have also added another subtle boost to the player in that, if the player destroys an enemy explosive (by shooting it), its ‘affilation’ is switched as if it was the player’s weapon in the first place. This allows the player to use an enemy’s weapons against them and, again, abides by the mantra of more destruction == more fun.

7. Explosive Damage
There were various inconsistencies with the way explosives worked which could make them difficult to predict and less fun to use. Consequently I’ve switched to using a raycasting algorithm for calculating explosive damage, this provides much more predictable (I hesitate to say ‘realistic’) results when explosive damage is blocked by buildings or other sprites.

As the shotgun also suffered from similar problems I’ve also switched to calculating shotgun damage using a raycasting method.

That’s all the ‘no fun’ that was really bothering me but if you’ve played the alpha and think of anything else please do let me know! Many of the above suggestions originate from player feedback.

Dev Time: 2.5 days
Total Dev Time: approx 209.5 days

previous | next

mockup_3x
The Tractor Beam – Crash Landings No Longer Necessary!

mockup_3x
Now You Can See When The Next Rocket’s Going To Be Awarded

mockup_3x
Working On Destructible Buildings

mockup_3x
The More Fun Gatling Gun

Testing A Raycasting Algorithm For Explosive Damage

Jetboard Joust Devlog #87 – Hidden Depths!

I always loved those bits in Super Mario World where you travelled down a pipe and entered a semi-secret room stuffed full of coins. Sometimes there was a mini-level down there – and the memory of discovering those hidden places, along with the way the background music shifted to a minor key, still gives me goosebumps. It’s one of my fondest gaming memories.

It’s replicated to an extent in other games. There’s the little side-caverns in Downwell, or the bonfires and merchant areas in Dark Souls. Often these places offer some kind of refuge from an otherwise hostile environment as well as a generous reward in the game’s currency or upgrades.

Though I’d never planned anything like this at the start of the game I wanted to add something similar to Jetboard Joust – and having the bosses guard hidden treasure chambers seemed like a good solution. Not only does it give a reason for the treasure chambers to be there (and a heightened sense of reward when they’re unlocked), but it means the bosses are semi-optional and don’t exist purely to block progress through the game (a common gameplay mechanic that I’ve never been overly fond of).

As I’d never intended having the player travel below ground level in the game, or a camera that moves on the vertical axis, introducing a subterranean component had a fairly substantial knock-on effect in exposing the general laziness of my coding and there were a number of things that had to be fixed in order to achieve this. Fortunately none of these presented serious issues but things could have been a lot easier if I’d have planned this from the start. So the lesson (as always) is – think very hard before you cut corners by saying to yourself ‘Oh, I’m never going to need to do x, y or z.’ as you’ll probably change your mind and it’s always easier to build functionality in from the start rather than try and retrofit it later!

I spent a long time on the art for both the chambers themselves and the entrance to the chamber but I must admit to having some help here. Whilst looking for reference material I came across a Unity asset pack that was remarkably ‘on point’ for the game’s visual style – in fact one of the images I used for reference when formulating the overall style was from this pack (I never realised it was an asset pack at the time as I found the original image on DeviantArt)! Though it made me feel somewhat dirty (why I don’t really know) I purchased this pack and the internal chamber backgrounds and the tower thing on the entrance originate there (with various degrees of editing involved). I may alter these more before release, not because I’ve done anything ‘wrong’ in using an asset pack, I just hate the idea of another game appearing with similar art when I’ve spent so long drawing everything else from scratch.

I’m pleased with the end result. There’s a bunch of details in there that I didn’t have to add but wanted to include for added atmosphere such as the drips falling from the chamber ceiling, the spooky eyes in the background, and the dust falling from the chamber doors as they open. I also wanted there to be a reason to use a weapon down there which is why the main reward is enclosed in a glass case! It’ll probably never give anyone goosebumps like Super Mario World but, once I add a some spooky background music, hopefully it’ll do a passable impression.

You can see the sequence of events for unlocking and entering a treasure chamber in the video – note that I’ve severely nerfed the boss for demo purposes!

Completing this means I’ve upped the progress level for the game to 80% complete on TIGSource – hurrah, major milestone! Unless I add another boos this should be the last significant addition to gameplay.

Dev Time: 5 days
Total Dev Time: approx 207 days

previous | next

mockup_3x
I Wonder How I Open This? At The Chamber Entrance…

Jetboard Joust Devlog #86 – Bosses Defeated!

At long bloody last!!

Finally finished all the boss battles – well, I say ‘all’ but I do have an idea for a fifth but I’m not going to add that until the rest of the game is complete (if I do at all).

Looking back through my files I started this process on the 13th March, so that’s around 2.5 months of elapsed time. It used to take me that long to bang out an entire J2ME game! No wonder it’s been doing my head in. There’s been the blogging as well of course, and preparation of GIFs etc for Twitter, plus a couple of bank holidays and (unlike most indie devs) I’m determined to maintain a sensible work/life balance so I only allow myself to work on this four days a weeks (otherwise I’d go completely nutso). Still, I think that’s far too long by anyone’s standards. Ironically though, despite the fact that I’m probably at the lowest-ebb I’ve been motivation-wise throughout this ridiculous project, in these bosses I’ve completed the work I’m probably most proud of throughout.

So this last week or so I’ve mainly been tweaking the first two bosses, the Stinger and the Snapper, to make them live up to the standard of the last two. When I started this process I had no intention of creating boss fights – these were just going to be ‘normal’ enemies (only larger), but as time went on I just had to admit to myself – ‘Face it, these are boss fights and you should approach them as such’. Consequently I needed to go back to the first two and approach them with this mindset.

1. The Stinger
This battle only comprised of two stages so I felt I had to add a third stage to make it consistent with the others. I added a second stage attack whereby, once the stinger’s abdomen is destroyed, it reveals a hive that unleashes a swarm of mini-stingers to attack the player.

To create the swarming effect I have a HiveMind class that is basically an invisible sprite that either tracks the player or returns to the boss. The individual creatures always swarm around this central point in an offset eliptical motion which looks random yet somehow predictable.

I also added audio for the various attack stages and made a bunch of code changes under-the-hood to make the way things were structured consistent with the other bosses (this was my first boss so some of the code was pretty hacky as I worked out the best approach to do things).

Oh yeah, I also now have the boss’s creepy legs get shot off one at a time in the third stage for added drama!

2. The Snapper
I spent quite a long time on this one as I just wasn’t happy with the ‘rhythm’ of the gameplay in the second and third stages. The motion and attacks were too clumsy and the ‘shredder’ weapon fired in the second stage was pretty much impossible to avoid which made the whole fight feel too random.

So I completely pulled apart the AI for the movement and improved it considerably, including adding a ‘reverse’ attack which I think plays out pretty well. I also swapped the shredder weapon for limpet mines which are can be shot or avoided by the player.

In the third stage I improved the exposed ‘brain’ animation considerably and turned this into the boss’s weak point for said stage (this seemed too obvious an opportunity to pass up). I also added another attack for this stage where bubbles containing strange fossilised plankton creatures are fired from the boss’s ‘exhaust pipe’.

Finally I added audio for all the various attack stages.

3. General Testing
Then I went through all the bosses testing them against the Flamethrower and Gravity Hammer weapons as these operate rather differently from the other weapons.

The Gravity Hammer particularly is a right pain in the arse as it affects the motion of any enemy it touches, effectively taking control of an enemy for a short period of time. As I never really planned for this properly when I structured my initial code it leaves things open to some nasty bugs. Oh well, lesson learned!

I also made sure each enemy and mini-enemy has an appropriate icon on the scanner (not really happy with the stinger one – looks too much like an aerosol can), added an obvious ‘hit’ effect for when the player takes damage by touching a boss, and finally applied some explosions worthy of such giant enemies.

Thank God that process is over!

Dev Time: 6 days
Total Dev Time: approx 202 days

previous | next