Time to expand my upgrade system and add more upgrades. This is a replayable roguelike — you grind the dungeon, die, get some points, buy some upgrades, grind the dungeon a bit faster and a bit further. Rinse and repeat until you max everything out or get bored and refund. I mean, technically, I don’t need to have upgrades, but it feels like I am missing a big reason to replay if I don’t have any. They are also not that hard to make, if tedious to balance. Thankfully, this being a roguelike, it’s sort of okay if the result starts at “impossible” and goes all the way to “overpowered”.
I am currently planning on three types of upgrades — player, environment and story. Player upgrades directly affect the gameplay with bonuses like health or weapon damage. Environment upgrades improve the game in additional indirect ways, like dropping more scrap or revealing secret walls. Finally, story unlocks are necessary or at least highly needed to progress further in the levels. I may break these down further, like player stat or weapon upgrades. But those are the three main groups.
One of the first things I definitely need is some way to quickly debug player’s upgrades. I will do this by having scripts in scene with custom editors:
Then I can list the info that I want, such as the player upgrades that I am interested in:
And I can list all the definitions as well and add debug buttons to quickly add them:
This basically means I can set up any player upgrades I want to test with.
Making most upgrades, especially direct player ones, is relatively easy. The amount of work spent on making a single upgrade is very small (in the grand of things) for the amount of features you get (in the grand scheme of things). As the most simple example — upgrading health amount. It’s a number I have to increase, but the gameplay result is massive when you consider how long the player can survive.
One “initial” upgrade I am adding is actually having armor or shields at all:
So the player starts with no armor:
They can unlock the first armor with some base amount:
And from there, they can keep upgrading (+2 levels here):
I need to make sure that the max armor upgrade is not available until the base armor upgrade is purchased, so I am adding prerequisites lists to my upgrades, which include previous upgrades and their level requirements, as well as overall min dungeon level where they can appear.
To debug all this, I have my editor debug showing what things are available or not (green – purchase, blue – available, red – unavailable):
I have been thinking about how to make the primary player stats (health, armor, shields) have a more meaningful progression. The player only starts with health and this depletes quickly, so they upgrade it a bunch. After that, they buy and start upgrading armor, which is effective in starting levels versus projectiles. Once they get past this, they unlock and upgrade shields that are effective in mid levels versus energy weapons. Even further down the line, they unlock improved armor versus energy and shields versus projectiles. So they sort of max everything out, but in more discrete steps and across slightly different upgrades rather than three 1-10 sliders. I just feel that the same upgrade where you just click it 20 times feels much less progression-y than, say, 4 upgrades with 5 levels each. If I can adjust exactly what they do slightly, that just makes it even better.
Geez, I wish I could show it in a graph. I’ve been thinking a lot about how to do my upgrade UI and in what format. Flat list, skill tree, something else? I might need to expand my UI significantly if I am to do this properly. The problem is twofold here — I need a place to upgrade and I need a place to view the upgrades.
I also implemented all the obvious weapon upgrades:
These are all just percentages on top of the weapon default values:
I don’t think I will have per-weapon upgrades, as I want the player to consider all weapon to be viable (more or less). Since upgrades costs non-refundable scrap, I don’t want them to spend it on something they might not use. In fact, every upgrade I add is useful.
I don’t have weapon projectile “types” yet, so armor and shields work equally on everything. So let’s do that first:
I will also make a special vitals (mob stats) definition, where I can specify values like:
and also add a special debug preview (kind of like a visual unit test) where I can quickly test values:
And I can check how these 20% rules behave versus different damage types:
The shields can only stop 20% of incoming non-energy damage, while armor can only stop 20% of incoming energy damage. So the player needs to get both the shields and armor to efficiently protect themselves.
I could go all out on these upgrades and have a full damage type vs resistance type matrix, but I think simplicity is king here. The player doesn’t need that kind of detail, and it’s just simpler to explain it when there’s fewer items. In fact, this whole thing can be summed up as: need shields against energy.
And the player can counter and eventually negate this penalty with an upgrade, making their shields and armor useful regardless of enemy weapon damage type:
I am also adding scrap drop bonuses from enemies and chests.
Enemy scrap drop is a little complex because they cannot directly use a bonus value — I have to store it separately in the world for enemies to use it later. And the bonus is also not a whole number, meaning that the desired number of items is a fraction. In other words, if my bonus is 25% then I should be dropping a regularly 1 item as: 1 1 1 2. This means when I drop scrap, I need to record how much I “overflowed” the drop amount (here I want 1.75 drops, which is 1 whole drop and 0.75 left over for the next enemy to drop):
And so the next enemy will end up with whole 2 drops instead of 1:
I can also modify the loot drop pipeline and similarly wire bonuses for the dungeon generator, so that props drop more scrap loot:
And that about takes care of all the immediate upgrades I was planning to make. I have lots of other potential upgrade ideas that I may or may not deal with later. I also need to work on upgrade UI and presentation, which I will do later on.