make the camera follow 2 players / split screen

[Quote]

Hi, i currently work on a multiplayer game (here), but i have a problem.

In the game the players are supposed to discover a map and for that, they need to split up (like one player goes to the east and the other to the west).

But here is the catch, if the players split up, the camera only follows one player and the other one is off screen.

My first solution was, that i could scale the game down, if the players get too far away from each other, but this would also mean that the players could see the whole map at once and would not need to discover it.

So i thought that maby i can use two canvas to get somewhat the effect of a split screen, but i don't know how i should do this...

Could someone tell me, how i can make the camera follow multiple objekts/players, or make some kind of split screen?

 

sorry for bad english...

[n-gauge]

How about simply just zoom out the viewport (until a certain size is reached) , then stop the players from moving until they are within a set proximity of each other?

(This could be achieved via css which on modern browsers is hardware accelerated)

Using 2 canvas's could get messy / have a slowdown on your game (which is looking fine btw). 

[JazzAceman]

The camera can only follow one player at a time, but you can imitate your desired behavior by setting the focus of the camera to the median point of the two player sprites. Then you must stop the players movement if one of them reaches the viewport border.

 

For example (not tested):

function update() {var medianX = (player1.body.x > player2.body.x) ? (player1.body.x - player2.body.x) : (player2.body.x - player1.body.x);var medianY =  (player1.body.y > player2.body.y) ? (player1.body.y - player2.body.y) : (player2.body.y - player1.body.y);game.camera.focusOnXY(medianX, medianY);if(player1.body.x < game.camera.view.x) {    player1.stopMoveLeft(); // implementation dependent}if(player2.body.x < game.camera.view.x) {    player2.stopMoveLeft(); // implementation dependent}if(player1.body.y < game.camera.view.y) {    player1.stopMoveTop(); // implementation dependent}if(player2.body.y < game.camera.view.y) {    player2.stopMoveTop(); // implementation dependent}if(player1.body.right > game.camera.view.right) {    player1.stopMoveRight(); // implementation dependent}if(player2.body.right > game.camera.view.right) {    player2.stopMoveRight(); // implementation dependent}if(player1.body.bottom > game.camera.view.bottom) {    player1.stopMoveDown(); // implementation dependent}if(player2.body.bottom > game.camera.view.bottom) {    player2.stopMoveDown(); // implementation dependent}}

... There might be more elegant implementations. 

 

A splitscreen solution would be difficult since Phaser dosen't support more than 1 camera at the moment. You would have to make 2 seperate game instances and synchronize them locally with shared variables or per Webserver. Depending on your target-platform's performance and desired graphics- and simulations-complexity, this approach could work. Another solution could be to simulate the split screen by generating 2 different parts of your tile map based on the players position, one on each side of the viewport. But I think this would be very hard to manage.

[ZoomBox]

I think the trick is to manage two game instances like it would be done in a server multiplayer game

[Quote]

thank you guys.

I will try to make it a server multiplayer game for now. But if this gets to complicated for me, i will try JazzAcemans's solution.

[jusahah87]

I did split screen: www.spacebombers.com/spacegame/

 

The trick for me was to have three separate phaser instances running simultaneously:

 

instance #1 runs physics calculations and game logic, broadcasting locations of game objects every 1/60th second

instance #2 listens for location updates and renders player 1 view. 

instance #3 listens for location updates and renders player 2 view

 

This naturally has some performance implications. But it was pretty easy to develop and it is possible to quickly turn into online multiplayer (just ship the #1 instance to server and broadcast locations through websockets or udp).

[Skeptron]

The controls of your game are so haaard (this acceleration makes it impossible to manoeuvre), however big up for the rest and the dual screen. It's pretty awesome!

 

Making a multiplayer game is (almost) never easy. Unless you want to make a naïve, broadcast-like implementation on the server-side, dealing with backend checks, lag compensation and threading is a hard thing to do, IMHO.

[jusahah87]

The controls of your game are so haaard (this acceleration makes it impossible to manoeuvre), however big up for the rest and the dual screen. It's pretty awesome!

 

Making a multiplayer game is (almost) never easy. Unless you want to make a naïve, broadcast-like implementation on the server-side, dealing with backend checks, lag compensation and threading is a hard thing to do, IMHO.

 

Hey, thanks for feedback! I did not realize controls are cumbersome (probably having had enough time to get used to them myself...). 

 

I was actually thinking about turning this game to three-way split screen but I dont know if a single threaded JS virtual machine can handle that. I guess one possibility is running a local node.js server which does all the physics calculations, and then simply three (1 per player) phaser.io render instances listening physics updates on some local port or something. That way at least the physics (which is probably most expensive!?) would be on its own thread.

[Skeptron]

I really don't think physics are the most expensive. I'd go for the rendering. But maybe I'm wrong?

[jusahah87]

You may be right Skeptron. 

 

Anyway I successfully implemented three-way split screen for Spacebombers. Latest version: http://spacebombers.com/spacegame/v3/

 

(Keyboard controls for 3rd player are keys [g,h,y,j,t,u,k] if somebody wants to try it out)

 

At least on my computer introducting 3rd screen ( = fourth phaser instance in total) did not affect performance in any noticeable way. So maybe I've grossly overestimated the cost of running multiple Phaser-instances at the same time.

[Skeptron]

Most people here are doing simple stuff and struggle with performances, and you manage 3 instance with 60 stable FPS : good job. The controls are still hard but what you've achieved is really awesome. Maybe you could do a tuto to address the multiple screens issue?

 

However I can't really imagine 3 people sharing a single keyboard. Could be awesome with controllers and a huge screen, but from what I've seen it would be quite unpractical.

 

Maybe a good old multiplayer with a computer per person would be more manageable.

 

Quick question for my curiosity : is the code so simple you could spawn instances on demand? Like "Pick the number of players", and bim! -> one instance for each player? Maybe there's room for an awesome plugin. Just sayin'

[jusahah87]

Yeah, keyboard sharing is not viable option for three players. 

 

The code is pretty simple for spawning new instance. I was actually thinking about making a "root menu screen" for the game where user can select how many players are attending the gaming session - like "2 players", "3 players", "4 players".

 

At the moment all rendering instances of Phaser share the same rendering code. That code is filled with conditionals like:

 

if (this.instance.owner === 'player1') {

 this.game.camera.follow(player1ship);

} else if (this.instance.owner === 'player2') {

 this.game.camera.follow(player2ship);

} else if (this.instance.owner === 'player3') {

 this.game.camera.follow(player3ship);

}

 

and so on. Adding fourth instance (for 4-way split screen) means adding fourth conditional check to about dozen places in the rendering code and then adding fourth physics body to the logic code (which has its own Phaser instance). 

 

With some refactoring that "pick num of players" functionality is very possible. I don't see any reason (apart from performance issues, of course) why it could not spawn ten instances for huge ten player split screen game.

 

One interesting possibility would be to run each rendering instance in its own browser window, thus utilizing multicore-CPUs better. Then one browser window could run the game logic and physics, and they all communicate through locally running node.js server. I dont know how the gamepads would work in this case though.