[Projet la relance] 3. Ce qui peut être fait
| nepser |
Posté le 25 Juil 2011 à 00:07
|
|
 Messages : 116 GCPoints : 23144 |
Ici le cœur du problème, choisir ce qui peut être fait par la communauté. Il existe des contraintes de base à mettre en évidence pour définir ce qui peut être fait: - Problèmes de contenu: --- La quantité de contenu: J'aurais tendance à dire exit un RPG avec des quêtes/environnement à la pelle. Plus il y aura de contenu, plus la date pour avoir un jeu intéressant sera repoussée. --- La qualité du contenu: On ne peut pas vraiment espérer avec les graphismes d'un Far Cry. Déjà parce-que je ne pense pas qu'il y ai énormément de pro/Semi-pro qui aient assez de temps à consacrer à chaque modèle / animation; mais aussi la quantité de profils différents qui pourront se succéder va certainement montrer de grosses différences entre les réalisations. - Problèmes techniques: --- Moteur graphique: On ne peut pas partir à 0 pour un moteur 3D, il est préférable d'utiliser aussi un modèle existant pour gérer de la 2D. Plus on repousse la date de mise en œuvre du jeu, plus la lassitude augmente. --- Quantité de données: Relatif au contenu, techniquement il va être dur de tenir énormément d'objets et de données. Plus il y a d'objets/cas spéciaux à gérer (comme des events) plus ça sera le bordel pour organiser avec ceux qui feront du contenu. --- Maintenance technique: Plus le projet sera riche, plus il y aura de points à connaitre pour faire la moindre modification (c'est toujours le cas). Si on va essayer de faire trop de choses, il y aura moins qui sera cohérent ou tout tiendra par un bout de fil. Tous ces problèmes sont liées aux problèmes de groupe suivants:
- Le membre qui dit faire un travail, mais qui ne le rend jamais => "Ouai je vais faire ça" Finalement on l'attend et rien n'est fait, ce genre de comportement est très compromettant pour un projet. - Le membre qui fait 10x plus que les autres => Le sur-investissement est souvent problématique, le membre bien investit aura l'impression que rien avance, les autres seront dépassés. - Le "Je vois rien qui avance" => Un gros problème de démarrer un moteur graphique est que rien ne sera visible avant x mois, ce genre de modification qui ne font pas avancer de façon fonctionnelle le projet jette souvent un froid sur ceux qui essaient d'apporter du contenu, un sentiment de projet à sens unique. - Le membre clef qui part => même si la relève est assurée, la qualité suivante n'est plus la même, avoir une charte de qualité sur chaque thème est indispensable afin d'assurer une cohérence sur le long terme. Cela inclut de la documentation de code par exemple. Ces problèmes SERONT rencontrés, et LIMITER ce que l'on va faire sur le projet permet de RÉDUIRE leur impact sur le projet.  Si tout le monde a comprit, est d'accord et pris en compte ce que je viens de d'écrire, alors je pense que tout le monde comprendra mon raisonnement qui suit pour déterminer le type de jeu qu'il est possible de faire:
2° Est-ce qu'on peut produire des modèles 3D? 3° Est-ce qu'un prototype serait faisable avec des dessins moches? Des ressources moches, et avoir son coeur de gameplay construit? 4° Est-ce qu'on veut privilégier un gameplay spécifique novateur, ou quelque-chose assez proche de l'existant? 5° Est-ce qu'il existe un moteur graphique pour faire tourner ce genre de chose facilement? 6° Est-ce qu'on a un développeur qui peut modifier/créer un moteur pour atteindre l'objectif du gameplay? 7° Est-ce qu'on peut avoir une démo technique en 3 mois? Je pense que ces questions sur essentielles pour déterminer la faisabilité de toute idée. D'autres avis sur les limites logistique de ce genre de projet à prendre ne compte? |
|
| Darktib |
Posté le 25 Juil 2011 à 13:17
|
|
 Messages : 4017 GCPoints : 347288 |
Je suis globalement d'accord. Pour ce qui est de la technologie, je conseillerais plutôt du C++ (notamment pour le nombre de bibliothèques existantes), en utilisant Irrlicht ou Ogre (si c'est de la 3D) ou la SFML (si c'est de la 2D). Refaire de 0 un moteur 2D/3D me semble complètement utopique. Il ne faut pas oublier qu'il faut aussi faire tous les logiciels annexes, ie les éditeurs de carte, de donnée du jeu. Ça, ça prend beaucoup de temps. Là, au niveau des choix, soit les éditeurs sont faits avec la GUI du moteur utilisé pour le jeu, soit de manière plus 'externe', en utilisant Qt par exemple (inutile d'utiliser l'API Win32 ou équivalent sur Linux). Voilà pour la question 5. Pour la question 3, oui, je pense qu'il faudra de toute façon utiliser ce genre de média (souvent appelés en anglais placeholders). Ca premet de débloquer la programmation: si les développeurs ont besoin d'un modèle 3D ou d'une image, ils ajoutent un truc tout moche et bien visible, et indiquent aux graphistes qu'ils doivent le faire. Après, pour la démo technique... faut déjà avoir un solide cahier des charges niveau gameplay (donc pas de programmation avant d'avoir quelque chose de probant). Peut-être utiliser le wiki pour le cahier des charges ? En tout cas, le mieux serait d'abord de définir le type de jeu à avoir (gameplay grossier), cela déterminera la partie technique. Donc je pense qu'on pourrait avoir un 0° Quelle catégorie de jeu ? (FPS,RTS, etc...) |
|
| nepser |
Posté le 25 Juil 2011 à 13:51
|
|
|
Messages : 116 GCPoints : 23144 |
En fait cette série de question est sensé déterminer si le choix avec ta question 0° est viable. | |
| SEB |
Posté le 25 Juil 2011 à 14:05
|
|
 Messages : 554 GCPoints : 103313 |
Je suis tout a fait d'accord sur le fait qu'il faut savoir d'abord ce qu'on est capable de créer sur la communauté pour choisir au mieux quel type de jeux on va réaliser. Donc pour moi ce sujet portant le titre : 'ce qui peut être fait' Tout en mettant effectivement en lumière des points important d'implication sur les choix de gameplay. Pour moi il devrait servir uniquement à recenser : Ce qui peut être fait. Je pense que je reverrais donc les questions en : - Est-ce qu'on peut produire des modèles 3D? - Est-ce qu'on peut produire des images 2D? - Est-ce qu'on peut produire des sons? - Est-ce qu'on peut produire du code source natif? - Est-ce qu'on peut produire du script? - Est-ce qu'on peut produire un cahier des charge de gameplay? Parceque meme si je suis d'acord avec tout ce que tu dis, je trouve que certaines de tes questions sont orientées et qu'elles semblent donner la réponse d'elle même en n'ouvrant pas réellement au débat. Mais tant mieux parceque elle me semble ne pas avoir leur place dans le titre du sujet (selon moi). Typiquement : Est-ce qu'on peut avoir une démo technique en 3 mois? me semble être la pour dire....voyons petit. (et j'adhère à cette théorie mais elle est un peu trop claire dans cette question) Donc concrètement pour ma part étant donné que je souhaite participer je dirais que je suis capable d'apporter ma contribution sur : 1 Organisation, aide au cahier des charges techniques, distribution de travail. 2 Mise en place d'outil : management et administration d'un système de partage de code source. 3 Programmation en tout langage (compilés, interprétés, objet ou non, y compris web et BDD) avec un sérieuse expérience en c++. 4 Création de conception orientée objet poussée. 5 Expertise en IA et en moteur 3D tout inclus (excepté quelques lacunes en physique). ps : je pense que l'on n'a plus ou moins sauté la question que tu suggérait comme étant la toute première.. et c'est à dire : qui participe? et comment participe-t-on ? Et je pense qu'un autre sujet devrait être ouvert à cet effet
NextGine : 3D games engine
Nombre de lignes actuel : 77683 |
|
| nepser |
Posté le 25 Juil 2011 à 14:24
|
|
|
Messages : 116 GCPoints : 23144 |
Les questions orientées étaient un peu voulues pour justement ne pas trop partir dans le débat, qui serait un débat théorique et très peu sur la pratique. Bien sûr les réponses restent ouvertes, ce n'est pas parce-qu'on peut pas faire de démo technique en 3 mois que l'idée est à jeter, mais disons que c'est une question à se poser lorsqu'on va étudier une idée: "Qu'est-ce qui va nous poser problème?". Le but est donc de voir quelles sont les limites du projet. Après j'ai encore essayé d'orienter vers le "cœur" du jeu les question, comment va-t'on faire pour avoir un noyau solide pour avancer. @darktib: pour ce qui est des placeholders, dans tout les cas il y en aura. La question était plutôt: "Est-ce qu'on peut atteindre rapidement la possibilité de tester tout le gameplay sans avoir énormément de ressources?" > ps : je pense que l'on n'a plus ou moins sauté la question que tu suggérait comme étant la toute première.. et c'est à dire : qui participe? et comment participe-t-on ? Et je pense qu'un autre sujet devrait être ouvert à cet effet Je te laisse engager le sujet, je ne savais pas trop sous quelle forme le présenter ni ce qu'on pouvait attendre des membres. |
|
| stilobique |
Posté le 25 Juil 2011 à 16:10
|
|
 Messages : 2387 GCPoints : 841900 |
On peut aussi partir sur une modification d'un jeu, je pense notamment au source engine qui est devenue gratuit ou bien l'UDK, ou même Quake 3 avec tout les outils et ressources déjà disponible... il y a aussi le moteur 3D de seb qui était bien parti... bref les choix et possibilité ne manque pas mais ce genre de choix demande de savoir aussi qu'elle type de jeu et gameplay on souhaite car c'est tout de même censé être le coeur du débat à mon avis. PS : Pour m'a pars je peut faire quelques modèles 3D et texture :)     (___/) (='.'= )Voici Lapin. Copiez et collez Lapin dans votre signature (")_(") pour l'aider à concrétiser sa domination du monde. |
|
| SEB |
Posté le 25 Juil 2011 à 16:26
|
|
|
Messages : 554 GCPoints : 103313 |
:p Et la on en vient à ce que je n'avais pas prévu mais qui me parait évident maintenant. Les point de vue des gens qui font réellement le jeux (à savoir les graphistes et game designer) et les points de vue des programmeurs. Nous sommes tous d'accord sur le fait de dire que le cœur du problème est le gameplay (en tout cas lorsque on lance un projet) Sauf que nepser (et moi même) ayant pris les devant sur le lancement du projet, et connaissant (un peu plus) les implications de tel ou tel idées de gameplay sur les temps de développement, nous insistons lourdement en amont sur le 'qu'est-ce qui est faisable' (d'ou le titre du sujet) parceque nous souhaitons pouvoir mener le projet à bout, et qui dit mener le projet à bout, dit avoir des idées... mais qui soient le plus compatibles possibles avec les capacités de production de l'équipe (tant en volume que en complexité). C'est gentil de proposer l'utilisation de mon moteur et cela me ferait plaisir, le soucis c'est que je ne pense pas qu'il soit prêt pour une utilisation concrète dans un projet (dans des délai convenables). Bref grâce à toi nous savons que nous pouvons avoir quelques éléments 3D. De quel types? Statiques? Animés? Animés sous quel modèle?
NextGine : 3D games engine
Nombre de lignes actuel : 77683 |
|
| SEB |
Posté le 04 Août 2011 à 19:54
|
|
|
Messages : 554 GCPoints : 103313 |
Concrètement, je pense que ce sujet ne sera jamais clos puisqu'il ne pose pas vraiment de question mais expose un avis qui a eu l'air d'être compris à la majorité, c'est à dire qu'il ne faut pas que nôtre projet ai des ambitions trop fortes. Et reste dans les cordes de l'équipe dans un temps et un volume raisonnable.
NextGine : 3D games engine
Nombre de lignes actuel : 77683 |
|
| MonchauxantZ |
Posté le 06 Août 2011 à 17:29
|
|
Messages : 117 GCPoints : 26910 |
Bon personnellement, je ne peux aider qu'en Basic, donc ça ne servira pas à grand chose. Seulement... Il faut également décider de la mise en forme du programme. Moi, j'utilise généralement un script dont les lignes sont renvoyées au programme (une facilité pour changer quelques petits trucs par-ci par-là), mais certains ne font pas pareil : Il faut donc décider de ça aussi...  MonchauxantZ. |
|
Voir le profil
Envoyer un message privé
Voir le site