Not a trivial question at all, but I can only come up with reasons not to do this rather then reasons to do it.
For one, if you isolate the code you need to make every weapon it’s own blueprint/actor class =
extra overhead, and extra code that can go wrong.
For 2, even if you actually create a weapon actor class to replicate with a custom “movement component” that is not A movement component but rather parameters for firing, it sounds more cool then the end result would be, which is extra overhead and a bunch of cast to calls.
For 3, you would then need to talk back to the character animation blueprint for recoil or trigger pulls and such - depending on how high class of an FPS you want to make.
For 4, your projectile component still has to be independent as with a regular implementation, so you would still need all the same struts and parameters in place to handle quantity/velocity etc, living the heavy portion of the work the same regardless.
For 5, what happens if you press the button for firing a weapon that’s not currently in use but is in the level?
Even if attached the pawn owner is never the player or the controller, Ergo I don’t even think you could get it to fire without some creative cast to + custom event calls on it’s own blueprint.
I’m not sure what the benefits would be from having a more OOP version of a gun with it’s own base class and parameters.
Creating it properly in CPP with functions that you can just call (from the character) would be beneficial in terms of usability - but the button presses are generally speaking still all happening on the character controller because IT has input and not the gun.
Also, fire → cast to → call remote function might take longer than
fire → call function. Might, that’s something you should test before deciding if it’s worth to proceed…
if anyone can offer any reasons to or examples I would be greatly interested. It’s always good to learn new stuff.