Discussion :

[leuhpoulpe]

Bonjour à tous,

Je souhaiterais vous présenter un projet issu d'un document de Game Design que j'avais ébauché il y a plus 3 ans et sur lequel je retravaille depuis près d'un an et demi.


Le concept de base est simple, c'est un jeu de survie dans un monde post-apocalyptique. L'apocalypse en question est somme toute assez classique : Une pandémie a tué l'extrême majorité de la population et transformé la plupart des survivants en créatures nocturnes agressives.
Assez rapidement le jeu s'écarte du classique jeu de zombie. Ici la pandémie a eu lieu près de 60 ans plus tôt. Les enjeux et risques ne sont pas les mêmes et les moyens non plus.

De plus il n'est pas question ici de tuer à la chaîne mais plutôt de se faufiler et d'éviter les risques autant que possible afin de trouver de quoi survivre.
De jour seuls les lieux sombres sont dangereux, les Infectés y allant pour se cacher du soleil. Mais ce ne sont pas de simples zombies errant à la recherche de cervelle. Ils chassent la nuit et dorment le jour, comme n'importe quel animal nocturne. Par ailleurs leur durée de vie est sensiblement égale à celle d'un homme, ils ne tombent pas en décrépitude en quelques semaines. C'est pourquoi près de 60 ans après la pandémie originelle ils restent suffisamment nombreux pour que l'humanité en soit toujours réduite à vivre dans des citadelles coupées du monde.

Le jeu est pensé pour être en vue subjective. Le gameplay du jeu tourne autour de quatre points majeurs :

• L’artisanat avec six établis permettant de créer divers objets.
• La construction, seul ou à plusieurs.
• L’exploration, seul moyen de récupérer les ressources nécessaires à la survie.
• La gestion des besoins primaires et des ressources.

Le jeu propose six établis différents, chacun avec un système de fonctionnement qui lui est propre et permettant de produire des objets précis :

• La menuiserie pour produire des objets dérivés du bois
• La forge pour les objets à base de fer
• La tannerie pour les objets composés de cuir
• L'atelier chimique pour créer médicaments et autres produits chimiques
• La cuisine pour préparer et assainir la nourriture et l'eau
• L'atelier pour l'assemblage des objets afin de créer des objets complexes

Outils et armes disposent de 6 niveaux de qualité distincts, déterminés à parts égales par la qualité des matériaux utilisés et la compétence du personnage. Plus il travaille un domaine, plus il devient performant.
Aucune survie ne peut être envisagée sans un système de production. Les objets tout faits sont très rares et particulièrement précieux.



Le système de construction simule la résistance des structures. Les sols doivent être soutenus par des poutres pour ne pas s'effondrer et certains murs (cloisons) nécessitent d'être fixés sur des structures solides (murs ou poutres) pour tenir debout.
Un système de «plan grandeur nature», le Mode Ghost, permet de visualiser ses constructions avant de les avoir terminées et de créer des chantiers participatifs.
Comme pour l'artisanat, l'acquisition d'une certaine «expertise» est requise afin d'exploiter au mieux les possibilités du jeu, que ce soit de la part du joueur ou du personnage qu'il incarne.




Si la nature peut fournir l’eau et la nourriture, les métaux, outils, armes et autres sont présents dans des ruines peuplées par les Infectés. Leur exploration demande une bonne planification et une prudence de tous les instants. Se battre est ici très risqué, une simple blessure pouvant dégénérer en infection voire en l'Infection. Mais plus vous exploitez de ruines, mieux vous serez équipés et plus vous pourrez vous attaquer à des zones à risque de grande taille.
Lors de ces expéditions, en plus des objets et des matériaux, vous pouvez trouver des écrits permettant d'en apprendre plus sur les causes et l'évolution de «l'Apocalypse», ainsi que des plans qui vous serviront à obtenir des objets plus ou moins compliqués et à mettre au point des structures complexes comme des moulins-génératrices et bien d'autres.



La faim, la soif et la fatigue rythme votre journée et si ces besoins sont négligés le personnage s'affaiblira petit à petit jusqu'à mourir. Pour survivre, il faudra gérer avec attention les aliments, les outils, les matériaux et les armes acquis au cours de l’exploration du monde – seul ou à plusieurs. Cette gestion sur le long terme est primordiale. La nourriture et l'eau saines sont rares, et seul le feu permet de les assainir. Ces ressources sont aussi indispensables pour construire un abri capable de vous protéger durant la nuit ou pour créer de nouveaux outils/armes.

Après plus d'un an de travail mono-maniaque pour mettre au point les mécaniques, les règles et les systèmes du jeu, j'aurais maintenant besoin des services d'un programmeur C++ afin d'attaquer le cœur du projet ensemble.
Bien qu'ayant toujours travaillé en essayant de prendre au maximum en compte les contraintes techniques, j'ai tenu à soumettre mes documents à un programmeur vidéo-ludique de métier de ma connaissance, ceci afin d'avoir son opinion sur la faisabilité du projet en équipe réduite. Son avis a été au final plus qu'encourageant puisqu'il n'a rien trouvé de rédhibitoire.
Bien qu'ambitieux dans son ensemble, le projet a été conçu de façon entièrement modulaire et les mécaniques de jeu sont prévues pour présenter le moins de difficultés possible, ceci afin de faciliter le développement itératif du projet, et donc la compatibilité avec un système d'alpha-funding.

Je suis moi même relativement compétent en 2D (interfaces, texturing, etc) et je peux donc, en plus du design général, m'occuper de tout ce qui est identité graphique du jeu, exception faite de la 3D qui est à la charge du modélisateur, déjà membre du projet.


Profils recherchés

Bon niveau en architecture logicielle
Une bonne maîtrise de la 3D (Ogre3D serait pressenti) et de la physique serait avantageuse
Bonnes connaissances en réseau serait appréciable.

Pour la programmation un seul codeur semble pour le moment suffisant. Une fois l'architecture de base mise en place, un second poste de programmeur sera sans aucun doute à pourvoir, mais je préfère recruter au fur et à mesure, lorsque le besoin se fait vraiment sentir. Cela dit, si vous souhaitez rejoindre le projet mais que le poste que vous souhaitez occuper est déjà pris, n'hésitez pas à tout de même vous proposer. Il me sera d'autant plus simple de vous contacter lorsque projet aura besoin de vos talents, dans le cas où vous seriez toujours disponible et intéressé.


Finalité du projet

Le développement du jeu est à visée commerciale et il se base sur le principe d'alpha commerciale (Alpha Funding) (toutes mises à jour ultérieures évidemment incluses) que l'on peut observer dans des projets comme Projet Zomboid, Minecraft, Towns et bien d'autres.

Merci de m'avoir lu jusqu'au bout. Afin de limiter la longueur de la présentation j'ai parfois du passer très vite sur certains points (notamment sur toute la technique) davantage développés dans le document pdf. Si des questions vous viennent, que vous soyez vous même intéressé par le projet ou non, n'hésitez pas.

Si vous souhaitez me contacter via mon adresse mail et/ou MSN, faites le moi savoir sur ce sujet ou en MP.

Figure 1 : Essai d'interface de l'atelier (WIP)


Figure 2 : Essai d'interface de la forge (WIP)

[Orvak]

Très beau projet, très bien présenté, ça fait vraiment envie
Par contre, j'aurais une petite question : pourquoi ne pas utiliser UDK pour réaliser votre jeu ? C'est un moteur solide et éprouvé et surtout ça vous évitera de réinventer la roue en utilisant Ogre3D (qui n'est qu'un moteur 3D et non pas un moteur de jeu).
UDK embarque cependant son propre moteur de script (UnrealScript), assez proche du Java et non pas du C++.

[leuhpoulpe]

Merci à toi Orvak. Et pour te répondre, je t'avouerai que l'UDK me fait envie mais je n'ai pas réussi à savoir s'il permettait la génération procédurale, en l’occurrence pour les bâtiments et complexes/centres urbains.
J'ai tracé les grandes lignes d'un système de génération procédurale des structures et grands ensembles de structures et je n'ai pas réussi à savoir de façon sûre s'il peut être intégré ou, à défaut, si un autre peut l'être.

Un autre point noir est le pourcentage demandé pour les projets commerciaux, les premiers 50 000$ vont dans leur poche et après c'est 25% qui partent pour ainsi dire en fumée. Je n'ai pas la prétention de penser faire un tabac tel que ça n'aurait aucune importance.
C'est le genre de décision que je préfère prendre après avoir discuté avec le "lead programmer" des avantages potentiels pour le projet que son utilisation apporterait. Pour un coût aussi important, il faut que ça en vaille la peine.

Si j'avais "préssenti" Ogre3D, c'était parce qu'il offre beaucoup d'avantages, je sais que beaucoup de programmeurs, arrivé un moment, s'essaie à ce moteur réputé très puissant. En clair, l'idée de base était qu'il offrait un bon compromis entre puissance, nombre d'utilisateurs et ... prix.

En bref, je ne suis pas fermé à l'idée, c'est un des points qui restent à voir avec le programmeur.

[leuhpoulpe]

Petite mise à jour pour montrer un peu plus en détail un des systèmes d'artisanat, à savoir la menuiserie.

(A noter que les moyens pour passer d'un objet au suivant ne sont pas représentés sur ce schéma)

Comme le laisse supposer cette image, à partir d'un arbre, il est possible d'obtenir tous les objets de base que la menuiserie peut produire. A partir de ces matériaux le joueur peut obtenir une variété d'objets comprenant par exemple chaises, tables, portes, murs de planches, parquet de planches ou lattes ou encore un simple bâton pouvant être affûté pour donner un épieu. Combiné à la forge les possibilités grimpent drastiquement avec les haches, lances, masses, pioches, pelles, etc.

L'idée de base étant de rendre chacun des ateliers interdépendants tout en permettant des productions spécifiques à celui ci, ainsi un «menuisier» seul peut produire des objets d'ameublements et de construction en bois. Ceci dans l'idée de permettre une spécialisation des joueurs (récompensée par les compétences qui permettent de produire des objets de meilleure qualité) sans que ce ne soit artificiel.

Même des ateliers en apparence complètement déconnectés peuvent se révéler complémentaires, par exemple le banc de chimie peut servir à développer un poison qui enduira la pointe d'un épieu ou d'une flèche.

L'autre avantage des différents systèmes d'artisanat du jeu est qu'ils ne représentent que très peu de travail pour créer les recettes de craft, limitant donc le temps requis pour les ajouter et facilitant le cas échéant le modding.

[leuhpoulpe]

Petite MAJ pour dire qu'une vidéo de test du rendu du système de construction est visionnable (en fin de message).
Elle a été faite pour vérifier le rendu d'un assemblage de «blocs» de 50cm*100, 50*50 et divers objets spéciaux (porte 200*100, poutre 300*25*25).
Le but était de voir s'il était possible de rendre quelque chose qui ne soit pas trop répétitif avec de si petits blocs. Bien entendu ce n'est absolument pas représentatif de ce sera le rendu des construction au final. Les règles de construction n'ayant par ailleurs pas été respectées.

Par ailleurs je suis pour ma part en train d'étudier de façon plus poussée les différents moteurs envisageables, en ce moment Unity. Suivant ce qu'il en ressortira je mettrai à jour le type de profil recherché pour le programmeur.

[ame="http://www.youtube.com/watch?v=VDp3bw-m_WY&hd=1"]http://www.youtube.com/watch?v=VDp3bw-m_WY&hd=1[/ame]

[yoyo3d]

Salut à tous, je trouve ton projet à la fois simple et titanesque.
je m'explique, le gameplay semble à la base, simple: manger, explorer,fabriquer, mais terriblement vaste par le crafting. c'est tout a fait le genre de jeu que je recherche.

Comment se fera la communication entre les joueurs (tchatbox ?)

En tout cas, le style grafique de l'interface me plait egalement (je n'ai pas pu voir les video, je suis au bouot...)

Vous faites les objets 3D avec quels logiciels?

[leuhpoulpe]

Salut à tous, je trouve ton projet à la fois simple et titanesque.

C'est l'idée, proposer des mécaniques relativement simples mais qui, les unes dans les autres permettent une expérience de jeu vraiment complète.
Que ce soit au niveau de l'artisanat, la construction ou la gestion de personnage tout est dans l'imbrication des différents éléments du gameplay.

La communication entre les joueurs se feraient via un tchat oui, l'idée étant de proposer une option à cocher (côté serveur) qui ne permet aux joueurs à n'accéder qu'à un channel local. En somme les joueurs ne pourraient communiquer qu'avec ceux qui sont à "portée de voix".
A terme il serait intéressant d'implémenter un système de VOIP qui lui ne permettrait que les discussions locales.

Je te remercie pour les interfaces. Autrement les modèles 3D sont fait avec blender.

[yoyo3d]

Re...
je viens de rentrer du boulot et l'anim de la construction du batiment est vraiment sympa, j'imagine que plus de personne travaillent sur le batiment, et plus la construction va vite...
c'est tout a fait le genre de systeme que j'avais envie de réaliser.

pour blender , je modelise un "chouillat". quel niveau de détail tu à in game pour les objets, (par exemple une pelle ou un outils à main,) tu vas jusqu'à combien de poly?

en tout cas beau projet.

[leuhpoulpe]

Re...
je viens de rentrer du boulot et l'anim de la construction du batiment est vraiment sympa, j'imagine que plus de personne travaillent sur le batiment, et plus la construction va vite...
c'est tout a fait le genre de systeme que j'avais envie de réaliser.

La vidéo est un rendu blender, ce n'est pas du Ingame, bien que les éléments qu'on y voit soient ceux prévus pour être dans le jeu (à un stade précoce cependant). La vidéo a été faite pour tester le rendu des éléments de construction dans un bâtiment (répétition, etc), par conséquent on n'y voit pas que les constructions se font par les joueurs lorsqu'ils placent un élément de construction. Mais au final oui, plus il y a de joueurs plus la construction avance vite.

Sinon, pour le niveau de détails, une pioche fait 235 polys pour le moment, mais après c'est fonction de l'objet et il est probable qu'elle gagne un peu en poly étant donné qu'elle est destinée à être juste sous les yeux du joueur.

Merci pour les compliments.

[zhouyu]

Projet très intéressant j'espère que tu arriveras au bout

[yoyo3d]

Salut, je reviens sur la vidéo de construction.
tu parles de répétition, je suppose que tu fait allusion à la répétition des textures.

Si lors de l'assemblage des blocs, les textures se repetent, effectivement cela risque de ne pas etre beau visuellement. PAr contre une fois la construction terminée, comment cela se passe t-il? l'assemeblage est remplacé par un objet complet (ou la tu pourra appliquer une texture beaucoup plus grande et donc moins répétitive) ou alors tu garde l'assemblage de bloc tel quel? un peu façon minecraft?

edit: en gardant la texture d'origine, mais en ajoutant aléatoirement une teinte plus foncé ou plus claire à chaque bloc, cela ne suffirait il pas à rompre la répétition?

[leuhpoulpe]

En effet je parlais de la répétition des textures/formes.
Le meilleur moyen que je connaisse pour éviter ça, ça reste de faire textures homogènes.
Par exemple, pour du bois, si tu places des noeuds très foncés sur un bois clair tu auras forcément un effet de répétition très visible. Tout le truc est donc d'éviter les textures avec des zones très reconnaissable (foncé sur clair ou l'inverse, forme reconnaissable, etc).

Autrement il y a deux autres possibilités, la première est d'avoir plusieurs textures pour un même objet, ces textures sont ensuite choisies aléatoirement. Au final la bordure de la texture doit rester identique sur chacune d'entre elle pour éviter les cassures lors de la répétition mais le centre peut n'avoir rien à voir. Cette technique a cependant pour inconvénient de demander plus de mémoire pour charger les textures alternatives.
La seconde possibilité est le decal, aléatoirement une seconde couche de texture vient s'appliquer sur la première, elle doit être majoritairement transparente et ne fait en fait que rajouter des détails de façon aléatoire (par exemple de la rouille sur du métal). Le CryEngine propose notamment un système de decals que je trouve vraiment sympathique.

Autrement les éléments placés restent sous forme d'élément, il n'y a pas de fusion prévue. Cela impliquerait d'avoir des modèles supplémentaires à cet effet et cela interdirait le démontage/destruction des éléments construits.

[yoyo3d]

Ok perso, je ne connaissais pas le "decal" et effectivement, c'est probablement la meilleur solutioncar je suppose que l'algo est moins gourmand en mémoire que le stockage de texture.

dans le screen "interface de l'atelier", la hache affichée est elle identique en rendu 3d in game? ou est ce juste une représentation "symbolique" de l'objet que peut produire l'atelier? (hum je ne sais pas si j'ai été claire là... )

Je modélise un chouillat sur blender et c'est plutot starwars mon domaine, mais si tu a besoin d'un coup de pouce, n'hesite surtout pas .

edit: autre question: les constructions sont basées sur des models prédéfinis?

[leuhpoulpe]

Ok perso, je ne connaissais pas le "decal" et effectivement, c'est probablement la meilleur solutioncar je suppose que l'algo est moins gourmand en mémoire que le stockage de texture.

Le decal est moins gourmand oui, et plus polyvalent. Toujours dans le cas de la rouille, au lieu d'avoir des textures avec variantes pour chaque objet métallique, tu peux avoir une seule texture par objet métallique et un ou plusieurs decals qui seront communs à tous. Moins de données à charger donc économie de mémoire. C'est vraiment un système sympa pour ça.
Le soucis qu'il pose, au moins dans le CE, c'est que généralement il n'est pas vraiment applicable sur un objet mobile dans l'espace, du moins pas sans modification du code associé toujours.
Unity n'a pas l'air de le permettre, mais tout moteur qui permet d'appliquer plusieurs maps de texture permet en théorie, par extension, le principe du decal.

Autrement tout ce que tu vois dans les artworks d'interface sors de photoshop uniquement, au final il y a de très fortes chances pour que les objets y soit présentés sous forme de rendu pour des raisons de temps de travail. Quoi qu'il en soit je te remercie du compliment involontaire.

Les constructions se font à l'aide d'éléments de 50*50,100*50 et des objets spéciaux (portes, etc), ce qui en est fait ... c'est au joueur de voir. S'il veut faire un labyrinthe, un mur de fortification ou autre, c'est tout à fait possible.

Pour ce qui est de ta proposition, si nous nous rendons compte qu'on a besoin d'un coup de main, je te ferai signe sans soucis. Merci de te proposer.

[yoyo3d]

Salut, cela fait un moment qu'il n'y a pas eu de news ici,
Ou en est le projet ???

[leuhpoulpe]

Salut,

Le projet suit son court. Un programmeur d'expérience est maintenant parmi nous donc la situation devrait commencer à évoluer.

Pour le moment nous sommes en train de poser les bases donc il n'y a malheureusement pas grand chose à montrer, mais ça viendra, à priori d'ici deux mois on devrait avoir un début de prototype.
Il est prévu de travailler les pans de gameplay un à un, par exemple actuellement on est sur le contrôle et la gestion du personnage (déplacements, santé, fatigue, etc) et l'inventaire.
Après quoi on s'attaquera assez rapidement au système de construction, qui devrait nous occuper un certain temps.
Bien sûr parallèlement on travaille aussi sur les assets.

Voilà voilà.

[yoyo3d]

Bien, le projet continu.

qu'appels tu "assets"? j'ai cherché, mais je suis principalement tombé sur les assets managers dans le monde de la finance qui n'ont probablement pas autant de rapports avec ton projet que ça


enfin, n'hésite pas à annoncer les ptites avancées, ça fait toujours plaisir de voir les p'tits détails...

A+

[leuhpoulpe]

Les assets ce sont les éléments qui se greffent sur le noyau du projet en lui même (le moteur Unity 3D), ça peut être des modèles 3D, des textures, des scripts, etc
Dans ce cas précis je parlais surtout des objets, éléments d'interface et autres éléments graphiques.

Je ferai une "vrai" mise à jour quand on aura bien entamé le système de construction.

[yoyo3d]

haaa, ( et c'est la que nous atteignons mes limites....)
comment décides tu que tel élément fait parti du noyau et tel autre élement fait parti des "asset"?
bon pour le moteur j'aurais eu bon car il fait parti intégrante du code source, même s'il peut etre codé "à part", mais les scripts.... c'est pas considéré comme du "code" au sens strict du terme???

A+

[leuhpoulpe]

Eh bien en fait je ne décide de rien, pour formuler autrement (et j'espère mieux), un asset est un composant qui nécessite une importation dans le projet, autrement dit qui n'est pas natif du moteur mais sera utilisé par celui ci.
Voilà une définition trouvé ici :

"(Informatique) Ressource numérique, composant, modèle, processus ou framework qu’il est possible de réutiliser, dont on peut envisager une exploitation générique."

Autrement dit c'est un composant qui est utilisé par un système. Donc un script rentre dans la définition.

Voilà voilà.