Monday, August 12, 2019

Bloodjak II Version 1.0.1

Firstly, I had just discovered that it's been impossible to make purchases off of Bloodjak II's Game Jolt page for the past week. I've since fixed it. I've never had this issue before when launching anything on any platform, and can't apologize enough. Thank you for your patience.

Otherwise, we've launched a small update to the game. Downloading the new version is recommended but not required.

Bug Fix
  • Jack out sound no longer resumes playing if the player dies during jack out and restarts the game through the pause menu
Other Changes:
  • If the player isn't logged into Game Jolt, the scoreboard now shows the Guest Scores by default
  • Can now change the ship color in the options menu by tapping the A key or A button
  • Version number is now on display in the menu

Saturday, August 10, 2019

The Story of Bloodjak II's Procedural Difficulty (Devlog #3)


From the perspective of difficulty progression, I had two objectives with Bloodjak II (which is out now on itch.io and Game Jolt). The game had to be infinitely playable while also never ceasing to become more difficult. 

Practically, this is due to the game's nature as a single score attack game type - the game cannot have a score ceiling or end, but the game's difficulty must, at some point, be able to overcome the player's skill. If there were a score ceiling, then the high score competition would end as soon as somebody hit it. If the game's difficulty plateau'd, then a player of a certain skill level would be able to play indefinitely.

The difficulty of pursuing both of these objectives simultaneously is that the game must always be fair. This is, of course, almost always an essential rule of thumb for game design, especially for a skill based game. The game's difficulty must constantly escalate, but never to the extent that it becomes impossible. Not only does this introduce a skill ceiling, but it also makes the game needlessly frustrating. Part of what makes the Bloodjak games work is that player death is always the result of player error. That is what keeps people making run after run after run.

Bloodjak the first technically accomplished both of these goals, but it had other issues. Not only were waves of enemies generally homogenous (they usually consisted of a collection of the same enemy type), but there was a lot of dead time in-between waves, and enemies also had a tendency to trickle it one at a time. I borrowed a lot of code and concepts from the original when making the sequel, but the enemy spawn algorithm was something that needed to be rewritten from scratch.

 

Bloodjak II's Spawn Algorithm - The First Iteration 

 

Enemies spawn in waves at gradually shortening intervals

Every set number of seconds, a wave of enemies spawns. If there are no enemies on the screen, then the next wave spawns within a half second to reduce dead time. Waves spawn more quickly over time.

However, the player does need a breather every once in a while. Every group of waves is collected into a group of waves, or a meta-wave. Each meta-wave consists of at least 6 waves, and on average gets longer as the game progresses.  There are an extra few seconds of dead time in between one meta-wave finishing and another beginning that are unskippable. The game's background also has a chance of changing during this time to better punctuate the end of the sequence.

After certain waves, new enemy types are introduced, and the maximum number of enemies that can spawn increases. The chances of more difficult enemies and larger waves to spawn increases over time.

This overall served as a solid foundation from which I was able to build the rest of the game, but it produced some immediate problems:
  1. There was no inverse correlation between how many enemies spawn and how powerful those enemies are. At times, you would be as likely to spawn a pair of small "fighters" as you would six large "destroyers."
  2. Enemy combinations would be produced that were excessively difficult. If they are arranged on the screen in just the right way, it may be impossible to survive when ten "heavy" ships clutter the screen with diagonal shots..
  3. Enemy combinations that were otherwise surmountable would suddenly fill the screen with lasers in ways that were nearly impossible to dodge. Firing patterns were often synchronized within large groups of enemies. 
  4. The early game would sometimes lack variety, even if it were hypothetically possible for the game to produce a wide variety of encounters. If an enemy's first appearance can be as early as wave 14, they still may not appear until wave 30.

 

 

Imposing Hard Limits

 

Some hypothetical enemy combinations are needlessly difficult

An obvious solution to the first problem would have been to assign a difficulty value to each enemy type,  impose a total limit on the overall game difficulty, and increase that difficulty limit over time. For example, you could decide that a fighter is worth 1 point while a destroyer is worth 10. The difficulty limit would start out at 5, meaning that the most difficulty encounter would consist of 5 fighters. When it increases to 10, anywhere up to 10 fighters could spawn, or a single destroyer. When it increases to 20, two destroyers could spawn. This prevents the problem I had where it was hypothetically possible for 10 destroyers to spawn in a single moment.

The problem with this system is that it wasn't compatible with the system I already had in place. As it stood, I already had a hard limit on the number of enemies that could spawn at a time. Combining this with a point based difficulty system above did not produce the desired results - enemy waves just got blander.

Instead, whenever a wave spawns, the game counts each enemy that spawns within it. Only the first two ships of a wave has a chance of becoming a powerful enemy like a destroyer. The first four or so can become intermediate enemies like heavies. Any enemy has the chance of becoming a "popcorn" enemy like a fighter or a bomb - the screen can flood with them without any serious consequence.

This mostly produced the desired effects. Small waves were more likely to consist primarily of larger foes. Larger waves were more likely to consist mostly of smaller ships, but may contain a managable number of more powerful enemies within them.   

Furthermore, certain hard limits on the total number of enemies of a type had to be imposed. The game is manageable with a single heavy on the screen, tricky with two, difficult with three, and often a nightmare with four. Generally speaking, only three heavies will be on the screen at a time.

However, I had to be very careful when imposing hard limits on the difficulty of enemy spawns - if I impose too many limits, it would create a difficulty ceiling, which, as stated, needs to be avoided! Thankfully, enough difficulty parameters were able to increase indefinitely that I was able to maintain my objective of infinitely progressing difficulty while imposing a handful of limits.

 

Making the Impossible, Possible


Regarding the third problem, one solution would have been to further limit the number of enemies that appeared on the screen at once.

That would be a boring solution for a boring game. An important aspect of the game is to make the player feel as though they must, and are able to, overcome great odds.

Enemies will often "take turns" firing
I did a number of things to preserve a high enemy count while not making it a death sentence. The first was that I put a limit on the number of enemy projectiles on the screen. If that limit were breached, then any ships present on the screen would have to wait to fire again until the screen clears of projectiles.

But doesn't that make the difficulty created by flooding the game with enemies illusory? No. A screen with twice as many enemies will still mean that the player is bombarded with twice as many projectiles - it's just that the player is attacked more frequently instead of being attacked all at once.

Furthermore, remember how the game counts each enemy that spawns in a wave? Enemies that are counted first will fire before those that are counted later. Enemy 1 attacks first, then 2, then 3. The result is that firing patterns are more staggered. Not only does this make individual waves of attacks easier to manage, but it also means that the player is spending more time dodging lasers.

Not only do both of these solutions make unwinnable situations winnable, but they also, counterintuitively,  make the game more intense. There is less dead time between volleys of attacks, meaning that the player is spending more time responding to fire and less time waiting.

 

A Designer's Touch


The fourth problem is one that is hard to solve with procedural generation. While all of the problems are caused by randomness, that the early game is occasionally dull is a problem that is more inherent to procedural generation itself.

When a game randomly generates content, there is a range of possibilities. In the early game, it is necessary that some of those possibilities are relatively uninteresting (oh no! a single enemy fighter spawned!). The problem is that, sometimes, the game only generates bland situations. Sometimes, you only roll ones.

There are ways to change the spawn algorithm to correct for this, but not anything that I could achieve during the last week of a brief, two month development cycle.

The game's first four waves

So, there are a handful of waves in the game that are predetermined. The first wave is always a fighter. The second wave is always two or three. The third is always a heavy (the earliest moment a heavy could've otherwise been spawned randomly). The random generation kicks in on wave 4, and the rest of the predetermined waves are scattered throughout.

It's not an ideal solution for a game where each run is supposed to be unique, but the predetermined waves are rare enough and feature enough random variation within themselves they are mostly invisible, and when they are visible, they are justified. 

 

Conclusion


How did I do overall? Improvements could always be made, but not only did I succeed in achieving my most critical design goals (achieving theoretically infinite playtime with theoretically infinite difficulty), but I did so in a way that improved upon the difficulty algorithm of the last game. Compared to the original, Bloodjak II is more varied. The player spends less time waiting for enemies to spawn or do something, and more foes can spawn at a time.

If you want to evaluate my work as a designer for yourself, feel free to get Bloodjak II from either itch.io or Game Jolt. Thanks!


Tuesday, August 6, 2019

Bloodjak II: Now available

I am pleased to announce that Bloodjak II is now available.

You can buy it for $3.99 from Game Jolt and itch.io!

It's good! I'm proud of it, and I'm proud of my team.

Here's the trailer:



Friday, August 2, 2019

Bloodjak II Devlog #2 - Where's my Game, Bruh?


Bloodjak II was supposed to ship on August 1st. Today is August 2nd.

A number of factors have lead to us delaying our release by a few days, the two main ones being 1) video games are hard to make and 2) I had been hospitalized for a couple of days due to my appendix becoming inflamed and being removed from my body. We are in the final stages of development and will be shipping within a few days.

If you dig through the history of this blog (don't) you will find a number of posts where I apologize for a game not being released, insist that it will be released soon, and make the claim repeatedly over the course of a year, after which the game is belatedly released (or not). This is not one of those posts. Bloodjak II is fully playable and is awesome - almost all of the remaining work is UI stuff.

Here are some cool GIFs showcasing some new enemies if you haven't been following us on Twitter.



Sunday, July 21, 2019

July News (Artscape, Charm City Meadworks, Social Media, and Bloodjak II)

Hello! It's been a busy month, and I just want to take a moment to poke my head in and address the many game projects and events I am juggling.

Regarding Underground Arcade and our events, past and future

First of all, thanks to everyone who attended Gamescape at Artscape this past weekend! It's a favorite event of ours (being Underground Arcade Collective), and that is largely due to the people. I personally loved watching many of you connect with our work in some fashion over the course of the festival. Shout out to IGDA Baltimore's Jonathan Moriarty for doing a stellar job of running the event.

Final high scores for the weekend are as follows:
  • Bloodjak II - 11,070 pts - Dom
  • Soul Eater - 6728 pts - Liz
  • Diablow - 14,264 pts - Stephen
  • Star Kid - 5443 pts - Kai
  • Aaargh! Condor - 1490 pts - Mr. Older
  • Koi Puncher MMXVIII
    • 30 Koi Punched in 1 minute - Brandon
    • 62 Koi Punched in 2 minutes - DDD
  • Monster Truck Power Fantasy - 47,600 pts - Dom (again)
  • Astro-Path - 6000 pts - Conlan
  • Fungilluminati - 2440 pts -Taylor
Those are some big numbers! I am impressed by everyone's performance. 

We will be showcasing in Baltimore again at Charm City Meadworks on August 14th! Facebook event details are here. We can't wait!

Speaking of Underground Arcade, you can now like us on Facebook (here) and follow us on Twitter (@UnderArcade). We're running for our third year now, and a social media presence has long been overdue.

If you're looking for our games, mine are here, Stephen's are here, and John's are here.


Regarding Bloodjak II

My apologies for the lack of Bloodjak II devlogs. You can better follow the game's progress on Twitter (@BloodjakII). The game is still set to release on August 1st, which means that little time can be spared for devlogs. While I hate to leave folks relatively in the dark, the game will be better for it.

I had a blast sharing the current build of the game as part of Underground Arcade's collection last weekend - we're on the right track, and I can't wait to share the game with the rest of the world.

Saturday, June 15, 2019

Bloodjak II Devlog #1


Hello.
We are making a game called Bloodjak II.

What kind of game is this?

It's the sequel to 2015's Bloodjak, an arcade-style shoot-em-up set in the darkest corner of cyberspace.

Footage from the original

Besides its fast-paced and unforgiving gameplay, what sets Bloodjak apart from other games of the genre is its scoring system. Dead players do not get to submit their score - in order to save your score, you must determine when to end your run and survive for the remainder of its duration. Complicating this is the fact that your ship is fragile and is destroyed in a single hit, resulting in a high-stakes, but rewarding, play experience.

The original version of the game was created in 48 hours for the 2015 Indies vs Gamers Jam at Game Jolt. It ranked in the top 10% of over 369 entries for the jam, and as a part of Underground Arcade Collective's exhibit, it's been widely enjoyed at the festivals and conventions at which we've shown it. While I've made countless small improvements over the years, the original is still constrained by the brevity of the original jam from which it was produced.

So, I'm leading an effort to remake the game, bigger and better than it's ever been. The game is being developed as part of Philly Game Mechanic's Profit Jam, an initiative to make, ship, and sell a game within two months. I've been itching to revisit Bloodjak  for a long time, and the Profit Jam seemed like the perfect opportunity.

What new stuff will be in the sequel?

At the very least, Bloodjak II will feature new enemies, more bosses, improved pacing, faster and more intense combat, improved visuals, and higher quality audio. My goal is to make a more complex, action-packed, and visceral experience.

The original was made a small team consisting of myself and Geoff Backstrom, who composed the game's music. To help deliver on the promise of a better game, I'm working with a larger team this time - Alex Cole and Dan Halma are handling the game's sound and music respectively, and Danielle Vuono is handling the visuals. They're all very good at what they do, and I am excited to work with them!

I'll be sharing regular updates about the game's development in the coming weeks - you can subscribe to this blog's RSS feed from the bar on the right, or you can follow me on Twitter @alchiggins. Thank you!

Wednesday, June 5, 2019

We Meet in the Dungeon


We Meet in the Dungeon is an asymmetrical card game for two players. I originally made it for Philly Game Mechanics' Try-a-New-Jam event earlier this year. The objective of the jam was to attempt something I've never done before - hence, the existence of this multiplayer tabletop card game.

Each participant assumes one of two roles: that of the Dungeon Player, or that of the Adventuring Player. The Dungeon Player is building a dungeon filled with monsters and traps while gathering darkness to summon a powerful overlord monster in an attempt to complete a sinister objective. In response, the Adventuring Player assembles a team of adventurers to conduct raids on the dungeon, attempting to recover two MacGuffins from the Dungeon Player and stop their ritual.

You can download the rulebook and card sheets from Itch.