### 2 player camera

#### osiaslemuel

• Posts: 370
I'm just wondering, How could I make a camera follow 2 players correctly, like in most 2 player games.
And how to ensure that all players will not going to leave the screen so no player will be left behind. Anyone knows?

#### Xietao

• Posts: 725
I thinks is very, very hard.
Free Time:
Monday, Wednesday, Friday: 13h
Tuesday, Thursday, Saturday, Sunday: 7h
Loving Linux...

#### ShivaFang

• Posts: 248
You are talking about 1 camera following multiple players, not a split screen, correct?  Similar to Secret of Mana, Gauntlet, Double Dragon and similar games?

I have not tried to do this myself, but this is the way I would attempt to code it and then work around any weirdness that comes up;

As a very very baseline, you'll want the centre of the camera pointing at ((p1x+p2x)/2,(p1y+p2y)/2)) rather than at the player directly (This is the point right in the middle of all players, adding their X or Y values together and dividing by 2 gets the average).  using the [Move Camera to [x,y]] block, you'll want to do this in an 'always' and move it gradually to that point at any given time.

Then it's a 'simple' matter of making sure that the players cannot move further in the 'x' direction than the width of the screen, and no further in the 'y' direction than the height of the screen.  This is done by checking the distance between the players in that direction.  Taking the 'absoloute' means you don't have to check if it's greater than and then less than, the absoloute makes -30 equal to 30, so you only have to really 'check' if it's less in one step to check either direction.

So in your movement code, it would be something like...
if <<[Aboloute Value of [P1X-P2X]] < [Screen Width]> or <[Absolute Value of [P1Y-P2Y]] < [Screen Height]>>
(Move the player)

You'll probably want to have a 'margin', perhaps equal to just a little more than the width of the player, so doing something like [Screen Width]-(margin value) and [Screen Height]-(margin value)] in your movement conditional would be a good idea.

(Oh except the way I wrote that it wouldn't let players move closer to each other, so you'll also want to check if they are moving towards or away from the other player before skipping the movement.)

The same principles apply to more than 2 players, and are really not that much more complicated if you understand the basics.

« Last Edit: May 12, 2012, 10:06:59 am by ShivaFang »
Justin "ShivaFang" White
Aquamentos Games - The origin of challenging Strategy and Role-Playing Flash gaming!
Visit our Developer Blog and Google+ Page!

#### Hectate

• Posts: 4645
Yep, ShivaFang has the details. If you want to kinda see how it turns out, one of my camera tests uses similar behavior - it averages the camera position halfway between the mouse and the "player" actor. It could just as easily be a second player's position instead of the mouse.

http://www.stencyl.com/game/play/9845
 :: Patience is a Virtue,But Haste is my Life.
Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

#### ShivaFang

• Posts: 248
Yup, but like I said that's a baseline and requires tweaking.  Having it always move to the middle between them will actually make some players motion-sick (because the camera is moving away from their player when they are trying to focus on their player - this is a lot the same reason that causes people to be seasick when the waves move them without their direct control).

One solution off the top of my head would be, moving it only if both players are more than 25% towards one side of the screen or the other.  If they are running in opposite directions it won't move, but if they are both going in the same direction then move it.  (This way if they are moving around the middle avoiding obstacles or fighting the screen won't constantly be moving - which can make people nauseous)

The flip-side would be if they are both near the edges of the screen, then maybe focus on the middle point between them, because then they can work together to move the screen whichever way is appropriate to the situation advancing a little at a time or whatever.

Another alternative would be to have the camera focus on player 1 unless player 2 is a certain distance away (more than ScreenWidth/4 or ScreenHeight/4) and then maybe offset it by ((ScreenWidth/2)*((Player2X-Player1X)-ScreenWidth/4)/((ScreenWidth*2)/3)) [Switch Width with Height and X with Y where appropriate]  Which basically means that when the 2nd player is less than 1/4 of the screen away, it focuses on the first player, and then the further away from that the 2nd player is, the more it is offset by, until they are a full screen away when the camera will be a half-screen offset from player 1 (and then right in the middle of the two)

This post is dedicated to:  Every High School classmate in any math class I've ever had who said "When would we ever use this stuff in real life!?" - especially Geometry and Algebra topics!

« Last Edit: May 12, 2012, 10:50:19 am by ShivaFang »
Justin "ShivaFang" White
Aquamentos Games - The origin of challenging Strategy and Role-Playing Flash gaming!
Visit our Developer Blog and Google+ Page!

#### Hectate

• Posts: 4645
Good point about the motion sickness, I hadn't considered that.

Your ideas are sound - when I think back to multiplayer games I've played and how they handled single-screen motion everything is very similar.

1. Super Mario Brothers Wii
Overall it averages between player positions, but with heavy smoothing. How quickly it picks up scrolling depends largely on the position and motion of the players (close together and moving same direction = immediate scrolling). The side screen bounds will push non-moving players forward (killing them as well if they get stuck or pushed into a pit), but upper/lower screen bounds are more forgiving as players can go beyond the screen somewhat.

2. Lego Star Wars II
3D camera but the levels are largely linear. It also averages out smoothly, but one player is designated as the primary (not always player 1, it depends on other factors). The primary's movement is given precedence in cases of opposite movements, while the secondary player gets pushed along the screen bounds (even when running in the opposite direction). There is a slight bias for forward motion in the "2D" sections, while 3D sections have a tendency to "look forward" into the playing field.

3. Battletoads (NES)
First level is locks camera from moving during certain fight segments. When those enemies are defeated, only forward (moving right) motion is permitted. If a player is on the far left of the screen, the other player is unable to move the camera further forward.

One technique to manage the camera behavior that bears consideration due to its flexibility is the "focus on an invisible actor" method. Not only could you manage the position by tracking players, but also override that to have more traditional scrolling cameras, or even cutscene intervals. All that simply by focusing on that invisible actor and controlling it's position rather than constantly setting the camera's X/Y.

Also: yes, I loved Algebra and Geometry, and I use them far more now than I would have ever expected at the time.
 :: Patience is a Virtue,But Haste is my Life.
Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

#### ShivaFang

• Posts: 248
Yup,  Double Dragon and Run Saber did the same as Battletoads (only forward motion) now that I think about it.  Good if there's only one route to the objective and backtracking isn't needed.

I considered saying 'a primary character' instead of first player, but I figured I'd simplify the explanation, since I wasn't sure about the skill level of the Original Poster

I like the suggestion of an invisible actor, then you can put the actor where it's needed and allow it to move itself rather than try to have the 'scene' calculate where the camera should be (much more complicated for the match-challenged)

Honestly, I probably wouldn't have thought about motion sickness.  I Alpha tested for Guild Wars, and I remember they made a change to the camera so that it was fixed to the player's head (or some other portion, torso or w/e), but when the player moved the camera 'bobbed' a bit.  I personally didn't notice, but a lot of the complaints on the forum at that time were about the camera making people nauseous!  So now I think about it a little.  (Also the meds I'm on make me a little nauseous regardless of what I'm doing, and I had taken them JUST before viewing your mouse-move demo, so I was feeling nauseous from the meds when I was viewingit that made me realise the potential connection)

(Side note:  100th post - about time I changed my avatar on these forums!)
Justin "ShivaFang" White
Aquamentos Games - The origin of challenging Strategy and Role-Playing Flash gaming!
Visit our Developer Blog and Google+ Page!

#### gonaka

• Posts: 30
my quick response is simply set camera to follow player 1 and player 2 cannot leave the screen boundaries and does not get followed by a camera - a la sonic 2's tails

#### osiaslemuel

• Posts: 370
Thanks for the answers, Ill try those tricks later.
I also want to learn how to do split screen  .

#### Nomosoft

• Posts: 122
- When any player gets within X pixels of the right edge of the screen and is traveling to the right, scroll right until the player stops moving or reaches the right edge of the map, OR the left edge of the screen hits the left edge of any player.
-- If the screen is scrolling right, don't follow any player to the left.

- When any player gets within X pixels of the bottom edge of the screen and is traveling downward, scroll down until the player stops moving or reaches the bottom edge of the map, OR the top edge of the screen hits the top edge of any player.
-- If the screen is scrolling down, don't follow any player upward.

Repeat for left and up.

Alternatively, just don't move the camera unless all players are within X pixels of a given edge.

« Last Edit: May 13, 2012, 12:16:12 am by Nomosoft »

#### ShivaFang

• Posts: 248
@osiaslemuel - split screen would be much trickier and would probably require you to turn off the sprites for all actors and do a 'when drawing' to draw what each player sees, and wouldn't work with tiles (unless there's a way to 'draw' a tile in code, 'cause I don't see a block)
Justin "ShivaFang" White
Aquamentos Games - The origin of challenging Strategy and Role-Playing Flash gaming!
Visit our Developer Blog and Google+ Page!

#### PrunePlum Games

• Posts: 174
my quick response is simply set camera to follow player 1 and player 2 cannot leave the screen boundaries and does not get followed by a camera - a la sonic 2's tails
...good idea, but that means that player 2 is trapped in the area until player 1 moves.