UE4 technical tutorials chapter 3 - Usage of custom actors / Design
grand marshal polycounter
This is the third chapter of my technical tutorial series...This chapter will be a bit different from the previous ones, instead of describing nodes and a "how to create this", I'm going to talk a bit about the usage of custom actors, why they can be good, and when to use/make them.
If you've read the second chapter, then it shouldn't be a problem to follow and understand this one. If you haven't, then here is a link to it:
http://polycount.com/discussion/158863/ue4-technical-tutorials-chapter-2-healer-pad-custom-actors-actor-components#latest
Lets get started...
Theory:
- Anything interactive, or anything that has/need some functionality also need a script. Usually its better to also make it modular / reusable.
Some examples for such cases:
- Doors
- Elevators
- Turrets
- Objects that can be picked up by the player
- Objects that can do or give something to the player
- Objects that can change stats
- Objects that can change something in the game world
There are a bunch of more, I just wanted to list some so you get the idea...
- There are always a logic behind what a such actor does, it can be described, written down, so its easier to you to see what you need.
- Design (not visual):
The logic behind it, a plan, needs. Examples:
Simple door:
There can be different types of doors in games, they open automatically in some cases, sometimes the player can open it manually.
I talk about the automatic one here. So we want it to open when the player is close to it and close it when the player goes further. We want to trigger these with a collision detections...
- door frame static mesh component
- door static mesh component or components
- collision component or components for the meshes
- collision component to trigger if the player is close to it and want to open or close it
- a timeline node to change position (animation)
- change nav mesh on opening/closing so the AI can also use it properly
...
Simple turret:
We want this turret to have range. When the player is in range, we want it to turn to look at the player, and shoot the player. So we will need some kind of projectile to shoot. We also want it to have cooldown on the shot and have hp so the player can kill it.
- static mesh component for the base
- collision component for the base
- static mesh component for the gun on it
- collision component for the gun
- collision component for range (trigger when player ender the volume)
- custom projectile actor to spawn on shot
- hp variable
- cooldown variable
- maybe some other components or actors for some effects like muzzle flash, explosion on death etc...
- states - sleep, active
- do something based on state
Simple pick-up (stat modifier) object:
We want it to change the hp of the player when the player character touched it.
- mesh component for visual representation
- collision to detect if the player touched it
- event that fires when the player touched it. In this case it would cast to the player and modify the hp using a simple math, then it would destroy itself so it will no longer exists in the world
- maybe we want to let the player choose if he wants to pick it up or not. Then we want a widget to appear to display the player's options.
...
In the second chapter we already made a custom actor which had some functionality so its one example for such cases. Now here is an another as an example. As I told this time, I won't go much into details about how to make it exactly, but I describe the needs:
An actor that you can click on, and then it will turn to be a selected actor. Then a menu appears, and the player or user can change its color with R G B sliders.
The click-able actor itself doesn't do much things, its simply reusable, and has changeable mesh and material, and a custom event to change color.
More things are happening inside the player controller, which detects where you clicked. Using a custom trace channel, it can be able to detect only specific actor types. Once you clicked on a traced actor, it store it as selected actor, so now we know whats selected, so we can do things with it:
The last part is the UI that we display/destroy based on whats clicked. It is sending color information to the click-able actor, and firing the color change event in it:
This is how it looks and acts in action:
https://www.youtube.com/watch?v=h07-9le_3Gs
...
So pretty much this is how you can plan and make actors that require functionality. Usually they require blueprint communication, but in the previous chapter and in this, I'm showing ways for doing it.
Thats all for this chapter, hopefully it helps you to understand how and when to use/make such things.
If you've read the second chapter, then it shouldn't be a problem to follow and understand this one. If you haven't, then here is a link to it:
http://polycount.com/discussion/158863/ue4-technical-tutorials-chapter-2-healer-pad-custom-actors-actor-components#latest
Lets get started...
Theory:
- Anything interactive, or anything that has/need some functionality also need a script. Usually its better to also make it modular / reusable.
Some examples for such cases:
- Doors
- Elevators
- Turrets
- Objects that can be picked up by the player
- Objects that can do or give something to the player
- Objects that can change stats
- Objects that can change something in the game world
There are a bunch of more, I just wanted to list some so you get the idea...
- There are always a logic behind what a such actor does, it can be described, written down, so its easier to you to see what you need.
- Design (not visual):
The logic behind it, a plan, needs. Examples:
Simple door:
There can be different types of doors in games, they open automatically in some cases, sometimes the player can open it manually.
I talk about the automatic one here. So we want it to open when the player is close to it and close it when the player goes further. We want to trigger these with a collision detections...
- door frame static mesh component
- door static mesh component or components
- collision component or components for the meshes
- collision component to trigger if the player is close to it and want to open or close it
- a timeline node to change position (animation)
- change nav mesh on opening/closing so the AI can also use it properly
...
Simple turret:
We want this turret to have range. When the player is in range, we want it to turn to look at the player, and shoot the player. So we will need some kind of projectile to shoot. We also want it to have cooldown on the shot and have hp so the player can kill it.
- static mesh component for the base
- collision component for the base
- static mesh component for the gun on it
- collision component for the gun
- collision component for range (trigger when player ender the volume)
- custom projectile actor to spawn on shot
- hp variable
- cooldown variable
- maybe some other components or actors for some effects like muzzle flash, explosion on death etc...
- states - sleep, active
- do something based on state
Simple pick-up (stat modifier) object:
We want it to change the hp of the player when the player character touched it.
- mesh component for visual representation
- collision to detect if the player touched it
- event that fires when the player touched it. In this case it would cast to the player and modify the hp using a simple math, then it would destroy itself so it will no longer exists in the world
- maybe we want to let the player choose if he wants to pick it up or not. Then we want a widget to appear to display the player's options.
...
In the second chapter we already made a custom actor which had some functionality so its one example for such cases. Now here is an another as an example. As I told this time, I won't go much into details about how to make it exactly, but I describe the needs:
An actor that you can click on, and then it will turn to be a selected actor. Then a menu appears, and the player or user can change its color with R G B sliders.
The click-able actor itself doesn't do much things, its simply reusable, and has changeable mesh and material, and a custom event to change color.
More things are happening inside the player controller, which detects where you clicked. Using a custom trace channel, it can be able to detect only specific actor types. Once you clicked on a traced actor, it store it as selected actor, so now we know whats selected, so we can do things with it:
The last part is the UI that we display/destroy based on whats clicked. It is sending color information to the click-able actor, and firing the color change event in it:
This is how it looks and acts in action:
https://www.youtube.com/watch?v=h07-9le_3Gs
...
So pretty much this is how you can plan and make actors that require functionality. Usually they require blueprint communication, but in the previous chapter and in this, I'm showing ways for doing it.
Thats all for this chapter, hopefully it helps you to understand how and when to use/make such things.
Replies
Thanks!
this is pretty useful, the reason I am not giving you more feedback yet is because I am mostly setting those aside for later when they become useful for me - I am not focusing on engine stuff at the moment but I know I will be in a few months and I will appreciate having those saved at this moment. As a total beginner when it comes to those things I can tell you it's very clear and neatly explained, at least for me.
I suppose you're not getting more feedback because let's face it, the UE4 subforum on Polycount is pretty much dead and always has been. Hell even Unity's (which for some reason that I fail to understand is a more popular engine than UE4, but I digress) is not seeing any traffic at all.
I guess you'd get more exposure from the UE forums, but maybe you also posted there? If so can you link it, I'd hate for you stopping doing this, it's pretty neat.