Sunday, August 23, 2020

Card Games vs Literary Characters: Enhanced and Print Editions

Here's one last little bit of game dev before the semester starts and I disappear for the next four months.

The first is: I've made a print version of Card Games vs Literary Characters at the End of the World! Since the game's original title only describes the narrative and not the theme of the game itself, I named the print version Cardinger. Its like"harbinger," but... card.

I'm really happy with how they turned out! I tried to mimic the original digital card design as much as possible while making enough changes to make them actually readable in-person. I also added flavor text to the cards, space permitting!

I printed the game through The Game Crafter, so if there's interest, I'll make it publicly available for purchase. Otherwise, card sets will be available as prizes at Underground Arcade events, whenever the world reopens.

Working on the print version of the game also has implications for the digital version. Before immortalizing the game in print, I wanted to make improvements to the rules that I wasn't able to do during the game's original brief development cycle. I used the digital game to test these changes against the AI, so I've released an "Enhanced Edition" of Card Games vs Literary Characters reflecting these changes.

 The list of changes is as follows:

  •  A point is only earned at the start of your turn when your deck replenishes, instead of every turn. The previous system was implemented as an easy way to stop the game from locking into a state where neither player can advance their win condition, but it was too passive.
  • You can now retire cards when you have five or more in play, discarding the old card and replacing it with a new one from your hand. This prevents the lock scenario described above.
  • If you do nothing during your turn, you may draw an extra card.
  • Cards with the "devour" ability can have no more than 4 HP, instead of 5. Formerly, a devouring card at max HP was practically invincible.
  •  Cards with the "prosperity" ability now score a bonus point for every 5 cards in hand instead of every 4. If a deck is built to maximize draw power, the prosperity ability quickly becomes overpowered.
  • "Miner Bee," "Combo Miner," "Idealogue," "Evening Tears," and "Vampire Princess" have been buffed. The draw power of the first three has been improved, as has the durability of the latter two.
  • "Blood Knight" has been reworked. He now has an extra HP, but he also now has the "decay" ability, so he's harder to pick off on the turn he's put into play, but easier to defeat after that.
  • The Oz cards: "The Lion," "The Tin Man," "The Scare Crow," and "The Wizard" have all been nerfed. Even with their high cost, they were otherwise absurdly powerful.
  • The final opponent's cards - those from Booster X - have all been nerfed. It is clear that she is way too challenging an opponent, and improvements made to the game's AI have made her invincible with her old deck.

The game also features some small improvements to the AI and UI, as well as bug and typo fixes. A version with the original rules is still available for download.

That's it for now! Enjoy.

Thursday, August 13, 2020

Clark Stanley's Van Racer

I made a short racing game for 1-2 players. Imagine 16 minivans traveling at 240 mph bouncing into each other, and that is this game.

This one was made for the Grid Grind Jam at Glorious Trainwrecks. Each game had to contain 3 elements from a 3-dimensional grid. I chose "van," "garden," and snake oil salesman "Clark Stanley."

I once had a dream about making a 2.5 racing game like F-Zero or Super Mario Kart, but with minivans. So I decided to make the game for real.

While the game embraces its trash aesthetic, this is probably one of the meticulously engineered things I've ever made. From the drift physics, to the graphics optimization, to the 3D audio, this ended up being a lot more difficult to make than I originally imagined!

All of the sound effects were made with my mouth.

Paul Schroeder made the soundtrack. It's awesome.

You can download the game for Windows from Itch or Glorious Trainwrecks.

Sunday, May 24, 2020

Quake Level - Borderworld Hole

I made a short Quake level that I'm calling "Borderworld Hole." I designed it to teach myself the Trenchbroom level editor, and so it very much features a "stream of conscious" sort of design that's a mashup of whatever themes and concepts I wanted to explore in a given moment.

You spend the first half of the level exploring twisted hallways that periodically reconvene at the same rocky pit, but the second half ends in a hectic battle in a massive outdoor arena of sorts, so that's pretty cool.

You can download the level here. Place the ah01.bsp and ah01.lit file in your game's id1/maps directory, and after selecting a difficulty level, type "map ah01" in the game's console to play it.

The map DOES NOT render properly in Quake's original engine. You have to play it using a modern source port - I most recommend Quakespasm.

I had a blast learning how to use Trenchbroom and am affectionate towards the classic Id shooters,  but Quake is too bloody and dark for me to immerse myself in it for very long. I'm going to turn my attention to something a bit lighter next!

Tuesday, January 14, 2020

Card Games vs Literary Characters at the End of the World

I made a single player TCG with 8 opponents, 94 cards, and general oddity.
I really like how this one turned out.
Play it here:
Game Jolt
Glorious Trainwrecks 

Saturday, October 19, 2019

Bloodjak II is free!

From here on out, Bloodjak II will be strictly available for free (on itch and Game Jolt)!

Thank you so much to everyone who bought a copy and supported our team in the months following the game's release - I hope you've enjoyed the game over the past couple of months! However, I believe that the best thing for the game, especially given its communal high score competition, is to grow its player base, and the best thing that can be done to accomplish that is to make it freely available.

Thanks again for the community support and enthusiasm. I look forward to seeing some high scores get topped!

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 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. 



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 or Game Jolt. Thanks!