Reprise du message précédent :
c'est pour ça que je vois bien quand même un "superserveur" pour prendre en charge les disparitions impromptues

Si on veut faire un truc qui s'assimile à du P2P, il en faudra plus d'un justement.

pas moyen de faire des serveurs virtuels justement?
jute un processus qui se connecte au réseau, mais qui physiquement se trouve sur une machine déjà connectée (avec éventuellement déjà plusieurs serveurs virtuels)

 
Et ton client va broadcaster le monde entier pour découvrir les autres serveurs ???
Nan, faut au moins UN serveur central ...

ça ne me satisfait pas alors pour le cas des disparitions de serveurs...
ou alors, c'est ce fameux serveur central qui prend en charge de simuler le serveur disparu?

Et si le serveur central se prend le jus?

et les splits?

j'avais oublié ça

et avant un split, généralement ça lague toujours de manière assez énorme si c'est un problème de charge...
dans la série je donne un ordre, c'est éxecuté tout de suite chez moi, mais tous les autres ne voient pas le changement avant 5mn... ça peut être assez surrealiste

 
Mmmmh bon, autre idée :
En fait, l'idée de base, c'était de donner la possibilité de jouer online ou offline ... si le joueur décide de jouer offline, il faudra de toute façon générer un univers "local" ... donc, online, pourquoi ne pas en faire profiter les autres joueurs ...  
Un univers est généré localement mais un seul système est "partagé" ... jouer online limiterait le joueur à ce seul système local chez lui ...
 
Maintenant, imaginons que dès la première connexion, le client envoie au serveur central la config de son système partagé ( et ce seul système ) ... tant que le joueur est connecté, les autres joueurs naviguent chez lui ... si il se déconnecte, les joueurs sont redirigés d'une façon transparente vers le serveur central ...
L'inconvénient, c'est qu'il faut que le serveur ait en permanence une "image" de tout ce qu'il se passe dans ce système ... et qu'à la reconnection du client à qui appartient ce système, le client reçoivent les données modifiées ou mises à jour sur ce qu'il s'est passé dans son système en son absence .......
On en revient presque au concept du serveur unique

 
De toute façon, on ne peut pas se passer du serveur unique pour plusieurs raisons (identification, sauvegardes, redirection vers les autres serveurs, ...). Ensuite, il se posera toujours le problème de la sécurité (à mon avis, il est d'ailleurs insoluble). Pour finir, un système distribué qui imposerait probablement des contraintes sur le gameplay serait, à mon avis, complètement moisi.
 
Aussi, je pense qu'il vaut mieux faire trois versions (qui n'en sont en fait qu'une):
- mono, le joueur a tout ce qu'il lui faut sur sa bécane, client, serveurs, le tout de manière transparente
- multi, un joueur a tout ce qu'il lui faut sur sa bécane; il joue le rôle du serveur pour les autres et il peut faire du persistant s'il a le matos qui lui faut
- persistant, une zone "trusted" avec les serveurs de jeu. On fera raquer les joueurs d'une modique contribution dès qu'il y en aura trop afin de pouvoir se payer les serveurs et leur hébergement

Enfin qq qui garde la tête sur les épaules. Je commençais à m'inquiéter.

lol je trouve aussi que ca commencait à partir en live, mais j'ai vu plein d'idée interessantes c pas mal
 
Je suis également pour les scripts interprétés, c'est très pratique, et franchement c'est pas SI lent qu'il faille les compiler je trouve
 

Ah, je vois que ça cogite !!    
 

 
Euh, tiens-nous au courant, je suis intéressé pour cela. Ceci dit, je ne vois pas pour le moment comment résoudre le problème de la triche.
 
 
Au passage, au fil de mes lectures, je poste deux liens qui pourrnt reservir :  
 
La FAQ Math and Physics de GameDev
http://www.gamedev.net/community/f [...] orum_id=20
 
Une série d'articles excellents (à lire absolument avan de bosser sur la dynamique): http://www.d6.com/users/checker/dynamics.htm
 
Le moteur physique ODE : http://ode.org
Il y a aussi Novodex mais je me méfie un peu de la licence (free of charge for non-commercial use), susceptible de changer du jour au lendemain.
 
 

 
Ah oui, felix est développé par John Skaller, un des membres de la communauté Ocaml. C'est pas mal du tout, si ce n'est que les perfs sont assez déplorables si on en croit le "computer language shootout" (sur alioth.debian).
 
Pour Squirrel, c'est vraiment un excellent petit langage. C'est pas aussi puissant que Python, loin s'en faut, mais c'est très suffisant pour bcp de problèmes, ça semble facile à apprendre (syntaxe C like) et c'est très léger. On peut réellement faire de l'OO avec. On comprend pas mal de choses en lisant le doc expliquant la philosophie de Lua (sur le site de Lua).
L'auteur semble relativement réactif, mais le produit n'est pas tout-à-fait mature vu qu'en jouant un peu avec, je suis tombé sur un bug : la fonction sort est foireuse (crash).
Donc dans mon esprit, ça va se jouer entre Squirrel et Stackless Python. Si une majorité veut faire du Python, je pense que la balance penchera vers ce dernier.

 
Pour la persistence, c'est marrant que personne n'ait commenté la "solution" que j'ai donnée page 14. Dites, vous l'avez lue ou quoi ?  
 
Sinon, pour les problèmes de la customisation, j'ai quelques idées en vrac :  
 
 - le serveur peut customiser certaines interfaces via des PNG/JPEG (uniquement du statique, sinon on s'en sortira jamais),
 
 - on peut inventer ses propres races. Chaque race peut créer son histoire, ses styles de vaisseau (donc ses modèles 3D genre avec 3DSMax ou je ne sais quoi).
 
Un nombre fixe de points (disons pour l'exemple 300 points) est à répartir dans divers postes, par exemple :
 1. capacité en propulsion (détermine la vitesse max du vaisseau),  
 2. tonnage (détermine la taille/charge max du chargement -> influe sur la manoeuvrabilité),  
 3. capacité d'armement (détermine le nbre et la puissance max des armements),  
 4. capacité de blindage (détermine l'épaisseur maxi du blindage),  
 5. capacité en équipements spéciaux : détermine le nombre maxi d'équipements spéciaux (aide à la navigation, système de visée amélioré, par ex.),  
 6. solidité : détermine au bout de combien de coups le raffiot se transforme en poussières d'étoiles   .  
Les caractéristiques du vaisseau de type "Starship Enterprise IV" par exemple sont réparties comme suit dans ces divers postes (50, 80, 40, 40, 55, 35, 50) dans les limites d'une valeur maxi de 100 autorisée/carac, comme pour la création de personnages. Ces caractéristiques seront elles-mêmes des valeurs maximales autorisées pour la création de vaisseaux de type "Starship Enterprise IV". Donc un joueur vréer un vaisseau de ce type aura des carac de base maximum de (50, 80, 40, 55, 35, 50). Il aura un certains nombre de points à répartir, mais les valeurs de son vaisseau ne pourront pas dépasser ces valeurs-là. On peut dire aussi que en-deça de 70 dans un poste (disons propulsion), le vaisseau ne peut accepter de propulsion de technologie de niveau 2 ou +. Si le joueur veut des technos de niveau supérieur, il lui faudra vendre son raffiot miteux et acheter un vrai vaisseau, qui lui, aura 450 points maxi à répartir (par exemple).  
A partir de là, en fonction de ces caractéristiques, le vaisseau pourra accepter plus ou moins d'équipements dans chacun des postes.
Un tel système permet de créer des vaisseaux marchands, de transport de minerai, des corvettes de combat (pour les pirates) ,etc.
La-dessus, on peut customiser encore ses races en disant que chaque race possède ses propres technologies (avec divers niveau de technologies). De la même manière, il faut faire appel à un système de répartition de points pour ne pas déséquilibrer le jeu.

ça fait fort penser à Stars! ce que tu racontes là

Ah ben peut-être, mais je ne connais pas Stars (en fait, ma culture du JV spatial est complètement nulle, j'ai tjrs pas trouvé le temps d'essayer Elite). J'ai pensé à ça ce matin, dans le métro.

La première étape pour jouer à Stars!, c'est de créer sa race, pratiquement selon le principe que tu décris: un capital points, chaque caractéristique valant un certain nombre de points, et tu peux choisir d'avoir certains avantages technologiques particuliers au détriment d'autres.

Ben c'est le système le plus simple et le plus logique, celui utilisé dans la plupart des JdR.
 
Au fait, sur GameDev, il y a un type qui a en tête un projet du même genre mais basé sur une interface web, ce qui limite les risques de triche, mais aussi grandement les possibilités du jeu, cela va sans dire. Tjrs est-il qu'une réponse d'un gars qui a bossé sur http://www.mankind.net est :  

 
Je pense que je vais commencer par faire une étude de besoin. Tant qu'à faire, autant le faire dans l'ordre
 

 
Tout dépend de l'architecture employée. A mon avis, si on utilise du distribué pour les serveurs (avec des personnes lambda à la manière d'un p2p), il y aura toujours un moyen de contourner les contrôles. La seule possibilité que je vois est d'héberger soi-même les serveurs et sinon, le joueur prend le risque d'aller chez un hébergeur malhonnête. Tout le problème du distribué est qu'on double en quelque sorte le problème de la triche qui n'est plus limité au client mais se retrouve alors aussi du côté des serveurs. Bref, si on ne peut faire confiance à personne, on est plutôt mal barré.
 

 
Je vous ferai mes remarques demain.

 
Le problème qu'induit cette solution à base de sg, le "zoned shard", est que le load-balancing y est inefficient. Par exemple, si pour une raison ou une autre, 200 joueurs décident de se retrouver dans un sg, le seveur correspondant sera à genoux alors que d'autres pourront se tourner tranquillement les pouces. Aussi, le découpage en zones sphériques me semble douteux du point de vue du réalisme et contraignant du point de vue du gameplay. Je serais plutôt pour faire du "dynamic shard" combiné avec du load-balancing (des espaces de calcul en somme) sur un ensemble de serveurs en réseau local.
 
Ensuite, ce n'est pas si compliqué que cela de gérer les frontières mais il est vrai qu'avec un système distribué, cela induira des latences réseaux suplémentaires. Il faudrait donc en plus que les serveurs soient organisés géographiquement d'une manière correspondante à leur organisation logique dans l'univers si l'on voulait ne pas avoir une telle limite imposée par l'archi réseau. Restera toujours le problème de la triche et, dans cette optique, je ne serais a priori pas trop pour que l'admin puisse faire tout et n'importe quoi sur son serveur (pour moi, c'est quasiment de la triche authorisée).
 
Aussi, il faudrait assez rapidement se mettre d'accord sur tout ce que le jeu comporte comme "simulation" non-joueur parce que si on développe un SimCity à l'échelle de l'univers, ça va vite virer à l'histoire de goinfre.
 
Il y a aussi l'histoire de la centralisation des données. Il faudra nécessairement un serveur central pour la bd parce que le cas échéant, si pour une raison x ou y le serveur où se trouvait un joueur n'est plus disponible lorsqu'il veut se reconnecter, c'est dans son cul. Après, même avec un serveur central, il faudra trouver une ruse au niveau du gameplay pour lui expliquer que pouf pouf, il a été magiquement transporté ailleurs pendant qu'il dormait (ce qui a priori pourra arriver assez souvent).
 
Bref, faire du distribué me semble extrèmement contraignant vis-à-vis du jeu et apporte plus de problèmes que cela n'en solutionne. En vrac:
- problème du zonage par blocs (ou sphères), cad. perte de réalisme
- problème à moitié résolu puisqu'il faut quand même un ou des serveurs centraux
- problème de load-balancing
- problème des serveurs fermés
- problème de la triche
- problème de communication inter-serveur
 
 
En conclusion, je ne suis pas pour les solutions techniques qui imposent des limitations au gameplay ni, définitivement, pour faire un système de serveurs distribués "à la p2p".

dans un sombre accès de folie, j'avais imaginé que lors du démarrage d'une partie, la galaxie se crée de la même façon qu'une vraie (dispersion des étoiles toussa, solidification des corps -> planètes, blablabla) et de la même manière, qu'on "construise" aléatoirement les races, civilisations et autres factions, histoire d'avoir un background plus ou moins solide mais différent à chaque fois

Je plussoie avec DocMaboul personnellement... De plus, j'ai l'impression qu'on s'égare un peu.
Le multi joueurs est il si crucial pour un jeu de ce genre ? Personnellement je pense pas. J'ai réussi à prendre mon pied avec les Elite(s), alors qu'Internet n'existait même pas.
Comme on a tout le temps qu'il nous faut, pourquoi ne pas d'abord se concentrer sur une version non multijoueurs dans un premier temps ? Parce que là, chacun expose son point de vue, très instructif de surcroit, mais on n'avance pas.
Je propose donc qu'on commence à coder un rough solo, et on verra ensuite le multi joueurs, non ?
Il ne faut pas oublier que des jeux commerciaux ayant nécessité plusieurs années de développement sont incapables de proposer un multi joueurs correct, preuve qu'il est assez complexe de réussir cet aspect. Donc bon, concentrons nous sur l'aspect solo, et on trouvera toujours le moyen de passer en multi le moment venu.

De plus, on ne sait toujours pas qui est intéressé pour se joindre au projet. A ce que j'ai lu, il semble que, outre les 3 cités en 1ere page, il y ait Moktar1er, El Muchacho et DocMaboul qui souhaitent participer au projet, j'ai bon ?

Perso, je suis pour la priorité donnée au solo, ça n'a pas changé depuis le début, c'est le truc qui m'intéresse. Mais si Doc est motivé pour creuser la partie multijoueurs, pourquoi pas
 
En tout cas ils ont raison sur un point: il faut avoir le multi en tête dès le début pour éviter d'avoir une trop grande partie du code à refaire si on veut implémenter un mode multi. Donc en parler maintenant ne me paraît pas être un égarement  
 
(j'éviterai toutefois de faire mention du multi dans mon analyse pour ne pas faire double emploi avec le travail auquel DocMaboul va s'atteler)

 
Disons que ce n'est pas crucial mais que cela apporte indéniablement beaucoup plus de fun (si le jeu est bien fait, stable et performant). Jouer, ça ne m'intéresse plus beaucoup mais un élite en multi-persistant, je trouve ça plutôt bandant.
 

 
C'est vous qui voyez mais cela va être plutôt lourd de transformer tout le code pour le faire passer du mono au multi. Ce n'est pas du tout la même approche. Après, c'est vrai que c'est particulièrement ardu et que cela apporte beaucoup plus de problèmes techniques à résoudre. Donc autant y aller par étapes et tant pis s'il faut refondre tout le code après coup (et puis d'ici là, on aura des serveurs plus performants encore ). Il vaut mieux garder la tête froide et se dire que cela ne sert à rien que de se lancer dans un projet de trop grande envergure pour arriver à un travail qui n'est ni fait ni à faire.

C'est sur, mais bon, fondamentalement, le multi est il si important pour un jeu de ce genre ?
On va modéliser l'espace, donc une étendue virtuellement illimitée. L'intéret du multi, c'est de pouvoir se confronter. Et quelle est la probabilité de rencontrer un joueur humain dans cet espace ? De plus, si on le rencontre, que fera t'on ? Dans la plupart des cas, ça finira en dogfight de 10 secondes entre vaisseaux surarmés, et puis voilà.
Déjà que je trouve l'intéret du multi très limité dans des jeux comme Flight Simulator, qui modélisent une surface fermée...
Bref, on créé une version multi, chaque joueur part d'une position aléatoire dans l'univers (déjà, on peut en déduire la probabilité de se rencontrer qui est quasi nulle), un joueur en rencontre un autre et lui éclate la tronche. Fin de l'histoire. La partie multijoueurs n'aura duré que quelques minutes.
Bref, je doute fortement de l'intérét de ce mode de jeu

 
Travailler sur la partie multi m'intéresse beaucoup, oui. D'ailleurs, ce serait pas mal de débaucher taz

chuis pas d'accord là
et les modes "coopération"?
si tu ajoutes à ton espace des joueurs robots, que ceux-çi s'associent et évoluent en formation, il vaut mieux en faire de même entre humains, sinon tout le monde se fera rapidement balayer

 
Pour ma part, j'avais plus en tête l'idée du jeu en équipe que celui de la concurrence.

ça va pas non ? on code un clone d'Elite là (donc ultra optimisé, donc possédant forcément du code dégueulasse), pas un bloatware templaté de partout

 
ma religion me l'interdit  

 
En y réfléchissant, je me dis que le code n'est peut-être pas le plus gros problème (au pire, s'il faut passer quelques mois à refondre le tout, ce n'est pas le bout du monde). Ce qui me fait plus peur, c'est d'avoir à partir d'un mode solo qui requiert, par exemple, 200Mo de ram côté moteur de jeu pour gérer un seul joueur.

Oui, je suis d'accord avec tout ce que tu as dit, je suis pas convaincu de l'intérêt, mais si il y a quelqu'un de bien motivé pour le faire, je dis: pourquoi pas

bin ce qui consommera le plus, ça sera sans doute l'univers lui-même, pas les avoirs personnels du joueur

 
Ben, les chances de réussite d'un tel projet sont fonction des compétences des devs et, a priori, il n'est pas trop mauvais ce petit

 
Effectivement ... c'est bien là le problème ... je vais pas pouvoir bosser avec qqun, aussi bon soit-il, qui me dira toute les 10 secondes "putain mais t'es trop con, t'as de la merde dans la tête ou quoi ? c'est quel mot que t'as pas compris dans ma phrase qu'un gosse de 3 ans aurait compris ?" !!!!!!
Il apprend d'abord le "social", on verra après !  

 
C'est le sans doute qui me fait un peu peur. Enfin, je voulais juste souligner le fait que si la partie purement joueur n'utilise que "quelques" dizaine de Mo, ça va vite grimper du côté des serveurs.

 
Eh bien je serai assez interessé par ce projet, mais je suis encore un débutant (enfin pas trop quand meme ), je n'ai encore jamais participé à des projets à plusieurs
 
Si ca vous interesse je peut vous montrer des trucs que j'ai fait  

 
C'est sûr qu'il faut pouvoir le supporter Après, je ne le connais pas. Il est aussi comme ça en dehors des forums?

Pour ceux qui voudraient se lancer dans la conception des modèles 3D , un générateur de textures http://hulud.planet-d.net/?item=12
Pas testé .. mais les samples sont pas mal ...