Ive always had trouble with this topic and its the source of what made me delete a bunch of code. For example i have 40 weapon modules which use spatial queries hitboxes detecting humanoids and dealing damage with the if statement. Now i want to add a window that can be smashed with weapons. Instead of going to all those 40 modules and adding a simple if statement checking if its a window, what else could i do to future proof my code?
1 Like
Use one module OOP to handle all of your weapons, you can differentiate between all the weapons by adding an argument like WeaponName to a .new function inside said OOP module
With that method you can update only 1 script and have it work for every single weapon in your game
2 Likes
Yeah what this guy said. I would have a module that requires and then a second module inside the weapon that has settings and extras. I recommend in the settings script having functions like: on attack, on equip, on hit, etc just for very specific things
1 Like
Adding to this - if the equip/unequip and attack methods are the same (eg. equipping is just playing an animation on all of your weapons) then implement them as methods in your OOP module rather than in the settings one so that updating is easier
1 Like
Yeah I’m just saying for like very specific stuff. Like: doing a giant explosion when you equip or giving speed when equiped.
1 Like
I like to keep going with the scripting until I’m at a totally generic state. To the point I could copy the same script to everything and it just clicks in place. Modules can be a game changer helping with this for your point, “very specific stuff”, as they can be added as needed or expanded on.
I follow 2 simple principles,
- Use modules when possible
- Never write the same code twice.
The only time my code is not in a module is when it cant be (event connections and such)
If I make a kill brick I tag each killbrick and then write a single server script to handle the killing
2 Likes
I do the same, modules hold up the code and store. And regular scripts are mostly used for putting them in place and connecting em.
For anything that would be repeated across scripts, either make a root script or a module script that the other scripts can use from and not have to write it themselves. Thats a basic rundown of it.
1 Like
I would just have one module for a ranged hitbox handler. And when needing to require a ranged hitbox i would go through this module.