Reprise du message précédent :
déjà, il faut faire un inventaire précis des différentes taches de programmation :
- IA
- code réseau
- code graphique
- code utile (gestion des I/O, fenêtres, scripts d'extension, son, etc...)
 
pour ma part, je veux bien me charger du code utile, et aider pour le code réseau. la partie graphique m'intéresserait également, mais je suis complètement largué à ce niveau (j'en suis encore à faire de la 3D à coup de Bresenham, de Phong et de Gouraud )

Pour gagner du temps sur la gestion des I/O, je suggère simplement d'utiliser ça : http://icculus.org/physfs/

bin au niveau graphique, les choses sont claires: on utilise un moteur donc a priori, pas de prog 3D de bas niveau.
 
Quant au code réseau, c'est ultra basse priorité pour l'instant.
 
Comme je le disais dans un post précédent, le premier objectif, ce serait d'avoir un vaisseau qui puisse voyager (y compris en atmosphère) et basta, on aurait déjà la partie de navigation et pilotage complète.

Une méthode facile: chacun code le jeu de son côté et quand tout le monde a fini on prend le mieux fait

De toute façon, je pense que dans un premer temps, il faufrait réaliser une maquette relativement simple en quelques semaines à 2 mois (disons), qui devrait permettre de soulever quelques lièvres et de voir les difficultés qu'on n'a pas prévues. Ce qui permettra de repartir rapidement sur une structure plus ambitieuse par la suite.

Que mettrait-on dans cette maquette?

ouahhhh un commité de pilotage ...
 
pourquoi vous le faites pas en .net ou en java votre jeu ?

nan

on parle de moi dans les topics où j'ai pas de drapal ?

t'es un peu notre figure de proue a nous

puisque t'es là, ça te dirait pas de faire l'analyse technique et mise au point des standards qu'on utilisera pour coder (histoire que chacun chie une merde illisible pour les autres dans son coin) ?

dommage, en misant sur une techno moderne, vous auriez peut-être gagné un développeur de talent.

j'ai 29 pages de retard, t'as pas un site web que je regarde plus tôt ?

 
qui aurait passé 15jours a se demander comment gerer le clic droit de la souris ?
 
 
Moi chui pour .net tiens

cf post 1.

mais y'a plein de mots dedans !

Lis déjà les 2 premiers morceaux de texte, si ça t'intéresse pas, tu es dispensé de lire le reste

merde, y'avait pas d'entête et de numéros de page dans le document. C'est pas sérieux ça /o\

Tu vas pas chipoter sur les détails hein
Ton traitement de texte te l'affiche dans la barre de statut

je suis pas *du tout* d'accord, c'est un jeu de commerce, il faut donc démarrer le projet par du commerce. développper une infrastructure de commerce qui grossira avec le jeu, alors que parler tout de suite de 3D est casse-gueule : ça veut dire partir sur le plus gros risque technologique (parce que ça va pinailer sur le choix du framework, qui lui-même influera sur le développement de tout l'aspect voyage, et que ça va impliquer un bon paquet de travail) sans avoir :
1) de backbone sur lequel s'accrocher  
2) dégagé la moindre contrainte structurelle (si on a pas assez de contrainte, le choix est trop vaste, ça va "vibrer" beaucoup, mais la décision sera pas "dominante" des autres).
 
 
Je ne renie pas que les risques technologiques doivent être gérés tôt, mais à mon avis, c'est trop tôt, ça pourrait être emmerdant par la suite.
 
 
Rien à voir, mais je suggère d'accrocher tous les devs au même IDE et sur les même outils, sinon il va y avoir en permanence "adaptation d'impédence" dans la circulation du code, et le langage commun va s'adapter au moins-disant. Par contre, je ne citerais pas de noms, j'ai pas étudié le domaine (pour C++). Je pense qu'on peut mettre comme contrainte qu'on doit trouver un IDE qui tourne sur les mêmes plateformes que le jeu.

j'ai imprimé

A part Emacs et Eclipse il n'y a pas grand chose comme IDE multiplateforme.

nraynaud> En ce qui concerne les IDE, chacun est libre, l'essentiel est que ça compile avec GCC. Sous Windows, le choix de l'IDE serait donc logiquement DevCPP, mais je suppose qu'Eclipse a aussi ce qu'il faut pour gérer ce compilateur.
 
Concernant les choix à faire (y compris la maquette), ben j'aimerais qu'on le fasse à plusieurs, et je ne pense pas être le plus qualifié ici pour faire le design technique. Je sais que chacun vient en fonction de ses disponibilités (notamment Mr Mala qui est assez occupé ) mais faudrait qu'on trouve un moment qu'on en discute tous ensemble

si tu pars sur un critère aussi faible, alors on est déjà dans le moins-disant.

Pardon  

gcc n'offre rien comme service autour du code, je suppose qu'il parle de make ou autoconf, mais à l'âge de la compilation incrémentale et des headers précompilé, c'est plus très adapté, les compilos de dev doivent collaborer avec l'IDE (compilation à la méthode près, construction des caches de symboles etc.). Et les IDEs font une invasion dans le projet.

au fait, il faut penser à définir le format du fichier de sauvegarde

 
+1 Backbone d'abord, développement d'une architecture si possible souple et extensible, et pensée de sorte qu'il soit possible de greffer la 3D sans tout casser. Un peu comme Lorill a fait pour lucane.
 
Au fait, on peut p-ê se servir de ce dernier pour la communication, ne serait-ce que pour son module de dessin en live et son forum.
 
Harko a écrit:

C'est subordonné aux structures de données utilisées, ne mettons pas la charrue avant les boeufs.

t'as des aigreurs d'estomac ? on sait même pas ce qu'il va y avoir dedans, comment tu veux choisir ?  
"on prend XML parce XML c'est dans 01 info toutes les semaine" ?

bof, du moment que ça compile pas trop lentement, que les perfs du binaire sont bonnes moi ça me va.
 
Pour l'analyse du code c'est à l'IDE de le faire, pas au compilateur. D'ailleurs, ctags est largement suffisant pour pas mal de projets et pourtant c'est vraiment basique.
 
Pour ce qui est de la gestion de projet, automake/autoconf sont bien plus que de simples makefile ( même si je ne peux pas supporter la complexité des fichiers à écrire pour faire marcher cette usine à gaz ) Heureusement, kdevelop sert directement de frontend à cette chose et ça aide beaucoup.

donc on est effectivement dans le moins-disant.

Prépare toi psychologiquement à y sauvegarder toute une galaxie (puisque celle-ci est créée aléatoirement à chaque nouvelle partie)

Oui mais quand même, à moins que la generation prenne breaucoup de temps, il suffit d'enregistrer la seed du generateur al&étoire et c'est bon.

 
tu sauve la graine initiale
 
(trop dur)

Euh non la seed ne suffira pas.

bin ske ton algo est mauvais alors

+1 sur drasche, si y'a plusieurs tirage au cours de l'évolution des planètes, il faut, soit rejouer toute l'évolution de la planète à la désérialisation soit stocker l'état de la planète, soit, beaucoup plus fin, exprimer l'évolution de la planète sous forme d'équation horaire (état = f(temps) avec f non récursive) ce qui est, à mon avis l'objectif à tenter.

deuxieme solution, tu dois etre capable de pouvoir calculer la pos de la planete a n'importe quel t et pas seulement en fonction de t-1

T'as surtout mal lu (contrairement à nraynaud qui vient de t'expliquer pourquoi).

Oui, ça on peut.

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.