I’m currently working on a college work,and one part required us to"create an additional enemy class which resembles the asteroids,this enemy must fragment into smaller chunks when struck by player bullets which then move into different directions,each fragment above a minimum size must also exhibit this same behavior.Collisions between the asteroid fragments and the player’s ship should have an effect"
So I would like to ask how should I comply my blueprint in order to archive this?I’ve completely no idea and deadline will be in 3 days later
1 Like
Note:My work is a 2D Space Shooter
So you need a base asteroid enemy class which has different properties like:
- Mesh: How the asteroid looks like.
- Movement speed: How fast it moves.
- OnDeathSpawnClass: Instances of what class should be spawned when this enemy dies.
- OnDeathSpawnCount: How many new enemies should be created on death.
This base class should also implement movement, rotation, collision handling and other such functionality.
When the Destroyed event happens it should do something like this:
- Turn collision off so the soon to be spawned new enemies won’t collide with this one.
- Spawn OnDeathSpawnCount number of instances of the OnDeathSpawnClass. Maybe best if you pick their spawn location randomly within the bounding sphere of the current, dying enemy, just make sure they are not overlapping with each other.
- Create special effects, play sound, increase score or whatever else needs to be done.
So this is what the base asteroid class should do. The next step is creating child classes which will be data only blueprints because only the aforementioned properties need to be changed: you should adjust how the enemy looks by changing the mesh, tweak movement speed and so on. The really important thing is to get the OnDeathSpawnClass references right: The base (perhaps biggest) asteroid class should reference the medium asteroid class, the medium reference the small, etc. The OnDeathSpawnCount in the smallest asteroids will be 0 so they don’t create any more chunks.
1 Like
Any screenshots example?
Which part seems unclear, what would you like a screenshot of?
I will say the overall blueprint structure of making this feature,plus the OnDeathSpawnClass and OnDeathSpawnCount which you mentioned(if these two are blueprint functions)
thanks
The class hierarchy would look something like this:
AsteroidBase
|__AsteroidMedium
|__AsteroidSmall
|__AsteroidDebris
One base class with 3 children classes.
Again, all the gameplay logic is in AsteroidBase, the children classes only there to store the modified class properties (which are just declared variables in the base class):
OnDeathSpawnClass has the type of AsteroidBase (Class) so the purple ball icon.
OnDeathSpawnCount is a simple Integer which you can use in a For Loop to spawn multiple enemies on death (Destroyed event).
You got the variables right. (Although it would be good practice to set SpawnOnDeath’s type to Asteroid to make sure you can not accidentally set it to something unexpected. Right now any Actor derived class would be accepted there.)
However by “class hierarchy” I meant the hierarchy of blueprint classes not components inside a class. The Class Viewer editor tab shows the class hierarchy/tree. You should see something like this at the end:
This shows how one class has several child classes derived from it. The following page is a good read on the topic:
Anyway, since you already have your Asteroid class, you can add a child class to it by right clicking on the asset in the asset browser and choosing Create Child Blueprint Class. This new class will inherit all the variables and functionality but you can change those without affecting the parent class. In your case you will just need to tweak the variables.
Alright,I had created the child blueprint class for my first chunks,now how should I comply it?
You mean complete? I don’t think this site is the right place for that, the discussion of the entire game mechanics would be way too long. See if you can find a mentor who could guide you through the process step by step.
Even not complete,can you at least tell me how’s the start of the structure?I don’t even have an idea on how to start with the structure of the child blueprints!
The child blueprints are the easy part: They do not need any new additional gameplay logic, they inherit all the functionality form the parent. For example you only need to implement in the parent class how asteroids move around. The child classes will do the same, the only work there is adjusting the speed variable, this is why the child blueprints should be “data only”.
So most of the work should be done in the parent class: that’s where you define how to move, that new actors should be spawned on death, etc. It might be best to break down each task into small pieces. You will have to ask many questions but if they are simple enough then you can google the answers:
- How do I get the location of an actor?
- How do I set the location of an actor?
- What is velocity?
- How do I detect if an actor collided with something?
- How do I destroy an actor?
…and so on. Going through and solving these bite sized problems will make you feel less overwhelmed.
If you found an answer helpful then please mark it as accepted. 