I am working on a small resource management game with a turn based battle system, and currently making a “harvestable“ that will drop items when destroyed and obviously i want to have different ones (trees, rocks, etc.), however the idea of having a different scene for each seems too time consuming and overall pretty inelegant so i thought of having a universal class called harvestable and then just set it’s properties within code, however the immediate problem i thought of is that it would be pretty hard to set properties like areas and collisions within code as compared to using the editor (i would use the same design pattern to create the skills the characters use during battle), among other problems i haven’t even thought of, so i wanted to ask you guys if it’s a better practice in the long run to just bite the bullet and use the editor or to stick to my idea.
Here’s a prototype for the class that would handle the properties to give you guys an idea, thanks in advance for the advice
yes, if you are going to make trees, rocks, shrubs, turnips, random deep-fried and delicious squid-on-a-sticks etc. then i would make the class for the nodes with editable properties such as sprite, loot, break time, sound effect, etc.
So, yes, what you are doing seems correct.
Nonetheless, making unrelated objects all use the same base class would probably create issues later on, say an item you want to damage the player and be unbreakable v.s. a rock should use different classes, unless you really want everything to be inversely related, i suppose that could work, but change the main class in any way, and all your other classes that inherit from the first will most likely break.
that’s really smart, but it would only really work with rectangle shapes right? I haven’t really decided if i want them all to be, but this definitely helps.
I was also thinking of perhaps making harvestable a base class and then have TreeClass and RockClass etc. so do you think it would be smart to make it so that the RockClass always has the same size to avoid the collision/area problem?
It depends on your workflow.
You could just have ObjectBaseClass—>RockLarge—>RockMedium—RockSmall, etc.
but it may be overkill whether you use the interface or not.
Even still, if all the rocks are going to be similar sizes, then this is not a problem and you should very much so use the same collision size.
Just delete the Sprite2D and CollisionShape2D nodes and use the CollisionSprite2D node from my Collision Sprite 2D Plugin. It will automatically create collision polygon shapes for you at runtime that directly map to your image, ignoring any pixels with an alpha of 0 (i.e. transparent).
I developed it during a game jam for my game Katamari Mech Spacey. You can see it in action there. When you blow up ships, their parts attach to your ship, and their collision shapes are automatically created. Here you can see the collision shapes for the player’s body, wings, guns, missile launchers, attitude thrusters, and engines.
