maybe some of you allready came accross the
gameframe (http://sf.net/projects/gameframe) project?
Stefano suggested making more joint work. Actually we have started with an abstraction of general multiplayer game.
Somehow your approach (defining necessary card game mechanics) and ours (modelling game so abstract, that it is never wrong) are like buttom up and top down. Therefore I wonder if we could meet somewhere in the middle.
That is when someone starts modelling card games in Java couldn't it be that the classes he writes fit into the gameframe abstractions? Or to put it differently, could one of the plugins to gameframe be an engine which interprets XML card game descriptions and makes them playable within gameframe.
This would make gameframe more useful and reduce the "time to market" of both projects.
Of course on first step would be that someone inspects Ataraxia found card game mechanics and the gameframe game abstractions.
Just my two Euro-Cent,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the first layer will be the "transport/game" apis that we'll define in the gameframe-apis subproject.
Then we will build a layer that will handle game status, containers, statuschanges, container visibilities, and some more (Ataraxia need them, I don't know if gameframe want to do this, too).
We'll build the generic "rule" system on top of this latest layer, I think.
I think card games are so different one from another that most of the work done for the card game framework will be useful in generic multiplayer games too. We do not mind of real-time/action/3d games: I think this is too far from our ideas, now... but who knows in future...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
maybe some of you allready came accross the
gameframe (http://sf.net/projects/gameframe) project?
Stefano suggested making more joint work. Actually we have started with an abstraction of general multiplayer game.
Somehow your approach (defining necessary card game mechanics) and ours (modelling game so abstract, that it is never wrong) are like buttom up and top down. Therefore I wonder if we could meet somewhere in the middle.
That is when someone starts modelling card games in Java couldn't it be that the classes he writes fit into the gameframe abstractions? Or to put it differently, could one of the plugins to gameframe be an engine which interprets XML card game descriptions and makes them playable within gameframe.
This would make gameframe more useful and reduce the "time to market" of both projects.
Of course on first step would be that someone inspects Ataraxia found card game mechanics and the gameframe game abstractions.
Just my two Euro-Cent,
Frank
I think we need layering (with encapsulation):
the first layer will be the "transport/game" apis that we'll define in the gameframe-apis subproject.
Then we will build a layer that will handle game status, containers, statuschanges, container visibilities, and some more (Ataraxia need them, I don't know if gameframe want to do this, too).
We'll build the generic "rule" system on top of this latest layer, I think.
I think card games are so different one from another that most of the work done for the card game framework will be useful in generic multiplayer games too. We do not mind of real-time/action/3d games: I think this is too far from our ideas, now... but who knows in future...