Reprise du message précédent :
bon ça va, je retaille

En tout cas, c'est vrai que Elite 2 est mieux que le 3. Je ne sais pas pourquoi car le 3 est juste un addon du 2 en fait, et en plus il est moins repetitif mais ça ne rend pas pareil en fait
 
Voici quelques screens de frontier de plus tiens :
 
screens
 
C'est des exemples de systèmes dans frontier. Certains explorables, d'autres trop loins pour pouvoir le faire.

 

 

 
 si ca, ca donne pas envie d'y jouer

 
A ce propos : http://www.codercorner.com/Opcode.htm
 
harko> le script sert à plusieurs choses :  
1. implémenter et tester rapidement certaines options dans le jeu, ce qui permet de se rendre compte facilement de l'intérêt d'une règle sans tout casser et sans avoir à recompiler (essaye de compiler Ogre, tu vas vite te rendre compte de ce que je veux dire. Dès qu'on utilise la STL et les templates pour obteir des perfs, les temps de compile explosent),  
2. le rendre évolutif plus facilement : une fois le game engine développé, le jeu peut être entièrement développé et modifié via script. Cela permet des mods de la part d'autres personnes,
4. à faire les pages d'IHM (écran de présentation, d'options, etc) sans se prendre la tête.
5. on peut même imaginer d'offrir la possibilité au joueur d'automatiser certaines tâches via script.
(6. last but not least, apprendre un truc amusant à coder et susceptible d'être utile au taf.)
 
n bref, à faire gagner du temps et à rendre le jeu bcp plus ouvert qu'il ne le serait sans. Un des dangers qui guette un projet aussi ambitieux est, outre de ne jamais aboutir ,  de se transformer en monolithe ingérable et donc voué à l'échec. C'est ce qui risque d'arriver si une architecture n'est pas sérieusement pensée, parce que chacun va programmer dans son coin et rajouter sa part au gros paté. Si au lieu de faire un gros exec, on a (par exemple) un coeur scripté qui pilote des librairies, l'une chargée du moteur 3D, l'autre de détecter les collisions, la troisième du son, etc, on a probablement une archi bcp plus souple et facile à modifier si le besoin s'en fait ressentir.  
Jette un oeil à : http://www.gamedev.net/reference/l [...] egoryid=76
 
Enfin, je soupçonne fortement que le temps CPU ne sera guère dépensé dans le script, mais bien dans la 3D et la détection de collision.

 
ogre utilise ODE qui utilise OpCode  
 
J'avais essayé d'utiliser opcode avec de l'opengl, ca marchait super bien jusqu'à ce que je rajoute une rotation, jamais compris pkoi, et ceux à qui j'ai demandé non +  

 
Euh, tu es sûr qu'ODE est inclus dans Ogre ? J'avais plutôt l'impression que c'est une espèce d'add-on (même si dans les démos, il y en a une avec une balle qui heurte une pyramide de cubes).

C'est envisageable une lib de grands nombres pour résoudre les problèmes de coordonnées? (question perfs surtout) non? bon on s'organise par secteurs alors?

Opcode est une librarie de détection de collisions.
ODE est une librarie de physique, qui utilise Opcode pour effectuer la détection de collisions avec un type d'objet particulier, les tri-mesh (triangle meshes).
Ogre utilise ODE pour la physique, mais ODE est bel et bien un moteur de physique indépendant d'Ogre. Par exemple Stalker utilise ODE.

 
C'est pour cette raison que j'avais émis l'idée des Secteurs Galactiques (voir mon post page 14). Ca facilite les choses tout en gardant la cohérence du jeu. De toute façon, une simulation vraiment réaliste d'exploration spatiale n'est ni envisageable, ni à envisager, tout simplement parce que les dimensions sont tellement importantes que les possibilités de rencontres seraient infinitésimales -> jeu où il ne se passe rien. Par conséquent, l'essentiel de l'action devrait se faire à proximité de planètes et de vaisseaux-colonies.
Au fait, j'avais rajouté un paragraphe sur le minage il y a qq jours. Faudra que je te l'envoie. Pis j'ai commencé à réfléchir sur un système de jeu (j'en ai décrit un début dans un précédent post).

 
Je ne voudrais pas faire mon rabat-joie mais j'ai de GROS doutes à ce sujet.

Tout dépend de la façon est utilisé le script, mais sachant que de très nombreux jeux ont des parties scriptées pendant le gameplay, par exemple FarCry, Unreal 2004 (UnrealScript), un paquet de RTS comme Total Annihilation (tous les mvts des unités sont scriptés...) ou StarCraft, Quake, Homeworld 2, etc. Or tous ces jeux tournent pourtant très bien, et souvent d'autant mieux que la carte graphique est de qualité. J'en conclus que bien utilisé, le script n'est pas le goulot d'étranglement, le temps CPU est essentiellement dépensé ailleurs que dans la partie semi-compilée. De toute façon, si une partie du code est mesurée trop lente, elle peut être facilement réécrite en C++, une fois que l'algo a été testé en script.

 
Il faut s'entendre sur ce que l'on nomme script. Si c'est juste un fichier de paramètres évolué qui sera digéré par un bousin compilé, alors c'est sans souci. A mon avis, c'est ce qu'ils nomment "script" dans les jeux sus-mentionnés. Par exemple, si vous scriptez votre carte de RTS pour que lorsqu'on passe à tel endroit il se passe quelque chose, quand le jeu charge la carte, il crée des objets C++ ou les structures C qui vont bien avec ça (CEventOfMyGameOfTheProut par exemple).
 
Si, par contre, c'est réellement du code qui sera parsé, interprété et exécuté par une VM, c'est se foutre un bousin qui va tourner de 10 à 100 fois plus lentement qu'un bon compilé de chez bien optimisé. Au lieu d'avoir du 100 à 200 fps, ce sera du 10 à 20 fps dans le meilleur des cas. Comme vous avez parlé de ne coder en C++ que le moteur 3D et la gestion des collisions, je pense qu'il s'agit plutôt de cette dernière option. Je ne vais pas y aller par quatre chemins: ce genre de coding, je trouve ça répugnant.

Doc, c'est bien du premier cas qu'on parle
Cependant, Muchacho dit bien que le second cas peut intervenir pendant le développement du jeu, mais en aucun cas dans une release du jeu

 
Je n'en suis pas si sûr ou alors il me faut une explication de texte sur ça:

Je suis sûr qu'il s'est un peu emporté
Ceci dit, c'est une caractéristique commune à plusieurs bons jeux d'avoir la personnalisation des objets embarquée dans des scripts (qui sont grosso modo des initialisations, pas d'algorithmes là-dedans)

 
Je ne sais pas exactement comment les parties scriptées sont utilisées et je suppose qu'il y a autant de manière différentes qu'il y a de jeu.  
Pour TA, par exemple, http://www.planetannihilation.com/ [...] t_01_3.asp
C'est p-ê bien juste une prédigestion.
Pour FarCry, j'ai déjà posté un texte qui détaille l'utilisation de Lua.
Quelque soit l'utilisation, le choix a dû faire gagner du temps.
J'ai bien compris que vous êtes un puriste du C et de l'optimisation. C'est très bien, mais ce n'est pas tout, le but étant de sortir qq chose de jouable et d'extensible (dans mon esprit en tout cas). Personnellement, j'aime les jeux bien écrits, mais je ne vois pas ce qu'il y a de répugnant à mettre qq chose de lent là où la vitesse n'est pas nécessaire. (Je dis ça après avoir vu plusieurs projets dans ma carrière entièrement écrits en C++ et qui se sont transformés en monstres indémerdables, ce qui m'a fait pas mal changer mon point de vue sur l'optimisation.) pour moi, le point le plus important à garder en tête, c'est d'avoir un jeu ouvert.

 
Oki

mmm, j'ai quand même un doute...la 3D et la détection de collision, on peut les optimiser. la partie scriptée, on peut pas, car dépendante d'une VM sur laquelle on n'a aucun controle (à part écrire soi même le code en bytecode, réduisant du même coup l'intéret du script à néant)

et merde, grilled

 
Dans un jeu, la vitesse, c'est un poil critique parce que si le jeu rame, le plaisir en est gâché. Vous parlez de TA et c'est le parfait exemple. J'avais bien aimé ce jeu et j'ai eu envie il y a peu d'y rejouer. J'estime ne pas avoir une machine merdique pour faire tourner un jeu qui va bientôt avoir 10 ans (512Mo de RAM, une GeForce3, un disque SCSI et un athlon 1400). Pourtant, dès qu'il y a un peu trop d'unités sur la carte, il se met à ramer.
 
Pour le reste, un projet qui foire, c'est un projet qui a été mal pensé, mal architecturé et, au final, mal codé. Ce n'est pas une question d'optimisation mais de réflexion sur ce que l'on veut obtenir, les moyens pour cela et les coûts de ces moyens. Le script interprété, cela coûte peut-être peu en terme de développement mais je doute fortement que cela soit un choix viable. Je voulais juste exprimer mes réserves à ce sujet d'autant plus que si on veut faire un mode multi allant au delà de quatre joueurs, il faut avoir une architecture qui supportera les calculs nécessaires pour une dizaine ou une vingtaine de joueurs. Autrement dit, même dans l'éventualité où cela reste "raisonnable" pour un joueur, je doute aussi fortement que cela reste "raisonnable" lorsqu'il s'agira d'avoir à gérer 10 ou 20 joueurs.

En plus, c'est pour scripter des caractéristiques d'objet et compagnie, donc des valeurs, qui seront lues au chargement, le script n'intervient plus trop en phase de jeu propremement dite, je pense que vous vous faites du mourron pour pas grand chose
 
Pis j'ai entièrement confiance en vos capacités d'optimiseurs fous que vous êtes
(d'ailleurs, vous pourriez optimiser l'interpréteur de script )

Il me semble que ut2k4 a une VM non? , pour interpreter du UnrealScript? Cela dit, seule une petite partie du code doit etre interprétée je pense, genre les petits mods server side

 
Si c'est cela, encore une fois, aucun problème. Si c'est du code, par contre...
 

 
La dernière fois que j'ai travaillé sur un projet où l'on a décidé de bien optimiser une machine virtuelle, on a fini par supprimer la VM et coder un générateur de C++

 
Je viens de regarder un doc là-dessus et, si j'ai bien compris, ils ne gèrent via le script que les évènements clés et évitent au maximum de passer dans le script.
 

 
http://unreal.epicgames.com/UnrealScript.htm
 
A mon avis, il faut étudier attentivement ce qu'ils ont fait et voir quels sont les perfs de squirrel en comparaison (à moins que quelqu'un se sente de coder un bon compilo, un GC, une VM et un runtime en plus de l'interfaçage du bousin).

 
quake3 avait déjà une vm, avec laquelle il était possible de développer des mods cross platform (qui marchent tels quels sous nullix et windaube)

Unreal premier du nom utilisait déjà UnrealScript pour toute l'IA des unités et pour régler toutes les animatiosn et leur enchainement etc...
 
Pour ce genre de taches, rien ne vaut un bon langage de script souvent de bien plus haut niveau que le C++. C'est comme pour la programation GUI.
 
Et pour info, il ne suffit pas de constater que TA rame quand il y a beaucoup d'unités pour automatiquement dire que c'est la faute de leur VM de scripts

Pour répondre au probleme, j'ai longtemps utilisé LUA pour des petits moteur de plugin dans des applis perso.
 
Recemment j'ai bidouillé un plug-in pour Diablo II qui utilise LUA pour rajouter des features dans le eju original. Moralité, la perte de FPS etait de l'ordre de 33% sur un jeu en 2D :-/
 
Par contre en utilisant du LUA précompilée (le LUB), la perte tombe à 5%, ce qui etait quasi négligeable.
 
 
DocMaboul à raison, il faut BIEN faire attention aux parties scriptées.

 
Bon, s'il y a bien une chose dont j'ai horreur, c'est d'avoir à me battre afin de faire des choix techniques raisonnables et sensés pour me retrouver au final dans le rôle du vieux con qui fait chier son monde. Compiler, c'est lourdingue, ça prend du temps? Tout scripter à part la 3D et les collisions, c'est top moumoutte délire over-méga-fun? Il faut donner du 64bits à bouffer à sa bécane pour coder une galaxie? Soit.
 

Je n'ai jamais dis le contraire aussi. Les profilers c'est pas pour les chiens "Remember : premature optimisation is the root of all evil"
 
Mais de toute façon, il y a une chose ou les langages optimisé enfoncent au niveau perfs tous les langages compilés standards : les microthreads. Allez faire plusieurs millions de context switch par seconde avec un langage compilé et on en reparlera

J'ai l'impression de très mal comprendre l'utilisation que veulent faire certains du scripting externe !
Dans mon idée, les scripts devaient servir à décrire des objets, des trucs, des brols divers ainsi que leurs comportements ( genre : race "machin" - type "commerçants" - négociation 18 - ruse 19 - honnêteté .. - aggressivité - .. ... etc etc .. ) ... jamais des pans de code entier à l'extérieur du moteur ! ...
Ces scripts sont chargés et traîtés UNE SEULE FOIS au démarrage .. puis fini !
NON ????

 
Au lieu de dire "moi j'ai raison, vous avez tord, vous n'y connaissez rien", pourquoi tu n'expliques pas clairement ce que seraient tes "choix techniques raisonnables et sensés" ?
 
Tu ne peux pas accepter que d'autres aient un point de vue différent, sans qu'ils soient foncièrement dans le faux ?
 
Vous allez être combien de développeurs sur ce projet ? 10 ? Vous allez avoir 10 visions différentes de ce que devrait être le jeu et de comment le développer. Si ça commence comme ça, je ne parierai pas sur vos chances de succès..

Faut pas perdre de vue qu'on veut faire un jeu libre et ouvert aux modifications, et le script est la voie royale pour ce genre de choss (sans compter que c'est un concept largement éprouvé et approuvé par la communauté des joueurs/moddeurs).

C'était mon idée aussi mais si maintenant on vient dire que l'IA est scriptée, je trouve ça un peu lourd

IA scripté = balle dans la tête de suite
 
le "script" doit rester une maniére souple et rapide de specifier des CARACTERISTIQUES des objets du jeu. point.

Bon, je vais MP DocMaboul parce que je pense qu'il a réagi un peu vite

Pourquoi ? Unreal premier du nom y arrivait bien sur un K6-2 300 MHz.

En même temps, tu parles d'un jeu qui n'a pas besoin d'une IA transcendante
 
Qu'en est-il de celle des Marines de Half Life?

Que du script, aucune IA. Par question de politesse, je demanderais à ce que vous arretiez d'appeler la chose qui sert de cerveau aux marines de HL une IA merci d'avance
 
Deus Ex premier du nom avait tout le comportement des pnj en UnrealScript aussi. Et les bots de UT2004 sont en UnrealScript.

 
Oh ce n'est pas du tout la manière dont je vois les choses. On est en démocratie et en démocratie on débat, on discute, on est tous égaux, ton point de vue vaut le mien, et patati et patata. Maintenant, vis-à-vis du code, on est pas tous égaux, loin de là. Coder en 64 bits les coordonnées sous prétexte que l'univers est grand, ça me hérisse déjà le poil. Qu'est-ce que vous voulez que je vous dise et que j'argumente vis-à-vis de ça? Des choses désagréables? qu'il n'y a pas eu d'analyse sérieuse, qu'on peut trouver mille et une manière de rester en 32 bits, qu'on a pas besoin de cette précision, qu'on fout ses perfs en l'air en procédant ainsi? Je n'ai pas envie d'être désagréable, ni même d'avoir raison. Ce que j'aime, c'est le travail bien fait et tant pis s'il faut se faire mal au cul pour y arriver. De toute façon, il faut se faire mal au cul pour pondre du beau boulot. Un autre point qui me hérisse le poil, l'argument comme quoi compiler, c'est long, c'est chiant, tout ça tout ça. Quand j'ai commencé dans l'info, on déposait ses fichiers sur un serveur dédié pour la compilation le soir et, avec un peu de chance, on avait le résultat le lendemain matin en arrivant. Forcément, ça me fait mal aux fesses de voir des devs qui aujourd'hui compilent toutes les 2 minutes à chaque fois qu'ils ont changé trois lignes dans leur code histoire que le compilo vérifie ça et réfléchisse à moitié pour eux. Ce qui m'énerve dans tout ça, c'est le gâchis. Certes, on n'a pas les mêmes bécanes qu'il y a dix ans mais ce n'est certainement pas une bonne raison pour faire n'importe quoi. Je me dis que vous auriez eu à coder ça il y a dix ou vingt ans, vous n'auriez certainement pas procédé ainsi. Ce n'est pas parce que nos ordinateurs sont puissants qu'il faut faire n'importe quoi avec cette puissance, tout comme ce n'est pas parce qu'on a un jour 30 000F sur son compte en banque qu'il est judicieux de les dépenser n'importe comment. On peut en avoir besoin ailleurs et comme dit le dicton, qui veut aller loin ménage sa monture. Mais bon, bref, on est dans démocratie et je ne vais certainement pas jouer peu ou prou le rôle du dictateur et du chieur de service, d'autant plus que je ne veux m'occuper que de l'éventuelle partie réseau.
 

 
Dans un porte-avion, il y a des centaines de matelots. Ca ne l'empêche pas d'avancer. Tout ce qu'il faut, c'est un capitaine pour donner le cap et que les matelots acceptent son autorité. Même en démocratie, il y a un président.

Pourquoi?  Il paraît qu'ils étaient d'une redoutable efficacité.

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