Reprise du message précédent :

 
En fait, on a à peu près les mêmes problématiques à résoudre en mulijoueur normal et en persistent. C'est dû à la taille de l'univers. C'est-à-dire que vu le nombre d'objets, on est obligé de gérer un état où les objets sont:
- en sommeil (rien à péter de l'étoile xyz qui est à 20 années-lumière du joueur le plus proche)
- en réveil (au moins un joueur s'en approche)
- en activité (un joueur peut interagir avec)
 
Ce qui est différent, c'est que dans un multijoueur persistent, on a des shards qui correspondent à une zone logique de l'univers (la zone n'étant pas nécessairement statique). Tous les objets de cette zone sont gérés dans le shard qui lui correspond. Si un objet (comme un joueur par exemple) se trouve proche d'autres shards, on se débrouille pour que les shards communiquent (en faisant un proxy de l'objet dans les shards où l'objet ne se trouve pas).
 
Dans un multijoueur normal, on ne programme qu'un seul shard ce qui ôte toute la com inter-shards mais on est quand même obligé d'avoir un système de zonage par rapport aux joueurs. Dans les deux cas, on envoit chaque input significatif du joueur (touche, mouvement du joystick) au serveur qui valide, traite et relaie ça aux joueurs impactés avec un système de gestion pour la correction des latences du réseau.

 
Heuuu ben il me semble que le but, c'est d'avoir un système de scripting EXTERNE ( pour créer des nouvelles unités avec leurs caractéristiques, leurs évènements, .. des nouvelles races, nouvelles planètes, nouveaux systèmes ... etc ) sans devoir chipoter au moteur ...
Non ?

 
J'y pensais aussi ca permettait de résoudre quelques petits problèmes (en particulier de latence, de bande passante, de charge CPU et de mémoire ). Le gros problème, ce sont les tricheurs et je ne vois pas du tout ce que l'on pourrait faire pour les contrer.
 
edit: grilled itou

 
Ben c'est comme pour tous les autres problèmes posés : "yaka" chercher une solution pour "protéger" le moteur

 
Ca roule en définissant une interface à la fois standard et évolutive
Ca me semble aussi être une bonne idée que de ne pas avoir de VM mais plutôt du script compilé (because ça divise les perfs par beaucoup).

 
Qu'est-ce que vous entendez par protéger le moteur?

On a dit que ça serait opensource je crois. Ca va être dur de "protéger" le moteur dans ces conditions
 
Les 2 seules solutions de toute façon sont soit de ne pas faire confiance au client, ou de lui faire entièrement confiance. Le deuxième cas ne marche que entre des amis avec un poil d'honneur et de respect pour le jeu

pour votre histoire de langage de script, j'avais jeté un oeil a ferite y'a quelquetemps, ca peut ptet vous servir ?

Moi je suis pas d'accord. Déjà, tous les moddeurs devront se taper l'installation d'un compilateur C++. Ensuite, ils devronts apprendre à compiler le jeu. Puis à chaque modif, ils devrot attendre que le compilateur C++ compile le code, fasse l'édition des liens. Plante parceque le moddeur à oublié de quitter le jeu ( merci windows pour tes locks tellement généreux sur les .exe ), refasse l'edition des liens, lance le jeu, teste. Constate qu'il a mis un plus au lieu d'un moins a la ligne 254, recommence.
 
Et puis, après il faudra fournir un debogueur. Vous vous voyez faire ça sur du code généré ?

Mmmh au départ, selon mon point de vue, le client ne doit avoir aucun contrôle. Il ne devrait tout au plus qu'envoyer des messages au serveur sur ses actions, et ce dernier décide si ces actions sont valides, puis met à jour le client.

 
Ben je sais pas moi .. je vais peut-être dire une connerie mais une espèce de centralisation des sources et impossibilité de jouer avec une compilation mmmmh "non-validée" par un "groupe de contrôle" ....
Merde, ça fait très Etat Policier ça ...

 
On peut couper la poire en deux et faire une VM pour les tests. Si le langage de script n'est pas trop baleze, c'est pas la mort. Enfin, je dis ça, je ne vais pas la coder la VM hein

 
On ne peut pas simplement se baser sur un executable auquel on aurait incorporé des protections ne se trouvant pas dans les sources publiques parce que des pirates feront tomber ça assez rapidement. Je pensais à plutôt un système de certification, c'est-à-dire donner un certificat à des personnes en qui nous avons une totale confiance (mais de mon intuition, ça reste à moitié miteux).

Il n'y a pas que pour les tests. On peut aussi envisager un système dans lequel le serveur envoie aux clients le code qu'ils n'ont pas par exemple. Comme dans Unreal[classic-2004]

Les certificats, ça se vole
Le code aussi
 
personne réagit sur mon dernier post?

 
Oui, c'est aussi comme ça que je voyais les choses. Le petit détail est que le client doit aussi exécuter les commandes du joueur avant leur validation par le serveur quitte à faire une correction en retour sinon c'est injouable à cause des latences.

 
Ouais .. mais QUEL code ? .. il faudra donc bien tout centraliser .. et qui va se charger de la validation ? ..  
Moi, j'ai pas envie de recevoir le code d'un gugusse qui voulait juste un bouton rectangulaire bleu au lieu d'un carré vert dans l'interface machin de la station bidule ... je l'aimais bien moi mon bouton bleu !

 
Dans un mode multi non-persistent ou mono, il n'y a pas besoin de validation mais pour du persistent, il en faudra nécessairement une (enfin, ça dépend d'à quel point on peut modder mais pour que ce soit intéressant, il vaut mieux).

On va supposer qu'on fait confiance aux serveurs quand même. Le code serait donc ici les scripts custom qui tournent sur le serveur.

 
Ok...
 
A propos des "mods", ne serait-il pas concevable d'implémenter dans le moteur qui va les interpréter un minimum de "vérification de cohérence" ?  
Genre, un vaisseau de X tonnes ne pourrait pas avoir un volume inférieur à X et supérieur à Y et du coup, ne pourrait pas avoir plus de X mètres cubes de cargo-bays ...
 
Ou un vaisseau type "cargo" ne pourrait pas avoir plus de XX armements ...  
 

Pas vraiment en fait. Si l'admin d'un serveur indépendant veux mettre des scripts foireux sur son serveur, on ne va pas l'en empecher car ce serait frustrant plus qu'autre chose.

 
En même temps, ça me paraît être une bonne idée. Disons que ça peut être optionnel.

 
Mouais mais ça va vite tourner au n'importe quoi ça !
Personnellement, je ne serais pas frustré si on m'empêchait de faire des conneries !

Bon voilà
Pour la partie multijoueurs (même monojoueur avec des bots), on peut imaginer une approche multi-agents.
On peut même aller très loin dans la reflexion, c'est à dire imaginer que chaque objet de l'univers soit un agent.
Ensuite, bien sûr, on aura des agents statiques, d'autres dynamiques, des agents simples, d'autres complexes etc.
J'ai retrouvé mon mémoire de DEA pour lequel j'avais bossé sur des trucs comme ça, si ça vous dit:
http://moktar1er.site.voila.fr/docs/ProjetDEA.pdf

 
Imaginons que dans l'univers du joueur qui se déconnecte, il y ait un soleil, tu as déjà entendu parler des super-novas ?    
 

Oua, le titre en jette sur la première page

Les supernovae ( ), ça n'arrive pas instantanément

je lirai ce soir mais ça me paraît déjà bien sexy comme intro

 
'taiiin j'ai fait une embolie cérébrale dès que j'ai lu le titre du point 2.1.1 "Equations différentielles"
Chuis nuuuul en math !!! me suis arrêté à l'algèbre et la trigo de base !
Bon .. on va faire comme si de rien n'était et je vais lire juste les chapitres que je peux comprendre !  

 
Heuuu ouais mais là, ça implique une destruction totale ...... et si le joueur se reconnecte ???
Ca ne peut justement pas être une destruction de l'univers du joueur .. plutôt une espèce de "transport" instantané .. par exemple dans notre propre univers "local" ...
Je sais que ça a un gros côté irréaliste .. tout comme les wormholes, les "points de saut", les stargates et autres joyeusetés venant de Hollywood !

 
Suffit de regénérer un univers de façon plus ou moins aléatoire pour chaque joueur qui se connecte    
Comme ça tu as la premier jeu persistant dont le monde change en fonction des joueurs et des coupures réseaux  

et pourquoi le système ne prendrait pas le relais lors de la deconnection d'un joueur?
il récupère son univers dans l'état et le fait vivre lui même jusqu'au retour du joueur...
par contre il faut que le joueur accepte que s'il quitte, il reviendra dans son monde mais... un peu modifié

 
Ben nan .. si UN serveur doit se charger de tous les univers "déconnectés", là, on perd le concept "multi-serveurs" ..

on peut faire du multi-serveurs sans n'avoir que des serveurs "réels" non?
j'imagine bien des "serveurs virtuels"

On pourrait peut-être "limiter" la tâche du client à la gestion d'un seul système et pas d'un univers ou d'une galaxie toute entière non ?

je suis d'accord, j'ai fait un abus de langage dans mon premier post.
en parlant "d'univers", j'entendais univers immediat du joueur, donc son "système"

Que se passe-t-il si le serveur plante, si on retire la fiche de courant, le câble réseau, enfin un impondérable quoi?

 
Ben comme j'ai dit, pq pas un "transport" instantané dans le système local du joueur ...

avec un système de "ping" régulier, les autres serveurs devraient s'appercevoir de l'absence de l'un d'eux non?

 
Mmmh ben si chaque client avait une connexion permanente avec un serveur central .. les clients pourraient interroger le serveur pour savoir quels "user-systems" sont dispo ... et pourraient être prévenus en direct de l'apparition ou la disparition d'un système .. non ?
Une espèce de "carte galactique" dynamique temps réel ...
Ce que j'imaginais, c'est qu'un client puisse se connecter directement, à la P2P, sur le système d'un autre client ... bon une fois de plus, je suis loin d'être une bête de réseau, je demande juste ...

c'est pour ça que je vois bien quand même un "superserveur" pour prendre en charge les disparitions impromptues