How do i manipulate the game screen/camera(or something else lol!?) to always show a character from the perspective of the main player - in a mulitplayer game?

1

Sup guys wasn’t too sure how to describe the effect im trying to achieve in the title but im hoping the following example can help:

So in this real time multiplayer card playing game for IOS/Android - lets say 2 players are battling (yugioh-esque :D) how do i make it such that on player 1s device the cards in their hand are always displayed at the bottom of the screen and player 2s cards are at the top. And similarly on player 2’s device…their cards are the focus etc.

Any feedback (alternative solutions) welcome

1 Like
2

I think in most (almost all?) games, each client sees things from their perspective… Can’t you just draw local players card collection on the bottom, and remote players on the top…? I mean unless I am missing something, your question answers itself. :slight_smile:

3

Each game-client shows “local player”'s cards at the bottom and “remote player”'s cards on top.

When you’re writing the code to communicate with another game client (or a server), this “local player” vs “remote player” differentiation will become naturally apparent because a local player needs local input processing code, while the remote player will need totally different code processing input coming from your network subsystem.

Decent multiplayer architecture will abstract these two different implementations into one Player concept without needing to know where the input comes from. This way you could also add a third implementation of Player that is driven by AI: and you have an AI opponent to play against.

While starting a new game, you will for certain have to track which Player is bottom-screen and which is shown top-screen. There, you will put the local Player at the bottom.

4

From reading, I guess you are basically asking how to render split/screen?

You can render each “screen” to it’s own rendertarget (size = half screen) and then just plot the the textures/rendertargets to screen however you want it. That way you have a distinct camera for each “view”

5

Not quite what im after but appreciate the input - didnt know i could that anyway so it could have its use in the future.
Thanks @reiti.net

6

The network library im using is signalr and at the moment im just sending the current position of all players in the game room to all players - the issue is that these positions are absolute so players 1s cards are gona be in the same position on all screens.

Hmm yeah based on what you guys have said i think i need to explicitly introduce the concept of the local and remote players, and once done what im thinking to do is effectively just adjust the positions of any remote players - something like that should work right?

Thanks for the feedback @Mando_Palaise, @Thomas_Vantroyen

7

Ooh… I see. No, dont share global position like that.

First, You should give each player a unique id and pass that along while talking to the others. If you have no authorative server that can assign unique ids (which im assuming since you probably use signalr for peer 2 peer comm) your best bet is to have each client assign its own id using Guid.NewGuid() which has a very high probability to being unique, and passing that along when talking to other clients.

You also need to decouple the way your game works from how it is visualized on screen. So, make a separated representation of all aspects of your game in classes and properties without using anything related to rendering. Add your gamelogic (DrawCard(), Yield(), Raise(), things like that) to those classes by adding methods that alter the gamestate. Everything that changes the ganestate must go through methods ao your gamerules are unambiguously modelled in 1 central place. This is called the game domain model.

Then, have your player input call those methods as a player performs actions.

Finally, create a renderer: a separate piece of rendering code that reads the gamestate from the gamelogic classes you created earlier and renders it (using sprites etc) like you already are doing.

Now, because each client knows its own id, you now can have that renderer decide which cards go where on the screen depending on the player id.

8

Yeah this makes sense - thanks again for the input @Thomas_Vantroyen