Design Help for Upgrades

Godot Version

4.1.1

Question

`hey there, hope You’re having a good day! I could use some help with my current Tower Defense project. Managed to get quite far into it but now I am rethinking some of the things I have made.
Basically I have a Base script for my towers which extends to each tower and its filled with a lot of export vars for easier management
I also made an upgrade menu but that one is a resource which holds upgrade values that need to be applied to the tower

Now my question mostly would be for the TowerUpgrades, when we upgrade a tower I want to make it change its sprite and also add more stuff like poison attack range increase and more
Now my idea is to just keep this TowerNode and apply the upgrades to it while changing the sprite with each upgrade.
Or should I create a a new Tower for each upgrade combination? While writing this I can see this would be a messy option implementing all those combinations and having everything in one tower node would be better but I still want to hear some of Your thoughts on this. This is my first larger project and I am really hyped in how far I have come and I always try to learn

Thank you for taking the time to read this `

I agree you should keep your towers intact and design a new resource class TowerUpgrade, which holds just a few information related to the upgrade itself: e.g. a new tower name, new sprite, new attack value (or a relative change, e.g. 0.2 for +20% change), new attack effects (like poison), new range etc.
Then you store the upgrades in an array on the Tower class, and when the time comes, you apply the changes after player buys the upgrade.
In theory, you could also make your base tower stats as an upgrade itself. This way you would hold all your stats in one place - as upgrades. Then at the start of the game you’d apply the first upgrade right away.

I would keep it in one scene. Depending on the complexity of your tower of if it is 3D or 2D or how you are animating it, the complexity of your tower scene may vary considerably. But a tower should be contained in a single Tower scene.

You may then have components that you load in and out of that scene, and a state manager for that tower that could be shared with other towers, and weapons you load in and out.

Lets say you have 5 weapon types, and 5 upgrades, your choice seems to be:

One tower scene
5 Weapon components to load in
5 components for the tower to load in

OR:
25 tower scenes.

Then if you add a turret instead of a tower:

One turret scene
Sharing weapon components (perhaps)
5 components for the turret to load in

OR
25 turret scenes

Is that what you meant?

Try to make every scene be able to load in the editor without dependencies. Make as much modular as you can and shareable. Make components modular like weapons. Make popups from a single popup component. Store all your changeable data items like ‘attack range’ as resources. Make all your indicators like ‘map fire range circles’ shareable components.

It takes a bit of work, but for instance if I want to add a new ‘ability’ for my game, I create the ability scene, amend the base resource for abilities to update what it does, and add it to the available list of abilities for player or enemy type. Because all the work has been done upfront, I can continue to add abilities to my hearts content.

It takes some prototyping which can be messy, but once you have fleshed out your plan, making everything modular, shareable and powered by resources and templates, development and maintenance become so much easier.

I hope I understood your question properly. Something like a tower defence game takes a lot of planning, so also keep good documentation for yourself for your own game. I make a docs folder and keep text files in there for each aspect. It does not take much text, but sometimes a paragraph to remind you how one of your systems works can save lots of time, especially when you come back to systems you have not worked on for 3 months.

Good luck.

Than you very much, I understood what You meant and I will try to go slowly while fleshing out and making them modular for my game.

1 Like