Syncing game state between server and clients

[Formedras]

I'm trying to figure out what the best way to synchronize the game state between each player is right now; what I had in mind is by no means ideal, and is a humongous waste of bandwidth. That is, have a game state class that held the existence of every card and Character, along with each player's Limit Gauge meter (should I change the name of that?), and serialize it to XML and send the XML Document over to every player and spectator. Like I said, BIG waste of bandwidth, sending every card pretty much every update.

I know what I should be doing instead is reduce the card information down to an in-game ID, card reference, and location after it's initially sent, leaving each card as a unique item, not to be changed. For some reason (maybe because I'd already half-implemented the bad way, maybe some other reason) I'm lost on how to implement it.

So, umm... in C#, how do I do it? I think maybe I should hold a list of cards on both the server and the clients and then reduce the game state cards down to the ID + card reference + location? If anyone has a better idea, I'm pretty sure I need it.

Two more questions: 1.) How obvious is it that I know much less about what I'm doing than I initially thought I did? and 2.) Am I posting too many topics in this sub-forum?

[Snacko]

Best client is a brain dead client meaning it only sends short queries like "I want to play this card" or "I want to see some zone". Then you server should only send the part of game state that was requested and is legal for the client to interact with, if it's illegal to do the action you just do nothing.
Clients should never ever have a full game state available to them, because this means someone could read it from the memory and cheat. You should track server side what the client knows and only send incremental data to conserve bandwidth.
Your idea with IDing everything is ok, however you need to make sure that IDs will always be unique. I don't know why do you need card reference ? Isn't that the same as ingame card ID.

[Formedras]

Thanks for the advice; I think that it is the best plan, and I'll use it unless I for some reason can't.

As for the difference between Card ID and Card Reference... as far as I was thinking, Card ID would be the specific instance of the card, while Card Reference would point to the card's rules (and probably extraneous info, like the expansion card number). Basically, the Card ID tells where the card is, but it would need the Card Reference to know what the card actually does. The Card ID would need to exist because I'm not using a contract between the server and client (at least not how I've come to understand data contracts), forcing me to use a method of IDing a card on both the client and server. Then again, I would pretty much just need to ID the card itself on the server, while just needing its position for client/server purposes, wouldn't I? Ugh... this stuff is why I need a fellow programmer working on this.

On the subject of reducing the bandwidth used, should I be creating separate classes for the card as used by the server and the card as visible to the user? (Basically using an explicit conversion method to transfer the card text into the VisibleCard class from the Card class, I think.) Taking out the server-side card rules should cut the transferred data by a few hundred bytes per card, right?

If I seem lost, it's because I probably am. If I seem like I know what I'm saying, I'm probably still lost.

[Snacko]

Yea same ID for client / server is the way to go. I don't see why you couldn't do that. I just hope the card reference is just another ID not some heavy object.

For communication you should have message classes as Arch described using event example viewtopic.php?f=73&t=4226#p56109

Do you really not trust the client to have data locally with the text and basic characteristics ?
Because if you do, then a simple message would look like "play card ID 5", "create card ID 5, cardRefID 10". Then the client does it's thing and if you ever get an invalid message this means the game state got desynchronized = cheating / packet loss (either abandon game or force client to recreate the current game state from zero). This means both server and client know the rules but the server acts as a judge to enforce them.
You could always have the client oblivious to the rules but it means you have to send very low level messages which direct the client step by step.

[Formedras]

Perhaps you're right about the card thing; right now, I'm basically trying to figure this out from scratch every week or so. (In the last month since I started I've gone through at least four different Visual Studio solutions...) I forget things left and right. This time, I forgot that there are parts of the GameAction class that I do want the client knowing, and therefore it'd be best if it had the GameAction itself rather than just a text description.

Thanks for the help; if you've got any other ideas, please reply or PM.

[Incantus]

This means both server and client know the rules but the server acts as a judge to enforce them.
You could always have the client oblivious to the rules but it means you have to send very low level messages which direct the client step by step.

In order for the client to be able to recreate the game state and know the rules, it has to know everything (including all hidden information such as your library and the other player's hand/library). So for a rules based game you have two possible options.

1. You have a client with full information, in which case you don't need a server - each player's client has a full rules implementation and one 'acts' as a server for the initial connection (but otherwise the connection is symmetric), and the only type of cheating that is possible is peeking at the any hidden information (any desynchronization between the two rules engines would suggest the invalid playing type of cheating). This is the approach Incantus takes.

2. You have a third party server that enforces the rules, and both clients are dumb and only know respond to low level events (such as move card from one zone to another, or show X amount of mana, etc).

For option 1, there is a possibility of implementing the game in a way that hidden information is only available with the consent of both clients (it involves some fancy cryptography - look up mental poker protocols if you are interested), but I haven't figured out how to make that work with magic yet, mainly since cards in MtG have functionality beyond just the value of the card (like in poker).

[MageKing17]

For option 1, there is a possibility of implementing the game in a way that hidden information is only available with the consent of both clients (it involves some fancy cryptography - look up mental poker protocols if you are interested), but I haven't figured out how to make that work with magic yet, mainly since cards in MtG have functionality beyond just the value of the card (like in poker).

It's a very cool bit of fancy cryptography, but yes, the complications of Magic mean that it's very difficult to do in Incantus (although if whatever game you're working on is simpler, Formedras, it may be possible).

[Formedras]

To Incantus: There is actually a third option that was being discussed here, and that is to let the clients know enough to not allow the player to choose an illegal option. That is, the client app can be privy to the card's Actions so that it can determine the valid targets for each Action. Unfortunately, the way my card format and card editor app are right now limits the ability to determine valid targets; for example, if a dead Character should be targeted, I can't currently (but will eventually be able to, once I modify the format) tell the program to JUST allow targeting of dead potential targets. Other than that, Option 3 would be pretty much dumb clients, though.

To MageKing17: It may be possible at face value, but is it really viable for a non-expert programmer like me? And is it really worth it? Either way, I probably shouldn't even try at this point.

[MageKing17]

To MageKing17: It may be possible at face value, but is it really viable for a non-expert programmer like me?

All you need is an encryption function, a decryption function, and a function to generate a random key. That can be "outsourced" to a more competent programmer, if you require, but with even a rudimentary knowledge of cryptography, you ought to be able to handle it yourself.

And is it really worth it?

Well, sure, if you want people to not be able to cheat. If you don't care about cheating, then no, you shouldn't bother.

Either way, I probably shouldn't even try at this point.

Well, that's a rather pessimistic attitude.

[Arch]

I don't think cheat-prevention is of any importance until you actually have players that may suffer from it.

[Formedras]

Well, that's a rather pessimistic attitude.

Perhaps it's more pessimistic than realist, I admit. (I usually try for realist.) But at least at this point, it's much more important to get the game working in the first place, and THEN prevent people from cheating, since it's probably just a handful of methods (regardless of how hard those methods would be to write) plus maybe a couple dozen lines? Plus, (loosely?) referencing Arch's statement, I'm not working on the phase where enough is at stake for the players to warrant anti-cheat. I'll probably have to implement it later, even if I have to hire someone to do it, but I'm not there yet.

On a related note: does anyone know if Cardmaster Conflict uses anti-cheat methods? That'll probably tell me right there whether or not it's really worth it for me to do it in the first place.

[Incantus]

To MageKing17: It may be possible at face value, but is it really viable for a non-expert programmer like me?

All you need is an encryption function, a decryption function, and a function to generate a random key. That can be "outsourced" to a more competent programmer, if you require, but with even a rudimentary knowledge of cryptography, you ought to be able to handle it yourself.

It's not quite that easy. Even the basic mental poker protocol is known to leak information about what cards an opponent has, and that's if you implement it perfectly. Many a programmer has fallen to the allure that cryptography is simply "an encryption function, a decryption function and a function to generate a random key" Even experts who know lots about cryptography screw up when implementing a protocol in real production systems.

And is it really worth it?

Well, sure, if you want people to not be able to cheat. If you don't care about cheating, then no, you shouldn't bother.

Well, as Formedras points out, without users there's no worry about cheating. That's why I've never bothered to implement it for Incantus. Also, if you go the server/dumb client route, then it's not necessary.

[Formedras]

I prefer SmartFTP myself. Its great for the fact that it automatically deletes files in non-empty folders so you can delete the parent folders. Im sure other clients do that too, but I just started using SFTP and just stuck with it.

...Huh? What does FTP have to do with game state management or anti-cheat?