Beat Em Up - Question that has to do with camera movement

In these types of games, it seems that the players move and the camera moves until they get to some enemies then the camera stops, and it locks down. After the enemies are dispatched, what I am calling the “notifier” appears somewhere on the screen in what usually seems to be a pointing hand a long with an audible “bling bling bling” sound to indicate it is time to move on. (And if you did not this usually meant some type of enemy to punish the players, In Golden Axe that was shadow skeletons, in P.O.W. that was instakill machine gun troops.)

If we divide the Beat Em Up “battlefield” into two halves left and right. Now, if per say ALL of the players were on the left hand side at the time of the notifier, most of these games seem to use the midway point (the camera actors Y in this case) to be a trigger point. Just branch it and if any of the player’s Y is greater than the CA’s Y? Reconnect an event tick feed to add actor world offset. Then just subtract the players Y from the CAs and that provides what you would expect here.

Here is the problem and or question, if ANY of the players are over that mid way point at the time of the notifier firing, if I use that last method then I get a quick snap by the camera. Not what I want here, most of these games seem to allow the furthest player to the right to move right from their current position and the camera moves, bypassing the midpoint mechanism, until another player gets less than a number usually right next to the left wall meaning they have fell behind and now the lead player cannot advance / move the camera. What I did here was at the “time of the notifer” took the lead player’s location and rectified the flow to a single pulse using a DO once to Set a variable.

Then using the following math.

As shown on the video, this looks correct, except you should not be able to move the camera left here. I am missing something here. And even if I figured out how to get it to not move left, that time of notifier float will have to likely be altered. That is essentially a difference of how far over the line they are. But what if that lead player was all the way to the right, moved left an inch or so (without the camera) but then moved right again? lol See what I mean?

Any help here is appreciated, thanks.

1 Like

bump

I am being asked in another thread I made tonight to offer some code that has to do with this BEU style camera. I am going to redirect them to this thread and hopefully they get some context.

I usually make pics of code using 3-4 screen caps composited to make one big pic but it does not seem to be working right tonight lol. The sizing is all wrong. So I made another vid and showed some code first.

This is in the Camera Actor BP, which in a Beat Em Up seems to act like the dungeon master and has overal control of the flow of the game.
This is from an event tick feed. I am showing you one branch inside of a macro that has to do with the P00 (formerly Player One as we all knew it before Unreal) and that character’s offsets.

I made considerable gains on the camera system tonight and I just about have it. I made a new diagram and added some new details on it.

Here is the newest video

The only two things not shown in that macro code is two bools the first checking if “P00 is Furthest right?” and “P00 is in A?”

I have divided the proverbial BEU moveable area or battlefield into two left and right halves. I am calling the left half B and the right half A. I have added two zones I am calling ahead zone and behind zone just before and after the two blocking walls attached to the moving camera actor.

The general jist of a “Beat Em Up” style camera system (in the classic arcade sense anyway). Is players move to the right (in this case 4 players) until they encounter a set of enemies. There may have been some camera movement leading to this if enemies are not in spawn range. And then the camera locks down. It will not move again until ALL enemies on screen are gone. Then usually what seems to happen is what I call “the notifier” appears, a flashing pointing hand accompanied by audible sounds, indicating to the player(s) it is time to move on.

Most of the BEUs seems to have a point halfway or in the middle and if any player crosses that Y then the camera moves (when the cam can move that is). Until…you reach more enemies and it locks down again.

One of the trickiest aspects though is if any player is in A whilst the notifier is up. The only thing that seemed to work here was using a Do Once node (i have been told it should not have mattered) to quickly take the difference or offset of how far the LEAD player is over the half. This then allows the cam to move AT that lead player’s location as he is in “A” already VS if they were all in B when the notifier was up.

Now, the lead player pulls the camera essentially UNTIL, any player is in the behind zone, and now the cam won’t move. If I am holding to the right on the lead player, and then the behind player comes out, what I find happens in most BEUs is that the camera moves as if no player ever fell behind, kind of like the first vid in this thread where they are just dragged along. But, for reasons I do not understand, as soon as that behind player comes out of that zone and the boolean turns false (in a macro not shown here, again event tick based) INSTEAD, of the lead player moving on, the behind player is allowed to move right, and the lead player has to turn left then back right and can resume. Hence the facing right bool and the Do Once.

This is not bad, for me anyways, but I still would like to figure that out and would basically have the BEU camera system down.

At around 1:12 of the vid there is a strange fall back effect where the camera moves left a bit, I have no idea why that is happening.

From what I remember of old school BEU’s 80’s to early 2000’s was the lead could push up until a certain point. But all stragglers were forced up into the play area.

TMNT for example did this.

1 Like

On that first video of this thread that is the way I had it.