Thanks for adding to the conversation, @TimCarter.
It’s true that one can access functions and variables through the CDO, but it’s important to remember that such access is intended to be read-only — meaning, if you do call one of the CDO’s functions, it should basically be a ‘getter’ type and it should definitely not modify the underlying default object.
In this case, using the CDO wouldn’t be a solution for the OP because the OP wants to make the player’s currently equipped gun fire when a higher-level manager calls Fire()
on a superclass of that currently equipped gun. This implies (really, requires) that the player’s gun already exists as an instantiated object, so the CDO is not really needed here.
Besides, calling Fire()
directly on the CDO is either meaningless or dangerous — for example, assuming the Fire()
function spawns a projectile or traces a line forward, where would that projectile or line trace begin? The CDO has no valid transform data, like position or rotation, because it doesn’t really exist in the world. The CDO’s purpose is to answer questions like the one featured in the first resource that you linked: for example, “How much does this thing cost?” or “How many tiles does this thing occupy once placed?” Those are safe questions to ask, because they are both “getter” questions.
Even almost a year later, it still sounds to me like the best solution for what the OP needs (and same goes for others in a similar situation) is, defining generic Fire()
behavior in a high-level (base) weapon class, deriving from that base class to create the individual weapons, and overriding the Fire()
function on the subclasses to implement the desired individual behaviors. This way, you could call Fire()
at a high level, not even needing to know which subclass you’re dealing with at that moment, and the individual desired behavior would execute, all thanks to polymorphism.
So, in my opinion, the accepted answer is still the best one.