Citation :Que fait-on généralement pour communiquer avec un serveur Web (qui sert juste de point d'accès) si on développe un serveur de jeu (qui s'occupe de l'état du jeu et des joueurs) ?
On utilise un serveur web en erlang (yaws, mochiweb, cowboy, …) ou un framework web qui intègre ce serveur, on démarre ça et le serveur de jeu sur le même node comme ça il n'y a plus qu'a appeller le serveur de jeu dans tes controlleurs.
Pour l'instant je bosse que sur mon serveur de jeu, et lentement, donc j'ai pas testé, mais disons que tu ferais dans tes controlleurs la même chose que tu fais dans ton shell pour tester ton serveur.
Pour communiquer avec ton serveur de jeu depuis un controlleur Rails, tu peux faire du TCP/IP ou bien du JSON/HTTP si t'es un flemmard. Ou bien tu peux simuler un node erlang avec Ruby je crois qu'il y a des bibliothèques pour ça.
Citation :Comment penses-tu le code métier (systèmes de quêtes, occupation des territoires, etc.) ?
Heu … ben je sais pas trop, mais tout ça c'est de la base de données. Quand tu parles à un PNJ, tu check en base les quêtes qu'il propose et celles que tu n'as pas déjà fait, et voilà.
Quand tu prends une quête tu l'indiques dans la base de données, etc… sur ce point y a pas trop de changement, si ce n'est que la base de données peut servir simplement de backup alors que tu gardes ces infos en RAM pour les persos connectés.
Citation :Comment utilises-tu (ou non) les processus. Imagine Risk en Erlang, est-ce que c'est raisonnable de créer un processus par joueur, un processus par partie, un processus par territoire, etc.
Bon ben déjà j'utilise le framework OTP, j'intègre tous mes processus dans un arbre de supervision, ce qui permet de récupérer mes morceaux en cas de crash.
Je t'avais dit que je fesais toujours du TDD mais j'ai un peu menti, avec erlang j'ai eu la flemme de ce côté là jusqu'à maitenant, je m'y remet peu à peu sur du code de test (sans OTP)
Enfin, il y a des frameworks pour les tests unitaires …
Un processus par joueur pour garder son State depuis le serveur ça me paraît pas mal. Ça te permet de créer un objet (au sens primaire) pour encapsuler ce State et gérer les interactions du joueur avec l'extérieur.
Le plus chiant étant d'éviter les deadlock quand tu vas demander à ton process de discuter avec d'autres process.
Par partie également, puisque tu vas garder dans ta partie la liste des joueurs, des infos les concernant comme leur score, la liste des territoires, par qui ils sont occupés et par quoi. (Et donc pas de process par territoire).
Ce n'est pas de la programamtion orientée objet, au début on a tendance à penser objet et à faire des process pour tout et pour rien. Mais les process sont faits pour modéliser ce qui est concurrent.
Comme tu as plusieurs joueurs connectés, plusieurs parties en même temps, c'est logique d'utiliser un process, mais pour les territoires, c'est une simple table, donc autant utiliser une liste de tuples
en anglais on dit territory ?
Code :
Territoires = [Territoire]
Territoire = {territory, AreaID, Owner, Troups}
AreaID = int()
Owner = PlayerID
Troups = [Troup]
PlayerID = int()
Troup = {troup, TroupTypeID, Amount}
TroupTypeID = int()
Amount = int()Je te conseilles de regarder les records (et si tu surmontes la syntaxe tu es bon pour erlang), car taper des tuples c'est un peu chiant.
Tu ne stockes pas le PID du player à la places de son id car si son process crash, quand le superviseur le relancera il aura changé de pid. Il te faut donc un système qui relie les id aux pid et qui soit tenu à jour
edit concernant le serveur, j'ai quand même déjà fait une appli erlang qui est standalone et je l'ai couplée à une interface web sur un framework Erlang et ça fonctionne bien. En fait c'est transparent.