Answer the question
In order to leave comments, you need to log in
What rake should be avoided when designing a turn-based client-server computer game?
Good afternoon. I am developing a computer game like chess, for the sake of getting to know wcf, EF and multithreading in c #.
Purpose: server service, desktop clients. The client registers (just a pair of login and password, without any security bells and whistles), gets the opportunity to create games, join current ones (as a player and as a spectator), play with bots (the bot already exists), receive a list of games. The database stores logins, passwords, game histories, player ratings.
The main question is: is it worth somehow maintaining a connection with the client during the game? It is clear that you can force the client to require a situation update every 5 seconds, but this will generate a lot of meaningless request-responses. It seems much more elegant to save data about the client connection, and send information there during OnGameChange().
The main question is: what other subtle points can come out in the development process?
Answer the question
In order to leave comments, you need to log in
I'll start by answering the answer above. Remoting is not a very pretty solution, its abstractions flow everywhere. "Sharing" an object over the network makes it difficult to determine the lifetime of the object, and the simplicity of method calls tempts you to make a bunch of small requests instead of one large one - which will inevitably lead to slowdowns.
WCF is the ideal solution. It's much simpler than proper socket handling - and doesn't suffer from the disadvantages of Remoting.
Transport in this task is better to use NetTcp - it is easier to implement two-way communication. The connection with the client can be maintained by means of ReliableSession - just set the correct timeouts here, otherwise the result will be strange. So, it is better to set the timeout for reading here to be generally infinite, and the session lifetime, on the contrary, is small.
There will be a lot of problems during implementation, especially if you write at a low level of abstraction. The OnGameChange solution is beautiful, but relevant for realtime games, like action games, etc. for step-by-step, sending a request every 500ms is not critical if implemented correctly, even if there are 1000 games on 1 server with 10 players on each, which hardly shines for a self-made game.
In my experience, this is easily and beautifully implemented using Remoting.
All client and server code will easily fit in 30 lines in the worst case. Wrote a similar client-server recently.
Your server should use high load technologies :). Forget about SQL, forget about markup generation on the server side, forget about wcf, xml and other wonders, just binary hardcore, I advise you to do it on the web platform and webSockets. SPA architecture, HTML5 + JS will allow you to make both an online game and an application for all mobile platforms using Apache Cordova.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question