Download

Inheritance Dilemma / Confusion

Development Discussion C++ Gameplay Programming
#1

I need to make a prop class where props can be either StaticMeshComponents or DestructibleComponents. Their behavior will be entirely identical with the obvious difference being one can be destroyed and the other never destroyed.

Looking at their hierarchy the closest common abstract class for the two is MeshComponent.

My idea was (likely a poor idea) to make a class derived from UMeshComponent that implements the common logic for all props and then, I’m not sure.

Looking at the excellent diagram I’ve made Screenshot - f2510488d96c6604392fc46313ccaf6c - Gyazo

Will I have to make a new class for each item there so that each new item derives from a custom version of those original classes?

For example I’m anticipating having to make a MyPropMeshComponent, then a MyStaticMeshComp which MyPropMeshComponent derives from.

Then for Destructible I’ll have to make a MySkinnedMeshComponent, a MyDestructableMeshComp followed by a MyPropDestructibleMeshComponent.

This seems really silly to have to make 6 new classes just to avoid duplicate code. But is this my only options?

Am I overlooking something?

#2

Im not sure really what you wanna do, but if i understod right? those props can be destroyed thats the only difference right?

So for example…
Some player shoot a lamp or wall or whatever and after X damage you wanna destroy that and use destructible mesh to “simulate” break effect and debris fall?

I guess you overengineering this one. Im not sure you need do new components if break / destruction is concept behind your idea and applied only for some proops (like in Overwatch where you can destroy some props)

Normally destructible meshes exist only for visual purpose.
In lot of case you dont wanna do anything after the mesh break and you wanna forgot and destroy debris after some time… (since destructible meshes can be expensive)

What if you inherit a new class from staticmesh actor (or do your own actor)?
This actor can store your health and one UDestructibleMesh which represents his destructible mesh… (of course there is lot more option like you can use database, dataclass etc.)

If Damage reach the limit and mesh should break just hide mesh / disable collisions (and of course set a lifespan to be sure it would be destroyed after time) and spawn a new destructiblemeshactor -> set destructible mesh -> apply damage to break that mesh -> set collisions if needed -> set lifespan and destroy.

This is kinda like spawn and forgot. you dont need care about this actors anymore (since they destroyed) and lifespans will do their job and actor will be cleaned up…

From other side there is ton of other methods to simulate destruction visuals!!!
Lot of game using Particles (yeah particles! :D) to simulate destroy effect… of course this method need asset support and someone need to create that particle, but its super lightweight.

If your concepts purpose is not “final” destruction effect as i mentioned pls add some details about your idea… because hard to “design” a system without knowledge what we really wanna do… :slight_smile:

#3

So if I’m understanding you correctly your suggesting I just use stAtic mesh actors and if it needs to be a destructible spawn in a destructible version when health hits 0, apply a flrce so destructible mesh breaks and then I’d achieve one actor that does both.

My only concern is with the swapping process. Will it be smooth? Will it look off with the object breaking a few seconds after it should?

I suppose I can test it out doing it this way.
For context I’m making a MP game where the player can pick up props and hurt other players with them kind of like you could in HL2 deathmatch.

Edit: I think you are right though I’m probably over engineering this and relying too much on inheritance to solve this problem. I think what I’m going to end up doing is just making a single actor that has both a destructible mesh and a static mesh and at the beginning I will decide whether this prop is going to be destructible or not and swap roots accordingly. This should allow me to reuse the same methods and not have to duplicate code.

#4

Hey, yup you understod right.
Im suggested to do your own actor (and you dont need add destructible component actually, close enough if you configure destructible mesh and spawn a basic destructible mesh actor)

And yes they will be smooth enough because you need spawn destructible actor and remove original actor only on client!..

If we talking about multiplayer lets say you have a repicated “health” variable…
Lets say we using OnRep_Health() notify for replication. (and i assume you apply damage on server)

Here is some pseudo code thingy




// runs only on server
YourClass::TakeDamage()
{
   if(bDestroyed)
         return;    

   // other codes
   Health -= Damage;

   if(Health <= 0.f )
   {
        //DisableCollisions, SetLifeSpan(10.f) etc.
        bDestroyed = true;
   }
}

YourClass:OnRep_Health()
{
   if(bDestroyed)
       return;

   if(Health <= 0.f)
   {
       DisableCollisions();
       SpawnDestructibleActor();
       SetHideInGame();
       bDestroyed = True;
       return; //we are done since lifespan set on server ue networking will destroy this actor after 10 sec
   }
}

So this will smooth because destruction actor will be spawned only on clients and only when health is replicated properly :slight_smile:
Im sure this will be fast enough and player will not notice anything…
Of course your two component solution is also good (static mesh component and destructible component thingy). Just mentioned you dont really need two component inside your class, because why… you wanna spawn and forget that “visual effect”

Anyway both solution will work and you can reuse that actor everytime if you need destruct that props :wink:

#5

Yea I’m trying out my approach but I’m running into this issue here.

https://answers.unrealengine.com/questions/778610/components-created-with-newobject-not-showing-in-a.html