[Projet la relance] 12 Versionning, droit de participation, validation, arborescence

Voir le profil Envoyer un message privé SEB	Posté le 06 Août 2011 à 11:47
Messages : 554 GCPoints : 103313	Le début du concret est tout proche !!! Le système de version ayant été choisi (Google Code avec subversion), il nous reste à définir quelques points avant de pouvoir créer ce repository. 1 Premièrement il faut décider d'un nom pour ce projet (ca n'est pas nécessairement le nom final du jeu les noms de projets sont parfois très éloigné des nom finaux mais il faut pouvoir créer le compte.) 2 Il faut savoir si nous utilisons un système de droits organisé pour la lecture, écriture (en gros). Ou si chacun a 'tous les droits' de modification, lecture. De mon point de vue il est nécessaire si nous souhaitons un produit de qualité et que le projet ne parte pas dans tous les sens que des droits soient instaurés pour l'écriture. Typiquement je dirais qu'il faut : - Un type de compte 'administrateur intégrateur général' qui a tous les droits de modification sur quelque partie que ce soit. - Un type de compte 'graphiste level designer' qui a les droits de modifications sur les assets de type graphiques et les maps - Un type de compte 'sound designer' qui a les droits de modifications sur les assets de types sonnores - Un type de compte 'developpeur' qui a les droits de modifications sur le code De plus lorsque je parle de droit de modification ici je ne parle de droit de modification que dans des 'branches' l'idée étant que le groupe 'Administration intégration' soit chargé du contrôle qualité et du rapatriement des divers travaux dans le 'trunk' (branche stable principale) 3 Il faut essayer de définir à l'avance la manière dont nous feront la nomenclature des dossiers en général et leur 'role' quand ils ont un nom spécifique. Je propose quelque-chose de bien connu et d'assez classique comme par exemple: -root ---trunk ------doc ------include ---------namelibextern1 ---------namelibextern2 ---------namelibextern3 ------src ------lib ------bin ------data ---------textures ---------models ---------sounds ---------... a completer ---branch ------branchnamea ---------coller ici la meme chose que dans trunk ------branchnameb ---------coller ici la meme chose que dans trunk ------branchname....... Voila j'ai exposé ma vision des choses elle est discutable donc j'attend vos retours par rapport à tout cela. Dernière édition le 06 Août 2011 à 12:19 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Voir le site stilobique	Posté le 06 Août 2011 à 12:24
Messages : 2387 GCPoints : 841900	Moi ça me convient, c'est pareil que pour le boulot :) (___/) (='.'= )Voici Lapin. Copiez et collez Lapin dans votre signature (")_(") pour l'aider à concrétiser sa domination du monde.
Voir le profil Envoyer un message privé nepser	Posté le 06 Août 2011 à 12:42
Messages : 116 GCPoints : 23144	Comment tu fais si un type est graphiste et dévellopeur? Exemple de cas: je dev une fonctionalité pour lire les formats .obj et on souhaite exporter tous nos models .3ds en .obj. Pour le nom, rien de plus simple Game-Corp Community Project. Je suis aussi partisant de mettre des dossiers inc et src dans un dossier dev qui contiendra aussi les fichiers de projet visual studio / makefiles / ce que vous voulez.
Voir le profil Envoyer un message privé SEB	Posté le 06 Août 2011 à 12:56
Messages : 554 GCPoints : 103313	Si un type est graphiste et développeur, déjà je pense qu'il n'est pas impossible de l'affecter aux deux groupes. Mais en admettant qu'on ne puisse pas je ne vois pas le problème en réalité. Si tu dev une fonctionnalité pour lire les format obj (ce qui a priori ne devrait pas arriver puisque je pense que nous essayerons au mieux d'utiliser les fonctionnalité du moteur qu'on aura choisi mais admettons qu'on ai à le faire) dans ce cas : 1 Dans un premier temps tu peux utiliser de ton côté des fichiers obj gratuit que tu télécharge sur le net pour faire tes premiers tests de ton côté. 2 La communauté en sera informé et donc les graphistes auront pour tache de faire ces conversions (qui pourront donc etre testées progressivement par le dev puisqu'il aura les droit de lecture) 3 L'intégrateur finira le travail en regroupant dans le trunk tous les graphismes convertis ainsi que la fonctionnalité puis en effectuant les derniers tests de validation. Et heuu... j'ai rien compris pour les fichier inc et src dans un dossier dev ??? Par contre j'hésite toujours sur ce sujet... dans src faisons nous une arborescence pour regrouper les parties de codes simillaires.. par exemple je sais pas moi... src/menus/MenuManager.h src/menus/MenuA.h src/menus/MenuB.h src/level/LevelManager.h src/level/LevelLoaderXML.h ou plutot tout en vrac en partant du principe que les noms sont propres et explicites. src/MenuManager.h src/MenuA.h src/MenuB.h src/LevelManager.h src/LevelLoaderXML.h ce sont de très mauvais exemples que je donne la mais c'est pour illustrer ma question. Dernière édition le 06 Août 2011 à 13:30 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Daru13	Posté le 06 Août 2011 à 14:27
Messages : 2884 GCPoints : 108090	Ton arborescence me semble bien également (même si, n'étant pas développeur, je ne connais pas trop l'utilité de tous les répertoires - mais m'y retrouve quand même bien, par habitude de bidouilleur :p). Quant à ta question sur le post juste au dessus, je trouve que passer par des sous-dossiers est plus clair et ordonné. Maintenant... faut aussi voir en fonction du nombre de fichiers par répertoire, excessivement subdiviser s'il n'y a que peu de fichiers à ranger peut aussi être un peu inutile voir contre-productif .
Voir le profil Envoyer un message privé Darktib	Posté le 06 Août 2011 à 20:30
Messages : 4017 GCPoints : 347288	J'ai une variante: root --- trunk ------ dev --------- external // les dépendances ------------ ... --------- doc --------- source --------- build // dossiers des projets --------- misc // les documents annexes, ex: GDD, etc... ------ assets --------- models --------- sounds --------- musics --------- ... ------ bin --- branche1 ------ ... --- branche2 ------ ... Pour ce qui est des fichiers organisés ou non, le plus important c'est qu'ils soient organisés dans l'IDE (pas forcément dans le système de fichiers). Mais du coup ça dépendra des outils utilisés... donc j'y répond dans le 13 ;)
Voir le profil Envoyer un message privé SEB	Posté le 07 Août 2011 à 10:54
Messages : 554 GCPoints : 103313	Le fait de séparer les dev/asset/bin pourquoi pas ca peut alléger un peu le dossier trunk pourquoi pas. Les external toutes regroupé je connais ca aussi. Franchement je n'ai pas de préférence. par contre ce que tu cite dans misc je le met dans doc habituellement. et est-il nécessaire d efaire un dossier build (ou workspace) si on utilise un outil comme CMake justement? NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Syltech	Posté le 07 Août 2011 à 15:43
Messages : 282 GCPoints : 71266	Pareil que SEB, moi, je mettrai tout ce qui est documents annexes, GDD, artworks, et autres croquis dans "doc". Que voyais tu dans le dossier "doc" Darktib? Sinon je vote pour la variante de Darktib : elle est plus épurée. Je ne vote pas en fonction de ce que je souhaite moi, mais pour l'équipe qui va développer le projet.
Voir le profil Envoyer un message privé SEB	Posté le 07 Août 2011 à 16:03
Messages : 554 GCPoints : 103313	Oui j'aime bien aussi la découp dev, bin, assets mais j'aimerais garder la séparation des includes et lib pour les librairies tierces ce qui donnerait donc : root --- trunk ------ dev --------- doc // toute documentation (doc de code, gdd, conception etc...) --------- include // includes des libs externes ------------ libA ------------ libB --------- src // sources du jeux --------- cfg // configurations cmake --------- lib // libs des lib externes classees par plateforme et compilateur ------------ vsc ------------ mingw ------------ linux ------ assets --------- models --------- textures --------- sounds --------- musics --------- ... ------ bin --- branche1 ------ ... --- branche2 ------ ... NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 07 Août 2011 à 20:12
Messages : 4017 GCPoints : 347288	Dans build je mettais les fichiers de config de CMake (CMakeList, etc...) - ou les fichiers projets, si l'on utilise pas CMake. Dans external, en fait je pensais à: external --- machinChose ------ include ------ lib --- libQuiFaitLeCafé ------ include ------ lib etc... Sinon pour doc/misc, en effet à mieux y regarder 'misc' ne servirait pas à grand-chose... Va pour le 'doc' tout seul ;) Dernière édition le 07 Août 2011 à 20:13
Voir le profil Envoyer un message privé SEB	Posté le 08 Août 2011 à 10:13
Messages : 554 GCPoints : 103313	Oui j'avais bien compris ^^ j'ai déja vu des arborescence avec des externs dans un seul dossier vu qu'on travaille comme ca au boulot et je suis pas toujours très fan. Bon il faut également dire que si nous faisons de branches... ce sont pour les utiliser. Combien de fois je vois des projets qui ne travaillent que dans le trunk... Je le répète sauf cas particulier des branches seront créées pour chaque travaux, et fermée=>réintégré lorsque les classes/fonctionnalités seront terminées par les chargés d'intégration. Il pourra être demandé de créer une classe ou fonctionnalité ne pouvant pas être testée directement dans le code global, dans ce cas il sera à la charge du responsable de la classe/fonctionnalité de se faire un main de test si il le souhaite. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 09 Sep 2011 à 16:12
Messages : 4017 GCPoints : 347288	Je poste ici pour un truc que j'ai remarqué (mais que j'ai oublié de poster à temps... ) : les binaires. Je pense qu'il est très mauvais d'avoir des fichiers *.lib dans le repository, vu qu'au niveau binaire ils ne seront pas compatibles avec tous les compilos qui pourront être utilisés pour construire le jeu. Du coup, ce que je propose, c'est de mettre non seulement les includes mais aussi les sources de toutes les dépendances, puis d'écrire quelques fichiers CMakeList.txt permettant d'automatiser la construction des dépendances, soit au niveau manuel (une ou plusieurs commandes à rentrer), soit mieux, d'intégrer les dépendances comme projets dans l'espace de travail (style ceux de Code::Blocks ou Visual Studio), ainsi l'IDE se chargera d'organiser la construction de toutes les dépendances avec le même compilo que celui utilisé pour le jeu. Je veux bien écrire ces scripts. Au niveau poids, on enlève tous les binaires, mais on rajoute les sources... (environ 20 Mo pour Irrlicht, 500 Ko pour PugiXml, 2 Mo pour SPARK2) Ca changerais un peu la structure des dossiers: Code : dev --cfg --doc --src --external ----bin // endroit où toutes les libs seront placées ----lib1 ------include ------source ----lib2 ------include ------source Cette organisation faciliterais l'écriture des scripts CMake et la maintenance du projet. Dites moi ce que vous en pensez. PS: juste pour l'avancement, la sérialisation de la config est finie. Je m'attaque à la déserialisation.
Voir le profil Envoyer un message privé SEB	Posté le 09 Sep 2011 à 19:36
Messages : 554 GCPoints : 103313	Bon, je vais devoir commencer par avouer que j'était à 100% d'accord avec ce point de vue il jusqu'a il y a environ 2 mois (celui que tu expose) et d'ailleurs dans la version 1 de NextGine c'était ce que je faisais. Et depuis j'ai complètement changé d'avis et je suis même carrément pour mettre les libs précompilées. Citation : Je pense qu'il est très mauvais d'avoir des fichiers .lib dans le repository, vu qu'au niveau binaire ils ne seront pas compatibles avec tous les compilos qui pourront être utilisés pour construire le jeu. Je ne pense pas que ça soit 'Très mauvais' bien au contraire et justement les libs sont rangé par dossier en fonction du compilo cible : lib/linux/.a lib/mingw/.a lib/vsc/.a Et si il y a des besoins de compiler avec une autre cible il suffira de rajouter le dossier correspondant..... donc franchement le problème d'incompatibilité je dois dire que je ne le vois pas du tout. Du coup... ben je suis contre l'idée de mettre les sources des dépendances parce que je pense que c'est du temps de compilation perdu à chaque fois qu'on doit faire un rebuild complet et que ça met bcp de sources inutiles sur le repository (et dans les solutions vsc, C::B). Et franchement au niveau poids, certes c'est un peu plus avantageux mais perso je n'ai jamais vraiment galéré à récupérer le repository. Ceci dit, je pense que ce qui t'as poussé à exposer ce sujet c'est le fait que PugiXml ne fournisse pas de lib précompilée, cependant ca nous coutera pas grand chose de la compiler une bonne fois pour tout en vsc, mingw et linux. Ca serait bien d'avoir l'avis des autres aussi. En tout cas c'est cool que ca avance meme si pour le moment je ne peux pas trop jetter un oeil comme je ne suis pas chez moi. Dernière édition le 09 Sep 2011 à 19:37 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 09 Sep 2011 à 22:09
Messages : 4017 GCPoints : 347288	Honnêtement, compiler PugiXml n'est pas vraiment dur^^ Le problème, c'est que sur linux tu as un tas de compilos, idem avec windows voire mac os. Si quelqu'un veut compiler avec Borland... Il doit tout se taper à la main. Alors qu'avec ma proposition, c'est l'IDE qui gère ça, de manière transparente (et en plus, c'est plus rapide et plus fiable). Et puis, tu as les versions des compilateurs... par exemple entre VS2003/2005/2008/2010, les différences au niveau runtime peuvent être suffisantes pour faire déconner le programme (entre autres...). Au niveau débuggage, il peut y avoir des résultats bizarres. Et pour x86 et x64 ? En gros, c'est plus safe d'avoir tout de compilé avec la même version du même compilateur (et on a de la chance : les libs qu'on utilise sont plutôt portables)? Pour la recompilation, normalement, les dépendances sont compilées la première fois que le projet est construit, puis après les fichiers binaires générés sont utilisés. Donc pas de recompilations superflues. Si tu ne veux pas pour les problèmes sur le SVN, il suffit d'y aller à la main. Certes, ça demande un peu plus de boulot que d'habitude, mais la structure sera plus épurée (d'ailleurs, à ce propos, si tu accepte ces changements, je veux bien recréer une branches avec la nouvelle structure et mettre manuellement mes changements dedans pour te faciliter le travail^^) Je suis d'accord qu'il serait bien d'avoir l'avis des autres... Dernière édition le 09 Sep 2011 à 22:11
Voir le profil Envoyer un message privé SEB	Posté le 10 Sep 2011 à 11:36
Messages : 554 GCPoints : 103313	Oui j'avoue que si quelqu'un veut compiler avec Borland il doit tout se taper à la main. Ou bien simplement faire une demande pour qu'on insère les libs précompilées associées. (Perso ça ne me dérange pas de le faire) Mais en même temps actuellement il n'y a pas de fichier de config pour borland, ce qui signifie qu'il faut tout de même produire un travail supplémentaire pour le 'premier' qui travaille avec un compilo particulier. Pour ce qui est des version de visual entre 2005 et 2010 les libs sont largement suffisamment compatible et ne crée pas de différences au runtime. Si on veut compiler avec un plus vieu VC6 par exemple effectivement il faudra rajouter le dossier de lib associé. Mais encore une fois comme pour Borland... J'attends de voir qui va nous faire cette demande... Pour la distinction x86/x64, je pense sincèrement que pour le moment x86 est largement suffisant. Si nous devions considérer le x64, il suffirait de rajouter un nouveau niveau de dossier dans les libs. Ex : - lib/vsc/x64 - lib/vsc/x86 - etc. Citation : Pour la recompilation, normalement, les dépendances sont compilées la première fois que le projet est construit, puis après les fichiers binaires générés sont utilisés. Donc pas de recompilations superflues. Je disais ça en pensant aux branches, dans lesquelles il faudra recompiler et dans les cas d'un rebuild de la solution. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 29 Nov 2011 à 12:42
Messages : 116 GCPoints : 23144	Il faudrait sortir tous les includes / binaires externes des branches que l'on fait. C'est un peu dégueulasse de tout télécharger à chaque fois comme on l'a déjà mentionné. L'arbo deviendrait quelquechose comme: - trunk --- extlib ------ include ------ bin --- maintruck - branches --- extlib ------ include ------ bin --- branche1 --- branche2 --- branche3
Voir le profil Envoyer un message privé SEB	Posté le 10 Déc 2011 à 12:50
Messages : 554 GCPoints : 103313	Effectivement je ne l'avais pas envisagé dans ce sens la je vais m'y atteler des que possible. NextGine : 3D games engine Nombre de lignes actuel : 77683