Ruby est-il viable pour coder un serveur de jeu ?

Vu que tu parles de jeu HTML5 et de websocket, j'ai bien envie de te répondre Node.js. Et je ne crois pas que ce n'est qu'une histoire de mode. L'avantage c'est que du fais du JS à la fois sur le client et sur le serveur.

Il y a pas mal de benchmarks sur Node.js qui tendent à le donner gagnant sur bien des choses, grâce à son mode de pensée asynchrone. IL faut toujours prendre les benchmarks avec du recul, mais c'est quand même toujours révélateur de certaines choses. Là Oû Node.js n'est clairement pas bon, c'est pour faire des gros calculs… donc si tu as beaucoup de logique de jeu côté serveur, ce n'est peut-être pas un choix judicieux.

Pour en revenir à ruby, à l'époque où j'avais voulu m'y essayer, un truc m'avait énormément bloqué: les threads sont des faux threads. Une entrée I/O, typiquement avec un socket TCP ou un fichier, ne bloquait pas seulement le thread où l'I/O était faite, mais l'ensemble du programme. En voyant ça j'avais laissé tombé direct. Mais c'était il y a au moins 5 ou 6 ans alors peut-être que ça a changé maintenant… je crois que ça devait être la version 1.8 quelque chose. Les threads totalement indépendants de la plateforme n'ont pas que des avantages et j'espère qu'ils n'ont pas persisté dans cette idée.

Autre truc chiant avec ruby que j'ai toujours l'impression de percevoir quand je fais des recherches, c'est que si tu utilises ruby, alors on suppose par la même occasion que tu utilises forcément ruby on rails. C'est presque à croire qu'en dehors de ce framework (certes populaire, très bien et avec une bonne communauté d'initiés), pour ainsi dire rien n'existe. Dans aucun autre langage on ne fait le même genre d'amalgamme (ce serait équivalent à dire que si on fait du python alors on utilise nécessairement Django; ou si on fait du PHP alors on utilise forcément Symfony; dans tous les cas c'est ridicule mais ça a l'air bien ancré pour ruby malheureusement)

De mon côté j'ai un serveur de jeu codé en Java. J'ai régulièrement 500 connectés simultanés et ça tient très bien la route. La majorité de la logique de jeu et des IA sont côté serveur mais ce n'est pas des IA très gourmandes (l'IA la plus gourmande, celle du puissance 4, est reportée sur le client).

Tout dépend du travail que doit faire ton serveur de jeu, mais en général, ce sont les IO qui empêchent de passer à l'échelle sur ce type d'applis et non le calcul, donc tu peux laisser C++ et Java dans leur coin si tu n'as pas envie de te les coltiner.

Ruby peut faire parfaitement l'affaire du moment qu'il supporte un truc de base : l'appel système poll, ou select (et je serais très surpris que ce ne soit pas le cas !).

À partir du moment où ton langage sait faire l'un des deux, il peut écouter sans bloquer sur un descripteur de fichier (dans ton cas une socket TCP) et donc tu peux implémenter un serveur asynchrone.

Ça résume à peu près ce que dit QuentinC juste au-dessus. Du moment que tu peux faire de l'asynchrone, tu peux gérer des dizaines de milliers de requêtes TCP par seconde sans problème. Du reste, en ce qui concerne les frameworks asynchones (pour d'éviter de perdre du temps à recoder tout le bas niveau de ton serveur), je ne sais pas trop ce qui existe en ruby.

Sinon dans ce domaine il existe deux ou trois alternatives : Node.js qui tient le sommet de la hype en ce moment, Go qui est fait exprès pour ça et offre des perfs remarquables, ou encore Python avec la bibliothèque standard asyncio, qui, depuis la sortie récente de uvloop, représente un très bon compromis entre les deux précédents, en éclatant les perfs de Node.js tout en offrant un plus haut niveau d'abstraction que Go, donc un feeling plus proche de Ruby.