Discussion autour de l'architecture de l'application

[archANJS]

Edit Sephi-Chan : cette discussion est née de la division de la discussion Créer son propre serveur dédié.


Et bien j'ai pensé à un nouveau concept; du moins nouveau pour moi, d'autres personnes y ont sûrement pensé.. 'fin bref.

La partie "Website" fonctionne comme une application habituelle (MVC, base de données MySQL, etc). Elle contient les différentes briques extérieures du jeu - connexion / inscription, gestion des membres / du profil, blog, forum, wiki, faq, etc - et contient également la couche de présentation (et de navigation) de la brique principale: le jeu en tant que tel.

(Il faut comprendre que l'utilisateur peut être connecté au site, commenter un article, lire le forum et tout et tout, mais sans toutefois n'avoir aucun personnage pour le moment! Dans le même principe, je peux arrêter le jeu ou bien en mettre une nouvelle version sans que tout le reste (communauté et vie du site) soit altéré.)

Le moteur du jeu fonctionne différemment. Son rôle est de :

- envoyer les informations demandées par la brique de navigation du Website;
- calculer le résultat des différentes actions exécutées;
- faire évoluer l'écosystème du jeu;
- etc.

En gros, lorsqu'un personnage veut en attaquer un autre, il clique sur le bouton "Attaquer" dans le Website, ce qui envoie un message à l'application serveur. Celle-ci la reçoit, le moteur l'exécute, et une réponse est renvoyée au Website, qui l'affiche.

D'où mon besoin d'avoir une machine (virtuelle ou dédiée), car le jeu ne s'exécute pas au niveau des scripts, mais bien dans le moteur de jeu ^^

---

Sephi : Si je choisi un dédié (mon choix de départ), quel hébergeur et quel forfait me suggérerais-tu?

---

Merci pour vos réponses

[Maks]

Je comprends pas trop non plus. Ruby ou Node côté serveur ?

[niahoo]

C'est pourtant simple : son serveur va héberger deux applications qui vont tourner en parallèle, d'un côté un site web qui permet de communiquer avec les navigateurs, d'afficher des pages, de renvoyer des données JSON ou autre format, et de recevoir les input des navigateurs, de l'autre côté un moteur de jeu qui va tourner en permanence, gérer l'évolution du jeu, les AI, les PNJ, l'évolution du monde (par exemple la forêt qui pousse), etc.

[archANJS]

Disons que pour l'instant, je ne me suis pas encore décidé; je suis en train de tester le tout, de développer mon idée et de comparer les options.

Mais la question n'est pas là

Quelle forfait devrais-je choisir? Avez-vous des hébergeurs à me recommander?

EDIT : Voilà niahoo, t'as tout compris

[Maks]

Niahoo > Oui j'avais compris l'architecture que archaANJS souhaite mettre en place. Je m'interrogeais sur les technologies à mettre en place, qui me paraissent redondantes.

Pour le site web, Rails & MySQL ok. Mais pour le serveur de jeu, Node ou Ruby ? Redis ou MongoDB ?... Ou les 4 en même temps ?!

[archANJS]

Disons que pour l'instant, je ne me suis pas encore décidé; je suis en train de tester le tout, de développer mon idée et de comparer les options.

Je n'ai pas encore choisi, donc je ne sais pas encore. Je m'informe, je teste, je compare; mais au final ce sera soit Ruby / soit Node, avec soit Redis / soit MongoDB.

[Maks]

Très bien, donc si tu choisis Node et le Cloud, tu peux te faire la main gratuitement avec http://nodester.com/

Par ailleurs tu peux aussi faire ton site avec Node & Express.

[archANJS]

Merci pour l'information, je vais regarder ça

D'ailleurs, je vais faire un retour sur tout ça sous peu, pour ceux que ça intéresserait.

[Maks]

Moi ça m'intéresse ^^

Pour Express, c'est vraiment robuste, mais pas aussi complet que Rails surement

Tout peut graviter autour de Node. Ton site, ton serveur. Node en point central. MySQL grâce à au module node-mysql c'est super simple. Ensuite le jeu Node et Socket.IO pour les Websockets + Redis ou MongoDB. Le site grâce à Express. Tu peux même utiliser JQuery et Backbone dans Node. Et coffeescript pour la touche de Ruby. Performances assurées

(oui ce message est parti pris ^^)

[Sephi-Chan]

Je ne vois pas trop l'intérêt d'inclure Ruby dans l'alchimie, à ce compte. Si on choisit d'opter pour Javascript (via CoffeeScript, pas besoin de Ruby pour ça), autant s'y tenir le plus possible.

Si je devais opter pour une telle architecture, je redonnerais sans doute un coup d'œil à Erlang, même si vois assez mal ce à quoi ressemble du code métier en Erlang.

Pour ce qui est du stockage, tu ne peux pas comparer MongoDB à Redis : leurs usages ne sont pas les mêmes.

Effectivement on risque de dévier de la conversation. Comme elle est intéressante, je séparer la discussion.