Reprise du message précédent :

Pour ceux qui auraient une fausse idée du but à atteindre, je suggère d'aller relire le second post du topic qui donne une assez bonne idée de ce qu'on veut.
 
Par contre, pour la technique, c'est autre chose (enfin ya déjà un truc sûr: on se moque d'avoir truc maxi-beau, on veut un gameplay finement tuné).
 
Globalement, je suis d'accord avec DocMaboul, ça m'a toujours énervé de voir qu'on scripte à tout va (l'install de Visual Studio.NET est un excellent exemple tellement c'est lent). Un autre exemple, c'est l'utilisation d'IE pour faire des interfaces d'environnements de développement (toujours le même): CA M'ENERVE

Il n'y avait aucune vrai IA la derrière, juste des comportements scriptés pas les concepteurs des cartes. Ca fait illusion il faut bien le dire mais c'est de l'IA bas de gamme.

Et bien ça tombe bien, c'est exactement à ça que les langage de scripts sont les plus efficaces. On n'obtient pas forcement le truc le plus performant du monde mais :
- On a passé beaucoup moins de temps à le coder
- On a passé beaucoup moins de temps à le retoucher pour obtenir un bon gameplay

OK. Et pour FarCry? (vu qu'on peut attaquer depuis n'importe quel point, je sais qu'ils devaient se creuser un peu plus la tête pour obtenir un truc valable. Est-ce que l'IA des persos de FarCry est scriptée également?
 
Je suis pas chaud DU TOUT pour faire de l'IA ici, parce qu'on va se retrouver dans le même cas: l'univers est vaste et il faut prévoir un maximum de choses: via un script, ça va être lourd.

Mais ça ne va pas être lourd parce que l'on ne va pas mettre de calculs complexes dedans. Ou si un jour on y met des calculs complexes, on va très vite convertir ça en code natif utilisé par le langage de script de toute façon.

Une API en quelque sorte?
Ca me plait déjà mieux

Exactement. Il faut voir le langage de script comme ça en fait :
 
- moteur en C++ qui fait pleins de calculs lourds ( 3D, pathfinding, detection de colision, gestion de la vision )
- langage de script qui gère l'enchainement des evenements ( après l'animation A viens l'animation B, je viens de voir un ennemi que dois-je faire ? le pathfinding a échoué, que faire ? )

Donc, en gros, on utilise une VM , mais on s'en sert le moins possible.
Je n'ai jamais utilisé de langage de script, donc je peut difficilement juger, mais je serait plutot d'avis de n'utiliser le script que comme descripteur d'objet/evenement/etc, donc pas de VM.
 
Mais si on en utilise quand meme une ca sera pas un drame, à condition d'en limiter l'utilisation, à l'image d'ut2k4
 
On peut voter sinon

Pas exactement en fait. Le but est d'écrire beaucoup de code dans le langage de script, mais de passer le moins de temps possible à l'executer. Donc, en un sens on utilise beaucoup la VM mais on l'utilise très peu
 
La raison pour laquelle on veut écrire beaucoup de code dans le langage de script est simplement que celui-ci est général beaucoup plus puissant et simple à utiliser que du C++

C'est un peu le Côté Obscur de la Force donc: plus facile, plus prompt à te rejoindre dans tes développements, il faudra faire gaffe à ça et établir des critères précis d'utilisation (et éventuellement, faire des mesures pour savoir combien de temps on passe là-dedans )

 
C'est la que je suis pas trop convaincu
(je sens que ca va etre dur de contenter tout le monde )

 
oui donc, du XML.

 
Bien sûr, si vous n'avez pas besoin d'avoir des dimensions ou des vitesses cohérentes, il n'y a pas besoin de plus de 32 bits. C'est ce que la plupart des jeux font.
 
Maintenant si vous voulez un univers plus réaliste, j'ai déjà expliqué pourquoi 32 bits est insuffisant, je ne vais pas revenir la dessus.
 
Les performances c'est bien, mais ce n'est à mon avis pas le seul point sur lequel se focaliser. Sinon autant tout coder en assembleur. Rendez-vous dans 10 ans.
 
En revanche je suis plutôt d'accord en ce qui concerne le compilateur et les scripts.
 

 
Bien sûr, bien sûr.. mais attention à ce que cela ne devienne pas de l'anarchie.

bon y'a un truc à dire (rappeller) sur les flottants 64 vs 32 bits (juste comme ça)
 
1) tous les calculs se font dans le cpu. hors un cpu tout comme les cartes 3D et les cartes son, ont plus de précision dans les registres interne.  
 
ie que tu mettes des classes avec des float ou des doubles, le fpu travaillera à la même précision interne (qui est proche du double en général, tu as 3 niveaux, et sous windows le fpu est configuré avec une précision plus basse que linux, mais ça se change).
 
ce qui change c'est la consommation mémoire de la structure/classe, un poil plus de bande passante et y'a que le SSE2 qui fait du vectoriel en 64bits.
 
2) les cartes 3D ne travaillent qu'avec des matrices 4x4 en 32bits.  
 
3) Donc même si la position absolue est en 64 bits, pour la manipulation géométrique et les calculs de collisions se feront toujours en 32 bits, ce qui compte pour les collisions c'est manipuler les matrices pour éviter d'avoir une partie "translation" de chaque matrice avec des +1000000000000, pour que lorsque l'on fait l'inverse l'une on ait un +1000000000 et -1000000000000, qui certes théoriquement s'annulleront mais boussilleront aussi les calculs (donc modifier les matrices à la mano pour éviter de tout boussiller), ou avoir un système de positionnement avec position en double, et un quaternion pour l'orientation. (et donc pour les collisions, prendre le repère communs aux objets interressant et construire les matrices avec la position "moyennée" )  
 
donc bref, il faut pas paniquer sur les doubles DocMaboul.
 
my 2 cents

et le bus CPU est 32 bits donc 2 cycles pour faire voyager un flottant 64 bits

+1
 
On codera la position des objets en 64bits et on codera la forme des objets en 32bits. Cela devrait suffire largement puisque quand 2 objets collisionnent, c'est qu'en général ils sont assez pret les uns des autres.
 
 
Pour ce qui y est de l'usage des langages de script, je vais quand même faire remarquer que ceux-ci ne sont pas beaucoup plus lents que du C ( si on utilise un langage bien fait quand même ) et que de toute façon, à part quelques rares points comme le moteur 3D et le pathfind, il faut bien avouer qu'il n'y a pas grand chose dans un moteur de jeu qui coute cher en terme de CPU.

petit rapel pour les systèmes de coordonées
 

 
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?)

Perso, je vois plus un système avec des secteurs galactiques (mettons des cubes tout bêtes). J'aime pas l'idée des flottants et de leur imprécision
 
Donc par exemple:
* Secteur galactique;
* Système planétaire;
* Planète.
 
(oui, ça fait 3)

Faut pas exagérer l'impressision des floatants quand même. Moi je propose le même système qu'Elite II avec 2 niveaux :
* Secteur galactique;
* Système planétaire;

Bon, en fait on veut pousser vers trop de réalisme, et ça complique inutilement les choses (en bref, on s'en cogne que ça soit réaliste). Je rappelle donc que le projet de base, c'est de cloner Elite et de lui filer un coup de jeune, rien de plus.
 
J'ai encore quelques discussions en cours à ce sujet, je vais d'abord tâcher de les conclure avant d'arrêter un choix. Peut-être faudra-t-il repréciser les choses, comme de restreindre le réalisme justement.

 
ouais et ?
aaaah, ces newbzor qui causent a tord et a travers

 
montre nous la lumière  

 
un langage de script peut tres bien etre compilé

il est reviendu \o/

 
il est reviendu \o/
 
(non tu ne refourguera pas kenaz dans ce jeu )

 
vas chier .. et je pèse mes mots !
Vas jouer avec ton d3d !

bin oui mais pourquoi on se ferait chier à compiler?

 
ca avance bien les specs de se trouve, ou ca dégénère totalement en compil des envies de chacuns sans idées directrices ni limites ?

j'ai pas compris le début de ta phrase (là c'est moi qui tente de diriger, avec l'assistance de Harko et Mr Mala )

pffff, la fatigue :  
 
ca avance bien les specs de ce projet ?, ou ca dégénère totalement en compil des envies de chacuns sans idées directrices ni limites ?
 
ma question ct surtout : est-ce que ca marche la coordination ?
 
y'a des choses concrètes de commencées, ou vous attendez les specs finales ?

Les specs (en cours) sont dans le second post du topic, j'y travaille avec l'aide d'un peu tout le monde. Pendant ce temps, Harko fait mumuse avec des langages de scripts pour la customisation du jeu, et Mr Mala explore les méandres de moteurs 3D, actuellement Ogre 3D.

bon, qd ca compilera sous win, vous me ferez signe, je sign up our etre beta tester
 
PS : ah, non j'oubliais : qd vous modéliserez le sys éco, je pourrai pe aider un peu...

 
ha bon t'as un 486 ?

Non là j'ai un Athlon FX (mince, lui il doit avoir un bus 64 bits )

un pentium 1 de 1994 a un bus 64 bits.

 
Oula, je vois que els discussions vont bon train   ...
 
Ben en fait oui, c'est tout-à-fait ça mon idée.    
Peut-être me suis-je mal fait comprendre. Ceci dit, si certains pensent qu'elle n'est pas viable, c'est pô grave, hein, je vais pas en faire un caca nerveux, hein  . Le script peut tjrs être utilisé comme moulinette d'entrée des données, comme suggéré par DocM (ainsi que pour faire les écrans statiques). Le seul truc, c'est qu'évidemment, ça veut dire qu'il faut correctement définir à l'avance l'ensemble des classes décrivant les divers intervenants du jeu.
 
Pour ce qui est du débat 32-64 bits, j'ai tendance à penser comme DocMaboul que 64 bits ne sont pas nécessaires, et qu'il faut se démerder par référentiels locaux. Je peux changer d'avis mais il me faudra prouver le contraire.
 
Enfin, comme DocM, je pense qu'il faudra un architecte. Qui se dévoue ?  
 
(PS : quand à la "lenteur" de TA, faut relativiser un peu. Moi jai tjrs trouvé ce jeu étonnamment véloce compte tenu du nombre d'unité qui s'entretuent, surtout quand on voit comment sont statiques des jeux comme Warcraft. Quel bonheur ! Petit rappel : à l'époque, en 97, la limite était de 250 unités par camp. Pis avec quelques milliers d'unités, moi, je blâme le calcul du path finding, le script n'intervenant que pour l'affichage et l'IA)

 
potentiellement les deux mon colonel
 
et l'argument de la pseudo-lenteur avec les doubles, c'est un vrai-faux problème si utilisé uniquement aux bons endroits, on est en pleine pseudo-optimisation prématurée sur ce truc.
 

 
c'est quoi ça, l'architecte, un mec qui a un fait une grande école et qui a fait 3 semaines de C++ dans sa vie ? (petit troll envers les beaux termes)

 
Ben il était évident pour moi que les scripts étaient précompilées, pas du JIT. Je ne pensais pas qu'il fallait le préciser. Mais bon, je vais pas insister, hein...
 
bjone> bon, ok, je voulais dire, un "lead programmer" , qui prendra les décisions importantes.

Moi je suis pour les scripts qui s'executent pendant le jeu. Je parle un peu par experience ici.
 
Imaginez que l'on commence par décrire des choses en XML ( l'enchainement des animations et des effets graphiques par exemple ), très vite, on va se retrouver avec un langage de script codé en XML : on commencera par avoir besoin de faire des branchements conditionels, puis on aura besoin de fonctions, puis de fonctions avec paramètres, puis de structures de boucle etc...
 
Ca en deviens très vite ingerable, lourd, verbeux et très hermetique pour ceux qui veulent apprendre à s'en servir.

 
Je ne pense pas que DocM pense à un système comme ça, mais à qq chose de plus traditionnel, essentiellement en C++ (pour le jeu, pas pour les écrans statiques), avec une partie scriptée pour le chargement des modèles. C'est en effet une voie parfaitement valable, si ce n'est qu'elle impose dès le départ d'avoir une vision parfaitement claire du jeu et donc une doc détaillée absolument complète qui prévoit à l'avance la possibilité de toutes les évolutions possibles. Ce qui n'est pour le moment pas notre cas. j'ai lu qq part que les auteurs de worldforge (un framework de MORPG), par exemple, avaient une spec détaillée de 400 pages.
Juste pour savoir, c'est quoi, ton XP dans le domaine ?