Please keep in mind that I haven't really looked into ViCE yet. I just want to share some hopefully helpful comments. I might be very mistaken about what I write, because you have certainly put much more thought into ViCE than I did. But here we go:
aspidites wrote:ViCE is at a standstill. There is a minimal working ORM and the plugin framework technically works and is documented. What's not done is to actually write the plugins.
When I read "plugins", I think this already sounds complex, because you have to think a lot about how other people integrate with your code. And plugins tend to integrate very deeply.
I assume you want to support server-side plugins, so that everyone can enforce a certain ruleset for certain games. I think it would make much more sense to not worry about rulesets and just trust the players to do the right thing. I mean, in RL with physical cards the players have to handle the rules by themselves as well.
My gut feeling is that the following implementation strategy would be a good idea:
Define a REST-based protocol which makes heavy use of JSON. The server then supports the most important primitives like deck shuffling, drawing cards, notifying about actions players have taken, marking cards as being in a certain zone (deck, hand, whatever-zone-you-need), the actual contents/rules of a card (in JSON format), upload a deck (in JSON format) and manage counters like health of a player.
Overall the server should be very stupid. And the client should not be clever too. The client should focus mostly on displaying the board and make it possible to translate player actions into REST calls and the server should be able to translate these REST calls to modifications in the game state.
The core principle would be the REST-based protocol. It should be simple and stupid and anyone should be able to implement a client and/or server for this protocol. If you need very special represenations of cards, you would fork some existing client and just add some additional functionality that supports these very special representations.
And we could still add more REST endpoints later on, if we notice that we need them.
That said, Over the last few years, I've been moving away from Python for personal projects (as it's my day job) and been messing with functional languages like Haskell and Purescript.
I know, it is very tempting to always reach for the newest and seemingly most powerful tools. I've been there many times... That's why a standardized protocol between client and server would be good, because it would give you maximum flexibility for choosing your implementation language.
I guess it would also make it easier to prototype stuff, because you can programm the client by using a dummy server that always returns the same cards. And in a similar fashion, you can programm the server by having a minimal (and ugly) client, that makes some requests.
I'll be on IRC (#wtactics) for a good part of the evening if you wanted to hop on and chat. Indeed, I think for the next hour or so I'll be experimenting with some architectural type stuff.
I've read this post too late. Bummer.
From a programmers' point of view, I think being able to assemble a deck, draw cards, and move them around would be a good first step.
Okay. So we are still in a very early developmental stage.
I think the current discussion focusses very much on code. We should continue discussing in a different thread but I am not sure which one.