Reprise du message précédent :
Si l'univers est vraiment vaste, on ne peut plus vraiment se permettre de le générer au complet. On aboutira alors sans doute comme dans Frontier à un générateur intégré au jeu et qui calcule les planètes uniquement quand on s'en approche.

Je quote ceci, j'ai oublié de l'ajouter dans les références la dernière fois qu'il a été posté.

D'un autre côté, si vous voulez une galaxie fixe une fois pour toute comme dans Elite, on peut en discuter. Je trouvais plus intéressant de générer une galaxie from scratch à chaque nouvelle partie, histoire de ne pas prendre certaines habitudes.

bin je vois toujours pas ce qui s'oppose a generer une galaxie != a chaque fois...

Mais on peut le faire aussi ça. Il suffit de changer de seed entre chaque partie et de sauver celle-ci dans la sauvegarde. Je ne vois pas c'est quoi le problème ( sauf si bien sur la generation de la galaxie est trop couteux en temps bien sur )

oui, biensûr, et il me parraît naturel de pas générer des choses inutilement (mais ça peut se "lazyfier" de manière fine et plus tard, ça ne doit pas être un gros centre de préocupation). ça veut aussi dire équation horaire pour l'évolution des planète qui n'ont pas encore interragi avec le joueur.

Note quand même. L'equation horaire pour placer les planètes devrait être valable même si le joueur interagit avec. On va considerer que la masse du joueur est negligeable devant celle des planètes

quel manque d'ambition dans la Science fiction moderne.

Disons que comme je le vois, il y a beaucoup de décisions aléatoires prises pendant la génération de la galaxie (pour générer son histoire). Maintenant, j'avoue que je n'ai pas encore d'idée précise sur l'exploitation de l'histoire en question, c'est plutôt à mettre en relation avec le scénario et le système de quêtes. C'est un truc encore à creuser. Il y a beaucoup à creuser sur ce terrain-là d'ailleurs.

Tant que ce genre d'interaction reste limité, c'est jouable.
 
Par contre, je ne veux pas être celui qui va coder la collision entre les planètes

l'aléatoire n'existe pas

 
au marching cube, a l'ancienne
 
(bah quoi, si on nage en science fiction, autant le faire pour de bon)

C'est pas tant detecter la collision qui me fait le plus peur que de simuler ce qui se passe après, tant visuelement que physiquement.
 
PS : tiens, il y a une nouvelle version de gcc en approche : http://www.osnews.com/comment.php?news_id=8788

 
Stait une boutade. Le marching cube a eut son heure de gloire dnas l'histoire de la demo a l'epoque ou le top du top c'etait les metaballs 3d
 

 
J'en profite pour dire que la version 1.0 de Squirrel est sortie et que devrait bientôt suivre la v2.0, qui inclura le support de classes et d'héritage simple.

drasche > t'es sûr que c'est utile de lier race et planète ? parceque y'en a 5/6 dont on sait pas où est la planète (dont les dysonians dont "personne ne sait où est leur planète" mais qui ont créé un truc autour de leur soleil).

http://www.google.com/search?hl=fr [...] rstructure
 
tu as confondu superstructure et infrastructure.
 
edit (parce que sinon ça va défiler) :
 
- le "générateur de champ interphasique" qui est rare mais y'a plusieurs modèles disponibles ; c'est pas intuitif comme situtation. Sauf dans le cas "d'objet de quête" (mais on est pas dans le même type de jeu).
 
- générateur d'énergie : précise bien ce que tu as en tête, parce que sinon, les réservoirs et le ravitaillement vont passer à l'as dans le jeu.
 
- l'ordinateur tactique, en réseau ça va être énorme (prévoir le coup du joueur).
 
- ça sert à quoi un hangar ?
 
- ça va être très "data-centric" et produire un bon volume de données, il faudrait peut-être évaluer la possibilité d'embarquer une bdd dans le jeu.

 
"data-centric" Le mot est lâché.

Effectivement, j'ai dû m'emporter  J'appelais superstructure la structure physique du vaisseau de base, sans aucun équipement.
 

Dans les faits, une fois que le champ interphasique est activé, ya plus besoin de détection de collisions (sauf quand on le coupe )
Ca pourrait faire l'objet d'une quête, ce genre de techno ne devrait en tout cas pas circuler dans la première moitié du jeu.
 

Je dois dire que je n'ai pas encore fini d'étudier la question, mais plusieurs types d'énergie entrent en ligne de compte. Et le générateur d'énergie électrique devra être alimenté par quelque chose (antimatière sûrement).
 

Bin pas plus que n'importe quelle IA, ce qui sera un rôle accessoire mais important de l'ordinateur tactique. Son rôle de base, c'est la gestion des équipements tactiques: armes et défenses.
 

A stocker des navettes. Tu me diras que la différence avec un cargo bay est minime, je me défendrai en disant que chacun est spécialisé: les hangars contiennent aussi le matériel d'entretien, et doivent "supporter" les phases de décollage et d'arrimage.
 

Rien que la galaxie elle-même va générer pas mal de données, d'où effectivement, une BDD ne serait pas de trop si on n'arrive pas à générer la galaxie à partir d'une graine.

Euh, pour la BD, j'ai peur qu'on arrive à une inflation de composans logiciels, déjà que les librairies qu'on n'utilise ne sont pas petites, entre le moteur 3D, la librairie de son, un éventuel moteur physique... C'est vraiment si on n'a pas d'autre moyen, hein. Quelques classes et scripts bien sentis devraient faire l'affaire amha. En tout cas dans les jeux du commerce, c'est comme ça qu'ils font. Parce que l'overhead à chaque requête à la BD, je le sens assez mal.

Muchacho > normalement, on arrive a avoir des perfs avec un truc style BSD DB, par contre, dans le cadre du dev, ça veut dire avoir du SQL partout (avec des string partout), inviter le problème de l'adaptation d'impédence, et surtout avoir un SQL qui n'est pas au bon niveau d'abstraction (puisque le niveau qui nous intéresse serait plutôt un truc style OQL, c'est a dire rechercher des objet à notre niveau d'utilisation, pas des données qu'il faut transformer en objet avant d'utiliser).
 
Par contre, avec une base, on gagne des transaction, de l'intégrité, des indexes, et, quand même, SQL.

Savez quoi? On n'a même pas encore commencé quoi que ce soit que j'ai envie de faire un port PalmOS  (bien sûr il faudra que ça soit super léger )

Pour le coup de SQL, j'émets quand même des réserves, ça me fait peur parce qu'on délègue à une librairie sur laquelle on n'a pas forcément un contrôle.

genre ? t'as plus de controle sur toutes les autres libs enoncée ?

non, mais au niveau moteur 3D, c'est indispensable, à moins que tu aies une envie incontrôlée de nous pondre un moteur 3D?

non, carrement pas

une bdd aussi c'est indispensable, +1 pour nraynaud la

surtout vu que le jeu c'est plus l'aspect interet que l'aspect graphique d'apres vos dires, non ?

Oui, absolument.

J'ai peur d'avoir été mal compris, je ne pousse pas forcément pour une BDD, j'apporte l'idée sur un plateau, de toutes façons on peut aussi choisir de pas décider, ont peut, par exemple démarrer le dev, l'introduire au moment du besoin de persistance (en la ségrégant), puis décider.
 
Par contre, le besoin de transaction et d'intégrité, lui, peut-être à la fois impérieux et invisible.
 
edit pour drasche :  
en faisant pas ça comme des porc, on peut retourner notre veste.

nraynaud, un jour il faudra que tu apprennes à parler à notre niveau parce que j'ai pas compris ta dernière phrase

ayé

il avait marqué quoi ?

ok
 
(désolé les mecs, j'aurais dû quoter )

ça parlait de separation of concerns et d'invertion des dépendances.

quand j'vous dis que j'lui ai tout appris à nraynaud

tu sors.

 
Ca a ses avantages, mais en même temps, y'a un truc qui me gêne un peu. Un des trucs que je considère comme important, dans un tel jeu , c'est la possiblité pour des utilisateurs d'étendre le monde, de créer des vaisseaux, des planètes avec des races, des tutorials, etc, voire même, -rêvons un peu -, de modifier certaines règles du jeu. On pourrait imaginer par ex. le développement d'un éditeur comme ceux qui viennent avec certains jeux de stratégie temps réel, qui permettrait de créer son vaisseau et de scripter certains comportements (le mvt d'une tourelle laser par exemple). Je vais passer pour un monomaniaque, mais j'en reviens tjrs au scriptage pour l'ensemble de la logique du jeu (d'ailleurs drasche, si tu veux porter le truc sur Palm, c'est de très loin la méhode là plus simple, à condition de dégager la 3D bien sûr).
 
Le pb de la BD, c'est qu'il faut créer le modèle de données à l'avance sous forme d'un ensemble de classes C++, et du coup, le jeu est figé, et nettement moins facilement extensible par la suite.
A moins que les requêtes SQL soient elles mêmes faites dans le langage de script, solution qui me parait sensée si celui-ci décrit toute la logique du jeu. De plus les facilités qu'offrent les générateurs et les coroutines, (des fonctions qui son interruptibles et peuvent être reprises par la suite) me paraissent tout-à-fait adaptées pour lancer des requêtes SQL et traiter les résultats de façon asynchrone.

muchacho > mais non on est pas obligé de figer tout à l'avance, demande à kadreg, son métier, c'est de stocker des modèles qu'il connait pas à l'avance dans une base de données.