Je me nomme Laurent (sous internet on me connaît sous le pseudo de Lolilolight), j'ai 30ans, je suis Belge et je suis développeur. J'ai déjà travaillé sur plusieurs petits projets dans le passé, comme celui-ci : (Petit problème avec le logiciel d'enregistrement, il a figé la première partie de la vidéo, et en plus, on entends de mon ventilo qui souffre à mort)
C'est une application qui détermine la caractère de la personne en fonction de ce qu'il choisit de répondre, projet que j'ai développé dans le cadre d'un bénévolat.
J'en ai réalisé pleins d'autres mais je n'ai plus les sources.
Mon niveau d'étude est bachelier en informatique de gestion.
Je vais vous parler du projet Sorrok.
Genèse.
Le projet a commencé il y a plus de 10 ans, à l'époque je l'avais commencé avec un membre qui avait observé mes compétences et qui m'avait proposé de créer un jeux ensemble, on était une équipe de 4-5 personnes, mais ils ont tous arrêter par démotivation, et donc, au final il ne restait plus que moi.
Je n'ai pas beaucoup avancé sur le jeux car ayant eu des soucis avec certains moteurs de jeux, j'ai été contrains de coder mon propre moteur de jeux, mais maintenant mon moteur de jeux me permet d'avancer sur le jeux.
Cette envie de développer mon propre jeux vidéo en ligne me viens depuis l'âge de 14-15 ans, lorsque j'ai commencé à avoir un ordinateur et à jouer aux MMORPG, je commençais a vite m'en lasser, alors je me suis dis "ça serait plus amusant de coder le mien" et en effet, coder le moteur de jeux et le jeux est un vrai plaisir pour moi et il y a aussi l'envie de devenir game master, gérer une communauté.
Le jeux est en 3D isométrique.
Généralités et avancement.
Outils utilisés et fonctionnalités.
Le projet est développé entièrement en c++14, j'ai choisi ce langage car les nouvelles fonctionnalités du langage c++11 et c++14 permettent d'implémenter du code générique qui facilite grandement la conception de librairies.
Grâce aux nouvelles fonctionnalités du c++11 et du c++14 le moteur de jeux est capable de :
-Créer et appeler des fonctions personnalisées pour chaque évènements de manière générique.
-Écrire tout type d'objets de manière générique dans un fichier, sans se soucier du format de fichier.
-Définir des actions de manière générique pour un ou plusieurs évènements.
-Définir un comportement pour une même famille d'objets.
-Supprimer/restaurer des états de manière générique.
Le projet utilise aussi SFML pour le fenêtrage, le réseau et le son ainsi que la librairie openssl pour le chiffrement.
Avancement.
Ce qui est implémenté :
-Scène nodes.
-Gestion de la 3D isométrique.
-Stockage des objets dans une grille virtuelle.
-Récupération des objets visibles.
-Rendu des objets à l'aide de composants.
-Batching.
-Gestion des collisions.
-Gestions des animations.
-Systèmes pour remettre à jour les objets.
-Rendu des ombres.
-Rendu des lumières.
-Système de combat. (PVE)
Voici une vidéo qui montre l'avancement. (J'ai corrigés certains bugs depuis mais le logiciel de capture vidéo bug)
-Programmation graphique : les shaders ne fonctionnent pas sous windows actuellement (ça ne m'affiche rien) et sous linux, les ombres clignotent, lorsque je les déplace avec une matrice de projection.
Ce qui me gêne car, tout les jeux commerciaux tournent sous windows.
-Programmation réseau : les données côté serveur et côté client ne sont pas toujours bien synchronisées.
-Graphisme : retouche de certaines images gratuite prise sur internet pas bonne.
-Order independant transparency. (Per pixel linked list pas supportées par ma carte graphique, les techniques que j'ai utilisées ne rendent pas bien avec les textures utilisées, je pense laisser tomber ce point, tout mettre sur une grande texture et faire un tri, je ne vise pas à implémenter des fonctionnalités trop complexe pour l'instant, ce n'est pas le but et je n'en ai pas encore l'expérience)
Objectifs :
-Faire de Sorrok mon tout premier projet commercial. (En effet, les allocations de chômage sont pas élevée et dans le monde du travail, si tu n'es pas rentable on ne te prend tout simplement pas)
-Passer du monde amateur au monde professionnel.
-Rentabilité. (J'aimerais prouvé que je peux être rentable sur le marché de l'emploi)
-Permettre dans le futur la création d'un jeux plus évolué, en 3D.
-Faire en sorte que le jeux aie du succès.
Le projet et son originalité.
Faire de Sorrok un jeux qui attirera un maximum de joueurs, avec un gameplay innovant qui sera défini en fonction d'une part par le game designer mais aussi d'autre part par les futurs joueurs qui pourront exposé leurs idées à travers un forum (sans favoriser certains joueurs par rapport à d'autres), bien sûr, les joueurs qui paient pour le développement du jeux seront favorisés comme sur tout les jeux en lignes. (Statistiques améliorées, accélération de l'expérience, etc...)
Je ne peux pas vraiment en dire plus car il est difficile, pour un simple développeur tel que moi, de définir l'originalité du projet, moi je suis plutôt le genre de personne qui dicte à l'ordinateur ce qu'il faut faire pour pouvoir y arriver, mais pas celui qui innove. Mes compétences limitées au niveau technique.
Un gameplay avait déjà été proposé dans le passé par un game designer, malheureusement avec le temps, j'en ai perdu le contenu.
Recrutement.
Sorrok est mon tout premier projet ambitieux et commercial et pour le finaliser je vais donc avoir besoin d'un petit coup de main de la part de personnes plus expérimentées que moi.
Une rémunération est envisagée pour les membres ayant participé au développement du projet.
Profil type recherché : ayant de l'expérience dans le domaine de la création de jeux vidéo en ligne à but lucratif et dans tout ce qui touche à la programmation au niveau du GPU.
Profil type recherché :ayant de l'expérience dans le domaine de la création de jeux vidéo en ligne à but lucratif et dans le tout ce qui est synchronisation de données entre le client et le serveur.
Un(e) game designer(euse) :
Profil type recherché : ayant de l'expérience dans le domaine de la création de jeux vidéo en ligne à but lucratif, être capable de réaliser des gameplay innovant et tirer bon parti des idées d'évolution du gameplaysuggérées par la communauté.
Un(e) modeleur(euse)/graphiste 3D :
Profil type recherché :ayant de l'expérience dans le domaine de la création de jeux vidéo en ligne à but lucratif, maîtrise d'au moins un logiciel de modélisation 3D)
Un(e) graphiste 2D :
Profil type recherché :ayant de l'expérience dans le domaine de la création de jeux vidéo en ligne à but lucratif, maîtrise d'au moins un logiciel de graphisme 2D)
Un(e) développeur(euse) web :
Profil type recherché : ayant de l'expérience dans le domaine de la création de jeux vidéo en ligne à but lucratif, maîtrise des langages utilisés pour concevoir un site web avec un forum et une plateforme de vente en ligne.
Et bien sûr, être sérieux.
Comment postuler ?
Contacter moi à l'adresse mail suivante : laurentduroisin@gmail.com.
Seul les candidatures accompagnées d'un CV et d'une lettre de motivation seront acceptées.
Salut! Comme j'ai créer ce sujet avec un autre compte (celui-ci était bloqué), je ne peux pas le modifier pour corriger les fautes de frappes.
Je vais donc simplement apporter quelques nouvelles :
-J'ai été contrains de créer un module fenêtre pour le moteur de jeux car celui de la SFML provoque un crash lors de la création d'une sous fenêtre pour le jeux, j'ai donc pris du retard, j'ai pu néanmoins commencer à coder le système de ramassage d'objets. (Je dois encore faire l'inventaire et normalement ça sera bon)
-J'ai des problèmes d'affichage avec les shaders depuis que je suis passé de ubuntu 14.04 à ubuntu 18.04 (et donc à la nouvelle version de MESA, le driver graphique opensource sous linux), en effet, parfois les lumières s'affichent au dessus des objets qui se trouvent devant et pour les ombres, lorsque je rajoute le réseau, les ombres que je déplace avec une matrice de projection, pour les remettre au bonne endroit, clignotent donc, elles ne s'affichent pas à toutes les frames.
De plus, opengl 3.3 ne fonctionne pas même si la nouvelle version de mesa me signale que cette version est supportée. (Je n'avais pas ce soucis sur windows)
Je n'ai pas encore recoder le module fenêtre pour la compatibilité avec windows mais j'espère que le fait d'éliminer une dépendance fera en sorte que les shaders s'afficheront sous windows. (En général une dépendance en moins est une sources d'erreurs en moins, cependant parfois, c'est bien de pouvoir réutiliser l'existant mais, pas toujours apparemment)
Mais avant d'assurer une compatibilité avec windows j'aimerais terminer le jeux.
J'ai essayé de retirer les pointeurs vers les classe gérant les shaders et les textures de rendus car j'ai remarqué que ça ne s'affichait pas toujours très bien lorsque j'utilise des pointeurs, mais là j'ai un bug bizarre lorsque je retire les pointeurs : (un crash, carrément, une adresse qui devient invalide)
Je ne sais pas si le problème provient :
-De mon code. (si c'est le cas je ne vois pas ou car lorsque j'affiche la valeur du vecteur elle est valide mais lorsque je veux effectuer la soustraction avec un autre vecteur, c'est là que j'ai le crash si je retire les pointeurs)
-Du compilateur. (Je ne tiens pas à en recoder un, ça prendrait trop de temps, surtout un qui gère les nouvelles fonctionnalités du c++14)
-De la machine. (Là encore je ne tiens pas à en racheter une, ni à en fabriquer une moi même pour avoir un language assembleur plus simple, même si j'ai des notions en électronique mais ce ne sont que des notions de base, j'ai juste appris comment un PC fonctionne, mais pas comment bricoler dedans et donc aucune pratique, dommage, j'aurai bien aimé)
J'ai pensé que pour l'avenir çà serait bien d'avoir (si le jeux marche bien et me permette d'avoir mon propre studio) :
-Un ingénieur du son.
-Un électronicien. (Pour réparer les pannes, maintenant je pense qu'il est moins cher d'acheter une machine, plutôt que de payer quelqu'un pour en fabriquer une)
Pour l'instant le mieux à faire je pense (pour moi) c'est de continuer seul malgré mon manque d'expérience, (je ne pense pas qu'il y ai de professionnels sur ce site et si il y en a je n'ai pas encore reçu de candidatures donc...) faire quelque chose de simple mais qui a du succès pour pouvoir financer la suite.
-J'ai tenté une compatibilité sous windows mais c'est vraiment la misère, l'OS ne me trouve pas certains fichiers en compilation, je pense que je vais juste faire une compatibilité linux, windows ça me gave en tout point.
-J'aimerais utiliser une très grande texture et faire un tri de tout les objets car c'est plus simple, le problème c'est que gimp ram à mort avec les grandes images (10 000 * 10 000). J'ai tenté de faire de l'OIT pour pouvoir utiliser plusieurs textures, mais c'est la misère, les textures ne s'affichent vraiment pas bien malgré que ça fonctionne les couleurs. Il existe peut être un autre logiciel plus rapide pour manipuler des grandes images, mais je n'en connais pas de gratuit.
-Idem pour filmer, Kazam ne marche plus aussi bien que pour la première vidéo que j'ai faîte et ça me film en gris.
-J'ai commencé le système d'objet, bonne nouvelle, ça ne crash plus à la création de la sous fenêtre pour ramasser les objets comme c'était le cas avec la SFML, mais j'ai un autre problème, avec l'OIT justement, parfois (pas à toute les exécutions), la couche avec les murs, les décors, les personnages et les particules ne s'affichent plus.
-J'ai tenté un une utilisation des VBO pour l'optimisation mais ça n'optimise pas, au contraire, ça ralenti, en plus, certaines ombres ne s'affichent même plus, donc, j'ai du repasser aux vertex arrays.
-J'ai passé le dépôt git en privé, de ce fait, seul les contributeurs auront accès au code du moteur de jeux, du jeux et du site web, le site web ne s'affiche plus du coup car on ne peut pas l'afficher avec un dépôt git privé, le système de don retiré du coup, quelqu'un m'avait fait la remarque lorsque je l'avais retiré mais j'avais eu une blague de très mauvais goût d'une personne qui a voulu me faire croire qu'une société me rachèterait le moteur.
-Avec un dépôt git privé je ne peux avoir que maximum 3 contributeurs et donc 3 programmeurs maximum, pas plus.
Je pense que tu devrais revoir tes conditions quand tu dit vouloir un CV et une lettre de motivation, ici en priorité tu as des amateurs et des nouveau né.
Donc n'espère pas trouver ici quelqu'un ayant un Master en programmation.
Ici quand tu te lance dans l'aventure il faut un peu faire confiance aveuglément et il arrive que tu tombes sur quelques pépites.
Personnellement j'aurais bien pris par à ton projet mais il a beau être sérieux j'ai l'impression que t'en fais beaucoup trop pour un projet qui n'en est qu'au prémices.
Le travail d'équipe ne mène que jusqu'au Trophée, seul l'être réellement évolué peut s'en emparer pour sa gloire personnel XD.
Je pense que tu devrais revoir tes conditions quand tu dit vouloir un CV et une lettre de motivation, ici en priorité tu as des amateurs et des nouveau né.
Donc n'espère pas trouver ici quelqu'un ayant un Master en programmation.
Ici quand tu te lance dans l'aventure il faut un peu faire confiance aveuglément et il arrive que tu tombes sur quelques pépites.
Personnellement j'aurais bien pris par à ton projet mais il a beau être sérieux j'ai l'impression que t'en fais beaucoup trop pour un projet qui n'en est qu'au prémices.
Tu as sans doute raison, j'en attend sans doute de trop hors que le projet n'est qu'à ses débuts.
Les amateurs qui souhaitent comme moi se lancer sont les bienvenus.
J'ai codé le système de ramassage des objets et l'inventaire du héro, mais en ce moment j'ai les nerfs qui lâchent, je manque de motivation et je dors très peu, donc, je continuerai un peu plus tard...
Je pourrai bientôt poster une nouvelle vidéo pour le système d'objet enfin, si je trouve un logiciel pour filmer qui fonctionne bien.
Aujourd'hui je suis super content car j'ai réussi à résoudre des crashs.
J'ai réussi à retirer les pointeurs, sans que ça ne plante, j'ai juste eu à installer le paquet "clang" en plus de g++-4.9 et ça ne crash plus, de ce fait, je n'ai plus de bugs d'affichage.
Les objets s'affichent dans l'inventaire du personnage désormais, je n'ai plus qu'à gérer l'utilisation des différents objets et après, je ferai une petite vidéo.
Par contre, j'ai essayé (encore) un algorithme pour faire de l'OIT trouvé dans le livre openGL superbible que j'ai adapté avec un shader pour filtrer les pixels semi-transparents et opaques (pour les textures contenant des pixels semi-transparents et opaques) mais ça ne fonctionne pas, j'ai des pixels bleus qui s'affichent sur les textures. (pas à toutes les frames)
Pour pas faire d'OIT je dois utiliser des grandes textures mais comme je l'ai déjà dit ça fais trop ramer GIMP, alors, je sais plus trop quoi faire, pour l'instant je ne dessine que des pixels opaque. (sauf pour le sol ou je fais un tri)
Alors pour gérer la semi-transparence j'ai fais du weighted blended OIT et ça à l'air pas mal. (Il y a un peu de transparence sur mes tiles opaques et ça va, ça supprime les points bleus que j'avais sur les textures)
Donc je peux maintenant finir le système de gestion des objets tranquille, ensuite viendra le système de quêtes et de compétences et j'ai fini la base du jeu.
Ensuite viendra la sauvegarde dans une base de donnée, l'éditeur de niveau et le site web et j'ai fini.
Je ne sais pas encore comment je vais financer l'hébergement du site et du serveur de jeux...
Dans la classe GameAction je vérifie si il peux utilisé l'objet en fonction de sa classe (ou le sors pour plus tard), et si oui, j'appelle le foncteur :
Je ne sais pas si c'est vraiment une bonne manière de procéder car c'est la première fois que je code un système aussi complexe, par contre, ce qui est bien, c'est que je ne dois pas faire de l'héritage avec une nouvelle classe fille pour chaque type d'item ou chaque nouvelle classe de héro, ou chaque nouveau type de sors, ce qui rendrait le code trop lourd.
Je vais aborder ici plusieurs points qui ne seront pas plaisant à lire, mais qui, si vous en prenez compte, vous permettrons d'éviter de vous investir dans un projet dont les résultats ne seront pas à les hauteur de vos attentes.
Le premier point concerne le produit que vous essayez d'obtenir : un mmorpg 2d.
Un mmorpg (ou massively multiplayer online role playing game) est un produit qui n'est pas à la portée d'une équipe amateur (sans parler d'une personne seule). En effet, il y a beaucoup d'aspects internes à prendre en compte, et beaucoup de facteurs externes qui peuvent réduire le travail fournis à néant.
Parmi les aspects internes, et passant outre la composition d'une équipe prête à travailler sur plusieurs années, on retrouve la complexité de mise en oeuvre (comment les éléments de gameplay interagissent entre eux, comment les profils utilisateurs sont gérés, quels sont les scénarios de pannes, etc.), la quantité/qualité de contenu à proposer afin que les joueurs ne partent pas aprés dix/vingt/cents jours, les sources de revenus pour payer les serveurs, logiciels et (dans un second temps) l'équipe.
Parmi les facteurs externes, il y a la (très) grande concurrence avec les jeux existants, qui nécessite que le produit proposé possède des éléments suffisamment différents pour attirer des joueurs, et les joueurs eux-même, qu'il faudra attirer (via de la publicité, par le bouche à oreille, et par bien d'autre canal de communication), et retenir (Et donc, en avoir suffisamment en même temps pour qu'ils trouvent pas le jeu vide).
Un mmorpg, même 2d, n'est pas un projet viable commercialement. Il peut-être intéressant en terme d'apprentissage pour un programmeur, mais ses chances d'être mener à terme sont presque inexistante, et celles d'être pérenne sont encore moindre.
TL;DR : Un mmorpg n'est pas un projet réalisable par des amateurs.
Le second point concerne les choix technologiques pour l'objectif commercial.
Refaire tout par soi même est amusant, et je ne saurais le déconseiller si l'objectif était d'apprendre pour le plaisir. Toutefois, l'un des objectifs est de pouvoir rendre le projet rentable. Hors, un projet est considéré comme rentable que si son coût de production et ses coûts de maintenance (de manière simpliste) sont inférieurs aux revenus engrangé. Et dans le coût de production vient le temps passé à développer le produit. Si vous mettez trois années complète (considéré temps plein pour plus de facilité) pour finaliser et mettre en vente votre produit, il vous faudra récupérer ces trois années de salaires (même si vous n'avez perçu que le chômage) (en plus des autres frais) avant de pouvoir affirmer que votre produit est rentable.
De même, si Linux n'est pas un mauvais choix de plateforme en soi, Windows reste actuellement le système d'opération ayant le plus de clients potentiels.
Dans cette optique, il serait peut-être bon d'envisager l'utilisation d'un moteur de jeu déjà existant tel qu'Unreal, qui utilise le C++ et permettra une exportation aussi bien vers Linux que vers Windows. Bien sur, d'autres moteurs pourraient être plus adaptés, selon vos attentes.
TL;DR : Ne perdez pas de temps à réinventer la roue et utilisez des solutions qui ont déjà fait leur preuves.
Le troisième point concerne votre demande.
Votre objectif est de recruter des personnes ayant des compétences diverse afin d'atteindre vos divers buts. Toutefois, ceux qui pourraient être intéressés seront probablement des amateurs ou des juniors, sans réelles expériences du travail en équipe (voir du métier). Il faudra donc vous attendre à ce que ces personnes partent pour diverses raisons.
Par ailleurs, votre projet n'est pas clairement établi, possède des points trop vague. C'est notamment le cas pour le gameplay. En effet, vous indiquez que celui-ci doit être innovant, mais aussi que ce sera au game designer de définir les points d'innovations. Et en cela, vous démontrez que vous ne savez pas dans quoi vous vous lancez. Pour exemple, si un game designer vous rejoignais, et vous proposait de faire en sorte que le produit soit en monde ouvert en réalité virtuel avec la possibilité de lancer les sorts en les prononçant de vive voix et d'attaquer en faisant les mouvement adéquat, que feriez-vous? Si vous répondez positivement, vous vous lancerez dans un projet technologiquement impossible à réaliser (sans vouloir entrer dans le débat, sachez juste que la reconnaissance vocale et la détection de mouvement complexe sont particulièrement complexes). Par ailleurs, si vous répondez négativement, vous aurez perdu du temps et de l'énergie, ainsi qu'un collaborateur potentiel.
Il est donc important qu'en tant qu'initiateur du projet, vous sachiez exactement quel sera être le résultat final. Et dans le cas présent, au vue de la complexité du produit que vous souhaitez produire, il ne sera que plus intéressant de revoir votre projet à la baisse, voir partir sur un nouveau projet plus simple (voir simpliste).
TL;DR : Concentrez-vous sur la formation d'une équipe stable autour d'un petit projet suffisamment réfléchis.
Le quatrième point concerne vos compétences.
Je vais parler ici uniquement de vos compétences en programmation, et par rapport à ce que vous avez montré lors de précédents messages. Par ailleurs, pour ajouter du contexte à mes propos, sachez que je travaille en tant que programmeur C# avec le moteur Unity. Ceci est donc purement subjectif.
Il est évident que vous n'avez pas encore bien intégré certains principes de la programmation orienté objet, et que vous mélangez objet et classes (ceci est un constat, pas une critique visant à vous dévaloriser). Ainsi, dans votre exemple de classes, vous avez les classes "Novice", "Warrior", "Magician" et "Thief", chacune possédant sa propre classe d'objet (ou en tout cas, étant représenté dans votre code comme quelque chose de définis). Hors, une classe "Class" est suffisante. En effet, même si un novice ne peux pas utiliser les mêmes objets qu'un guerrier, ni les même sorts qu'un magicien, il n'en reste pas moins qu'il peux utiliser des objets et des sorts.
Pour mieux expliciter mon point de vue, je vais décrire, de manière simplifié, la façon dont j'aborderais le problème :
4 classes sont disponibles :
Novice,
Warrior,
Magician,
Thief
4 objets sont disponibles :
HPPotion
ManaPotion
OrbOfDormammu
ThrowingKnives
Les classes correspondantes seront donc :
Une classe Entity, contenant une référence d'une Class et d'un Inventory,
Une classe Class, contenant un tableau d'Item (whitelist) et un tableau de Stat,
Une classe Inventory, contenant un tableau d'Item auquel est associé une valeur entière (Number)
Une classe Item contenant une valeur entière (ID), une référence d'une Stat et une valeur entière (Value),
Une classe ThrowableItem, qui hérite d'Item, et contenant une valeur entière (ThrowableBehaviour).
La façon dont va interagir les différentes classes est la suivante (les méthodes sont écrite en c#) :
Lorsque la méthode "UseItem(int pIndex)" de l'objet Entity est appelée, celui-ci fait appel à la méthode "CanUse(int pItemID)" de l'objet Class auquel il est associé, lequel va vérifier dans sa whitelist si l'ID s'y trouve, et renvoyer le résultat. Si celui-ci est négatif, rien ne se passe. Si celui-ci est positif, la méthode "Use()" de l'objet Item. Cette méthode ajoutera la valeur de (Value) à l'objet Stat associé.
Les données pourraient ainsi être représenté tel que :
TL;DR : Vous n'avez pas encore un niveau suffisant, et vous devriez apprendre quelques patrons de conceptions.
Enfin, le cinquième et dernier point concerne vos objectifs.
Globalement, vos objectifs vont dans le sens de devenir un développeur de jeux vidéo professionnel. De ce fait, je vous conseillerais de mettre votre idée (version revisitée, s'entend) de coté, et de vous concentrer sur de petits projets (morpions, tetris, bejewel, etc.) que vous pourriez faire seuls, afin d'étoffer votre portfolio. Ensuite, si vous apprenez à utiliser des moteurs de jeu tel qu'Unreal ou Unity, vous pourriez postuler dans divers studio qui recrutent régulièrement (par exemple sur l'agence française du jeux vidéo). Je ne pourrais vous conseiller de studio belge car, travaillant dans le milieu, il est difficile de s'y faire embaucher (tout du moins dans le Hainaut).
Bien entendu, ce qui est écris n'est qu'un conseil, et d'autres personnes pourraient vous conseillez d'autres approches peut-être plus judicieuse pour votre situation.
TL;DR : Réalisez des jeux simple (voir simpliste) pour vous familiariser avec des moteurs de jeu, et postulez dans des entreprises afin d'augmenter votre expérience.
Note : Pour rappel, aucun propos ici n'a pour but la dévalorisation, mais bien l'orientation vers des alternatives vous permettant d'atteindre vos objectifs, tout en vous prévenant des possibles écueils auxquels vous aurez à faire face si vous souhaitez tout de même continuer sur votre projet tel qu'il est à l’heure actuelle (ce qui est votre droit le plus strict).
Salut, je ne suis plus "vraiment" un amateur et j'ai déjà réaliser des petites applications (autre que pour moi même) c'est pour ça que je me suis lancé sur un plus gros projet et puis peu de MMORPG intègrent des graphismes avec gestion de lumières, ombres et plus tard la réfraction.
De plus je ne connais pas de MMORPG qui tournent sous linux, j'ai essayé avec la platforme wine d'en faire fonctionner quelques uns mais pas moyen donc, j'ai été déçu, c'est pour cela que je me suis dis ça serait bien d'en créer un ne nécessitant pas l'utilisation de wine.
Maintenant, je le fais avant tout pour m'amuser, apprendre et parce que je m'en suis lassé du développement des petits jeux, la rentabilité ça, ça passera après.
J'ai essayé d'utiliser des moteurs de jeux existants (de ceux que tu as cité) mais j'ai eu des problèmes d'affichage, de gestion de collision aussi, c'est pour ça que j'ai créer le mien qui fonctionne bien sous linux.
Maintenant la compatiblité windows je pense laisser tomber même si, un grand nombre d'utilisateurs utilisent windows, et ce n'est pas parce que j'ai essayé d'utilisé un moteur de jeux existant que ça a fonctionné sous windows, en plus il y a facilement moyen de mettre linux à côté de windows et en plus, linux est gratuit et opensource. Sous windows si il y a un bug que ce soit avec mon moteur ou un moteur de jeux existant je ne peux rien tenter. (Code source propriétaire)
Peu importe le moteur que j'utilise (surtout sous windows), bug d'affichages, bugs de collisions, bref, ce n'est pas pour rien que j'ai créer mon propre moteur de jeux. Code source plus simple, aussi, que je comprend mieux, ça aide énormément dans la résolution des bugs, car dans d'autres moteurs ils utilisent les même techniques de rendu mais avec un code source plus complexe que je ne comprend pas pour le normal mapping, le dereffered rendering et tout ça.
Et puis finalement j'ai trouvé que faire un moteur de jeux simple en 2D c'est plus simple que d'utiliser un moteur de jeux existant ou il faut comprendre tout les rouages et toutes les mécaniques.
Bref, c'est comme réinventer quelque chose mais plus simplement, il y a moyen de réaliser des applications très complexe avec un code très simple tout dépend de la façon dont on raisonne et puis la plupart des formules complexes sont sur Internet donc je n'ai même pas eu besoin à réfléchir, de plus avec les petites libs, ça rend les choses encore plus simple.
Donc mon moteur de jeux finalement c'est quoi : des formules et du code source trouvé sur Internet que j'ai remanié pour simplifier le code source et l'utilisation de petite libs dont j'ai aussi remanié le code source de certaines libs comme la SFML par exemple.
Et puis personnellement pour un développeur, devoir passer par une interface avec pleins d'options avec les moteurs de jeux pré-existant je m'y perd hors qu'avec du code source de petites libs c'est simple.
Je ferai juste une interface graphique pour l'éditeur de map, et puis, peut être un éditeur de script c++ mais pas une interface avec pleins d'options que je n'utiliserai sûrement jamais car trop complexe pour un amateur.
Donc finalement je ne pense pas que ça soit plus simple avec un moteur de jeux déjà existant, même pour créer des petits jeux, j'ai plus simple à la faire en c++ directement. (J'ai jamais réussi avec un moteur de jeux existant, même pour créer des petits jeux, j'avais toujours des bugs)
Maintenant je ne sais pas si je deviendrai un développeur de jeux vidéos professionnel, si j'y arriverai un jour, mais, en tout cas, le projet Sorrok ne va plus me prendre 3 ans, peut être un ou 2 ans maximum je n'ai plus que le système de quête et de sorts à réalisé et l'éditeur de niveau que j'ai déjà commencé aussi et qui est simple à faire quand on a un moteur de jeux qui en plus gère des guis.
Là aussi j'ai fais quelque chose de beaucoup plus simple au niveau des guis.
Ta solution est bien cependant moi je n'ai définit que des structures vide que j'utilise juste pour le Variant, pas besoin de spécifier, pour chaque classes, les ids des items utilisables,ce qui je trouve serait un petit peu lourd, je n'ai donc qu'une seule classe, pour tout les types de classes.
Ensuite lorsque je traite les actions du jeux je n'ai juste qu'à vérifier, avec l'id de l'item, si il peut l'utiliser ou pas (et je ferai la même chose pour les sorts) :
Pour les stats, je les stockes dans une std::map avec un id et la valeur pour chaque stats, mais je pense que plus tard je vais utiliser un State pouvant prendre des valeurs de n'importe quel Type pour par exemple les items de type "box" contenant d'autres items et donc là ce ne seront pas des stats mais des items.
Bref ça revient, à peu de chose près, au même que ce que toi tu fais, cependant moi, je veux avoir des structures vides pour les classes, et puis j'aimerais utiliser les fonctionnalités du moteur c'est à dire les naryvisitors, les variants, bref, ça simplifie les choses je trouve, pas besoin de mettre pour chaque classe les ids, il faut juste, tester, dans le foncteur, en fonction du type de l'objet, si il peut l'utiliser ou pas, même pas besoin de se soucier de la classe comme toi tu fais car, on la connais d'avance grâce à l'appel du bon foncteur, et je peux même faire un truc, genre, tel classe peut utiliser les items compris entre les ids [x,y] en faisant juste un test dans le foncteur.
void GameAction::operator()(const Hero::Novice&, Item& item, FastDelegate<void>& action) {
std::cout<<"action"<<std::endl;
if (item.getType() >= 0 && item.getType() < NOCICE_ITEMS) {
std::cout<<"Novice use item"<<std::endl;
action();
} else {
std::cout<<"can't use item"<<std::endl;
}
}
Bref, plus simple que de devoir spécifier les ids pour chaque classe et si on rajoute les sorts et d'autre choses, il faudra respécifier les iids pour les sort.
Hors que moi je n'aurai qu'à faire ceci ;
void GameAction::operator()(const Hero::Novice&, Spell& item, FastDelegate<void>& action) {
std::cout<<"action"<<std::endl;
if (spell.getType() >= 0 && spell.getType() < NOCICE_SPELLS) {
std::cout<<"Novice use spell"<<std::endl;
action();
} else {
std::cout<<"can't use spell"<<std::endl;
}
}
De plus imagine que l'action doit se faire non pas sur un item, ni un sort, mais sur un autre joueur, je ne vois pas comment tu ferais.
Bref, j'en ai fini avec l'utilisation d'objets, je vais bientôt envoyé la vidéo, mais avant, je dois régler quelques problème d'affichage, je dois réarrager mais tilesets pour les animations de combat, elles ne sont pas bonne dans toutes les directions.
Et après j'attaque les quêtes, là aussi tient il y a certaines quêtes qui sont réservées à certaines classes, donc là aussi il faudrait spécifier les ids avec ton système, ça ferait id des items + id des sorts + id des quêtes pour chaque classe, ça serait lourd.
PS : par contre un jeu avec un capteur de mouvement et de voix, franchement non, je n'ai pas le matériel pour, un capteur de voix, je pourrais essayé à la limite ("j'ai un micro") mais ça me semble complexe à réaliser.
Aujourd'hui, j'ai revu le système d'animations et plutôt que de modifier à chaque fois le pointeur sur la frame courante dans les composants de rendu ce qui rendait le code complexe, j'ai fais un seul pointeur sur un mesh qui contient tout les tableaux de sommet de la frame courante, ainsi, lorsque je change de frame, je n'ai qu'à changer le tableau de sommets, et comme j'ai un pointeur sur un mesh le tableau de sommets se me aussi à jour, dans le composant de rendu.
J'ai ajouté aussi la possibilité de faire des interpolations linéaire, pour ne pas devoir afficher trop de frames.
Ah oui et je vais également passer à assimp pour importer des modèles en 3D.
Je pense passer le jeux en 3D, car pour les animations, c'est vraiment trop galère à faire, faire un tileset de x frames fois 8 pour les 8 directions fois le nombre d'animations par personnages. Je n'y arrive pas au niveau graphismes, alors je vais utiliser des modèles 3D existant ou là, je n'airai qu'à importer et afficher sans devoir faire des retouches graphiques.
Salut, j'ai optimisé le moteur de jeux, car, pour l'affichage de la 3D, c'était beaucoup trop lent, déjà pour la 2D je n'avais que 5-6 de FPS et j'ai réussi à charger des modèles 3D avec assimp et les afficher.
J'ai remplacé tout les accès séquentiels par des accès indexés. (Les parcours de tout les élements des std::vector et le find de std::map étaient trop lent)
Et j'ai également remplacer des passages par valeur, par des passages par références et des pointeurs.
Je suis passé de 1 FPS à 40 FPS.
Par contre je ne peux pas "déstringifier" une std,,string pour la convertir en une valeur d'une enum en c++ même avec une macro.
Dommage ça aurait été plus rapide de déstringifier le nom d'une valeur d'une enum en compilation plutôt que de faire un std::find dans une std::map.
push_back ça m'a l'air d'être lent aussi, faire un resize et puis remplir le vecteur ça me semble être plus rapide.
Je dois optimiser encore car la copie des sf::Vertex est lente mais si j'ai un framerate trop élevé j'ai des bugs d'affichages. :/
Je crois que je vais devoir, revoir les classes du module graphique que j'ai reprise de la SFML mais complètement et faire quelque chose de plus simple.
J'ai des bugs avec les shaders, des bugs avec l'affichage de texte, ...
Et pour le réseau je vais aussi revoir le module SFML j'ai des erreurs avec openssl lors du transfert de clés sur le réseau.
Bref, j'ai déjà dû revoir le module fenêtre de SFML (car crash à la création de sous fenêtre avec contexte opengl), je l'ai recodé partiellement de manière plus simple et j'ai mis en commentaire du code (repris de la SFML) qui ne fonctionne pas, bref, je n'aurai pas dû passer par cette lib, j'aurai dû faire abstraction moi même sur les plus petites libs, en plus j'ai toujours du mal à m'y retrouver dans le code source des autres alors j'ai vraiment besoin d'un code source minime et simple.
J'ai essayer de faire en sorte de définir une macro pour ne pas devoir changer le code source si je veux changer de lib pour tester et ne pas devoir recompiler mais ça ne fonctionne pas non plus là aussi j'ai un crash avec la lib X11.
Le pire c'est la programmation graphique j'aimerais bien pouvoir voir les valeurs écrite dans mes textures, car, il y a vraiment des choses inquiétantes avec ça, parfois la lumière s'affiche devant le mur, parfois pas, une fois aussi il ne me changeait même pas n paramètre uniform, et quand je veux utiliser les classes de la nouvelle version de SFML ce n'est pas mieux mais pire encore.
J'ai trouvé pour les bugs d'affichages des guis mais par contre je n'arrive plus à mettre à jour le dépôt sur git, il me met à chaque fois "authetification failed" pourtant le mdp est bon car sur le site j'arrive à me connecter, et le nom d'utilisateur aussi est bon.
J'ai essayé d'installer renderdocs pour voir ce qui se passe au niveau des shaders et des fbo, pourquoi j'ai des affichages différents à différentes exécutions, mais le problème c'est que renderdocs ne supporte que la version 3.2 d'opengl jusqu'à la version 4.6 et en plus seulement le core profile, et comme la dernière version de mesa driver ne supporte que opengl 3.1, je ne peux pas utiliser ce logiciel, il y en a peut être un autre, je ne sais pas...
Ok non c'est bon j'ai trouvé, pour les bugs d'affichages et pour la lenteur c'était parce que j'avais oublié de retirer un sf::sleep dans la boucle d'exécution du client.
Maintenant ça marche du tonnerre!
Bon, je dois refaire mes tilesets mais j'en ai marre (c'est trop lourd à faire), je pense que je vais passer à la 3D et chercher des modules animé sur Internet (mieux pour un développeur) mais je n'ai pas encore trouvé de site ou on peut en télécharger gratuitement!
Ddans un premier temps je vais encore essayer d'optimiser pour atteindre 60 FPS avec un tableaux de pointeurs sur vertex ainsi, je ne devrai pas remettre à jour les sommets des animations dans les composants de rendu et j'évite les copies de sommets lors du sprite batching qui sont lourdes.
PS : oui mais non je ne pourrai pas car, à cause du sprite batching, je suis obligé de tranformer les positions des sommets au niveau du cpu, et donc copie obligée car je dois conserver la position des sommets avant la transformation pour les retransformer ensuite. Pour se faire il faudrait que je puisse envoyer toute les matrices de transformations d'opengl à un shader et récupérer aussi un id vers le sprire en cours de dessin. Malheureusement il faut utiliser l'instanced rendering pour faire celà et mesa driver ne le supporte pas. J'avais essayé sous windows en mettant les matrices dans un vbo mais ça n'a pas marché. (Il ne me traçait rien) Donc pour l'optimisation c'est mort. A moins que je puisse passer un attribut de sommet supplémentaire pour l'id et un tableau de matrices à un shader, je ne sais pas..., il faudrai que j'essaie.
Pour les bugs d'affichages en fait c'est mesa driver qui remet à jour la texture avant que les shaders aient fini de s'exécuter donc il n'affichent rien ou alors juste une partie du rendu...
J'ai reporté le bug mais comme je n'aime pas attendre que le bug soit résolu j'ai télécharger le code source de mesa driver pour regarder, cependant il me faudra aussi du temps pour trouver ou ça bug mais c'est un problème de synchronisation et il faut être très prudent avec la programmation asynchrone comme celle des GPU par exemple.
La bonne nouvelle c'est que j'ai découvert que les extensions d'OpenGL 4.5 son supportées (En les déclarant, dans les shaders) et donc, contrairement à ce que je pensais mesa driver supporte OpenGL 4.5 même si glxinfo me donne 3.3 comme information ce qui m'a trompé, dès le début.
Cependant je ne suis pas encore à bout du problème de textures semi-transparentes à cause du bug et mesa driver semble être lent avec les per-pixel-linked-lists.
De plus avec le bug, seul la couleur des premiers fragments écrit dans le shader buffer storage object sont visible en mémoire à la lecture lors de la seconde passe, même en ajoutant une barrière.
Donc bon la priorité maintenant pour moi c'est de régler ce bug.
Même en utilisant un moteur de jeux existant, si déjà, le driver graphique bug, ça ne marchera pas.
J'ai tenter de débuguer mesa avec le débugueur de code::blocks, pour ajouter des break points pour voir ou sont appelée les fonctions, mais il y a des fichiers qu'il ne me trouve pas.
Bref il y a plusieurs options :
-Soit je n'utilise plus les shaders pour le moment en espérant que le bug sera fixé plus tard.
-Soit je fais ma propre version de mesa mais en plus clean en me basant sur ce qui existe déjà. (Mais il y a beaucoup de fichiers, et donc, ça va être dur de repérer les fonction essentielles et ça ne risque de n'être compatible que avec ma carte graphique vu que je ne pourrai pas tester pour les autres cartes il me faudrait donc l'aide d'autre développeurs pour les autres plateformes et puis avec le jeux j'ai déjà assez de travail comme ça alors, mais d'u autre côté, c'est frustrant d'avoir acheté du matériel exprès pour pouvoir compiler le language GLSL et après de se rendre compte que en fait ça ne fonctionne pas. :/
Je ne pense pas qu'il y ai des développeurs spécifié dans la codification de driver graphique ici, mais bon, je vais supposer que plus tard il corrigeront le bug, et si c'est toujours pas fais dans un an, lorsque le jeux sera plus avancé, je tâcherai de faire quelque chose histoire de ne pas perdre de temps parce que, le bug sera corrigé, avant que je finisse le jeux, ce qui, serait bête.
Je pense avoir trouvé le problème d'affichage du driver graphique (mesa 3D) avec les shaders.
Mais je n'ai pas encore pu tester car, j'ai essayer de l'installer sous ubuntu, mais, l'interface graphique ne démarre plus et sous ubuntu il suffise que j'installe un mauvais driver pour faire planter l'interface graphique. (De plus ça m'a installé, les drivers pour toutes les cartes donc..., à mon avis, c'est ça qui a fait tout planter, de plus je n'avais pas supprimer les ancien et quand j'avais supprimé les anciens, glxinfo ne m'affichait rien, et même en ayant supprimé les nouveaux et remit les anciens, l'interface graphique d'ubuntu ne démarre plus.)
Bref, je vais le compiler sous windows et le tester, c'est plus simple, là, même si le driver est mal installé on sait encore démarrer l'interface graphique sans devoir reformater.
Je vais sans doute passer sous windows si ça fonctionne parce que ubuntu 18.04 freeze de trop. Toute les 10 minutes quand je compile un programme, j'ai ubuntu qui freeze pendant 5 minutes...
Bon pour le bug d'affichage du shader ça à l'air d'être ok.
Par contre, il y a un autre bug, et là, même si je n'utilise pas de shader, le bug persiste : parfois le frambuffer ne se remet pas à jour et donc il y a des éléments qu'il ne m'affiche pas.
Je ne sais pas comment ils ont codé ce driver mais, ça a été mal fait et aucun dev ne répond.
Je vais essayer de voir si je peux pas changer de driver et si pas hé bien il faudra que je trouve une solution, enfin bref, j'ai le temps, tant que le gameplay n'est pas établi je ne peux plus avancer.
Bon, comme le driver graphique ne fonctionne pas (aussi bien l'opensource que le propriétaire) je vais devoir, faire mon propre driver, je ne peux pas débuguer mesa car :
-Il y a trop de code et pas moyen de trouver de la doc ni de le compiler en mode Debug pour mettre de break points.
-Il y a l'air d'avoir plus qu'un seul bug. (Un au niveau de la copie du framebuffer ou de l'image dans la texture liée, même sans shader ça ne fonctionne pas)
Et j'ai vraiment besoin d'utiliser desframe buffer object.
Apparemment ce n'est pas si compliqué que ça en a l'air, ça ce code comme un bête programme c++ que l'os charge dans la RAM et exécute sûrement au niveau du GPU, il y a juste deux choses que je dois encore voir comment faire :
-Transférer des données depuis la RAM vers la VRAM avec libdrm en DMA.
-Charger le contenu du framebuffer dans la fenêtre.
Mais comme j'ai le code source de mesa-driver ça devrait aller,
Il faudra aussi que j'installe une machine virtuelle pour tester, pour ne pas devoir à chaque fois recopier la lib dans le dossier de l'os installé.
Si ça ne fonctionne toujours pas je vais tenter de voir si la cause n'est pas une attaque réseau car ce n'est pas très normal que ubuntu ram comme ça.
Je met donc ce projet en pause, je ne peux plus le continuer pour le moment.
Donc maintenant ce dont j'aurai le plus besoin c'est d'un développeur spécifialiser dans la codification de driver.
PS : j'ai trouvé comment le faire sans FBO, dessiner la première couche ensuite faire un appel à glClear(DepthbufferBits) et puis dessiner la couche suivant.
Mais bon comme je ne peux pas avancé tant que je n'ai pas d'équipe, autant faire autre chose qui ne nécessite pas d'avoir forcément une équipe sous la main.
J'avance petit à petit dans la création du driver mais je ne l'ai pas encore testé.
Le problème de mesa driver c'est qu'il exécute du code au niveau du GPU uniquement pour les shaders et non pas pour tout le pipeline, ni les commandes opengl.
Mais il y a un autre problème : le compilateur c++ ne peux générer du code source que pour le CPU, hors, le pipeline est codé en c++.
Je vais donc faire un parseur qui sera capable de traduire du code c++ en byte code compréhensible par le GPU en plus du code GLSL.
L'avantage c'est qu'il ne faudra pas passer par openCL (qui ne tourne pas avec mon GPU) ou encore des compute shaders (avec le SSBO qui bug chez moi lors de la création des per-pixels lists)
Bref, je vais essayer de faire ça et voir ce que ça donne.
Ce que je vais dire est d'un ordre purement subjectif et ne cherche en rien à te dévaloriser.
Premièrement j'aurais une petite question: où trouves-tu le temps de réaliser un projet aussi conséquent, alors que tu es dans la vie active (selon tes propres dires) ??
Je suis moi-même étudiant avec (je trouve) pas mal de temps libre et trouver le temps de programmer pour le plaisir - sans même parler de gros projets/jeux - est assez difficile... Je n'arrive tout simplement pas à imaginer trouver autant de temps à consacrer à un projet d'une ampleur aussi importante que le tien, avec en plus un emploi à côté.
Deuxièmement: crée toi un DevBlog. Ce forum (ou n'importe quel autre d'ailleurs) ne devrait pas faire office de rapport pour chaque petite modification que tu ajoute à ton programme. Un post par release suffit amplement, à supposer qu'il y en aient.
De plus, ce thread était censé faire office d'annonce de recrutement pour une team de développement, pas vraiment de présentation exhaustive de projet.
Troisièmement: j'ai l'impression que tu n'est pas à l'écoute des gens qui ont répondu à ce thread (et du thread sur le forum de la SFML par ailleurs - celui sur ton framework "adapté à chaque jeu").
Combien de fois t'as ton déjà dit ce que je t'ai dit ? La réponse est sans doute "beaucoup". Je me rappelle des remarques - parfois assez violentes - par trop de personnes sur le forum de la SFML concernant la création d'un DevBlog, et d'arrêter de poster en permanence. A chaque fois, tu passe au dessus, balaie la remarque d'un revers de la main, et surenchéris.
Je ne veux pas m'étaler sur le sujet, mais s'il te plaît: arrête. Ce n'est pas en postant 18 messages par jour que tu vas intéresser plus de personnes à ton projet, cela pourrait même avoir l'effet inverse.
Ok, je vais moins parler ici, donc je ne dirai pas ce que je suis entrain de faire ici, je vais juste, faire un devblog comme tu dis, mettre un lien et ceux que ça intéresse liront et les autres ne verront que les releases.
Je n'ai pas de vie active, je ne travaille pas et je ne suis plus étudiant donc j'ai le temps pour un projet d'une telle taille, c'est même pour ça que je fais un projet d'une telle taille pour ne pas m'ennuyer...
J'ai arrêté de posté sur le forum de SFML, mais il arrive que parfois, j'ai du mal à m'arrêter.
Si le projet devient une entreprise un jour je compte faire quelque chose de nouveau, pour éviter la concurrence.
Recréer un MMORPG ne sert à rien, il en existe pleins, la concurrence est trop élevée, car il y en a beaucoup, alors je me suis poser cette question.
Comment certains de l'informatique on t'il réussi ?
Et j'ai trouvé cette réponse : ils ont simplement inventé (ou reprit des idées) pour vendre des produits qui n'existaient pas encore et donc dans un secteur naissant.
Je pense donc, plus tard, si j'ai les fonds, investir non pas dans un MMORPG mais une sorte de VMMORPG. (c'est mon rêve depuis que je regarde la websérie noob)
Le joueur pourra contrôler un avatar virtuel à distance (non pas avec une télécommande comme sur la wii) mais en utilisant une autre technique que j'ai en tête depuis un petit temps.
Il pourra aussi lancer des compétences en parlant, (en effet, retenir tout les raccourcis claviers, pour toutes les compétences à lancer et dans un mmorg il y en a beaucoup, ce n'est pas très pratique, de plus sur certains jeux c'est encore pire car il y a plusieurs bar de compétences, il faut aussi parfois changé d'équipement, bref)
Au sujet du gameplay, je le posterai moi même, car, je n'ai plus de nouvelle du game designer depuis, un long moment.
Pour l'instant tout est dans ma tête mais là encore je vais faire quelque chose d'innovant.
PS : Ha oui et aussi, l'OIT fonctionne enfin.
Donc en résumé, je fais ce projet juste pour m'amuser, si je trouve des gens pour faire ça entre potes tant mieux. Et si je trouve des fonds hé bien je ferai une entreprises et je recruterai des gens, parce que pour l'instant, j'ai pas l'argent pour recruter des gens.
Sinon il faut faire des prêts mais c'est risquer :
-Il faut avoir du bon matériel, être sûr que ça fonctionne correctement.
-Il faut trouver les bonnes personnes.
Et moi comme j'ai déjà eu des problèmes avec le hardware et le software que j'ai acheté et en plus que la plupart des gens ne supportent pas mon comportement, je n'ai plus trop envie de prendre ce risque, surtout que, les banques, elles s'en foutent de ça, si tu ne rembourses pas, ce qui est à toi, est à eux.
Laisse béton, je stop tout, j'ai pas assez de temps de vie pour réaliser un tel projet tout seul et je n'ai pas les fonds pour payer des gens pour m'aider. (Parce que les gens, préfèrent faire des dons pour autre chose)
Et non je ne vais pas faire de prêts pour un tel projet.
Je dois être l'un des seuls qui ai accepter de travailler bénévolement, mais ce n'est pas le cas de tout le monde, car moi, je dois payer.
Mais bon, je peux m'en sortir avec ce que j'ai alors, je vais plutôt profiter de la vie maintenant plutôt que de perdre mon temps sur un projet, qui n'aboutira pas à cause des raisons que j'ai cité.
Le travail d'équipe ne mène que jusqu'au Trophée, seul l'être réellement évolué peut s'en emparer pour sa gloire personnel XD.