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.
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.
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.
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 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.
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.
I am also adding scrap drop bonuses from enemies and chests.
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.