Best practices for distributed Magic play
Posted: 03 May 2013, 22:50
Hi all!
After my latest attempt on a Magic engine ended after I realized that I had fundamental flaws at the lowest level, I was now thinking again about what is really necessary to support a Magic engine that will survive adding network play in different variants.
With different variants, I basically mean these features:
Besides that, there are a few other requirements:
With transmittable actions, there come a few other features that would be great and shouldn't add too much additional work at that point; undo and game persistence, namely. Undo adds the possibility for Min/Max and possibly other AI algorithms, besides being nice for the user, and game persistence is practically self implementing when even a remote engine can be initialized with a list of actions taken.
I thought I wouldn't be the only one interested in these things, and I haven't sorted out what is the right thing to implement first so that my work stands on a solid foundation. Do any of you have ideas on these topics, already implemented or otherwise? Do you see other questions that I forgot to ask?
I'm not looking for a how-to or something. I'd like to discuss here, not necessarily answer the questions directly. Getting a better understanding of what is and what isn't needed is half the work.
After my latest attempt on a Magic engine ended after I realized that I had fundamental flaws at the lowest level, I was now thinking again about what is really necessary to support a Magic engine that will survive adding network play in different variants.
With different variants, I basically mean these features:
- A classic client-server model, where the clients do not run the game engine themselves, but only receive the information they need (here, I don't yet demand that a malicious client couldn't cheat)
- A true peer-to-peer solution, where the clients all run game engines, but they are kept in sync, ideally even across multiple versions of the software (to some extent of course)
- A combination thereof, e.g. clients connected to different servers that have mirrored game engines
- Spectators that view, but don't participate in the match (e.g. a GUI for an AI only match)
Besides that, there are a few other requirements:
- For client-server, the clients shouldn't be able to cheat. That can be quite sophisticated. For example, a client should be able to tell that a library was shuffled, but must not be able to infer from any IDs what the shuffling did to the library.
- For mirroring, it shouldn't be necessary to transmit game states, but rather only actions that modify the game state (or is there a third option?) Implications are that object references must be somehow valid across the network, and even worse, objects created through the action must receive the same ID on all mirrored engines.
Ideally, the transmitted actions are still on the semantic "Magic" level, e.g. "attack with these creatures" instead of "tap these creatures and add them to combat." I don't know, but I feel that would be the better way to transmit actions.
With transmittable actions, there come a few other features that would be great and shouldn't add too much additional work at that point; undo and game persistence, namely. Undo adds the possibility for Min/Max and possibly other AI algorithms, besides being nice for the user, and game persistence is practically self implementing when even a remote engine can be initialized with a list of actions taken.
I thought I wouldn't be the only one interested in these things, and I haven't sorted out what is the right thing to implement first so that my work stands on a solid foundation. Do any of you have ideas on these topics, already implemented or otherwise? Do you see other questions that I forgot to ask?
I'm not looking for a how-to or something. I'd like to discuss here, not necessarily answer the questions directly. Getting a better understanding of what is and what isn't needed is half the work.