Reprise du message précédent :
Certes non, mais j'ai vu la news sur flipcode. Pour le moment je suis assez privé de mes outils de devs, et jme suis un pue éloigné de la 3d au profit du script (enfin, script pour de la 3d, quoi). Enfin voila.

une fois le rendering de planètes avec rentrée en atmosphère et atterrissage résolus, on pourra s'attaquer à ceci: http://users.rcn.com/jasp.javanet/dyson/
 
ça vous tente?

Mise à jour du document de référence. Je l'ai remanié complètement, il commence par le game design générique que j'avais rédigé au début, mais il est largement étendu et complété par l'analyse. Manque encore pas mal de choses comme la navigation, le pilotage et un arbre technologique de référence détaillé  Mais dans les grandes lignes, je pense que tout est là
 
J'ai introduit la notion de quêtes (cfr Space Traders), je ne pense pas que ça existait dans Elite.
 
http://www.nightwing.easynet.be/fi [...] gn.rtf.zip (rich text format)
http://www.nightwing.easynet.be/fi [...] Design.sxw (OpenOffice.org Writer format)
 
Si vous ne savez pas quoi faire de votre vendredi, bonne lecture

Il y a un truc qui me dérange au niveau des rétrofusées, c'est le fait que c'est le nom même de rétrofusée est utilisée à mauvais escient. En effet rétro signifie "en arrière", ce sont donc des fusées destinées au ralentissement de l'appareil.  
 
Sous Elite il y avait 2 propriétés essentielles dans les moteurs : l'accelération et la décélération. L'accélération était généralement supérieure car elle s'appuyait sur les moteurs principaux et la décélération inférieure car elle était réalisée par les rétrofusées placées à l'avant de l'appareil. Le pilote automatique utilisait ces 2 types de moteurs pour amener le vaisseau à bon port, cependant le joueur avait la possibilité de désactiver le pilotage automatique, de retourner le vaisseau dans le sens inverse de la marche et d'utiliser la puissance des moteurs principaux pour décélérer plus rapidement. Je pense que ça serait pas mal de garder cela car ça rendait le pilotage plus intéressant.

Pour ça je propose tout simplement d'abolir la difference de performance entre les moteurs principaux et les moteurs secondaires ( retro fusées et moteurs lateraux ). Cela n'en vaut pas trop la peine il faut bien dire.

Mouais, en fait, si j'avais dû l'exprimer en anglais, j'aurais utilisé le terme "thruster", et même "manoeuvering thruster", mais je n'ai pas trouvé de traduction convenable  Pour moi, il n'y a pas de moteur principal ou secondaire à ce niveau: ces réacteurs servent à exécuter de petites manoeuvres comme l'amarrage.

Moteurs ou fusées d'appoints ?

Moteurs est trop générique Mais fusées d'appoint conviendrait certainement mieux

Je viens de tester OpenSceneGraph et en particulier la demo bluemarble et il n'y a pas à dire, c'est un très serieux candidat pour un projet pareil
 
PS: je parle de ça pour ceux qui veulent tester par eux mêmes : http://www.andesengineering.com/BlueMarbleViewer/
 
PPS: non on n'a pas forcement besoin de créer des textures des 400Mo pour chaque planète. Ce n'est pas obligatoire car on peut tricher avec des générateurs qui calculerons les textures à la demande.

ah bin perso j'aime autant et c'est une des idées de départ: avoir un truc assez compact
 
bon, je pompe tout ça et j'essaie

Bon, en passant, je suis aussi un peu sur la création de quelques civilisations, et votre créativité ne sera sûrement pas de trop. Alors si vous avez des idées, balancez
 
Le but, c'est de les intégrer au système de quêtes, afin de créer une vraie aventure au milieu du jeu. Pour ceux qui n'ont pas lu ou seulement survolé le document de game design, je rappelle que ce système des quêtes n'a rien d'obligatoire: tant que le joueur ne s'y intéresse pas, le jeu restera un pur Elite. Si par contre il veut se lancer, le jeu prendra une dimension supplémentaire.
 
Voici ce qu'il y a sur le feu pour l'instant (extrait du document de game design):
 
The Watchers (inspiré par vous-savez-qui)
Ceux qu'on dit avoir vus sur Terre. Ils disposent de vaisseaux dont la forme est universellement connue: des soucoupes. Tous leurs vaisseaux sont basés sur cette forme, qu'ils soient de reconnaissance, patrouilleur, transporteur, vaisseau de guerre. Ce sont ceux qui observent les civilisations “ en bas âge ”. Personne ne se rappelle quelle est leur planète d'origine, qu'ils ont quittée depuis longtemps pour explorer la galaxie.
 
The Persecuted (inspiré par un épisode de Dragonball Z, non j'ai pas honte )
Ils voyagent à travers l'espace et n'ont plus de planète mère, détruite par une race belliqueuse aujourd'hui disparue. Comme ils ignorent ce dernier fait, ils voyagent à bord de vaisseaux dit “ miroir ”, et se fondent dans l'infini sans pouvoir être détectés à vue d'oeil. On dit qu'ils sont paranoïques, à cause de la crainte de se retrouver face à ceux qui ont tenté de les annihiler. Leurs vaisseaux sont généralement de forme oblongue.
 
The Locusts (inspiré par... Independence Day)
Ils voyagent à travers l'espace depuis tellement longtemps que nul ne se rappelle d'où ils viennent. Ils sont la plaie de la galaxie. Ils voyagent de planète en planète pour en utiliser les ressources jusqu'à épuisement, puis ils vont ailleurs. Ils sont si puissants qu'aucune planète n'a pu leur résister jusqu'à aujourd'hui.
Tous les leaders craignent que leur monde soit le suivant. Et bien entendu, tout le monde les évite comme la peste. La présence de leurs éclaireurs dans un système planétaire est considéré comme un très mauvais signe.
 
The Dysonians (inspiré par la théorie de la Sphère de Dyson)
Cette civilisation est peu connue et personne ne sait où trouver leur planète. Certains racontent qu'elle connut son heure de gloire il y a plus de quatre mille ans et fut ensuite vouée à l'extinction. Personne ne pourrait même dire à quoi ils ressemblent.
En réalité, nul ne sait que les Dysonians sont les créateurs de la plus impressionnante construction stellaire: une sphère qui englobe leur système et leur soleil. Les Dysonians vivent sur la face intérieure de la Sphère. Celle-ci pose un danger pour les vaisseaux qui s'en approchent: elle génère un formidable champ de gravité, et il vaut mieux être bien équipé pour compenser la puissance de ce champ. Les Dysonians sont sans doute la civilisation la plus avancée de la galaxie.

Ça ne vous dirais pas de commencer à coder plustôt que de rajouter encore plus de features ?

 
ben on a pas encore décider quel moteur utiliser, ni réglé la question des scripts
 
je suis en train de d/l OpenSceneGraph, effectivement ca a l'air pas mal

que viens tu de dire la, malheureux, tu vas te faire echarper par la crew pensante de ce topic.
 
Tant que la feature liste n'aura pas la taille du botin de paris, fo continuer a en rajouter

Les choix techniques définitifs, il me semble qu'on peut les faire, mais il faut les faire en connaissance de cause en ayant examiné toutes les possibilités. Et là, ce n'est pas moi qui choisirai, je laisse ça à ceux qui s'y connaissent.
 
Que rien ne vous empêche d'expérimenter et de partager ici vos conclusions
 
Mais perso, le game design n'est pas fini, il serait imprudent de commencer à coder sur le projet proprement dit avant cela.

c'est mal parti si personne ne cherche à coder....

Bah non justement. Commencer à coder seulement après que le gamedesign soit fini est une grosse erreur pour pleins de raisons que je vais ennumerer ici :
- le gamedesign n'est jamais fini
- même quand le gamedesign est fini, on trouve toujours des trucs à changer ( cf point 1 )
- avoir un gamedesign de la taille d'un botin et sans une seule ligne de code est le meilleur moyen de ne jamais avoir une seule ligne de code
- le code ne pourra de toute façon jamais s'adapter exactement au gamedesign. Il faut donc faire avancer les 2 en plus ou moins même temps pour que chacun tienne compte des contraintes de l'autres. Faire avancer le gamedesign seul est le meilleurs moyen d'avoir à en jeter la moitié par manque de temps ou par impossibilité à coder/dessiner le truc

Dans mon expérience, vouloir faire avancer les 2 en même temps est la première raison pour laquelle on perd du temps, je le vois tous les jours

Ben je pense que maintenant on a une bonne idée de ce qu'on veut faire, donc on peut au moins choisir le moteur graphique et le bidouiller un peu

Tu noteras quand même qu'aucun d'entre nous ( enfin je crois ) n'a d'experience de gamedesign. Ce serait sans doute suicidaire de se lancer dans un gamedesign complet sans pouvoir faire des experiences pour voir si les features demandées sont fun à jouer. Et puis, si on entrelace le dev et le gamedesign, cela nous permet implicitement d'avoir des étapes intermédiaires "jouables" qui pourront faire de la pub et attirer plus de force de travail.
 
Sinon, il faudrait voir comment Wesnoth a été organisé. Ils ont presque atteind une version 1.0 à ce que je vois ce qui est pas mal pour un jeu libre créé de toute pièce.

 
  merci, grâce à toi j'ai découvert Wesnoth, ca a l'air super  

Disons que j'assimile le game design à une analyse classique, ce qui, il est vrai, n'est pas exact. Au travers de mes lectures, j'ai vu que le game design consiste à créer une ligne directrice plutôt qu'une spécification complète et précise, afin de laisser de la marge à ceux qui vont donner vie au jeu.
 
Maintenant, tu nous montres un exemple de jeu libre, mais qui n'est pas comparable: c'est un jeu de stratégie 2D au tour par tour, assez simple à réaliser à mon sens (à part l'IA comme toujours). Or, on veut ici créer une simulation de commerce spatial en temps réel avec des morceaux de jeu online persistant dedans, c'est un tout autre défi!
 
Je ne dis pas qu'il faille attendre d'avoir créé toutes les civilisations avant de commencer à coder mais je n'ai pas encore pu coucher toutes les règles par écrit, et ce point me semble primordial (a priori, cette partie n'est pas scriptée).
 
Ceci dit, qu'est-ce qu'on peut commencer à coder? (je sens votre impatience, je ne vois pas de raison qu'on n'en discute pas maintenant )

Il y a déjà pas mals de trucs que l'on peut commencer en fait :
- environement de dev ( makefile/scons/ant ? cvs/svn ? etc... )
- infrastructure de base ( gestion d'accès aux fichiers, traduction etc... ) Je suggère de jeter un coup d'oeuil à physicsfs pour les formats d'encapsulation de données et pour les accès disque.
- moteur son. Celui-ci ne mange pas de pain mais n'est pas fondamental. Le code produit maintenant ne sera probablement pas perdu par contre alors si qq veut se lancer la dedans. L'usage de OpenAL est fortement recommandé pour avoir accès au son spatial 5.1 de façon multiplateforme
Et bien sur :
- moteur 3D si on se met d'accord sur l'echelle du jeu.
 
D'autres idées ?

OpenAL est un premier choix pour la gestion du son, je pense bien que ça sera lui qui sera utilisé
 
Pour PhysicsFS, ça m'a l'air intéressant, mais il faut tester tout ça!
 
Il faudra aussi de bonnes libs pour gérer le calcul fractal (génération de textures par exemple).
 
Pour l'environnement de dev, je préfère makefile  pour le versioning, pas de préférence.
 
Qu'entends-tu par l'échelle du jeu? La taille de la galaxie?

Nan, seulement la taille d'un système solaire en fait Il est très probable que le moteur 3D aie à dessiner les objets stellaires du système courrant, et il est très improbable qu'il aie besoin de dessiner les autres étoiles de la galaxie en fait.
 
PS : scons c'est bien, automake/autoconf c'est mal !

Au niveau de la spécification : j'ai jamais fais de gamedesign, (donc mon point vaut ce qu'il vaut), mais un minimum de spec est nécessaire. Ne serait-ce que pour savoir quoi coder : définition de la hiérarchie des classes/structures représentant les éléments du jeu, etc.
Et pour avoir ces définitions, on a pas d'autres choix que de spécifier un minimum de trucs.
 
Comme alternative à OpenAL (qui n'est utile à mon avis que si on se penche pour du 5.1 ), SDL fournit via SDL_mixer une librairie pour gérer le son assez sympathique.

Bin j'ai jamais fait de game design non plus, je m'appuie surtout sur ma formation d'informatique de gestion et mon expérience de programmeur. Mais comme je le disais quelques posts plus haut, le game design est un peu différent, je tente de m'adapter  Par exemple, je vais tâcher d'éviter tout ce qui peut être ajusté par les scripts, comme régler la difficulté du jeu et autres paramétrages.  Au moins, je tâcherai de définir justement, qu'est-ce qu'on mettra dans les scripts, et que n'y mettra-t-on pas.

 
Je pense aussi qu'il va être temps de commencer à coder, vu que depuis quelques pages, on ne fait que tourner en rond. Mais les choix techniques n'ont tjrs pas été faits. Et ça, je vois mal comment on peut y échappper.
 
edit : ah ben je vois que les bonnes questiosn sont déjà posées. Une qu'il faut ajouter en priorité est : sur quel serveur de projets ? Perso, j'opterais bien pour un serveur qui fait du svn si y'a moyen.

Pour l'instant, la seule chose bien arrêtée, c'est le langage: C++  Pour le reste, on attend un retour d'info et des choix de la part de Mr Mala et Harko à propos des moteurs 3D et langages de scripts (mais plusieurs avis, ça serait bien aussi)

Update du game design (cfr second post):
* nouvelle civilisation (the Idlers, qu'on pourrait traduire par les Branleurs)
* ajout des opérations effectuées par le vaisseau du joueur (gros morceau )
 
Au niveau features, ya rien de nouveau (j'avais à peine oublié la notion de forage et de vaisseau auxiliaire mais c'est réparé)

Je tilte un peu à la bourre mais avec ce qu'il y a dedans, vous devriez avoir de quoi commencer à coder sérieusement
 
sauf gros oubli de ma part, je pense que tout y est, à part la description du déroulement d'une partie

up
je vous ai fait peur ou quoi?

Je regarde ton swx demain pour dire ce que j'en pense

OK, je risque d'en uploader une nouvelle version d'ici demain, j'ai déménagé le dernier chapitre pour le placer en seconde position, raccourci le sommaire pour ne faire apparaître que les points jusqu'à 3 chiffres, et ajouté une petite précision au début pour le cas où certains auraient des doutes sur un certain aspect de ce projet que je tente d'élaborer

Ok  

Voilà, update effectuée, rien de changé au niveau game design lui-même, juste les modifications énumérées un post plus haut.

bin quoi?
ya pu personne?
 
up

Arf, l'imprimante était down hier (plus de toner noir, c'est con ).
 
Bref, j'me suis bien fait chier en cours de management
 
Je lis ça dès que je peux (accessoirement, dès qu'on aura racheter un toner )

 
 
Si si, j'ai commencé à lire ton rtf de game design dans le bus.
(si tu voulais bien ajouter C++ et script a coté de mon pseudo, ça serait sympa, merci)
J'ai quand même une objection sur le fait qu'il n'y aurait pas de limites au domaine d'exploration, selon tes propres mots. Euh, comment comptes tu implémenter celà ? Je ne vois pas comment rendre ça techniquement réalisable.

ah ouf, je savais bien qu'il restait 2 ou 3 motivés

OK

Bin ça rejoint un peu la discussion du début à propos de la concrétisation de la galaxie, je suis conscient que ce n'est pas un truc évident à réaliser  Mais c'est un truc dont j'avais fort envie au départ: une totale liberté de mouvement.

perso je te conseille plutot de séparer les deux.
svn sur berlios c'est un peu bof, tu prends svn sur opensvn.csie.org, ca passe par webdav. Et du coup pour le gestionnaire de projet t'es moins emmerdé