Dynamic Casting of Config Models at Runtime

Hey all, so basically, what I'm trying to do is this: I have a ScrollObject descendent called "Orb" which may be instantiated by creating a ScrollObject from either of two config models (named "OrbP1" and "OrbP2", respectively). Let's say I've already created an instance of "OrbP1", but at runtime, want to make that an instance of "OrbP2" instead, meaning that it now has the graphic, body, etc. associated with an "OrbP2" instead of an "OrbP1". Does anyone have any good advice as to how to go about this? Thanks so much.



  • Hey @zgcrowno, thanks for posting your question here (I also took the liberty to delete the duplicated post from the help request section).

    I assume you want to carry over data of your own as well, ie. the data stored at your object, that derives from ScrollObject, level, is that correct?

    I can't think of any automated way to do that, you'd have to handle the copy yourself. Regarding the orxOBJECTs, I'd recommend to simply delete OrbP1 and create an OrbP2 as a replacement. If you have any synchronization to do, like keeping the same animation/frame, for example, you'd have to do it yourself as well.

    If you simply want to preserve the position/scale/orientation, you could also have a hierarchy of objects instead. You'd keep the parent object, which would hold the position/scale/orientation data, and simply replace the child object OrbP1 with an OrbP2.

    Sorry if this is a bit of a vague advice, but unless I know exactly what you are trying to achieve in term of gameplay feature, it's hard for me to propose an alternate scenario.

  • @iarwain, thanks for the response. Currently, your recommendation of deletion and replacement is what I've got implemented, and it's serving me perfectly well (I just didn't know if there was a built-in way to address this sort of scenario).

    Just to give you a better idea of my use case, I'm working on a small scale fighting game in which projectiles from one character can be countered and deflected back at the other character. Since both players may opt to play as the same character, I've got "player 1" (P1) and "player 2" (P2) config models for each selectable character, each of which have their own distinct bodies and projectile bodies, so as to avoid collisions between a character and a projectile they've fired, themselves.

    The reason I asked this question is because I was looking for the optimal way to replace a projectile of one type (P1 or P2) with a projectile of the other type in the event that it's deflected. That way, the deflected projectile no longer collides with the player who deflected it, and instead collides with the player who originally fired it.

    Again, it's working perfectly fine as is, though I may implement your recommendation of an object hierarchy should I encounter a case in which I need to preserve that extra data.

  • Ah I see, thanks for the details!

    In that case, I believe the current situation of spawning a new kind of projectile is probably the best approach. If it were just about collision flags, those could have been updated programmatically on the fly, but going with a full object replacement could lead to much more flexible setups, like defining the type of deflected projectile for each kind of regular projectile, for example, and storing those in config.

    In a similar order of idea, that's how I implemented weapon impacts in Mushroom Stew where projectiles would define the kind of impact they'd produce, and this was then used to retrieve the actual object to spawn from the surface that was hit.

    For example, a bullet would do a RegularImpact and a missile an ExplosionImpact, then those would be config properties defined on characters/objects that could be hit.
    For example, a Mushroom soldier would have

    ExplosionImpact     = Explo1
    RegularImpact       = BloodSplatter1 # BloodSplatter2 # BloodSplatter3 # BloodSplatter4 # BloodSplatter5 # BloodSplatter6 # BloodSplatter7

    while a grass tile would have

    ExplosionImpact = Explo2
    RegularImpact   = RedImpact

    Of course, this system was a bit crude though quite flexible for a game jam entry done over a short time period.

  • Thanks for the example, @iarwain. I may end up dialing back my current implementation such that it just changes collision flags if I decide to do color alterations instead of entire graphic swaps, but I'm pretty pleased with the results I'm seeing now.

Sign In or Register to comment.