Que voilà une question intéressante :D
Quote:
Je cherche à faire un serveur de jeu (un truc galactique genre Elite II - en 2D - mais en multijoueur).
Ah Elite... :) ça me rappelle l'époque de mon Amstrad 6128 et d'Elite I. J'avais réussi à aller au bout... :) Mais bon la nostalgie m'égare. :D
Quote:
- d'un client (javascript dans le browser du joueur)
Ok.
Quote:
- d'un serveur général (apache/PHP)
Pourquoi cela ? Pourquoi pas Erlang tout de suite ? :)
Quote:
- d'un serveur de jeu qui n'interagit qu'avec le serveur général par sockets et qui gère les événements du jeu - y compris la BdD.
Ok. Oh ok... quoique...
Deux serveurs Erlang, c'est bien ça que tu voulais dire n'est-ce pas ? ;)
Quote:
J'étudie en ce moment la possibilité de faire le serveur de jeu en Erlang, car tel que je le conçoit, il est basé sur des notions d'échange de messages.
Et en effet Erlang semble un choix excellent :)
Quote:
Or, débutant dans ce langage, j'ai du mal à voir comment traduire certains concepts de mon architecture - ou comment adapter l'architecture, d'ailleurs.
C'est assez normal. Si Erlang est un langage facile en tant que tel, pour mener un gros projet en Erlang il est impératif de penser en Erlang.
Erlang est un langage fonctionnel concurrent orienté processus.
Java ou Php, par exemple, sont des langages impératifs orienté objets.
Il y a une nette fracture entre ces deux mondes. Et si Erlang est facile, "penser" en Erlang doit s'acquérir. Et ça ce n'est pas nécessairement facile, ça demande même une phase d'apprentissage non négligeable. D'abord en raison de l'environnement qui ne ressemble à aucun autre. Et ensuite parce qu'il faut apprendre à se débarrasser des habitudes de programmation, inconscientes, ancrées dans le geek rompu à la programmation objet que tu es :)
Quote:
- Chaque joueur incarne un personnage.
Ok.
Quote:
- Ce personnage est dans un vaisseau particulier
- Ce vaisseau est d'un type générique mais dérivant de concepts plus élevés (ex: Véhicule->Véhicule Spatial->Cargo), mais avec des ajouts uniques (détecteurs, moteurs, etc...) qui eux aussi sont de type générique, etc...
Je sens pointer ici une habitude de réflexion/conception orientée objet et donc un manque de "pensée Erlang".
Quote:
La question (j'y arrive enfin) est :
Comment au mieux peut-on, en Erlang, gérer cette notion de type générique "dérivé" avec des attributs particuliers ?
En Java je fais des classes abstraites que je dérive sur plusieurs niveaux et mes objets les instancient. Mais en Erlang je sèche un peu
Tout est dit: "En Java". En Java c'est ok. Pas en Erlang.
De même qu'en Erlang les desing pattern, pour puissants qu'ils soient en orienté-objet, sont à oublier.
Je vais dire une chose, mais en fait je ne devrais pas le dire. Il est possible de définir ce qui ressemble à des interfaces "Java" en définissant des behaviour en Erlang. MAIS même si je l'ai dit, il faudrait l'oublier au moins pendant la phase d'apprentissage du langage.
Il faut commencer à apprendre à penser en Erlang. Puis je suggérer que ton projet pour intéressant qu'il soit est ambitieux et qu'il est peut être pertinent de te familiariser plus avec le langage lui même d'abord ?
Pour penser en Erlang, il faut avoir un point fondamental chevillé à l'esprit: ** Erlang est orienté processus **
Java est orienté objet, donc tu penses en objets: classes abstraites, spécialisation, etc. parfait, rien en redire.
En Erlang tu *DOIS* penser processus. Erlang modélise le modèle réel concurrent tel qu'il est. Prend une voiture. En Java la classe Voiture a un moteur et des essuies-glaces.
En Erlang le processus superviseur voiture supervise le processus moteur et le processus essuie-glace. Tous ces processus sont liés entre eux et forment un graphe de processus: la voiture, MAIS moteur et essuie-glace tournent indépendamment. Tu vois la différence d'approche ? Donc ton vaisseau tu dois le penser comme un graphe de processus. Tu as cargo avec simplement un processus moteur ? Tu veux en faire un vaisseau de combat ? Alors tu crées un processus canon laser, qui s'intègre dans le graphe de processus du vaisseau.
En Erlang *TOUT* est processus. Par exemple quand tu lis un fichier, qu'est-ce que ce fichier dans le système Erlang, ce n'est pas une instance de classe, ce n'est pas un descripteur, c'est un processus :)
Donc avant tout il faut te familiariser avec cette idée, et avant tout penser en termes de processus. Avant même en fait penser à définir des behaviours. Si ça se trouve, on peut implémenter ton jeu sans définir la moindre behaviour personnelle. Je n'en serais pas surpris :)
Pour conclure, probablement, il n'est pas pertinent d'adapter ton architecture, mais de la repenser.
Imagine le monde de ton jeu comme un monde réel, donc totalement concurrent, et pense ton architecture en fonction de ça, parce qu'Erlang est fait pour ça, et c'est en l'approchant comme ça que tu vas profiter de sa puissance et de son expressivité. Sinon, la programmation Erlang ne sera qu'une suite de contorsions douloureuses.
Que voilà une question intéressante :D
Ah Elite... :) ça me rappelle l'époque de mon Amstrad 6128 et d'Elite I. J'avais réussi à aller au bout... :) Mais bon la nostalgie m'égare. :D
Ok.
Pourquoi cela ? Pourquoi pas Erlang tout de suite ? :)
Ok. Oh ok... quoique...
Deux serveurs Erlang, c'est bien ça que tu voulais dire n'est-ce pas ? ;)
Et en effet Erlang semble un choix excellent :)
C'est assez normal. Si Erlang est un langage facile en tant que tel, pour mener un gros projet en Erlang il est impératif de penser en Erlang.
Erlang est un langage fonctionnel concurrent orienté processus.
Java ou Php, par exemple, sont des langages impératifs orienté objets.
Il y a une nette fracture entre ces deux mondes. Et si Erlang est facile, "penser" en Erlang doit s'acquérir. Et ça ce n'est pas nécessairement facile, ça demande même une phase d'apprentissage non négligeable. D'abord en raison de l'environnement qui ne ressemble à aucun autre. Et ensuite parce qu'il faut apprendre à se débarrasser des habitudes de programmation, inconscientes, ancrées dans le geek rompu à la programmation objet que tu es :)
Ok.
Je sens pointer ici une habitude de réflexion/conception orientée objet et donc un manque de "pensée Erlang".
Tout est dit: "En Java". En Java c'est ok. Pas en Erlang.
De même qu'en Erlang les desing pattern, pour puissants qu'ils soient en orienté-objet, sont à oublier.
Je vais dire une chose, mais en fait je ne devrais pas le dire. Il est possible de définir ce qui ressemble à des interfaces "Java" en définissant des behaviour en Erlang. MAIS même si je l'ai dit, il faudrait l'oublier au moins pendant la phase d'apprentissage du langage.
Il faut commencer à apprendre à penser en Erlang. Puis je suggérer que ton projet pour intéressant qu'il soit est ambitieux et qu'il est peut être pertinent de te familiariser plus avec le langage lui même d'abord ?
Pour penser en Erlang, il faut avoir un point fondamental chevillé à l'esprit: ** Erlang est orienté processus **
Java est orienté objet, donc tu penses en objets: classes abstraites, spécialisation, etc. parfait, rien en redire.
En Erlang tu *DOIS* penser processus. Erlang modélise le modèle réel concurrent tel qu'il est. Prend une voiture. En Java la classe Voiture a un moteur et des essuies-glaces.
En Erlang le processus superviseur voiture supervise le processus moteur et le processus essuie-glace. Tous ces processus sont liés entre eux et forment un graphe de processus: la voiture, MAIS moteur et essuie-glace tournent indépendamment. Tu vois la différence d'approche ? Donc ton vaisseau tu dois le penser comme un graphe de processus. Tu as cargo avec simplement un processus moteur ? Tu veux en faire un vaisseau de combat ? Alors tu crées un processus canon laser, qui s'intègre dans le graphe de processus du vaisseau.
En Erlang *TOUT* est processus. Par exemple quand tu lis un fichier, qu'est-ce que ce fichier dans le système Erlang, ce n'est pas une instance de classe, ce n'est pas un descripteur, c'est un processus :)
Donc avant tout il faut te familiariser avec cette idée, et avant tout penser en termes de processus. Avant même en fait penser à définir des behaviours. Si ça se trouve, on peut implémenter ton jeu sans définir la moindre behaviour personnelle. Je n'en serais pas surpris :)
Pour conclure, probablement, il n'est pas pertinent d'adapter ton architecture, mais de la repenser.
Imagine le monde de ton jeu comme un monde réel, donc totalement concurrent, et pense ton architecture en fonction de ça, parce qu'Erlang est fait pour ça, et c'est en l'approchant comme ça que tu vas profiter de sa puissance et de son expressivité. Sinon, la programmation Erlang ne sera qu'une suite de contorsions douloureuses.