Multiplayer game state management

[Laurens]

Hi guys (and gals),

 

I have been playing around with networking lately and have come up with a multiplayer architecture that works reasonably well. I did however not forsee how easy it would be to hack when all clients have full knowledge over each other as they do right now. I came up with the following functioning solution:

 

In the context of a card game, for each domain object (such as a Deck, Hand, etc.) I have a representative counterpart (DeckRepresentation, HandRepresentation, etc.). For example, a Hand object contains a number of concrete Card objects that tell the player what rank and suit it is. A HandRepresentation only contains an integer representing the number of cards in the actual hand. The idea is that each player only has a reference to the full Hand object it is controlling him/herself, and HandRepresentation's for the other players. I guess you could say the representations are simply stubs for the real thing.

 

This leads to a small class explosion because I need two of everything. This is tedious to maintain (even though in the context of a card game the number of classes is pretty limited) and was hoping to get some input as to what you guys think of this solution. I would also be very interested to hear how others have tackled this particular issue.

 

Thanks!

[Guest Red Ocktober]

i dunno for sure... i prefer to keep everything on the server... for me, it seems to simplify things a bit...

 

in your example, hierarchically, i'd start out with a shoe, and work downwards to a deck, a hand, a card...

 

a game of blackjack for example, would have 1 shoe, 4 decks in a shoe, and six players each with one hand...

 

since they're all represented on the server, clients only see a 'ghost' of what's happening on the server...

and all clients do is send input messages to the server (hit, stay, surrender, etc.)...

 

 

--Mike

[Laurens]

Hi Mike,

 

Thanks for your response! Everything is on the server as it is and clients only have full knowledge over the player they are controlling in the game and not the others. The need for representation classes is that I will still need to render the other players, i.e. if the player to my left is holding three cards I need to render the backfaces of three cards. The client won't know which cards it are, simply because it is never told him/her, but I will need to know the amount in any case.

 

In other words, the "ghost" of the player you're controlling yourself needs to be more knowledgeable of the game state than of any of the other players and I ran into the problem that this distinction cannot always be properly made by using the same data structures. If I have a Hand class for example, it has a method +Add(Card card): void. It obviously adds a card to the hand of the player but a remote client that is not dealt that particular card can't know which card it was and cannot call that method. The HandRepresentation class therefore exposes an +Add(): void method that simply increases the card count for that hand.

 

So I guess all I'm asking is: how do you (or others for that matter) separate a full-knowledge (about him/herself) local client from the remote clients on a class-level? Do you use the same data structures or make two separate structures for each purpose like I did? I hope I made myself clear

 

Cheers!

[Guest Red Ocktober]

ahhh... i see now... thanks for the explanation...

 

--Mike