I am making a top down PVP game and am using an invisible box collision that follows the mouse and when it overlaps with a player character it sets a specific Boolean called “Is Character A Target?” to TRUE and is set to FALSE when the actor leaves the box volume on end overlap. The big problem here is that after the Boolean is set to TRUE - when I move my mouse to select a move from the attack menu; my blueprints will set the “Is Character A Target Acquired” too FALSE. Making this system kind of useless. I need to make a system where I can track the RECENT character who entered the collision box and connect my attack blueprints off of it. I am doing research on Arrays to maybe make a better system and then somehow get the information of the character who was last in the box. But I am lost.
This mechanism here goes through a list of characters and checks who is in the box and moves on to search the next character if false is returned. On true their respective “Is Target?” Boolean is set to true. This system was the best I could think of but hopefully y’all have something better.
This mechanism here is in each character’s attack menu and searches each character “Is Target?” Boolean to identify who to dish out the attack to after pressing the attack button.
I figured out this system was an issue during playtesting when I would use my selected character (Character A for example, who’s first on all the search lists) to attack another character (Character B), and instead of damage being applied to Character B the damage would always go to Character A. Because A is at top of the list (this was because at the time “OnComponentEndOverlap” was connected to the set “Is Target” Booleans to FALSE at the time of testing, hence resulting in my targeting system not knowing who I’m attacking when my mouse moves to select an option from the menu. I definitely need a better system other than Booleans.
Set an actor object variable either on your player character or the collision box(if it’s an actor) that retains the value of the overlapping actor until desired event, if you need a list of characters you could use a map, of booleans to actor object references. Or probably it would be better to use the actors as the key and Boolean as the value
Actually, the interface isn’t a good solution in this case, since they’re all characters; you’re just patching it up. Simply create a base character that all characters inherit. This way, you’ll easily know which one is the last one, since you can save it in a single variable, since they all inherit from a default. You can also do for loops since you can save them all in an array.
If later, in a more advanced phase, you don’t want this trigger to have references to the characters, you could use interfaces. But the way you talk to the other actor doesn’t answer the question.
very incorrect, ultimately he is looking for ‘targets’ a character could be a target, so could an explosive barrel, or a tank which cant inherit from character because it doesnt use CMC.
Interface is 100% better in this situation
I thought I only saw character names in the cast festival. But okay, let’s imagine there’s also an explosive barrel. So the solution to the problem of how to assign targets to characters and not characters would be an interface… or not, because if they’re going to share a lot of code, you could use a component, search for it by tag, and access it with an interface. Or are you going to repeat the same code in all the targets? Also, characters with inheritance could inherit the component. But in any case, the way of communicating with the targets is still not the solution to their problem.
You should always go with inheritance first, and then see if you need to communicate using an interface.
All the characters in the game have a variable called Armour Class, so you should place it in the parent class (e.g., CH_GameCharacterDefault) and cast to the parent. This is the standard approach.
If you skip inheritance and think an interface is better, you’d have to go into every character blueprint, implement the interface, create a variable, and set up an interface function to retrieve the Armour Class — and remember to do this for each one.
Using an interface only works efficiently when mixed with inheritance, as you could define the variable and implement the interface in CH_GameCharacterDefault alone.
However, using an interface here would mainly serve to avoid a hard reference. At this stage of the project, which could pivot in any direction, is memory management really a concern worth prioritizing?
Now imagine you decide barrels and chairs also have an Armour Class. You might think about using an interface again, but you face the same issue: are you going to go through all the blueprints, adding interfaces, variables, and functions one by one? A better approach would be to create a component that holds the Armour Class variable, attach it to CH_GameCharacterDefault, and also to any other object, regardless of its inheritance. And since you’re already handling this setup, avoid hard references from the component by using an interface for communication.
not really true because they go hand in hand, so you just put the interface on the parent, same result but now it works for everything in the game.
with an interface i can ultimately decide to still use inheritance or actor components or any other method but with inheritance alone you’re locked in could face trouble later.
it also means i can reuse that interface and linked systems (say damage) in completely different projects where the character wouldn’t be viable.
but ultimately all solutions can work it just depends on your game.
Placing the component in the parent is inheritance. We’re actually saying the same thing . Inheritance has nothing to do with communication between blueprints.
I think when you say inheritance, you mean casting and abstract classes I guess, and I misunderstood.
Moving from casting to interface is very easy, and I prefer to leave it for when the game is already in the polishing phase or because they are too lazy for the cast to especially the things of the gamemode and gamestate
But yes, of course, it is still a personal choice.
. Inheritance has nothing to do with communication between blueprints.