Best client/server architecture for a mobile management game?

Question

For the past year I have worked on a small company that develops a traditional browser based strategy game, of the likes of Travian or Ogame, but using a more interactive approach like Tribal Wars 2.

The game is made in a simple php server without frameworks and a simple mysql database, and all of the game happens in a single static page that is changed through ajax calls and has a map made in pixi.js. The automatic updates are delivered to the client side through polling the server which then queries some specific database tables made for the purpose for changes.

While this approach is solid and works, it has 2 big problems:

• Having a mobile app is increasingly more important and there are not enough resources for having two separate codebases. Having a app which is simply a wrapped webview is also not a solution because the performance of a really complex page with a giant webgl map is, while usable, really subpar;
• Polling the server for changes creates a lot of programing challanges that make some simple tasks really complicated and creates a lot of convoluted code if we dont want to hurt the game performance, as we are not going make dozens of database queries every 5 seconds.

I want to start developing a game idea that I have that is basically inserted in the same genre and which is going to be, at least initially, mobile only. The real problem here is that after reading a lot on the internet, I am confused on what should be a good client/server architecture for me to start prototyping in a way that I do not run in the problems mentioned above.

Basically, above all, I want the server to be able to know which page/screen/state is each client looking at, and be able to send them messages when another client changes something on that specific screen. It would also be nice if the solution is something lightweight on the server side to be able to scale a little.

Client side I was thinking about Unity because of being cross platform, of all the environment around it (ads, analytics, a lot of support and answers on the internet), and because I have previous development experience with it.

Server side is the real question.

• Simple http calls will not work and so PHP is out of the equation.
• I have though about using node.js with socket.io to use websockets solving the polling problem. Is this a good idea? Would it be better to store the game state in a relational or nosql database in this case? Would this work on unstable mobile conections?
• Lots of people seem to use a c# and sockets for unity. Would this be overkill in this situation? Taking this approach how would the data be stored? would it be feasible with a linux server or would I need a windows server? Would this work on unstable mobile conections?
• Don't know, I'm open to suggestions.

tl:dr: I want to make a mobile management game in unity but am confused what to choose for the server side architecture considering that I want the server to be ablose to send a message to the client without the client asking for it. Is there anything I should take in account?

Sorry for the broad question and thanks for the help.

Answer 1

I think really your question seems to be one of protocol rather than language. You've ruled out HTTP, but that doesn't necassarilly rule out PHP, as you can implement websockets in that as well as other languages. The same is also true of sockest, so if you know PHP my advice would be to stay with that language server side unless there's a compelling reason not to.

You can run C# on a linux server (take a look at Mono or .Net Core), but again, if you're happier in another language then use that.

On the client side, a native Unity app will best support HTTP and Socket connections (there is a Web Socket implementation in the Asset store, but it's not native yet), and there may be other protocols supported in the Asset Store.

For the server side, I would recomend TCP sockets though, as they are fairly reliable, and don't have the overhead of a HTTP request. You can find code examples for both the client and server implementation (as well as a wrapper class for socket interaction) here. The examples assume C# on both the client and the server, but there is no reason you couldn't replace the socket code with a PHP implementation, or Node.js, as the server side language doesn't need to match that of the client side.

In each case the database backend is largely down to what you're comfortable with (MariaDb, Mysql, MongoDb etc) and the connection is language specific. Again, go with what you're familliar with, it'll save you a lot of time.

There is no one-size fits all answer. Really it's donwn to what you're experienced in and what your exact requirements may be (for example, HTTP is a perfectly acceptable implementation for slower paced games). Hopefully this'll give you some ideas about what's ouyt there though, and get you on a path you're comfortable with.