I’m currently creating a two player top down shooter. Both players play on the same screen and I’ve set up a camera to always follow the mid point of the players. Unfortunately, I can’t figure out a way to stop the players running off screen. I’ve tried setting up collision boxes in the camera blueprint, which isn’t ideal, stopping player movement when a set distance from the other - but also not ideal as the player always needs to be able to move (still allowing them to run back toward the centre of screen).
Is there a way to invert the collision sphere? Seems like that would be perfect to slap into the camera blueprint.
You can just limit their position in world space. Meaning, when you update their movement you check if their global position is in the bounds you’ve set up and if not - do not update their position this tick.
Upon reading your question again I’ve realized that I might’ve interpreted it wrong. Do you mean a map-boundaries? Like the end of the level or just the camera viewport boundaries?
Viewport boundary. So both characters are always on screen - like Diablo III on consoles. The camera is always a fixed height on a spring arm, so the view is consistent throughout - it just focuses on the mid point of the vector between the two players.
You need to calculate your viewport size using your field of view value which you can get from your camera component in blueprints. Then, you will need to construct your viewport boundaries using your camera anchor point and its dimensions. This will basicaly give you a plane of some size (x, y). In general, you will need to make sure that your player’s position realtive to the anchor point (the center of the plane) is always inside of that plane (abs(Player.X) - abs(Camera.X) < Camera.MaxX and same for Y).
It’s not the easiest thing to implement, but absolutely doable. Tell me if you need more info.
You could have your camera zoom in and out dependent on the distance between the players (smooth average between the two) and then limit the distance they can be apart from each other by measuring the difference in distance and giving a branch if greater than distance then movement wouldn’t work?
Thanks for that dude. I totally get what you’re saying, but I’ve had no luck implementing it into blueprints unfortunately. Any sort of simple breakdown you could give would be much appreciated.
Wouldn’t it be easier to attach two Collision components(box) to the Camera component. These invisible walls will always follow the camera. To position them accordingly to Viewport size just Get Viewport Size node / 2 = X. One wall will be at Camera location(x-axis) - X and the other Camera Location(x-axis) + X. Maybe I’ll test it out later for you.
You could set these walls to only block the players and nothing else.
Oh I was thinking of a 2d side scroller, my bad Well I think It could still work though you would add two more walls on the y axis.
Tried using four collision boxes in the camera component, but not to any great effect. I didn’t use the viewport size node, though. Worth a shot! Thanks.
This was the first approach I took to it (without the zooming functionality), but then there was the issue of enabling the player controllers after disabling them.
NavMesh is a necessity in Top Down gamemode. There’s a NavMesh in the template when you start a new project and the player won’t move without it.
However, now that you’re questioning this and I assume you’ve already seen the players run out of the cameras viewport, I don’t know what to tell you <.<
I’m not sure how that’s set up then to be honest - although the topdown template does have one, I’ve built this project from scratch without a navmesh. Both players can move freely without one (collision with geometry the only thing to restrict a players movement).
I was kind of hoping for a better answer here. I’m having the same issue, except my camera also needs to zoom in and out. For some reason, this question is basically the only place online I’ve seen somebody try to get an answer for this.
Currently my fix is attaching four planes with Blocking collision to my camera, which sucks because it took forever to get their size/position/rotation right. And also I’m pretty sure they won’t work if your screen has a different aspect ratio than the computer I set them up in. Not ideal at all.
That anonymous guy with the vector math was onto something, but he just showed how to calculate whether or not the players are in-bounds, not how to actually keep them there.
Well I think It could still work though you would add two more walls on the y axis.