My upgrade system is very lacking at the moment. I also have no controller-usable UI for upgrading. My upgrade terminal is currently broken. An upgrade can be summed up as (cost, stat boost, level):

Barring pretty UI, this is pretty much it. I can do better. I can do so much better than this. It will won’t even take forever. I could even justify this as “positive feature creep”, as in, features that pay back more than the time saved not doing them. More practically, I want to make features that I would want in a game, even if it costs me time. Because the other cost is motivation, and it’s much harder to come by for me.

I’ve been thinking about upgrade design and progression. I’ve been writing and sketching some ideas down to come up with some reasonably not-too-overscoped features. I want to add RPG-ish mechanic elements to the game. Basically, experience, gear, stats — that sort of stuff. So not really “role-playing”, but the dressing of mechanics that RPGs have.

In short (I will describe these in more detail as I implement each), the features I am going for are: experience, upgrades, gear, scrap. Player gets experience for killing enemies, then they can buy upgrades for levels they acquire. They also collect gear from enemies and chests, and can craft gear items. Some upgrades unlock gear as well.

Before I can get to any actual features or UI, I need to redo my upgrade framework.

First, I am making a new “gear” asset, which is some gear item that the player can equip:

I’m not yet concerned with exact gameplay details, but I do need to have upgrades come from this. Now, my “upgrade” nomenclature fails here, so I will call it bonuses. Basically, the gear provides some bonus:

Of course, it also needs to specify a value for that bonus:

In fact, I can have multiple:

Now, my upgrades are very very similar as before, but they also specify the same type of bonus list:

This is a short description, but it’s a lot of underlying framework to make it all use the same bonus concept, so that I can aggregate bonuses from my upgrades and from my gear. So a health upgrade might give me 20 health and a “reinforced hull” gear item can give me 30 health, and these would sum up.

I removed level, cost and dungeon level requirements from upgrades. This makes them simpler, more streamlined. Levels for upgrades feels too artificial — I rather have a “full” slot for each upgrade that the player unlocks. Similarly, cost will go to crafting gear from scrap rather than using on upgrading. I’ll get to that.

I organized everything into 2 collections — gear and upgrades. These have their own assets and all that:

I also created additional systems. Firstly, the gear system, which stores, saves, loads, and does whatever needs doing with gear. Relevantly, it looks up the bonuses the the current gear provides. I also refactored the upgrade system to similarly work with upgrades, but not bonuses directly. Instead, bonuses are now in the bonus system, which gathers all the entries, calculates all the totals, and then applies them wherever it needs:

Now, I can’t exactly implement the whole system, but I need to test this framework. So I need some editor test/debug scripts for this:

I already had the one for upgrades, which I can adjust for the new spec:

It now shows all the individual bonuses the upgrades provide.

Similarly, I can see gear, adjust unlocks and see bonus totals with gear debug:

Now, this isn’t to spec yet as I need recipes instead of permanent unlocks, but I’ll get to that in the future.

And to see it all work together, a bonus debug that gathers them from all the individual places:

The gear isn’t wired yet, but the upgrades work fine.

This might be slightly over-complicating the bonus system. But at the same time, it’s modular, reusable, clearly defined, and extendable. It has maintenance and readability costs, but it also let’s me iterate quickly and potentially wire bonuses to other things. For example, a per-playthrough bonus, a per-dungeon bonus, etc.

Alright, so that brings the codebase up to speed with the new design direction. Now I need the new features and I will cover these one at a time in future posts.

Related Posts

MicroRogue DevDiary #70 – New upgrade system
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *