Discussion :

[nouknouk]

Projet interressant.

Tout d'abord, merci pour ta contribution et les encouragements

construire correctement sa sandbox pour que la couverture des fonctionnalités soit bien définies n'est pas trés simple. On a vite fais d'oublier un petit trou laissant la main mise sur toute l'application.

J'ai effectivement déjà eu une première réflexion pour l'aspect 'sécurité'.

Après quelques recherches, j'ai lu une partie de ce post qui parle justement de la possibilité de n'autoriser l'accès qu'à certains packages & certaines classes Java (cf. ClassShutter).

Après, je ne sais pas si -in fine- le ClassShutter ainsi qu'ne exécution du serveur avec des droits limités (genre un nobody/nobody sous linux) seront suffisants.
Il y a également le problème de répartition des ressources: Il me faudra pouvoir détecter et interrompre en runtime un script qui prendrait trop de ressources (charge processeur, mémoire). En effet, sans gestion des ressources, il suffirait d'un petit malin qui pond un script 'pourri' pour faire tomber un serveur complet, hébergeant plusieurs mondes.

Si vous avez de l'info là-dessus, n'hésitez pas à partager

LUA est très apprécié [...]il s'agit apparemment d'un très bon langage de script.

J'entends également beaucoup parler de LUA.

Effectivement, c'est un candidat sérieux. Il n'a pas ma préférence pour le moment pour une raison totalement personnelle: je ne connais pas sa syntaxe, et j'ai pas envie de prendre le temps de l'apprendre.

Ceci dit, j'ai l'impression que mon choix se fera surtout en fonction des performances de chacun d'entre eux: le nerf de la guerre dans ce projet reste tout de même la charge serveur, et à priori 90% de la charge sera causée par l'exécution des scripts.

Il me semble donc primordial à ce stade de trouver de bons articles pour comparer les performances de chaque moteur de script pour voir où je vais.
Donc si vous avez des liens vers des bons articles, n'hésitez pas

Ne pas implémenter une version UDP est une bonne chose également.
Mettre en place un protcole UDP "semi-fiable" est un vrai calvère [...]

C'est exactement mon idée: la charge de travail que ça induit est généralement largement sous-estimée par les développeurs.

Le mieux que vous puissiez faire est de construire la couche réseau de façon à être inter-changeable tout en implémentant qu'une version qui sera TCP.

Je pense que ce sera globalement le cas: si tu te réfères à mes schéma d'architecture générale du moteur réseau (second post du topic), l'API réseau ne sera vue que que par les action plugins et les events plugins. Ajouter des plugins supplémentaires pour l'UDP ne sera pas bien dur.

Ceci dit, ce n'est vraiment pas l'orientation que je souhaite donner à ce projet. Pour moi son fondement est l'aspect 'smart user experience':

1- "je construis un monde en ligne en dessinant un terrain, en posant deux objets et en codant trois scripts"

2- "je distribue l'URL de ce monde"

3- "les visiteurs n'ont qu'à copier l'URL dans leur navigateur et ça démarre tout seul, tout de suite sans rien à installer ou configurer".

Mon choix de ne pas utiliser d'UDP est surtout pour respecter le paradigme ci-dessus, plus encore que pour des raisons de charge de travail (même si ça va dans le même sens).

Après ... il ne faut jamais dire jamais ...

[Idrakis]

Salut,
je trouve ton projet très interessant.

D'après moi, ce qui t'offrira les meilleurs performances serait d'utiliser du java comme langage de script, et de le compiler à la volée ( c'est ce que font les autres langages de script, sauf qu'en plus ils doivent interpreter le code juste avant ).

Pour la sécurité, il suffira de ne pas importer les namespaces "critiques". Pour ceux qui contiennent des classes nécessaires à l'user, mais pouvant avoir un comportement critique, il sufit que tu encapsule ces classes ( de manière transparente pour l'user ) et que tu modifie leur comportement là ou ça t'arrange pour éviter que l'user des scripts ne puisse avoir accès à des comportements "critiques".

L'avantage pour l'utilisateur est qu'il pourra coder ses scripts dans un IDE performant, avec des possibilités puissantes ( grace au langage objet ), de plus, le gain de performance profitera non seulement à la charge du serveur,mais aussi aux utilisateurs qui pourront se permettre des scripts plus poussés.

Personelement, rien ne m'a plus énervé de ne pas avoir la notion objet dans LUA ( on peut se débrouiller pour avoir une sorte de ressemblance, mais c'est vraiment crade ), ou de ne pas pouvoir créer ses propres types et de ne pas pouvoir fortement typer ses variables. Ou alors de ne pas avoir d'IDE digne de ce nom. De plus, le débugage des langages de scripts est très souvant monstrueusement chiatique.

Le seul désavantage est que ça limitera l'utilisation des scripts à des développeurs, mais rien ne t'empeches d'implémenter 2 langages de scripts différent, les débutants pourront importer leur script LUA par exemple, et le public un peu plus averti en programmation, qui aspirera a des fonctionalités plus élaborés et à un meilleur confort de programmation sera ravi de pouvoir coder en java

Bonne continuation

[nouknouk]

Salut,
je trouve ton projet très interessant.

merci

Pour ce qui concerne le contenu des scripts en eux-même, ton post m'a fait me rendre compte que j'ai été trop flou sur leur contenu. En fait, l'objectif n'est pas d'avoir des scripts complexes, mais juste la possibilité de programmer quelques comportements triviaux.

Ainsi, les scripts n'auront pas pour vocation de programmer une IA trop évoluée pour un PNJ, mais plutôt des réponses -certes scriptées- mais simples à une liste d'événements fixés.

Dans ce sens, un script ne devrait logiquement faire que quelques lignes de code. Par exemple, pour un événement 'joueur x se prend un coup', on aurait quelque chose du genre (côté serveur):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
onPlayerInjured(injuredPlayerId, attackingPlayerId) {
    var playerObject = getObjectWithID(injuredPlayerId);
    var health = playerObject.getProperty("health");
    playerObject.setProperty("health", health-10);
 
    if (playerObject.getProperty("health") < 0) {
        teleportPlayerToMap(injuredPlayerId, "deathMap");
    }

Ici, onPlayerInjured est un des événements proposé par un des EventPlugin, on peut penser ici à un plugin qui gère les combats entre joueurs.

C'est l'appel à la fonction setProperty() proposée par un ActionPlugin qui va entraîner:
- une modification de la valeur de la propriété 'health' côté serveur
- un check de la visibilité de cette propriété. Admettons ici que 'health' soit une propriété 'publique'. Une notification va être automatiquement envoyée à tous les autres joueurs aux alentours.

Côté client, le créateur de monde aura défini un 'GUI' script qui été lié à l'événement 'la propieté health a changé':

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
onHealthPropertyChanged(objectId, oldValue, newValue) {
    var player = getObjectWithId(objectId);
 
    if( newValue < oldValue ) {
        player.addAnimatedAlphaColorOverlay(player, 0xFF0000, 1000); 
    } else {
        player.addAnimatedAlphaColorOverlay(player, 0x00FF00, 1000); 
    }
}

Ici, on va admettre que addAnimatedColorOverlay() est une des fonctions mise à disposition par un ActionPlugin pour faire clignoter un objet avec une couleur donnée pour un temps donné. Là, le joueur clignotera en rouge lorsqu'il perdra de la vie ; en vert quand il en gagnera.

Voilà pour l'idée générale.

D'après moi, ce qui t'offrira les meilleurs performances serait d'utiliser du java comme langage de script, et de le compiler à la volée ( c'est ce que font les autres langages de script, sauf qu'en plus ils doivent interpreter le code juste avant ).

Effectivement, le plus rapide sera Java. Mais le gain comparé à un langage de script capable de se compiler en bytecode (un fois pour toutes, au chargement) sera - j'imagine - relativement faible.

Par contre, ça restreindrait d'un coup les 'créateurs de monde' potentiels à ceux qui connaissent Java. Cela va un peu en contradiction avec mon objectif initial.

rien ne t'empêche d'implémenter 2 langages de scripts différent

Effectivement, laisser le choix du langage permettrait de gagner en souplesse. Mais je vois deux inconvénients majeurs:

- pour des raisons techniques d'interopérabilité entre scripts, on ne pourra pas se permettre d'avoir plusieurs langages de scripts en même temps pour un même monde. Cela imposera donc au 'créateur de monde' de choisir son langage dès le départ et de s'y restreindre ensuite. Plus exactement, avoir plusieurs langages en parallèle, c'est techniquement faisable mais ça augmentera la complexité du framework, chose à laquelle je ne tiens pas dans un premier temps.

- Si le projet "marche un minimum" et arrive à fédérer une communauté de 'créateurs de monde', l'intérêt principal de la communauté sera justement de pouvoir s'échanger des scripts et des ressources. La communauté autour du logiciel RPG-maker est un exemple typique.
Laisser plusieurs langages de scripts cohabiter amènera la complexité et ne favorisera pas ce genre d'échange

- Pour le côté client, cela imposera à l'application cliente d'embarquer non pas un moteur de script, mais trois, augmentant d'autant la taille du premier téléchargement et donc le temps d'attente.

L'avantage pour l'utilisateur est qu'il pourra coder ses scripts dans un IDE performant[...]Personelement, rien ne m'a plus énervé de ne pas avoir la notion objet dans LUA ( on peut se débrouiller pour avoir une sorte de ressemblance, mais c'est vraiment crade ) ou de ne pas pouvoir créer ses propres types et de ne pas pouvoir fortement typer ses variables.

Comme présenté précédemment, le langage de script n'a pas vocation à faire des choses complexes, donc:

- un IDE complet et un deboggueur avancé me paraissent superflu. Un simple 'syntax checker' capable d'opérer en direct pendant l'écriture des scripts me paraît largement suffisant.

- en aucun cas, l'écriture des scripts doit impliquer de définir des nouveaux types (classes), etc. Non seulement ça dépasserait le seuil de complexité que je recherche, mais surtout ce serait juste une horreur à gérer par mon framework. Un exemple tout bête: une fois qu'une classe est créée, il faudrait être capable de la sérialiser pour la transmettre sur le réseau ; c'est le genre de compétence qu'on ne pourra pas demander à un 'programmeur en herbe'

En conclusion, pour essayer de mieux faire comprendre le but du langage de script et ma volonté de garder une approche simple, j'ajouterai que je voudrais me rapprocher de ce que propose un logiciel comme RPG-Maker qui est destiné avant tout a des non-programmeurs, et pas d'une nième solution (plus ou moins avancée et intégrée) destinée à des développeurs.

[Idrakis]

Donc si j'ai bien compris, il y aura une liste d'évenements pré-definis par ton moteur, et la programmabilité du monde se fera en scriptant un comportement à adopter au déclenchement de ces évenements.
En effet, pas besoin ici de quelque chose de très élaboré.
Je pense que n'importe quel langage de script ferait l'affaire sur le plan technique.

Cependant, je te conseillerais le ruby. Car c'est un langage bien connus des scripteurs de RPG maker, tu pourrais ainsi récupérer une partie de ce publique ( lassé de RPGM ou alors attiré par les possibilités online que n'offrait pas le logiciel ), en leur proposant un univers de création différent de ce à quoi ils ont l'habitude ( tout en restant dans le domaine du rpg rapidement et facilement personalisable ) sans pour autant avoir à apprendre un nouveau langage.

En effet je pense que le choix doit plutôt se faire en fonction des communautés déja présentes plutot que réellement sur les détails techniques.

[nouknouk]

Donc si j'ai bien compris, il y aura une liste d'évenements pré-definis par ton moteur, et la programmabilité du monde se fera en scriptant un comportement à adopter au déclenchement de ces évenements.

C'est exactement ça

A noter que le framework aura tout de même une architecture volontairement modulaire permettant d'étendre les possibilités au moyen de plugins écrits en Java (les fameux Event et Action plugins de mes schémas).

Mais en aucune façon un "créateur de monde" ne pourra lui-même ajouter ses propres plugins (au moins pour le moment). Ce sera uniquement l'administrateur du serveur qui pourra le faire.

Cependant, je te conseillerais le ruby. Car c'est un langage bien connus des scripteurs de RPG maker, tu pourrais ainsi récupérer une partie de ce public

Tu as raison, c'est un excellent argument en faveur de Ruby.

Son principal défaut semble être la lourdeur du jar du moteur (4,2Mo).
A voir si on peut espérer le réduire.

Quoiqu'il en soit, je vais ajouter JRuby dans ma liste de langages potentiels.

Je pense que le choix doit plutôt se faire en fonction des communautés déjà présentes plutôt que réellement sur les détails techniques. [...]En effet, pas besoin ici de quelque chose de très élaboré.
Je pense que n'importe quel langage de script ferait l'affaire sur le plan technique.

On est d'accord pour l'aspect 'communauté', ceci dit plus j'utiliserai un langage performant, plus un serveur pourra monter en charge et supporter un grand nombre de visiteurs et de 'mondes'. Ca reste donc quelque chose d'assez critique pour que je veuille amasser un maximum d'infos là-dessus avant de me décider.

Ce serait à relativiser si -question performances- tous les langages se tenaient (à 10% près). Mais plus je fais de recherches, plus que j'ai vraiment l'impression que d'un langage à un autre (voir même d'un moteur à un autre), il peut y avoir des différences réellement énormes en termes de performances.

[nouknouk]

Salut,

J'ai relu à tête reposée ce que j'avais écrit à propos des scripts et le petit exemple composé de deux scripts:
- le script côté serveur qui s'occupe de changer la valeur de la propriété "health"
- le script côté client qui s'occupe d'ajouter une petite animation de 1000ms lorsque la propriété "health" a changé.

Dans ce cadre de cet exemple là, l'approche peut très bien marcher, mais elle n'est pas vraiment en phase avec ma séparation initiale des reponsabilités:

En effet, initialement les scripts côté client ne sont censés être utilisés que pour gérer les entrées du joueur (souris, touches, boites de dialogue, curseur en 3D, ...).
Ils ne devraient rien avoir à faire avec quelque chose qui est commun à plusieurs joueurs (et l'animation du script client l'est).

La bonne approche serait donc d'avoir un seul script, celui côté serveur, contenant l'appel à la fonction 'addAnimatedAlphaColorOverlay'.
Le serveur, évidemment, ne va pas jouer l'animation de son côté, mais ce sera son rôle de notifier les clients concernés qu'ils doivent lancer cette animation (exactement le même fonctionnement que le changement de la valeur de 'health' explicité ci-dessus).

Deux avantages majeurs:

- déjà ça n'oblige plus à demander au concepteur de scripts de séparer le code en deux parties, une pour le client, l'autre pour le serveur.

- mais surtout, le serveur gardera la trace de cette animation. Ainsi, si un autre joueur se connecte 50ms après que cette animation ait été initiée, le serveur pourra lui dire au chargement de la carte 'il y a une animation en cours de 1000ms de long, elle a commencé il y a 50ms'. La cohérence du monde entre les joueurs est ainsi maintenue: tout le monde voit la même chose au même moment.
Dans notre cas précis, si le client qui vient se connecter 'perdait' cette animation, ce ne serait pas un drame, mais il est très aisé de trouver des autres cas de figure (animation plus longue, plus importante, déplaçant un objet de façon définitive, ...)

Voilà.

[nouknouk]

Autre chose: je viens de recevoir un ticket pour l'inscription dans la beta privée de Metaplace.
C'est très intéressant pour moi car la plateforme se rapproche vraiment pas mal de mon projet, hormis qu'ils ont une approche en 2D isométrique et un client en Flash (qui rame!).

J'ai déjà pu prendre deux minutes pour jeter un oeil à leur wiki, et surtout conernant la partie 'conception de scripts' et autre comportements personnalisés.
C'est très intéressant car ça me permet de comprendre dans les grandes lignes l'approche qu'ils ont eu pour le design de leur plateforme.

... et puis ça fait toujours un peu plaisir de voir qu'au final mon approche est plutôt proche de la leur:
- utilisation de la notion d'événements (Trigger) et de scripts qui y sont reliés
- notion de plugin de fonctionnalités pour étendre l'API
- éditeur de script en ligne
- etc...

Ca m'encourage en tout cas à continuer dans cette voie là.

Ils ont également une notion de 'classe d'objets' et d'héritage (ils appellent ça un template). Un template est basiquement un objet qui contient une liste de propriétés, et de scripts donnant différentes capacités à l'objet.

Si mon projet vous intéresse, le leur devrait vous titiller également. N'hésitez pas à vous inscrire sur le site ; personellement j'ai dû recevoir mon accès environ deux semaines après l'avoir demandé.

Je verrai par ailleurs si l'EULA pour la béta privée me permet de poster quelques screenshots ici-même.

[dstar]

Salut nouknouk,

Je me disais comme ça, en passant: comment vas-tu gérer l'IA des ennemis et des PNJ ? Va-t-il y avoir une IA qui sera paramétrable ? Ou sera-t-il possible aux concepteurs d'intégrer leur propre IA ? Ca sera fait sur la partie cliente ou serveur ?

dstar

[nouknouk]

Je me disais comme ça, en passant: comment vas-tu gérer l'IA des ennemis et des PNJ ? Va-t-il y avoir une IA qui sera paramétrable ? Ou sera-t-il possible aux concepteurs d'intégrer leur propre IA ? Ca sera fait sur la partie cliente ou serveur ?

Salut dstar,

pour l'aspect client/serveur, le paradigme "never trust the client side" impose de tout mettre côté serveur. Il serait bien trop facile sinon de tricher.

Pour l'aspect technique, il me semble qu'à partir du moment où ce sera un tant soit peu évolué, une programmation en langage de script de l'ensemble de l'IA aura beaucoup de mal à monter en charge. On a donc pas trop le choix, il faut que les parties les plus consommatrices en ressources soient programmées en code 'natif', ici en java.

Or, dans le périmètre de mon projet, le code Java est quelque chose qui ne sera pas modifiable par le 'créateur de monde', d'où la seule solution qui reste possible:


Au niveau 'fonctionnel':

1- les parties critiques en termes de performances devront être entièrement écrites en Java et mises à la disposition des 'créateurs de monde' via les fameux Event et Action plugins. On peut globalement distinguer deux types de besoins:
* d'un côté les fonctionnalités pour analyser la situation (ex: qu'est ce que le PNJ a dans son champ de vision ; ...)
* de l'autre côté les fonctionnalités pour mettre en oeuvre une décision découlant de l'analyse (fuir, combattre, chercher à se regrouper, ...)

2- le but étant d'avoir quelque chose le plus générique possible, il faut que l'articulation entre la collecte des résultats de l'analyse et les décisions qui en découlent soit paramétrable ... donc scriptable.


Au niveau technique:

Une collection d'outils pour l'analyse, plutôt situés du côté des 'event plugins' dans mon schéma d'architecture globale. Ces outils généreront des événements (genre "player x entre dans le champ de vision de y") et/ou permettront de récupérer des données (genre "ratio force joueur x / pnj y").

Les scripts du créateur de monde s'appuieront donc sur les événements & données fournies pour déclencher des actions (fuir, combattre, etc...).

Techniquement parlant, on aura des scripts qui pourront être lancés par des événements et composés d'appels de fonctions appartenant à l'API d'action plugins.

[dstar]

Donc en fait, si je résume, tu offres des outils de base pour évaluer la situation du point de vu d'un PNJ ou d'un ennemi, et tu laisses à la charge du créateur de monde le codage de la prise de décision. Ca me semble être aussi la bonne approche.

Par contre, il me semble que tu oublies (ou que tu n'as pas précisé) un certain type d'outils: la mise en oeuvre des actions des PNJ ou ennemis. Ceux-ci doivent pouvoir se déplacer via path finding: déplacement en ligne droite, A* et D* (à prononcer comme mon pseudo ), éloignement, chemins prédéfinis, vérifier si ils sont capables d'atteindre un adversaire en utilisant une certaine attaque. Il faut également prévoir de pouvoir entrer les règles de combat... bref, je pense que ce n'est pas aussi simple que ça en a l'air.

Je pense que ça serait sympa si tu pouvais mettre un schéma d'architecture de ton système en ligne.

dstar

[nouknouk]

Donc en fait, si je résume, tu offres des outils de base pour évaluer la situation du point de vu d'un PNJ ou d'un ennemi, et tu laisses à la charge du créateur de monde le codage de la prise de décision.

Exactement, tu l'as dit mieux et plus vite que moi

Par contre, il me semble que tu oublies (ou que tu n'as pas précisé) un certain type d'outils: la mise en oeuvre des actions des PNJ ou ennemis. [...] bref, je pense que ce n'est pas aussi simple que ça en a l'air.

Question pathfinding, j'ai déjà un algo A* qui marche pas trop mal (cf. IsoChat). Pour le reste, effectivement, pour avoir tous les outils nécessaire pour faire un RPG like il y a pas mal de choses à coder.

Mais il faut séparer deux grands concepts dans l'architecture:

1- d'un côté le 'noyau' qui correpond grosso modo à la gestion des ressources (cartes, objets, textures, ...) + le réseau (sockets, protocole de comm, ...) + la persistance + la notion générique d'événements, d'actions et de scripts + le système de gestion de plugins.

2- de l'autre les fonctionnalités plus ou moins spécialisées pour un type de jeu. Typiquement des événements et des actions spécialisées (genre pathfinding, IA de PNJ, système de gestion de dialogues, de combats, ...). L'approche se veut entièrement modulaire (notion de plugins)

Le point (1) est celui sur lequel je me concentre actuellement. Typiquement, je suis en train de réfléchir aux notions d'événements et d'actions

Une fois que j'aurai une première version fonctionnelle du 'noyau', on pourra se concentrer sur les fonctionnalités supplémentaires (2).

Je pense que ça serait sympa si tu pouvais mettre un schéma d'architecture de ton système en ligne.

L'architecture est dispo sur le second post de ce thread. Tout n'y est pas en détail, mais ça donne déjà une bonne idée.

[blueman1]

j'ai lu en diagonale l'ensemble des posts. Ton projet est impressionnant, tant pas la qualité technique que par son existence.

Gasp! interpreter du javascript pour redistribuer la dans une applet java...



Ton projet a l'air tout a fait énorme. Tenir deja la comparaison avec metaplace et vraiment ambitieux. J'ai quand même du mal a appréhender l'ensemble des aspects de ton framework. En premier lieu, le choix de l'applet me parait discutable, car il t'oblige a réécrire toi meme la partie gestion du réseau.

Et tout ca pour une connexion max de 100 joueurs...

Ensuite interpeter toi meme des scripts fournis par l'utilisateur... je suis tout a fait curieux de voir comment on peut réaliser ca en java.

Coller tout ça a un moteur "réelle" 3D, ca devient de la folie furieuse.

Bref, bravo, et courage, ton projet vole très haut !

[nouknouk]

salut,

j'ai lu en diagonale l'ensemble des posts. Ton projet est impressionnant, tant pas la qualité technique que par son existence.

Merci

Gasp! interpreter du javascript pour redistribuer la dans une applet java...[...]Ensuite interpeter toi meme des scripts fournis par l'utilisateur... je suis tout a fait curieux de voir comment on peut réaliser ca en java.

Techniquement, l'intégration de javascript dans une application Java est loin d'être compliquée : la notion de moteur de script et une implémentation d'un moteur javascript sont déjà dans le framework de 'base' de Java (1.6 et plus) grâce à la JSR-223.

Au final, il suffit de trois lignes de code pour exécuter un script en Java, genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine engine = mgr.getEngineByName("JavaScript");
engine.eval("print('Hello, world!')");

Le 'binding' entre les objets java et javascript est également parfaitement transparent. Par exemple, utiliser la méthode 'myFunction(int i)' d'une classe Java se fait simplement en écrivant en javascript 'myObject.myFunction(123);'
Donc rien de bien compliqué de ce côté là.

Ton projet a l'air tout a fait énorme. Tenir déjà la comparaison avec metaplace et vraiment ambitieux. J'ai quand même du mal a appréhender l'ensemble des aspects de ton framework.

Effectivement, il y a pas mal de choses à faire. Ceci dit, je n'ambitionne pas non plus d'avoir quelque chose d'aussi abouti que metaplace, encore moins en quelques mois ! Il serait totalement utopiste d'imaginer que je pourrais à moi tout seul (et à temps plus que partiel) concurrencer le produit d'une boite d'une dizaine de personnes.
L'exemple de metaplace que j'ai donné ici à plusieurs reprises était surtout pour positionner le projet:
- je ne veux pas faire un jeu en particulier, mais un 'outil auteur'
- je ne veux pas faire une librairie, mais plutôt une solution 'tout intégrée' à la fois pour le joueur comme pour le créateur de monde.
- je ne veux pas me diriger vers un "RPGMaker-like", mais plutôt vers quelque chose de plus générique et où l'aspect "on line" est présentdès le départ.

En premier lieu, le choix de l'applet me parait discutable, car il t'oblige a réécrire toi meme la partie gestion du réseau.

Deux choses ici:
- concernant la notion d'applet, ça reste encore à définir. Même si coder tout sous forme d'applet est finalement exactement la même chose que coder une application 'classique' java, l'applet pose pas mal de restrictions. Une applet est en effet exécutée dans une 'sandbox' limitant les possibilités (politiques sécuritaires, mémoire vive utilisable, ...).
Donc au final, on verra bien si l'intégration dans une applet est toujours envisageable une fois que j'aurai pondu une première alpha du framework (j'ai notamment peur pour l'utilisation de la mémoire vive). Si ce n'est finalement pas possible, je me rabattrai vers du Java Web Start plus classique.

- concernant la partie réseau: il n'y a rien de spécifique aux applets étant donné qu'on peut utiliser de bonnes vieilles sockets TCP comme dans n'importe quel programme Java. Pour la brique réseau, la majeure partie est déjà implémentée et fonctionnelle: je l'utilise déjà dans mon projet isoChat.

Coller tout ça a un moteur "réelle" 3D, ca devient de la folie furieuse.

Pas tant que ça: en utilisant une API 3D de 'haut niveau' (très certainement JMonkeyEngine), ça simplifie énormément le problème: avec JMonkeyEngine, quelques dizaines de lignes de code suffisent pour afficher un terrain genre ça:



Mais le 'gros du boulot' ne se situe pas vraiment dans l'aspect 3D. L'affichage n'est finalement que la partie émergée de l'iceberg qui s'occupe simplement de la 'vue' (au sens MVC) guidée par un amas de données partagées entre les clients et qui évoluent au fil du temps. Après, que la 'vue' ce soit -in fine- de la 3D, de la 2D, de la 2D isométrique, etc... ce n'est qu'un "détail" (avec des gros guillemets)

La plus grosse partie consiste surtout à définir une architecture générique et efficace pour le 'moteur d'interactions' (cf. les schémas du deuxième post du topic). Donc le 'modèle' et le 'controlleur' du triptyque MVC. Par exemple, je cherche actuellement à poser les bases pour le modèle de données, avec des questions comme:

- Qu'est-ce qu'une entité (objet, caméra, lumière, ressource, ...) ? Quelles fonctionnalités de base doit-elle avoir ? Doit elle stocker une collection de propriétés ? Quels types de propriétés ? Comment les transmettre efficacement sur le réseau ?

- Qu'est ce qu'une propriété ? Comment agir dessus depuis le code Java, depuis les scripts ? Comment transmettre ses changements sur le réseau ? Comment faire qu'elle soit facilement manipulable en Javascript ? ...

- Comment implémenter des 'templates' d'entités (par exemple un objet 3D doit avoir des propriétés génériques: position, orientation, taille, ...) ? Comment avoir des entités qui dérivent d'un ou plusieurs templates (un PNJ est un objet 3D, animé, capable de se déplacer sur terre, qui a une IA associée, une capacité de dialoguer, ...) ? Comment faire pour que des templates personnalisés puissent être conçus par le 'créateur de monde' (par exemple il voudra définir un template 'Magicien', ayant une propriété 'Mana' pour son RPG) ?

- Qu'est ce qu'une action ou un événement (requête d'un joueur, timer) ? Comment connecter dynamiquement des événements à des actions, qu'ils soient en java ou Javascript ?

- etc...

En résumé, effectivement si je devais tout coder 'from scratch', ça représenterait une somme de travail bien trop énorme pour une seule personne.
Mais grâce à l'utilisation de nombreuses briques logicielles à ma disposition (framework réseau déjà développé, JMonkeyEngine, JSR-223, ...), ça devient à nouveau raisonnable car mon boulot se concentre quasi exclusivement à l'élaboration du "moteur d'interactions" ; le reste n'étant grosso modo que de la réutilisation de briques logicielles déjà existantes.

Merci au passage aux nombreux projets sous licence libres (genre (L)GPL) qui rendent tout ça possible pour mon projet, comme pour tellement d'autres

[Elendhil]

Interressant ton projet .

Pour ce qui est d'une applet ce n'est pas forcement si contraignant. Si tu fais signé ton certificat par l'utilisateur , et aprés ton applet peut faire tout ce qu'elle souhaite.
Quand on regarde runescape avec 1 millions d'abbonnés et 15 qui l'ont testés , ca n'effraie pas tant l'utilisateur que ca. D'ailleur c'est un mmo classique tout en 3D , qui utilise jogl. L'applet n'a pas besoin d'être signé en soi pour fonctionner mais ca évite a l'utilisateur de tous retélécharger à chaque visiste.

Et jagex ne se gène pas pour mettre tous les fichiers dont le client a besoin dans un répertoire caché. 90% des utilisateurs ne s'en rendent même pas compte.


Sinon j'ai quelques petites questions sur ta partie réseau de ton projet.

On entend toujours parler de web service / client riche. Les gros projets comme la messagerie gmail utilisent des serveurs d'application comme glassfish en utilisant de nombreux framework JEE ce qui permet d'avoir une implémention vraiment mvc et de ne pas se préocuper de la couche réseau "basse". Même les jeux de styles casino poker, roulette ect ... utilisent ce genre d'architecture.

Pourquoi ce ne serait pas viable dans un monde virtuel comme ton isochat ?
On vois que la plupart des mmo par exemple dofus, se crée leur propre protocole de communication réseau basé souvent sur tcp des fois tcp/udp conjugués.

Es ce réellement nécessaire , j'ai un peu l'impression que c'est de refaire ce qui existe déja ? Si tu es partie sur la même optique c'est à cause de quelles problématiques ? Utilisation trop importante de la bande passante ? lag si de nombreux tchateurs ?

Et sinon j'ai vu que par la suite tu voulais ouvrir le code. Es qu'il serait possible d'y jetter un coup d'oeil pour voir comment tu gère la communication réseau entre le serveur et les clients . Ou alors donner des explications plus approfondies sur cette partie. Notament comment le serveur informe un client qu'il ya plusieurs autres joueurs a coté de lui.

Sinon je te souhaite bon courrage pour ton projet.

[nouknouk]

Salut,

Pour ce qui est d'une applet ce n'est pas forcement si contraignant. Si tu fais signé ton certificat par l'utilisateur , et aprés ton applet peut faire tout ce qu'elle souhaite.

Effectivement, mais mon objectif initial est d'avoir une applet non signée, pour au final fournir la même expérience utilisateur qu'une appli flash (et surtout éviter les boites de dialogue inquiétantes et peu explicites dans le cas d'un certificat non approuvé par une autorité de certification 'officielle' qui coûte la peau des fesses).
Ceci dit, on verra dans les faits si ce voeu est réalisable. Si c'est vraiment trop contraignant, je dériverai vers les applets signées, voir vers du WebStart

On entend toujours parler de web service / client riche. Les gros projets comme la messagerie gmail utilisent des serveurs d'application comme glassfish en utilisant de nombreux framework JEE ce qui permet d'avoir une implémention vraiment mvc et de ne pas se préocuper de la couche réseau "basse". Même les jeux de styles casino poker, roulette ect ... utilisent ce genre d'architecture.

Pourquoi ce ne serait pas viable dans un monde virtuel comme ton isochat ?
On vois que la plupart des mmo par exemple dofus, se crée leur propre protocole de communication réseau basé souvent sur tcp des fois tcp/udp conjugués.

Il y a différentes raisons à cela:
- pour des besoins d'interaction en 'temps réel', on ne peut plus se satisfaire de requêtes plus ou moins synchrones de type question/réponse (ou RPC) et d'une utilisation de TCP uniquement. Là où tu accepteras que ton interface GMail mette plus d'une seconde à t'afficher le résultat d'une action (clic sur un bouton), un jeu devra être baucoup plus réactif.
- pour la charge des serveurs: faire qu'absolument tout le traitement soit supporté par les serveurs et que le client ne gère que la 'vue (au sens MVC) implique un gros investissement dans la capacité de traitement des serveurs dès que tu veux monter en charge.
- pour la bande passante: plus ton protocole est conçu pour ton besoin, moins tu ne gaspilleras de bande passante. Ca peut être utile à la fois pour les serveurs, mais également pour les clients qui n'ont pas une bande passante illimitée.
Après, rien n'empêche d'utiliser ce genre de solution pour des besoins simples (genre jeu de carte ou autre en tour par tour), mais les limitations risquent de pointer rapidement le bout de leur nez.

Et sinon j'ai vu que par la suite tu voulais ouvrir le code. Es qu'il serait possible d'y jetter un coup d'oeil pour voir comment tu gère la communication réseau entre le serveur et les clients. Ou alors donner des explications plus approfondies sur cette partie. Notament comment le serveur informe un client qu'il ya plusieurs autres joueurs a coté de lui.

Quand le code sera ouvert ... ben ... il sera ouvert donc effectivement ce sera pas bien compliqué de jeter un oeil
En attendant, mon implémentation actuelle n'a rien de révolutionnaire, loin de là: un peu de Java NIO, des sockets TCP, quelques fonctions génériques pour sérialiser/désérialiser les types de base (bool, int, float, ...) et c'est à peu près tout (ici un post où j'avais un peu détaillé le concept)

Pour la partie plus 'haut niveau', je gère avant tout des 'entités' qui sont reliées au monde par leur position (en tout cas pour 90% d'entre-elles qui sont des objets graphiques 3D). Quand le joueur est téléporté à un endroit du monde (genre quand il se connecte), un message lui liste l'ensemble des entités à proximité (ie. dans un rayon de x unités par rapport à sa propre position).
Ensuite, au fur et à mesure de ses déplacements ou du déplacement des autres entités alentours, le serveur peut facilement déterminer ce qui rentre dans l'espace de proximité d'un joueur ou ce qui en sort. Quand ça arrive, il suffit de déclarer la nouvelle entité, de la même manière que la liste d'entités du départ. Quand ça sort, le client s'en rend compte lui même et sait d'avance que le serveur ne lui enverra plus de mises à jour pour cette entité.

Sinon je te souhaite bon courrage pour ton projet.

Merci, il en faut
Pour le moment ça n'avance malheureusement pas très vite tellement j'ai du boulot à côté (sans compter une vie à deux qui va devenir une vie à trois ), mais ça n'empêche que je continue à mûrir les concepts tranquillement.

Après tout, je ne suis pas pressé

[IrmatDen]

<HS>

qui va devenir une vie à trois )

Hey, félicitations nouk² (enfin, à vous 2)
</HS>

[Charlie111]

Salut,

j'ai une petite question matérielle (J'ai essayé ton programme isochat, ça marche super bien). Quel serveur utilises-tu ?

Je travaille sur un projet du même genre et je ne me rends pas bien compte...
Les serveurs les moins chères coutent quand même une petite somme (60€ par mois ?!).
As-tu créé ton propre serveur ? (il tournerait donc nonestop).

Bye!
Charlie

ps : je ne suis pas fou nan, un hébergement mutualisé ne fonctionne pas pour ce genre de programme ?!

[nouknouk]

j'ai une petite question matérielle (J'ai essayé ton programme isochat, ça marche super bien). Quel serveur utilises-tu ?

Isochat et MultiJoo fonctionnent actuellement tous les deux sur un petit serveur 'privé' (comprendre 'serveur dédié où l'espace de stockage est mutualisé') de chez OVH, le RPS 1 qui est facturé 10€HT / mois.

Auparavant, j'utilisais un petit serveur perso tout simple (un vieil AMD Sempron avec 512Mo de RAM de récup') hébergé chez moi, sur ma connexion ADSL. En fait, après un petit calcul trivial, je me suis vite rendu compte que mon serveur perso allumé 24h/24 consommait près de 6€ par mois de courant ; d'où la migration vers un serveur dédié qui offre une bande passante sans comparaison (100Mbits) pour à peine plus cher et qui ravit ma compagne car elle n'a plus de tour affreuse dans le salon

Pour ces deux petits jeux, le besoin est assez faible non seulement en bande passante (moins de 0.5ko/sec et par utilisateur) mais également en ressources (processeur + mémoire).
Pour les ressources processeur justement, j'avais fais quelques tests basiques de montée en charge pour le serveur de multijoo et je m'étais rendu compte que je pouvais accueillir sans souci 2000 utilisateurs en même temps (et encore, le code du serveur est loin d'être optimisé).

ps : je ne suis pas fou nan, un hébergement mutualisé ne fonctionne pas pour ce genre de programme ?!

- si tu entends par "hébergement mutualisé" un serveur dédié virtuel, pas de soucis car les besoins en ressource processeur & mémoire sont faibles et tu auras un accès 'root' sur le serveur pour lancer ton programme serveur.

- par contre, si tu entends par "hébergement mutualisé" un hébergement web uniquement (genre page persos de free), là ça ne pourra pas passer, car pour ce genre de jeu, il te faut un logiciel serveur qui tourne en permanence et qui écoute sur un port TCP, ce qu'aucun environnement d'hébergement de site web ne te proposera, encore moins les hébergements gratuits (*).

(*) a noter qu'il existe une solution intermédiaire dans le genre de ce que propose Your-Socket qui est un hébergement de serveur de socket. Mais le prix de l'offre de base (8€/mois) est bien trop élevé comparé à un serveur de type RPS qui offre bien plus en termes de fonctionnalités, de ressources disponibles et de flexibilité pour à peine plus cher

[millie]

En fait, après un petit calcul trivial, je me suis vite rendu compte que mon serveur perso allumé 24h/24 consommait près de 6€ par mois de courant ; d'où la migration vers un serveur dédié qui offre une bande passante sans comparaison (100Mbits) pour à peine plus cher et qui ravit ma compagne car elle n'a plus de tour affreuse dans le salon

Bon, ça va paraitre con. Mais tu l'as fait comment ton calcul ?

En fait, j'ai jamais vu la consommation sur mon ordi, donc ça n'aide pas trop.

[Furikawari]

T'as une borne sup : la capacité de ton alim.