If you are building an aynchronous game without any real-time requirement using something like SmartFox, Electrocloud or Photon will just complicate things a ton - as these are made for real time games, if I were you I would stick to some type of JSON or XML based protocol which is sent over HTTP and backed by a standard “web” setup like Error: ASP.net | The ASP.NET Site server/etc.
Just as a side question etc as I’m interested in the topic (and hopefully this won’t derail the thread but contribute) but:
Is there a “break point” for when it is a good idea to use something like SmartFox / Photon ? For instance, most async games have a meta-game attached. Things like real time chat, secure connection, user profiles etc. In your opinion, would you put up with the pain to add these features or use those libraries to add the features where needed and just transmit turns via XML transactions, or just roll your own completely ?
Crispie: If the game is strictly asynchronous I would think long and hard before using something which is intended for real-time play (smartfox, photon, whathaveyou). The features you list can be achieved with HTTP, the only one which would be cumbersome is real-time chat, but for that I would probably use XMPP/Jabber or some other pre-packaged chat solution.
@Crispie : Thanks for the question, this was something I was wondering. @Fholm : Thanks for the answer !
As I explained in Unity Answer : Asynchronous Game server, we can compare my game to a chess game with realtime actions but not like a realtime update game. And requests to the server may look like a move in a chess game. So for me a HTTP server is good enough.
Concerning an in-game chat I thought about using direct connection between players with RPC calls.
It seems that Jabber uses unsafe code through p/invoke, therefore you can not get jabber-net working in the webplayer. But maybe there is a solution, that’s just what I saw in the forum.
I use MS Azure for my non-realtime game (a WIP) and it works as follows:
Web Role receives HTTP(s) requests.
When a request is received, I create a socket connection behind the firewall to a Worker Role which is running the actual game world and send over a packet containing relevant information.
The Worker Role then sends back a packet response after taking the appropriate action.
The Web Role creates an XML response based on the response and sends it back to the calling client.
The client then parses the XML and acts accordingly.
I use the Worker role methodology because the game world is constantly running and updates. The worker is necessary to maintain persistence since the Web role is transient. I have a database in the background where updates in the game world are saved in a separate thread. I flag elements to be updated when necessary and this keeps the world in-sync with the database should the world ever need to be re-loaded. For example, I can bring everything down to patch the game, bring it back online, and load from the database.
The database is also used for read-only metrics and queries. For example, I can run reports to see what players are doing and output it to a BI tool such as Tableau (or connect directly to the database as a data source.)
