J'ai des idées de très bonnes idées pour un jeu de stratégie en ligne similaire à Travian. Il y a un certain contenu que je n'ai pas encore compris et quelques autres défis que je ne connaissais pas encore.
C'est un projet assez important et peut-être trop lourd pour une personne qui n'est pas un développeur Web qualifié (encore). J'aimerais toujours lui donner un coup, mais j'ai du mal à choisir une plate-forme. Le monde des "balances" a été projeté beaucoup ces derniers temps et j'ai vu de rubis sur des rails étant basses parce que cela ne va pas bien, alors je suis venu ici pour obtenir des réponses.
J'aime rubis sur les rails, à la fois rubis et rails. Je ne suis certainement aucun expert à cela, mais j'aime travailler avec elle. J'ai également travaillé avec Python + Django avant et aussi avec PHP (que je n'aime pas.)
Idéalement, le jeu aurait, disons, 7000 joueurs par serveur, probablement beaucoup de données à traiter par seconde. Serait toujours une plate-forme viable?
Je suis désolé si cette question est vague, je suppose que je cherche un "ror va bien, y aller!" genre de réponse. Tout ce que vous voudrez peut-être ajouter est bien.
Merci!
5 Réponses :
Comme vous avez dit vous-même, vous avez déjà la réponse et vous recherchez uniquement des mots encourageants :). Je ne suis pas ror expert moi-même, mais je ne pense pas que l'évolutivité est toujours une question si grande sur cette plate-forme. Je vous conseillerais de faire une crèche d'architecture (terminologie XP). Écrivez un test avec 7 000 clients et méthode qui effectueraient des opérations similaires à ce que vous avez l'intention de créer. Par exemple, vous pouvez charger des fichiers, rendre vues ou même simplement attendre ... Le point est de ne tester que la chose qui vous inquiète. Bonne chance!
Donc, si j'étais vous, je regarderais des serveurs non bloquants comme Node.js, juste parce qu'ils sont beaucoup plus adaptés à la conservation de nombreuses connexions ouvertes pendant de longues périodes, ce qui est à quoi les jeux doivent faire, comparé aux serveurs Web traditionnels.
qui étant dit
Il y a 3 choses principales à craindre lorsque vous mettez une application Web; mémoire, vitesse d'exécution et io (HD et réseau) dans cet ordre.
Pour la mémoire, les choses sont bien meilleures que possible. Passager de la Phusion Utilise une copie sur l'écriture à la fourchette Ses ouvriers. L'environnement des rails sera donc partagé parmi tous les travailleurs sur une tranche donnée, ce qui est assez important. Il y a également eu d'énormes améliorations à la façon dont Ruby gère la mémoire par rapport à "The Dark Times", si vous utilisez 1.8.7, vous souhaitez utiliser les patchs qui composent Ruby Enterprise Edition (la différence est comme la nuit et la journée) . 1.9.x était à peu près une réécriture totale de l'exécution, donc si vous utilisez que les problèmes de mémoire rubis ont déjà été abordés.
Pour la vitesse d'exécution, 1.8.7 est généralement "assez rapide" (au moins après avoir réglé les paramètres de collecte des ordures). 1.9.2 est en fait autour de la même vitesse que Python, ce qui le met sur le côté plus rapide des langues interprétées. Dans quelle mesure ce point dépend complètement de la nature de votre application.
Le dernier point est IO, ce qui n'est pas vraiment une préoccupation des rails, mais plus votre stratégie de persistance. Les rubyistes ont tendance à aimer de nouvelles choses, vous trouverez donc un soutien de première classe pour des choses comme Redis et MongoDB, avec des charges de personnes qui parlent de l'utiliser et de leur victoire / gotchas. Je regarderais à Mongo si j'étais vous et je vois si les compromis de la durabilité sont acceptables.
J'étais à Java / .Net avant d'aller aux rails et à la fin de la journée, vous allez payer davantage pour l'infrastructure, mais le montant sera complètement nain par ce que vous économisez dans le temps de développement.
C'est le genre de réponse que je voulais entendre; quelques avis généraux et astuces. Merci un tas! =)
"Passager de la Phusion utilise une copie sur l'écriture à la fourchette de ses ouvriers. L'environnement des rails sera donc partagé parmi tous les travailleurs sur une SLIC donnée". Mais la copie-on-écrite n'est possible qu'avec Ruby Enterprise Edition, pas avec 1.9.2. N'est-ce pas?
Construisez-le dans les rails, l'hôte sur Heroku.com - Job fait. Une échelle presque infinie que vous n'avez pas à vous soucier de la manière dont cela fonctionne (cela fait simplement) et qu'elle héberge de nombreuses applications Facebook très traitées afin que cela puisse la gérer.
Joli. Je ne savais pas à propos de Heroku.
Je savais à propos de Heroku mais je n'ai même jamais pensé à organiser mon application là-bas. Merci pour le conseil.
En tant que nouveau développeur qui n'a pas eu beaucoup d'expérience de l'évolutivité, vous constaterez que vos goulots d'étranglement proviennent de votre propre code: demandes redondantes, chargement de modèles en mémoire lorsque vous n'avez pas besoin de, oubliant add_index, etc. Ce sont des choses Vous apprenez à refacteur lorsque vous acquérez plus d'expérience. Une fois que vous avez beaucoup d'utilisateurs, la base de données IO est le prochain goulot d'étranglement, et c'est une préoccupation, quel que soit le cadre que vous utilisez. Je recommande également Heroku. Externalisez votre échelle afin que vous puissiez passer votre temps au développement. Vous pouvez même réduire l'échelle automatisée: github.com/ddollar/heroku-autoscale
C'est un peu une question impossible à répondre car afin de savoir si les rails conviennent à ce que vous voulez faire, nous aurions beaucoup plus besoin de ce que vous essayez de faire. Le meilleur conseil que je puisse donner en l'absence d'informations est pour vous de consulter le RailsLAb Vidéos de mise à l'échelle afin de le calculer pour vous-même.
Je pense que Ruby On Rails est un bon choix pour ce dont vous avez besoin. En fait, nous avons récemment créé une plate-forme pour un tournoi de jeu en ligne, où les joueurs et leurs robots de jeu jouaient un jeu logique.
Nous avons utilisé Ruby sur les rails et la SIDEKIQ sur le backend, les réactons et les standards sur le frontage. Et cela a bien fonctionné pour un nombre assez massif de joueurs. Voici le tutoriel basé sur ce que nous avons appris tout en la construisant: Comment Pour écrire un moteur de jeu en utilisant Ruby sur Rails
Je pense que vous devriez essayer d'obtenir 7000 personnes de jouer d'abord votre jeu avant de vous inquiéter de l'évolutivité.
Bien sûr elmt. Je pensais que le mot "idéalement" signifierait que j'avais supposé que cela serait un jeu de succès par an ou cinq à partir de maintenant. ;)
@Elmt Je suis d'accord sur "l'inquiétude de l'évolutivité plus tard", mais c'est toujours une question valable.