Public web-service interface to support multiple front-ends
Posted: Fri Oct 05, 2007 10:53 am<Subject>:
Concise Idea - ConquerClub web service to provide all functionality via a web-service so that different people can develop different types of front-ends without having to do screen-scraps.
<Body>:
Specifics - The CC game logic could be modified to support web-service interface. You're basic methods needed for web-service support are:
Why it is needed - It's not needed, but the results could be beneficial to CC in the form of more front-end options for the players. It could also benefit CC by separating the logic from presentation, the presentation code can be updated and changed without ever modifying the game rules/code and vice-versa. Since there is this logical separation, physical separation can also occur by moving game code or presentation code to another server (if desired), providing better stability and performance.
Also, a properly developed front-end could significantly cut down on the bandwidth. Not everyone is interested in the history and, in reality, the game log can be send at a much less frequent interval than map updates and chat updates (possibly even on-demand).
I realize that the current code structure of CC probably is not going to lend itself nicely to this idea, but I wanted to throw it out there and see what others think. I already saw someone, who was bored, try to develop a flash front-end version of CC and this would help that project out immensly.
Concise Idea - ConquerClub web service to provide all functionality via a web-service so that different people can develop different types of front-ends without having to do screen-scraps.
<Body>:
Specifics - The CC game logic could be modified to support web-service interface. You're basic methods needed for web-service support are:
- Authenticate - Authenticates the person using the front-end and returns a token that they must provide in all other web-service calls
GetMyGames - Gets basic status of all the user's games
MapUpdate - Gets all current map information and timer information
LogUpdate - Gets all log information (relative to the user)
ChatUpdate - Gets all chat (relative to the user)
BeginTurn - Indicates the user is starting their turn
EndTurn - Indicates the user is ending their turn
GameAction - Indicates an in-turn action (i.e. Submit cards, attack, fortify, deploy)
LogOut - Indicates the user is logging out
- - Prevention of Web-Service call flooding (i.e. a front-end sending update requests at .1 second intervals)
- Prevention of sending any non-user relative information such as what cards the opponents have.
- Indication of the which users are using which front-ends and ability to allow only CC based front-ends in their games.
Why it is needed - It's not needed, but the results could be beneficial to CC in the form of more front-end options for the players. It could also benefit CC by separating the logic from presentation, the presentation code can be updated and changed without ever modifying the game rules/code and vice-versa. Since there is this logical separation, physical separation can also occur by moving game code or presentation code to another server (if desired), providing better stability and performance.
Also, a properly developed front-end could significantly cut down on the bandwidth. Not everyone is interested in the history and, in reality, the game log can be send at a much less frequent interval than map updates and chat updates (possibly even on-demand).
I realize that the current code structure of CC probably is not going to lend itself nicely to this idea, but I wanted to throw it out there and see what others think. I already saw someone, who was bored, try to develop a flash front-end version of CC and this would help that project out immensly.