Reprise du message précédent :

 
lol, ce qui est sur c'est que je risque de faire pâle figure à coté de vous  

 
Ouaip .. mais ça va là, c'est ok .. j'ai réussi !
( c'était mon cerveau qui était en mode "pré-week-end" )

 
Parfait, on a trouvé un volontaire pour s'en occuper : Moktar1er
 
Bon sinon, je suis assez motivé pour participer à mes heures perdues.

moktar1er, s'il participe, je sens qu'on va lui filer tout ce qui cause IA

 
Effectivement, rien qu'en voyant le nombre de classes, ça n'est pas un petit projet, ce moteur. De plus, il semble scriptable.

j'ai pas suivi tout le topic mais bon, c'est p-e le genre de projet auquel je serais interressé à participer même si j'ai jamais accomplit ce genre de boulot.
 
J'ai surtout des connaissances au niveau infrastructure Unix, mais jme débrouille quand même pas si mal avec le C et le C++ plus récemment
 
jvais tenter de lire ce que jai manqué du topic, faite moi savoir si toute aide serait apprécié, sachant qu'au départ faudra p-e me corriger mais j'apprends assez vite et jsuis plutot débrouillard

Bon, j'ai jeté un oeil au forum de GameDev cette nuit, et il apparait que pour FarCry, LUA a été légèrement modifié par l'auteur du langage squirrel, censé être un chouillas plus rapide et surtout orienté objet (ce qui n'est pas vraiment le cas de lua à première vue). Compte tenu de cette expérience (voir le CV de l'auteur, qui a bossé sur FarCry), on peut supposer que squirrel a gardé les caractéristiques utiles de lua. Il y a au moins les tables et les coroutines.
Donc squirrel pourrait être un choix intéressant, si ce n'est qu'il ne bénéficie pas de la communauté lua (donc peu de support possible, contrairement à lua qui a pas mal de supporters dans le monde du jeu), et que c'est un produit encore tout jeune.
 
squirrel semble plus adapté aux contraintes temps réel des jeux vidéo.
 

Sinon, parmis OGRE a l'air d'être un moteur 3D apprécié. Un autre choix open source (licence MIT) est Nebula device, qui ne se contente pas d'être un moteur 3D, mais est un "game engine", c-à-d qu'il gère bcp d'autres choses que l'affichage, à savoir les opérations réseau, le son, les collisions, etc, et s'interface avec lua entre autres. Il est développé par GarageGames pour leurs propres jeux. Inconvénient : OpenGL n'est pas supporté mais c'est "on the works" d'après leur site.

En avant-première, je vous livre ici quelques-unes de mes réflexions métro-esques, le reste étant dans une révision du Drasche-draft tjrs en cours, que je devrais lui passer d'ici la fin du w-e.
 
Commentaires bienvenus.
 
Repère galactique
 
La Galaxie bénéficie d'un système de coordonnées polaire centré sur le centre de la Galaxie (CG).
Le repère galactique se décrit ainsi :
Dans le plan galactique, un point se repère par :
 - l'angle/axe CG-planète de référence (de 0 à 360°),
 - sa distance au CG (en parsecs, 1pc = 3,26 a-l = 9460 milliards de km),
Ensuite, dans l'axe perpendiculaire au plan, la distance est un réel (signé), en pc.
 
 
Aspects multijoueurs
 
Serveur
Chaque serveur décrit une région sphérique limitée de la Galaxie nommée Secteur Galactique (à défaut d'un nom plus approprié, SG).
Un SG a une taille et des coordonnées bien déterminées mesurées dans le repère galactique. Le diamètre maxi d'un secteur est de 10 pc, soit 32,6 a-l.
Les joueurs qui se connectent à ce serveur ne peuvent évoluer que dans le SG qu'il décrit.
 
NB: en pratique, un vaisseau peut s'éloigner autant qu'il veut du centre du SG dans lequel il évolue, mais il ne fera aucune rencontre intéressante, et il ne changera pas pour autant de SG, ceci afin de limiter les échanges de données entre serveurs et de s’épargner la gestion du problème compliqué des frontières.
 
Chaque SG peut contenir autant d'astres (étoiles, planètes, planétoides,  etc) que nécessaire, et autant de factions que voulu. L'administrateur du serveur peut décider de la politique, des commerces, et de tous les paramètres nécessaires au jeu (dans des limites  à définir) sur chacun des astres, ou bien laisser l'ordinateur les créer automatiquement. Il doit avoir la possibilité de modifier les png et les jpeg des écrans associés à ses planètes afin de personnaliser le jeu.  
Enfin, il doit pouvoir limiter le nombre de joueurs sur son serveur.
 
Le serveur ne fait pas que gérer l’activité des astres, il gère aussi les factions, la politique, le commerce et les positions et les actions des PNJ, les cours des marchandises, etc, en plus de synchroniser tous les clients (heartbeat de synchronisation, position, orientation, vitesse des vaisseaux, indication de projectile lancé par l'un des vaisseaux, de destructions éventuelles, etc ).
 
Question : comment sont transmises les données dans les FPS ? Via le serveur ou en direct entre les joueurs (ce qui signifie que chaque client transmet ses infos à tous les autres sans attendre de réponse) ?
 
Communication entre serveurs
Au démarrage, le serveur cherche les adresses IP d'autres serveurs en ligne à partir d'une liste de départ (qui sera remise à jour par échange, à la manière du P2P), et leur signale sa présence sur le réseau.
Les serveurs échangent les coordonnées galactiques de leurs SG respectifs, ainsi que le nombre maximum de joueurs qu'ils acceptent.
 
Changement de SG
Les joueurs peuvent changer de SG via un portail cosmique ou un wormhole. Chaque portail cosmique transmet au vaisseau le SG avec lequel il communique.
Les wormholes, eux, n'affichent pas les SG vers lesquels ils communiquent. Il faut pour le savoir acheter une carte adéquate sur une des planètes habitées.  
 
-   wormholes: couloir transdimensionnel menant à un point plus ou moins distant ailleurs dans la galaxie. Le wormhole connaît divers degrés de stabilité, et les wormholes stables sur de longues périodes sont très rares. Les wormholes peuvent aussi poser des problèmes techniques: il faut que le vaisseau soit équipé et/ou configuré correctement, sinon, avaries. Enfin, certains wormholes peuvent changer aléatoirement de destination au cours du temps. Les wormholes aléatoires envoient les explorateurs spatiaux qui les franchissent sur un serveur quelconque, qui peut aussi bien être le serveur d'origine (mais ils réapparaissent alors dans un autre wormhole). Les vaisseaux qui sont dans ce cas ne savent pas où ils sont tant qu'ils n'ont pas atteint une planète habitée.
 
-   portals: technologie permettant de créer un couloir transdimensionnel entre deux “portes”, un wormhole artificiel. La technologie mise en oeuvre limite cependant fortement la masse et la taille d'un vaisseau voulant passer dans ce portal, et enfin, la distance maximale pouvant être parcourue.  
Les portails cosmiques étant maintenus par la Guilde des Portails, - seule guilde habilitée à les opérer -, ils ont un droit de péage pour être franchis. Le montant du péage est évalué en fonction des capacités susmentionnées.
 
Lorsqu'un joueur franchit un portail cosmique ou un wormhole, le serveur contacté lui envoie toutes les données nécessaires pour évoluer dans le nouveau  SG : positions, masses et aspect des astres, caractéristiques des vaisseaux des PJ et des PNJ, jpeg divers, etc. Attention : cela pourrait représenter plusieurs Mo de données si on  n'optimise pas les textures des planètes et des objets.
 
Un joueur sortant d'un Portail ou d'un wormhole est invulnérable pendant 5s, (le temps de sa matérialisation pour les autres joueurs), de sorte qu'il ne soit pas surpris dès son entrée dans un nouveau SG, en cas de combats violents à proximité.
 
Question, comment limiter la tentation d'échapper à un adversaire en franchissant  un Portail ou un wormhole ? Une des façons est de requérir d'être bien dans l'axe. D'autres idées ?
 
 
Les problèmes posés par un monde "quasi persistant"  
 
Ce que j'appelle un monde quasi persistant est un réseau de serveurs décrivant l'univers dans lequel peuvent évoluer les joueurs. Cet univers est d'autant plus riche et varié que le jeu est personnalisable et extensible, certains joueurs pouvant faire des mods en empruntant aux univers "Star Wars", "star Trek", "Total Annihilation", voire "HitchHiker's Guide"... Certains serveurs peuvent être momentanément hors ligne, retirant ainsi une partie de cet univers, d'où le nom de "quasi persistnt"L'idée de faire un monde quasi persistant est séduisante, mais se heurte à plusieurs difficultés dues au fait qu'il est multi serveurs:
 
1. La disparité des prix entre SG: étant donné qu'il est possible d'acheter dans un SG et de vendre dans un autre SG, il est facile de trouver des "filons" facilement lucratifs. Cette technique de triche peut être contrée en faisant varier assez rapidement les cours des marchandises, de sorte qu’une “affaire en or” ne puisse durer très longtemps. Ou alors on restreint les cycles achats-ventes à l’intérieur d’un même SG.
 
2. L'évolution des PJ. L'intérêt principal des mondes persistants est de pouvoir faire évoluer un PJ au cours des parties, les vaisseaux gardent les caractéristiques acquises. On peut même imaginer de conserver l'historique des faits marquants de son histoire (victoires, ventes particulièrement lucratives, changement de statut, etc). Cependant, pour que le jeu soit constamment intéressant, il faut pouvoir jouer entre joueurs d’un même niveau. Il semble alors nécessaire que chaque serveur indique le niveau approximatif des joueurs pour lesquels il s’adresse, ce qui signifie qu’il devrait refuser les joueurs d’un niveau supérieur.
 
3. Le problème les plus ennuyeux est le risque de triche.  Si on laisse un joueur conserver son PJ sur son disque dur, il peut à loisir modifier les caractéristiques de son vaisseau, d'autant plus facilement qu'il a le code source. Et on ne peut les conserver sur le serveur d'origine, car cela implique qu'il soit en ligne dès qu'un joueur veut jouer. D'autre part, il suffit de conserver son PJ sur son propre serveur et de le mettre en ligne pour contourner ce système. Un serveur peut tjrs l’éliminer (en envoyant un Blade Runner expéditif par exemple), mais rien n’empêchera le joueur de revenir sous un autre nom, à moins d’établir une liste d’IP bannies.
 
Les points 2 et 3 ne semblent pouvoir être contournés que si on abandonne le principe de l’évolution d’un PJ au cours des parties.
 
Les principales simplifications  
 
Les simplifications doivent avoir deux buts :
 - simplifier le programme,
 - améliorer le gameplay : l'accumulation de règles compliquées n'ajoute pas forcément de richesse au jeu et peut entraver le plaisir du joueur ou la rapidité du jeu.
 
Un choix de simplifications (à discuter):
1. Le temps est le même pour tous les joueur d'un SG, donné par le heartbeat du serveur.
2. La densité des atmosphères est considérée comme constante dans les calculs de portance et d'usure.
3. Le champs d'attraction gravitationnelle d'un astre est fonction de sa masse et de la distance au centre. On ne compte pas plus d'un astre à la fois dans le calcul du champs, ceci afin de ne pas trop charger les CPU. (jeter un œil aux algos à N corps efficaces)
4. En vitesses supraluminiques, les collisions ne sont pas prises en compte. Les risques de collisions  avec des astres, bien que minimes, peuvent à la rigueur être étudiés.

supraluminique ou pas, les collisions vont etre problematique (parce que a 200.000km/s, une planete ca se traverse rapidement). Il faut donc passer du mode discret habituel au mode continue, doit avoir de la doc la dessus

Et hop, un dernier thread sur l'utilisation de lua dans FarCry :
http://www.gamedev.net/community/f [...] _id=230021
 

Une question : que viens faire la portance dans un jeu de vaisseaux spatiaux ?
 
Et une remarque : le lua est quand même un langage un peu faiblard. C'est bien quand on a un projet qui est déjà bien avancé et qu'on veut ajouter après coup un langage de script mais sans plus.

Il faudrait inclure un "détecteur de collisions" qui modifie la trajectoire/diminue la vitesse en conséquences. Avec la possibilité de le désactiver, au risque et péril du vaisseau...

 
 
Q1 : lors des rentrées dans l'atmosphère des planètes.
Q2 : que lui reproches-tu ?

 
je me souviens dans elite2 tu pouvais mettre le cap sur une planete, accelerer le temps X 10000 et traverser la planete sans probleme ^^

Intrinsèquement LUA est quand même très limité.
On pourrait lui préférer Python même si il est plus gourmand et moins facile à utiliser avec plusieurs threads.
http://lua-users.org/wiki/LuaVersusPython

Un vauisseau spatial n'a en général pas une configuration aérodynamique. En tout cas, cela ne vaut pas vraiment la peine d'en tenir compte vu les capacités des moteurs pour les voyages spatiaux.
 

Déjà, les cons indiqués dans ton post. J'ajouterais alors :
- Pas de type entier. Seul le type float existe. De même, il n'y a pas de support pour les entiers de precision infinie ou pour les flottants de precision arbitraire integré.
- Pas de type liste ou tableau indexé par des entiers de base. Seul le type dico existe. Bonjour les perfs. Et puis de toute façon, il n'y a pas d'entié en lua
- Coertion implicite entre les string et les integer lors des operations arithmetiques. Ca pourrait être pire car l'operateur d'addition et l'operateur de concatenation de chaines n'est pas le même.
- Pas de coertion implicite entre les chaines et les nombres lors des comparaisons. Faut penser à être coherent quand même. Bon d'accord, faire la coercion dans ce cas aurait été une source de bugs immonde mais bon, il n'auraient jamais du la faire de toute façon
- Je n'aime pas leur façon de traiter le scope des variables globales/locales. C'est une grosse source d'erreur.
- La notion de weakreference n'existe que pour les clefs et les valeurs des tables. C'est assez bizarre comme concept. Et puis, tu ne peux donc pas faire un objet qui contient une partie de weakref et une partie de ref normales.
 

 
D'un autre coté, a vitesse x10000 tu ne sais plus trop ce que fait l'autopilote
 

 
+1

 
nan c'etait en vol manuel ^^
c'etait juste qu'entre 2 image on avait traversé la planête ( bon c'etait sur mon atari aussi, ca ramait à mort )

Au fait, je trouve bizarre que personne n'aie cité Crystal Space comme moteur 3D : http://crystal.sourceforge.net/tik [...] ticles.php

Il suffit que le vaisseau dispose d'un système antigrav et le problème est résolu
D'un autre côté, on peut avoir les deux: ceux qui ont besoin d'aérodynamisme parce que n'ayant pas d'antigrav, et ceux qui en disposent.

J'allais le citer quand j'ai vu Nebula Engine parce qu'il gère aussi le réseau, le son, etc... (c'est le premier moteur 3D que j'aie connu). Mais je suis pas sûr que ça soit le plus performant

 
Même si Python est un langage plus général que je n'hésiterais pas à utiliser dans d'autres applications plutôt business, il ne me parait pas vraiment adapté pour ce type d'application (embedded scripting language) pour lequel il n'a pas été créé. C'est d'ailleurs bien ce qui ressort des commentaires de ton lien. Plusieurs facteurs essentiels entrent en considération : la vitesse, la gestion mémoire, et la facilité de l'interfaçage avec le C++. Sur les deux premiers points, lua est réputé meilleur, et sur le troisième, c'est à vérifier, mais à parcourir les forums et le manuel, Lua a l'air pas trop mal équipé, ce qui est normal vu le but avoué. Ce n'est pas tout-à-fait un hasard s'il est populaire dans le monde du JV.
Python a bcp de fonctionnalités qui en font un bon langage de script généraliste, mais ne servent à rien dans un jeu: prenons l'exemple que tu donnes avec les nombres. Python a par défaut des nombres multi-précision, eux mêmes dans une classe nombres complexes. Dans un jeu, non seulement c'est totalement inutile, mais c'est infiniment plus lent que les double de lua, qui sont directement calculés par le processeur. De plus, si tu lis bien la doc, lua peut être compilé avec float ou int par défaut, plutôt que double, ce qui colle parfaitement avec un proc 32 bits.
De plus, la simple fonctionnalité des coroutines, qui permet de se passer de threads dans bien des cas, est un avantage évident pour un jeu. Le seul désavantage majeur que je vois à Lua / Python, c'est l'absence de débogueur qui permet de faire du pas à pas (mais bon, c'est interprété donc assez facile à déboguer quand même).
Enfin, d'expérience, le seul jeu auquel j'ai joué qui utilisait Python comme script engine est "Temple of Elemental Evil", et il était horriblement lent, même sur une machine performante. C'est p-ê dû à une mauvaise utilisation du langage plutôt qu'au langage lui-même, mais ça n'est tout de même pas très concluant. A l'opposé, Homeworld 2 tourne de façon très fluide, et Far Cry (je n'y ai pas joué) est plutôt connu comme une bonne référence dans le domaine.
 
Attention, je ne cherche pas à faire l'apologie d'un langage particulier ni à créer une guerre des langages, je dis simplement que 1) scripter une partie du jeu devrait aider à le rendre plus modulaire, 2) lua me parait adapté à cette appli, et probablement plus encore squirrel, vu que ce dernier langage dérive de l'expérience d'un JV créé en partie avec lua 3) pas mal d'expériences positives dans le monde du JV confirment cette impression.
Après, je te dirais que personnellement, ma philosophie est plutôt celle des langages statiquement et fortement typés que dynamiquement typés, et que je préférerais me lancer dans un truc en Ocaml qu'en C++ si j'avais le choix.

 
D'après pas mal de témoignages sur divers forums, Crystal Space serait plutôt à éviter pour les jeux vidéo.

c parti pour ogre 3d alors?

- Pour la vitesse, je n'y crois pas. Je suis aller voir le comparateur de langages cité dans la page LuaVsPython et il 'ma fallut 5 minutes pour gagner 33% de perfs sur un des tests en Python et 66% en Psyco. ( perfs étant le temps d'execution )
- Pour la gestion mémoire, le Python est avantagé car son mecanisme en refcount permet une desalocation mémoire plus proche de celle des langages a gestion mémoire explicite. Le GC n'a au final que peut de travail à faire dans un programme bien concu et donc il ne coute pas très cher. Le GC est d'ailleurs cité comme étant une des grandes faiblesses de lua
- Pour les coroutine, il suffit d'utiliser StackLess Python. Ou plus simplement le module greenlets qui parait-il permet d'ajouter les microthreads a n'importe quel environement Python avec un simple module d'extension en C
- Pour la liaison Python C++, il y a plein de choix de bonne qualité : boost pour le C++, SWIG pour générer du code automatiquement et Pyrex pour écrire du code dans un langage proche du Python et qui sera généré en code C directement utilisable dans un projet.
 
Pour la gestion des nombres Python, il faut remarquer que le langage supporte les 2 types de nombres : les 32bits et les precision infinie. Il n'utilise pas la precision infinie par defaut. Et je ferais remarquer qu'un fois que tu as compilé lua en mode int, tu ne peux plus utiliser des float et vice versa.
 
Oui, Lua est plus facile à intégrer à du code déjà existant que Python. Mais cela ne veux pas dire que pour un projet qui part de zero le Python ne soit pas beaucoup plus facile à utiliser. Et de toute façon, il faut bien admettre que le Python à part rapport au Lua un langage bien plus robuste, source de moins d'erreurs et bien plus puissant.

Juste deux citations de ton site :

 
C'est simple, l'un est fait dès le départ pour être embarqué dans des applis, l'autre est fait pour être un langage généraliste complet à part entière. P-ê que squirrel est la meilleure option, vu que c'est un espèce de mix entre les deux langages développé par un programmeur de JV pour ses propres besoins, avec aussi un compteur de référence épaulé par un GC.

 
Ca ne l'empeche pas de pouvoir être utilisé pour être intégré à un système. Ce n'est pas parcequ'un gars a essayé pendant 4 jours d'intégrer Python 2.3 avec boost.python alors que celui-ci ne marchais qu'avec Python 2.2 que ça en fait un mauvais choix. De plus, je peut montrer des succès story moi aussi : Eve Online utilise Stackless Python pour tout la logique http://www.eve-online.com/faq/faq_07.asp
 
Et en plus, c'est un MMORPG Elite Like. Si c'est pas adapté pour ce projet je ne sais pas ce qui l'est
 
Edit : marche -> marchais. La dernière version de boost.python necessite la version 2.3

Ok, Ok. Bon, c'est à étudier. Je ne vois que le test réel pour se faire une idée. Dans ce cas, la seule objection que j'ai est la lourdeur relative du langage, mais ça devrait rester assez mineur par rapport à l'ensemble du JV. N'écartons pas les possibilités, sachant qu'une fois le choix fait, ce serait très chiant de revenir en arrière. P-ê que squirrel est aussi une option à étudier, vu que c'est un espèce de mix entre les deux langages développé par un programmeur de JV pour ses propres besoins, avec aussi un compteur de référence épaulé par un GC.
 
ps : 'tain EVE online, ça a l'air de donner... démo en cours de download

Ca a l'air pas trop mal en effet Squirrel. Je bookmark car ça pourra me servir un jour. J'aime pas trop la syntaxe quand même
 
 
Au fait, sur un sojet completement different. Pour ce qui est du gestionnaire de projet à utiliser, il y a les bon vieux makefile ou la version upgradée avec autoconf/automake. Par contre, je n'aime pas vraiment ces outils. C'est pour ça que je suggère de jeter un coup d'oeuil à ça : http://www.scons.org/
 
Pour les fans de Java, il y a aussi ant mais bon, je ne dirais pas trop ce que je pense de l'XML comme langage de script ici

Argh, on ne peut pas tester EVE online, faut forcément passer à la caisse. Snif.
 
Dommage, parce que ça ressemble pas mal à l'idée du jeu (bon,je doute qu'on arrive un jour à faire aussi bien, mais bon...)

Si python est de la partie je veux bien proposer mon aide.

 
pour donner un ordre de grandeur, notre voie lactée est un disque d'environ 25000 pc d'une épaisseur de 5000pc en son centre.  
 
25000pc = 2.36*10^15m
 
Si on veut avoir un système de coordonnées avec un précision d'1 mètre, il faut employer un codage qui mémorise au moins 16 décimales.
 
Les doubles suffisent tout juste avec leur mantisse sur 53 bits.
 
A mon avis il vaut mieux se fendre d'un double système de coordonnées:
- au niveau galactique: en u.a (500 secondes lumière)
- au niveau local: en mètres (ou peut être moins?)

 
Je l'ai beta testé.
tu t'amuse une journée et apres c'est fini, y a vraiment rien d'interessant à faire à part miner

finalement, tous les jeux de rôles massivement multi joueurs sont pareils: ça finit toujours en gros billing. Je pense que c'est une mauvaise idée de se lancer là dedans.

   
J'ai l'idée qui tue, mais si je vous la dis je devrais tous vous tuer  

 
pas la peine , l'idee nous aura deja tuée

 
D'après les derniers échos de la filière sur EVE online dans la section Jeux PC, la version actuelle n'a rien à voir avec la version en beta test. Les échos sont positifs.

l'objectif premier, c'est un jeu solo
éventuellement multijoueurs (putain déjà qu'on dit qu'on a le temps, si on se lance dans le multijoueurs, on est cuits )

+1 pour le solo

 
J'aurais dû préciser que dans mon esprit, le système de coordonnées galactique n'est là que pour repérer les secteurs galactiques, donc n'a pas en fait une importance bien grande, c'est juste histoire de donner un peu de réalisme au jeu. Il faut bien évidemment un autre repère à l'intérieur d'un SG, repère qui lui, a une véritable importance.

 
 
Va faire un petit tour par ici: http://www.gamershell.com/news/17215.html

Quand vous entendrez parler d'un jeu révolutionnaire vous penserez à moi