[Sohcahtoa82]

> The other reason is that the client and the server have to be written in the same language.

This isn't true at all.

Sure, it can help to have both client and server built using the same engine or framework, but it's not a hard requirement.

Heck, the fact that you can have browser-based games when the server is written in Python is proof enough that they don't need to be the same language.

[Thaxll]

Browser game don't need performance, I'm talking about AAA online games here, which 99% are built in c++ and the rest in c#.

[Sohcahtoa82]

> Browser game don't need performance

Mobile users will hate you when your game drains their battery much faster than it should.

> I'm talking about AAA online games here, which 99% are built in c++ and the rest in c#.

It still doesn't apply. There's absolutely nothing stopping you from having a server written in Java with a game client written in C#, C++, or whatever.

I'm really curious why you think client and server must be written in the same language. A TCP socket is a TCP socket. It doesn't matter what language opens the connection. You can send bytes down from one side and decode them on the other. I mean, sure, if you're writing the server in Java and use the language's object serialization functions to encode them, you might have a hard time decoding them on the other side if the client is in C, but the answer then is to not use Java's object serialization functions. You'll roll your own method of sending updates between client and server.

[Thaxll]

Because games are built with engines, and you're not going to re-implement all the simulation / systems in a different engine or language. Why would you? A gameserver is basically a game client stripped from rendering with a bit more logic.

I'm talking real time games here, not an .io game over websocket/json.