Rival Books of Aster is a collectible-card game (CCG) not unlike Magic: The Gathering and Hearthstone. More information on this game is available at:
I was pleased to contribute to this project as a server programmer and AI developer.
While this game has a number of distinctive features — including a non-linear player-influenced story and a unique art style — in this post I will talk a bit about the server architecture.
First of all, we decided that building our own distributed server architecture didn’t make sense; the programming team was only 3 people, and we didn’t have the time or budget to invest in developing basic server-software technology from the ground up. We chose to start with SmartFoxServer as a base server technology (our base client technology was the Unity Engine).
I personally pushed for an authoritative server model. As an Internet-connected turn-based game, cheating was a concern, but network latency was not. An authoritative server model meant that all moves made by the player were validated by the server — even if a player were to create a hacked version of the game client, the server would refuse to accept moves that it decided were illegal.
Another benefit of this server model is that the client did not need to compute the (sometimes quite complex) effects of any given move. When a client submits a move, the server returns all effects of that move (assuming the move is valid). The effect computation logic needs to exist only on the server — the client does not need to duplicate this logic. Adding new or modified moves or effect types can be done by a redeployment of the server, without requiring an update of the client.
I chose to write the server logic in the Scala programming language. There were two reasons for this: I wanted to see if the Scala language features could be used to express the server logic in a more compact and understandable way than other languages (e.g., Java or C#). The use of Scala also allowed me to more easily justify the server development effort as a research effort — at the time, I was actively working with Scala on another research project. Justifying the effort as a research project allowed us to qualify for research funding, which meant that I was able to get paid to work on this project.
It is difficult to tell whether the design and programming decisions I made were the “right” decisions. I suppose the decisions can’t be too far wrong — the game server has been up and running for over a year now, and as far as I know, there haven’t been any major failures. Some of the code was fairly experimental (in that I’d never done anything quite like it before). Investing in experimental code during a tight production timeline poses a risk, but also helps me maintain interest, develop new skills, and (at least in this case) qualify for research funds.
There are other interesting aspects of this project that I do not cover here, but may in a future post. The AI may be of particular interest — look for a future posting on the Rival Books of Aster AI.