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.