Hello! I want to create a upgrade system which has many tiers to it. For example, the player chooses what skill to upgrade and each skill can be upgraded separately a certain number of times. And since each skill also has visual changes, how to go about keeping track of everything and also enabling and disabling new skills and visuals What is the most efficient way to go about it?
Thanks!
There is just way too many things you might mean with this. I dont think anybody can give a precise answer like that. Are we talking about a upgrade tree per skill? Are upgrades exclusive, or can you get two at the same tree depth from different paths, which might conflict? How complex are the upgrades?
What can you change? What cant you change, specifically?
That’s things you have to think about, as there is no such thing as a perfectly flexible system.
Any implementation will always put stones in the way of something else.
For a basic, but pretty flexible, system i would start by defining skills mostly through their attributes. The attributes must describe everything the skill can get through upgrades. This obviously includes things like damage and range for most things, but might also include a projectile count, or a melee hit count, debuffs that are being applied to the enemy, or buffs it might apply to the actor. The set of these will be different for each skill, so while you can make an OOP hierarchy, each skill wants their own class in the end.
Upgrades adjust these stats. Increase damage, apply bleed on hit, add projectile count, …
They are loaded once when needed. The values are then maintained in memory, only save if the player buys a new upgrade.
You have full control over what these might do for each skill. Multiprojectiles for the fireball could mean that they fly of in a spread, or are fired in a row. If there is only one such perk, you can hardcode the behaviour. If there is several perks, the multi-projectile behaviour itself should be an attribute (like an enum). Similarly, a sword attack hit count might behave differently on a sword slash, than on a dash. The latter might dash to X additional enemies instead of hitting the same enemy X more times.
More complex things like bleed or low-health execution can be checked on hit of the attack, or be passed to the shot projectile which then needs to do these things on hit.
There is lots of things to think about. There is about a gazillion different upgrade systems out there, and likely as many approaches to implementing one. It all comes down to precisely what you want. The above might work, or point you in the right direction, or completely miss the point. In the latter case i’d ask you to heavily ramp up the description details tho.
1 Like
Sorry for not specifying but the upgrade system that I want does not lock the player from accessing any skill. You can go to tier 4 of one skill and then upgrade another skill to tier 2 and then if you wish, you can move on to skill 5 and upgrade it to tier 6. All skills are independent of one another.
Won’t making a new class for every skill lead to messy code and lots of scripts? Is there a way to create functions for the skills and then enable and disable those functions through one script which keeps records of tiers and types of skills?
These things (upgrade systems, character customization, inventories, shop systems) are fairly tricky hairy beasts, definitely deep in advanced coding territory. They contain elements of:
- a database of items that you may possibly possess / equip
- a database of the items that you actually possess / equip currently
- perhaps another database of your “storage” area at home base?
- persistence of this information to storage between game runs
- presentation of the inventory to the user (may have to scale and grow, overlay parts, clothing, etc)
- interaction with items in the inventory or on the character or in the home base storage area
- interaction with the world to get items in and out
- dependence on asset definition (images, etc.) for presentation
Just the design choices of an inventory system can have a lot of complicating confounding issues, such as:
- can you have multiple items? Is there a limit?
- if there is an item limit, what is it? Total count? Weight? Size? Something else?
- are those items shown individually or do they stack?
- are coins / gems stacked but other stuff isn’t stacked?
- do items have detailed data shown (durability, rarity, damage, etc.)?
- can users combine items to make new items? How? Limits? Results? Messages of success/failure?
- can users substantially modify items with other things like spells, gems, sockets, etc.?
- does a worn-out item (shovel) become something else (like a stick) when the item wears out fully?
- etc.
Your best bet is probably to write down exactly what you want feature-wise. It may be useful to get very familiar with an existing game so you have an actual example of each feature in action.
Once you have decided a baseline design, fully work through two or three different inventory tutorials on Youtube, perhaps even for the game example you have chosen above.
Or… do like I like to do: just jump in and make it up as you go. It is SOFT-ware after all… evolve it as you go! 
Breaking down a large problem such as inventory:
2 Likes
Of course you should write base classes and use inheritance and composition however you prefer, in order to reduce code redundancy to a minimum. Filecount itself is pretty much irrelevant (and can be organized and hidden through folders). You should not repeat code. But since some skills likely handle even similar attributes in a different way, you will have to specify that behaviour in some place. In the end, just do as Kurt said and jump right in. Try something, see if it works, what potential weaknesses or strenghts of that approach are for your specific goals, and then scrap it or adapt. Do some rapid prototyping to see what works, then try to scale it.
This is one of those topics where specifications for what’s desired can (and usually do) vary so much, that there simply is no fits-it-all kind of solution you can adapt. So while there is certain patterns for certain problems, unless you mostly copy a system from some other game and know how they did it, you will have to enter experimental territory and see what works for the system you have in mind. This is definitely an advanced subject, and you likely wont get around doing some trial and error work to see what fits your needs.
2 Likes
Thanks for all the tips everyone!! I’ll start with some trial and error now, I think.
1 Like