New Guy Needs Help


As you can see from the graph, I have a combat system designed, wherein the player makes a choice as to which space he’s going to attack at the enemy – this creates for fun and engaging combat where the choices of both players really put fate on the line. I haven’t designed the stats for the game yet, but I want to get my combat system up and running before I jump into stats.

There are 6 spheres that are hovering around the character, and these represent the six spaces of the “field of attack.” However, I am puzzled as to how I’m going to program with Blueprint, in a way that when, for example, the 1 key is pushed, your player is ready to attack at the enemy’s 3 space. If anyone wants to help and enlighten me on how I can accomplish what I’m aiming for, any help is greatly appreciated. I think I need to first design the multiplayer aspect of the game before I design the Field of Attack.

1 Like

As you can see from the image, these are the spheres which act as the field of attack.

1 Like

This might be too detailed to get a satisfying answer.

A lot of developing with the engine is about just doing anything that takes you in the right direction, and then re-evaluating.

It’s good to plan, for sure, but you are probably going to have to develop this combat system many times before it get anywhere near what you want.

I can say, from what I see so far, that the spheres you have are all WAY to near to the camera. To get the kind of effect you’re after, they would need to be more like

Which only give 4 zones.

They would be collision volumes, by the way, probably ( not spheres ).

I’d recommend trying to find a free or cheap combat system on the market and picking it apart as part of your education.

4 Likes

Thanks for responding. I will consider your advice.

1 Like

The trick I’m seeing is that there will have to be a linking that occurs between the player and target. For example in an Action game you would just hit attack and the character swings the sword forward, or a variation like modern zeldas or witcher where you lock on target and the attack towards your target. In your case the buttons you hit do action relating to a specific target. If the game was turn based this would be very easy since you could target and the select the move but this looks real-time to me.

The first thing you need is a way for the player’s character to identify what it is attacking. I would do a scan on tick to detect what is most centrally in front of the character. This can be done with LineTrace / GetDistance and Angle check / Overlap events. Personally I would just add all spawned enemies to an array and do a distance and angle check on each every tick. to determine who the valid target is and what spheres are accessible.

Once you have this working it would be a matter of a bCanAttack check on your main character. If the character has no active target (found by step 1) or if they are currently in a swing or in some kind of damage animation then it returns false, otherwise it accepts the input and does the attack.

The spheres sound more like visual indicators so I wouldn’t even worry about them until the game is working via input however if I am picturing this right, 3 would light up at a time showing the 3 spots you can attack at any moment. After step 1 where you calculate angle to your opponent you would decide what 3 should be lit up. At this point do a check on all spheres to see if all the ones that should be lit up or dimmed are correct and adjust a Dynamic Material Instance parameter to change the visual appearance.

2 Likes

It seems to me that you really thought out your reply, and for that I’m grateful. Here’s a graph that explains what you would see from a first-person perspective.

1 Like

"The trick I’m seeing is that there will have to be a linking that occurs between the player and target. " Then why don’t I just use a Collision object around the player and begin the program with “OnComponentBeginOverlap”?

1 Like

To help me understand, in the first person view, i understand why you are seeing the enemies 3 grid spots so that you can identify what points you will be attacking but what information does the player gain from seeing their own targeting spots, would they light up to show when someone is attacking those spots?

BeginOverlap will work just fine however I would still advocate for just making a list in game mode and whenever an enemy begin plays, add it to the list in game mode, and remove it when it dies. The reasoning for this is that behind the scenes begin overlap does the same thing on tick but it deals with a much larger list of potential things (All components or all actors) that could be available. Secondly multiple enemies could be overlapped in the same areas at the same time, and potentially untargetable due to some kind of effect or dead, so you’d still have to run some kind of distance / angle check anyways on everything currently overlapped to determine who the target is and what circles are currently vulnerable.

I’m still piecing together your game concept so I’m sorry if I’m missing the mark on some of your things, I’m just sort of free rambling what my process would be as I get a picture of your game’s mechanics.

2 Likes

Yes, you’re correct that the zones flash the color red when an enemy strikes you in one of your rows. I am a disabled person, so, I’m just gonna sit on my butt and work on my game until it’s finished. I got a piece of paper, and I take notes of the things that I learn. I understand now why OnComponentBeginOverlap is probably not the best choice. You’ve been more helpful than you’ve needed to be.

1 Like

No problem at all. BeginOverlap would work though, you aren’t going to hit a performance bottleneck or anything from using it instead so if you are more comfortable using it go for it. I just feel the alternative would offer more control and solve the problem cleaner. Best of luck on your project, the pic looks good and I like the sound of your mechanics, cool diagram and plan as well!

2 Likes

Any advice on how both players end up with the same field-of-attack? As if Player 1 is programmed to attack one of Player 2’s spaces, Player 1 will attack himself, because his field-of-attack is the same as Player 2’s. I’m gonna have to start reprogramming from scratch in order to make this a multiplayer game.

I am having a hard time understanding the issues exactly and some of them are most likely due to some specific random mistake that is hard to predict.

Unreal Multiplayer is very trick, it would be best to just keep a multiplayer mock up as simple as possible until you are sure it’s entirely working, just movement being replicated, spawning and despawning. The issue you are describing sounds like it could be from a number of hard to isolate things but don’t despair and keep at it, I’ll give some thoughts…

First I wouldn’t mess with multiplayer until you can nail down your combat system perfectly against an immobile training dummy. While doing this i’d also work on the side when bored on a super simple multiplayer lever just to get spawning, despawning and moving in multiplayer mastered. The multiplayer issues sound like you might be triggering the same function many times where code is being double triggered by client + server. With multiplayer you really have to carefully track what is happening and no matter how much you do it, it’s a pain.

I use the blueprint “Print” node often when working in multiplayer to see if the trigger happened on the client or server. Print node will say CLIENT or SERVER on it so it’s a very easy good way to tell what is happening. Another trick is that if you set your game to 3+ character the outliner shows the client world, where as 1 or 2 players shows the server world. This is helpful to see what is being actually spawned server side. (By setting it to 3 sometimes and tracking what is spawning).

You have to use classes very carefully in multiplayer, the player controller is very important and the best way to isolate one client’s commands from another.

Focusing on the field of attacks and their names: I would not do unique names per field per player. Instead give each character a component that contains the code for handeling field of attacks. I would make an enumerator (Enumerator is a BP type you can make from the menu) that holds the 6 fields of attacks instead of using typed names. This way regardless of who is attacking who the function/event is the same: Player->Attack(OtherPlayer EAttackFields::RearLeftSide) . This translates to “Player do and attack on this other player at their RearLeftSide”

This is a concept called Object oriented program (OOP). It’s one of the most powerful and fundamental things to try to understand. This way your system could easily grow to have as many enemies on screen as you want and each has their own instance of the combat system. Enumerator is cleaner because you don’t have to type it and you can use it like an array.

Sorry for the ramble there was a lot to take in and I’m just running with what comes to mind.
Don’t be afraid to start over and over, you will improve each time, and all aspects of any project that has some substance (UI,Combat,AI,Menus] will have to be restarted many many times before you get each individual part working in a way that feels good and does exactly what you want.

2 Likes

Object oriented program sounds like a very good idea. I also like the idea of an immobile, target dummy. The enumerator will come in handy. I will mention that one time my old man was playing Gears of War 2, in Horde mode, and he spawned as one of the Horde, where he proceeded to kill his own team! So you’re indeed correct that Unreal Engine has issues at times – especially during a multiplayer game.

1 Like

Hopefully that will give a place to start solving this problem. I’d say the multiplayer as implemented is reliable and very powerful it just makes you have to be extra careful with lose ends. It’s fairly accessible even to someone new to UE4, so it’s very possible and on the table but there is a mental price to it. Any project that I implement multiplayer in feels like it’s x10 longer to develop and it sucks the fun out of the development process, I also have to sacrifice cool features that I wanted to start because they are just to complicated to pull off in a multiplayer setting. So it’s very possible to do it just becomes a huge mental burden as the game grows.

2 Likes

I will mention that I’m not poor, but neither do I have the money to pay someone to make my game for me, so I’m a one-man-team, and I intend, if I can get a finished product out, to offer the game for absolutely free. My associate, one of the original developers of AlienWare, has also taken interest in my game project – I figure his nerdy eye routed out my clever game mechanics.

1 Like

Indeed the enumerator is useful. However there still has to be circles around the player, and I will explain to you why: because it’s imperative that the game knows from which direction that an enemy is attacking you from. So the circles act as a form of indicator of location. (Ignoring the fact that my character is just an egg with a sword, at the present moment) you can see the circles below. There are actually four and not six, because you can strike them from their left or right side, and the front and back circle each represent all three spaces. Also, at this rate I’m gonna have to put “Stegoboston” in the game’s credits! I don’t know what it means, maybe a stegosaurus from Boston.

1 Like

Yes! You’re actually exactly on point, I am a Stegosaurus Dinosaur from Boston.

So after considering your project further I see now you have two separate things:

AttackDirection: Left | Center | Right
AttackLocation: FrontLeft | FrontCenter | FrontRight | RearLeft | RearCenter | RearRight

There is a node I believe called “Find LookAt Rotation” which will give the angle one set of transforms has to be to face another set of transforms. You could use this to always know the position of the attacker relative to the attacked.

So in this function example:

Character → Attack(OtherCharacter, AttackDirection::Left)

A function like this would have all the information it needs to calculate the resulting AttackLocation using some quick math.

The collision for tracking these things would also work, I’m not sayings it wouldn’t function but I think you can approach this from a different angle that gives you far more control and also makes things easier to develop and advance.

2 Likes

I have a very serious newbie question here though, and that is: how do I create a function whose target is not itself? No matter what, its target is “first-person character,” and cannot be changed, because no nodes are compatible with the “target” node. I have had this same problem before.
Target-Self

Target isn’t really a target like you would think of in a game sense, it’s a sort of hard to describe programming concept called a “method” and it refers to who is running the function.

So in this function I type out:

Character → Attack(OtherCharacter, AttackDirection::Right)

Character is the Target that is running the function called “Attack”. In blueprints Target is what is running the function, and in order to run the function it has to have that function in it’s class. (This is hard to explain, I can try to be more detailed if you want)

This is the function I would like to see in your character class.

So lets say your characters all come from a class called ZogzorsGameCharacter. You give the class ZogozorsGameCharacter the function “Attack” and make one of it’s input parameters a ZogzorsGameCharacter.

When you call this “Attack” function the target can be any ZogzorsGameCharacter then and it can accept any other ZogzorsGameCharacter into the parameter AttackedCharacter.

2 Likes

I should be paying you. That aside, from what I understand you created the Zogzorsgamecharacter as an actor variable, am I right? And “attack direction” is a byte?