La vérité sur la conception de jeux amateurs

Voici une des erreurs classiques dont je vous parlais : réaliser un fan game.

Les fan games sont des jeux basés sur un univers existant (films, animés, livres…) réalisés par des fans.

Vous n'aurez pas de problèmes particuliers pour réaliser votre jeu, mais alors pourquoi dit-on que les fan games sont des PFA et pourquoi je considère ce genre de projet comme une erreur ?

Le principal problème, c'est que, même si le jeu final est gratuit, il peut se faire interdire du jour au lendemain à cause des droits d'auteurs et vous risquez des problèmes juridiques pour violation de copyrights. L'avenir de votre jeu se fait donc au bon vouloir des ayants droit et ce n'est pas parce que le jeu de votre voisin est sorti depuis un an sans se faire interdire que vous aurez autant de chance.

Si vous recevez des remarques des ayants droit, il vous faudra alors changer d'univers et refaire une grosse partie du travail, notamment la partie graphique, scénaristique et parfois même changer certains mécanismes de votre jeu. C'est beaucoup de travail alors que votre jeu était censé être fini, c'est aussi un coup porté au moral de l'équipe et il sonne souvent l'échec du projet.

Si vous souhaitez vraiment faire un fan game, demandez d'abord l'autorisation aux ayants droit en leur précisant exactement ce que vous souhaitez faire. Très peu de personnes pensent à le faire, pourtant vous serez gagnant à 100 % :

• soit les ayants droit refusent et vous pouvez modifier votre projet de sorte qu'il ne soit pas interdit à sa sortie ;
• soit les ayants droit acceptent et non seulement vous pourrez garantir à vos coéquipiers qu'ils ne travailleront pas pour rien mais, en plus, selon les ayants droit, vous pourrez en retirer quelques avantages.

Vous en rêvez depuis plusieurs nuits, ce jeu si parfait qu'il fera un carton, tout le monde se l'arrachera et il vous rapportera des millions, il sera même une véritable révolution dans le domaine du jeu vidéo ! Le jeu du siècle, que dis-je ? Du millénaire !

Ce jeu a un gameplay révolutionnaire unique en son genre, mais sera-t-il agréable pour les joueurs ou sera-t-il même jouable ? Le gameplay doit rester relativement simple et intuitif : si on n'arrive pas à s'adapter à votre gameplay, on ne jouera pas longtemps.

Dans les autres jeux, les mobs (éléments mobiles contrôlés par l'ordinateur, souvent utilisés pour désigner les ennemis que le joueur doit affronter) sont assez bêtes et on trouve assez vite des failles dans leur IA (intelligence artificielle). Vous, dans votre jeu, vos mobs commenceront par être bêtes mais ils apprendront au fur et à mesure de leurs erreurs jusqu'à devenir presque parfaits et donc très difficiles à battre. Très simple à dire mais beaucoup moins facile à réaliser. Pour un jeu comme le go (jeu où on pose des pions sur un plateau de 19x19), réaliser une IA capable de battre des professionnels (sans handicap) vous fera gagner plusieurs millions d'euros.

Ils utilisent pour cela des supercalculateurs avec 15 To de mémoire vive.

Imaginez alors ce qu'il faudrait comme performances pour un gameplay avec bien plus de règles et qui en plus a un processus d'apprentissage. Sans compter que le go est un jeu au tour par tour ; pour un jeu en temps réel, il faut que l'IA soit réactive, il faut aussi essayer de représenter les données de manière optimale (ceci impactera la RAM utilisée, le temps d'exécution de l'algorithme et facilitera la création des IA), etc.

Je ne vous parle même pas des connaissances nécessaires pour réaliser une telle IA.

Il faut aussi savoir qu'un jeu a pour vocation d'être joué : s'il n'intéresse que vous, il n'a pas grand intérêt. Votre rêve n'est pas toujours compatible avec les rêves des autres joueurs.

Essayez de présenter votre idée à des amis pour voir si un tel jeu les intéresse ou non. Demandez-leur les points qu'ils apprécient le plus et ceux qu'ils aimeraient voir disparaître, améliorez votre jeu et revoyez votre copie.

Un jeu amateur dont le but est d'apprendre peut très bien se passer de joueurs.

Pendant la phase de création de votre jeu, il est possible que vous ayez quelques dépenses à faire (rémunérer certains de vos coéquipiers, louer un serveur pour effectuer des tests…).

Si vous avez un projet très solide et attractif, vous pourrez trouver des investisseurs (très rares en France) qui vous donneront de l'argent en échange d'une part des bénéfices.

Vous pouvez aussi utiliser des sites de crowdfounding (plates-formes internet de collecte en ligne de fonds) comme Kickstarter qui vous permettent de récolter des fonds sous certaines conditions.
Certains concours donnent aussi de l'argent si le projet gagne (arrive premier).

Vous pouvez cependant très bien réaliser un jeu sans dépenser de l'argent, c'est même très conseillé pour les jeux amateurs qui ne sont jamais sûrs d'aboutir.

Il y a encore quelques jours vous jouiez à un jeu puis vous avez eu des idées pour l'améliorer.

Il faut déjà comprendre qu'un tel jeu a été codé par de nombreux professionnels pendant des années avec un budget financier assez important. On sous-estime trop souvent les compétences et les coûts pour créer de tels jeux.

Un amateur ne peut pas (ou très exceptionnellement) rivaliser avec une équipe de développeurs professionnels.

En effet, les professionnels travaillent à temps complet au sein d'une équipe relativement stable, ils sont aussi plus expérimentés et peuvent sous-traiter une partie du travail grâce aux financements qu'ils possèdent.

Les amateurs conservent tout de même quelques avantages : déjà, vous serez maître de votre projet, on ne pourra pas brider votre créativité ; votre projet ne comportera pas ou peu de risques financiers et il ne sera pas remis en cause ou annulé s'il est en retard.

Ne pas confondre jeu amateur et jeu réalisé par un débutant !
Un jeu réalisé par un débutant est bien souvent un jeu amateur, mais un jeu amateur n'est pas obligatoirement fait par des débutants.
Ainsi, un jeu amateur peut très bien être réalisé par de très bons programmeurs et se rapprocher des jeux professionnels tandis qu'un projet de jeu réalisé par des débutants a déjà moins de chances d'aboutir.

Il est courant de vouloir créer un jeu en réseau mais ce n'est pas aussi simple qu'on pourrait le croire.

Sa réalisation demandera souvent de fortes connaissances en programmation bas niveau (mutex, sémaphores, socket et programmation multi-thread) mais aussi haut niveau (architecture réseau, répartition de charge, gestion des lags, antitriche).

Si votre jeu prévoit un grand nombre de joueurs et des besoins en ressources importants, choisir un serveur plus performant n'est pas toujours une solution viable. Il vaut mieux choisir une bonne architecture, optimiser les algorithmes utilisés et les sections critiques, ce qui nécessite de solides connaissances du langage utilisé, savoir « comment il fait ».

Ainsi, vous pourrez réduire vos besoins en performances de manière non négligeable et, par là, réduire les coûts d'hébergement.

Les jeux au tour par tour sont généralement plus simples que les jeux en temps réel. En effet, ces derniers vont souvent nécessiter quelques astuces pour limiter les lags (latence entre le serveur et le client).
L'une des solutions utilisées est de faire calculer les informations deux fois, une fois côté serveur et une fois côté client, afin qu'il n'envoie pas des informations inutiles au serveur et qu'en cas de lag, le jeu reste fluide. Toutefois, ceci nécessitera de s'assurer que le client est toujours synchronisé avec le serveur.

Pour une application réseau, n'oubliez pas de garantir un minimum de sécurité :
- le serveur doit ne jamais faire confiance aux données reçues, il doit toujours les vérifier ;
- ne jamais stocker de mot de passe en clair mais utiliser des hashs sécurisés (pas d'algorithme personnel ou dépassé comme MD5 ou SHA1) comme actuellement le SHA512 et bientôt le SHA3 ;
- le client doit envoyer le hash du mot de passe mais le hash ne doit pas circuler en clair sur le réseau, préférez envoyer au client une clé à chaque nouvelle connexion lui permettant de crypter le hash afin que les hackeurs ne puissent pas le connaître et que la séquence des bits réservés au hash crypté varie à chaque connexion ;
- pouvoir bannir un compte.
Le domaine de la sécurité est tellement vaste qu'il faudrait faire un tutoriel spécialement dédié à celui-ci.
Il existe des failles comme le man in the middle ou les injections SQL qu'il faut aussi corriger. Vous pouvez regarder ce tutoriel si vous souhaitez en savoir plus.
La conservation de données sur vos joueurs est soumise, en France, à la Loi n° 78-17 du 6 janvier 1978 (Informatique et liberté). Prenez donc bien le temps de consulter la(les) loi(s) équivalente(s) pour votre pays et pour le (les) pays où vous effectuez des traitements.

Un projet a besoin de différentes compétences complémentaires et pas uniquement des compétences en développement.

Nous pouvons distinguer quatre principaux groupes de compétences nécessaires :

• le management du projet : il s'agit de gérer l'équipe et le projet, attention, c'est tout un métier (ou plutôt deux métiers). Dans un projet amateur, rien que de constituer une équipe stable et d'attribuer des tâches n'est pas facile et prend pas mal de temps, alors que c'est loin d'être suffisant. De plus, la personne s'occupant du management de projet occupe souvent une autre fonction au sein du projet. Pour plus de détails vous pourrez consulter mon prochain article ;
• le développement proprement dit ;
• le travail artistique, pour tout ce qui est graphisme, son, scénario, etc. ;
• le game design, qui s'occupe de mettre en place les règles du jeu. Encore une fois, c'est bien plus compliqué qu'on peut le penser. Même dans le domaine professionnel, ce n'est pas une tâche aisée. Si vous avez déjà joué à des MMORPG, vous remarquerez qu'il y a régulièrement des rééquilibrages entre les différentes classes, ceci fait partie du travail du game designer. Mais quand il y a 12 classes avec 20 attaques pour chacune, il est très compliqué d'équilibrer ces classes tout en conservant des points forts et des points faibles. Bien sûr, la difficulté du game design varie selon le type de jeu (un Tetris ne nécessite pas de game designer alors qu'un RPG en a grandement besoin).

Il ne faut surtout pas sous-estimer l'importance des autres connaissances que la programmation dans un projet.

Tout comme il existe pas mal de domaines en infographie (2D, 3D, particules, etc.), on peut aussi en avoir beaucoup en programmation :

• IHM : il s'agit de s'occuper de l'Interface Homme-Machine, c'est-à-dire tout ce qui va être affiché à l'écran, faire jouer les sons, tout ce qui va être entré par l'utilisateur, comme les événements de clavier, souris ou de tout autre périphérique d'entrée comme une Kinect ;
• scripteur : il s'agit de faire des « scripts » dans un langage qui sera interprété par le jeu, ceci permet de déléguer des tâches à des non-programmeurs et de ne pas devoir recompiler votre jeu à chaque ajout de contenu ;
• développeur IA : il s'agit de la personne qui mettra en place l'intelligence artificielle. De solides connaissances en algorithme et en mathématiques (calcul booléen, graphes et automates) sont conseillées. Il est généralement aussi scripteur ;
• programmeur outils : il s'occupe de réaliser différents outils nécessaires au projet. Généralement, il part d'un outil existant et le modifie pour qu'il corresponde au besoin du projet ;
• programmeur réseau : il s'occupera de tout l'aspect réseau (cf. II.E Jeu en réseau ) ;
• programmeur physique : il réalise le moteur physique, qui gère la gravité, les collisions, etc. ;
• programmeur gameplay  : met en place le gameplay en se servant du travail de tous les autres programmeurs (il peut être aussi scripteur).

Il existe bien évidemment d'autres domaines en informatique et parmi ceux-là, on peut encore faire des distinctions entre plusieurs spécialisations.

Bien sûr vous ne pourrez pas (et ne devez pas) recruter autant de personnes. Il faudra donc que les programmeurs jouent plusieurs rôles.

Il est aussi conseillé d'avoir de bonnes connaissances en mathématiques surtout si vous souhaitez afficher de la 3D, pour plus de détails, consultez la FAQ

Vous l'avez compris, savoir faire un « Hello World » n'est pas suffisant pour se lancer dans un projet.

Sans connaissances académiques, un projet important a moins de chance de réussir.

L'autoformation est bien, mais elle ne pourra pas remplacer les études, qui restent un avantage non négligeable et qui permettent de se perfectionner tout en acquérant de l'expérience.

Une formation académique permet aussi de ne négliger aucun aspect de l'informatique auquel on ne pense pas toujours, proposant des cours sans rapport direct avec la programmation mais qui restent très utiles (économie de l'informatique, droit, par exemple).

L'assembleur par exemple permet d'avoir une plus grande compréhension des effets de votre code aussi bien au niveau des ressources utilisées qu'au niveau des actions qui sont réellement exécutées par votre machine. Ce qui vous permet par la suite de produire des codes plus intelligemment et nécessitant un minimum de ressources.

La situation idéale est de combiner une formation officielle à des approfondissements autodidactes et surtout de continuer à lire les forums et articles, ceci vous permettra de voir des outils que vous ne connaissiez pas (ex : template, fonctions inlines) mais aussi de corriger vos erreurs.

La plupart des MMO sont des échecs car très difficiles à réaliser : il faut aussi environ 150 000 joueurs pour qu'un MMO soit rentable (ce chiffre vous donne un ordre de grandeur, il est évident qu'il varie selon le projet, l'investissement et l'argent moyen que vous recevez par joueur et par mois).

Pour contenir un tel nombre de joueurs, l'architecture réseau est assez complexe et utilise plusieurs serveurs.

Il faut aussi des systèmes réactifs pour limiter les lags, synchroniser les clients et les serveurs, accéder à la base de données, établir des protections contre le piratage et la triche, rendre le client opérationnel quels que soient les OS, cartes graphiques et autres (d'où l'avantage de faire un code portable).

Un programmeur même très bon ne peut pas être calé dans tous ces domaines.

Ce n'est pas tout : il faut aussi faire venir les joueurs et les conserver. Or, même en faisant de la pub à un niveau professionnel, il n'est pas toujours facile d'attirer un nombre suffisant de joueurs. Donc, même si vous réussissez à finir votre MMO, il risque d'être un échec par manque de joueurs.

Ensuite, les joueurs d'un MMO ne jouent pas tous aussi fréquemment, il ne faut pas que les joueurs les plus rapides se retrouvent à ne rien faire et s'ennuient. Mais il ne faut pas non plus que les joueurs un peu moins rapides se retrouvent trop en retard sous peine d'isoler les joueurs rapides des joueurs moins rapides.

Il faut donc proposer trois contenus (ou gameplay) à différents moments : à court terme (moins de vingt heures de jeu), à moyen terme (aux alentours d'une centaine d'heures) et à long terme (plus de dix mille), ce qui va demander beaucoup de contenu de qualité, c'est-à-dire ajouter plus d'objets, créer plus de cartes, créer un très grand nombre d'images, créer plus de sons, etc. avec toutes les difficultés en game design que cela peut poser.

Il faudra aussi être rapidement disponible à toute heure en cas de bogues ou autres pour les corriger au plus tôt, au risque de perdre des joueurs.

Tout d'abord, il faut apporter une innovation et ne pas seulement faire une copie d'un MMO existant ; sinon, votre MMO ne pourra jamais trouver sa place. Ne faites surtout pas un MMO payant par abonnement, c'est le meilleur moyen de se fermer une très grande partie du marché, ce qu'un jeu amateur ne peut se permettre.

Le joueur doit se sentir chez lui dans votre monde (décors désertiques ou extraterrestres à proscrire), il faut proposer un « foyer » aux joueurs et leur faire vivre une histoire. Le joueur doit s'identifier au personnage.

Les joueurs sont de plus en plus exigeants, il faut donc les « chouchouter » et répondre à leurs attentes en évitant par exemple les quêtes de livraisons, qui, au final, à part faire courir le joueur et augmenter artificiellement la durée de vie du jeu, n'ont pas grand intérêt.

Même si vous devez satisfaire les joueurs, le projet n'en reste pas moins votre projet.
Ne cédez pas aux réclamations des joueurs si vous êtes absolument contre et que vous pensez que cela ne peut rien apporter à votre jeu ou que deux semaines plus tard les joueurs auront oublié ce qu'ils voulaient.
Pour chaque réclamation, vous devez donc peser le pour et le contre en regardant ce qu'elle pourrait apporter au niveau du jeu et de sa communauté.

Quoi que vous fassiez, il y aura toujours des personnes qui n'aimeront pas vos modifications : n'oubliez pas que, s'ils manifestent leur mécontentement, c'est qu'ils aiment votre jeu (sinon, ils ne feraient qu'ignorer vos modifications ou partir sur un autre jeu).

S'il est facile de connaître les réclamations des joueurs, il est bien moins aisé de déterminer le pourcentage de joueur en faveur de cette réclamation. Pour ce faire, on va devoir s'appuyer sur des méthodes de statistique. Plusieurs solutions sont envisageables (et peuvent être utilisées conjointement) :

• se constituer une équipe de testeurs. Il faut que cet échantillon soit le plus représentatif de la communauté possible au moment du sondage. Or l'échantillon et la communauté peuvent changer continuellement ;
• faire un sondage sur le site. Mais tous les joueurs ne vont pas sur le site vous aurez donc des résultats qui concernent les joueurs visitant le site mais non pas la communauté dans son ensemble. De plus sur certaines questions sensibles vous pourrez avoir quelques petites triches sur le sondage ;
• contacter des membres au hasard et leur proposer un questionnaire relativement court avec récompenses à la clé. Mais c'est plus que laborieux pour avoir suffisamment d'avis pour obtenir des résultats « fiables » ;
• intégrer un système de vote dans le jeu ;
• vous fier aux données de jeu pour voir si les arguments avancés par les joueurs sont vérifiés ou non (ex : un boss est trop dur, vous regardez le taux de victoire et le comparez au taux de victoire des autres boss, ou vous testez vous-même le boss avec un équipement d'un joueur moyen).

Aussi, n'hésitez pas à surprendre le joueur pour que le jeu ne devienne pas trop lassant. Vous pouvez pour cela faire des petits événements (event dans le jargon des joueurs) de temps en temps, afin de proposer un contenu intéressant et attractif.

Permettez aussi aux joueurs de jouer seul ou à plusieurs, ne sous-estimez pas le solo. En effet, sur un jeu amateur, on a souvent moins de joueurs que dans un MMO professionnel, donc pas toujours une personne avec qui jouer.

La communication est aussi un point important, aussi bien pour trouver de nouveaux joueurs que garder les anciens. N'oubliez pas que la majorité des joueurs n'iront pas sur votre site, pensez donc à bien faire répercuter les informations dans le jeu.

Pour répercuter ces informations, vous pouvez afficher les nouvelles dans le launcher (petit programme servant à mettre à jour le client puis à lancer le jeu) ou faire des annonces régulières (texte bien en évidence s'affichant quelques secondes).

Chacun fait son MMORPG dans son coin : il vaut mieux se joindre à un projet existant, il y aura déjà de plus grandes chances de réussite.

Comme vous commencez à apprendre à marcher à quatre pattes avant d'apprendre à courir, comme vous commencez par faire des additions avant de résoudre des équations quadratiques, il ne faut pas commencer par un projet compliqué mais plutôt par un projet simple.

Lorsqu'on débute, il est normal de ne pas être conscient de la difficulté d'un projet : c'est pourquoi commencer par de petits projets vous permettra de mieux apprécier ces difficultés, de les connaître et de savoir quelles solutions adopter.

Même de petits projets sont durs à réaliser, imaginez donc la difficulté d'un grand projet complexe : viser trop haut n'aidera qu'à faire capoter votre projet. Il vaut mieux démarrer petit et augmenter progressivement la difficulté. Ce sera aussi l'occasion de montrer vos compétences en tant que programmeur ou chef de projet.

Un petit projet ne signifie pas forcément de réaliser un pacman ou un tetris, rien ne vous empêche de faire preuve d'imagination et d'originalité comme Florale.

Ces petits jeux simples mais originaux peuvent avoir beaucoup plus de succès qu'un jeu bien plus complexe ayant moins de chances d'aboutir.

Un petit jeu terminé vaut plus qu'un gros jeu inachevé .

Un bon jeu est un jeu dont les concepts sont simples mais qui permettent une richesse de jeu importante (comme le jeu de go).

Il ne faut pas oublier qu'un jeu trop réaliste est très (voire trop) compliqué, aussi bien pour le programmeur que pour le joueur. Le manque de réalisme d'un jeu ne l'a jamais empêché de cartonner (cf. les RPG sur table ou les jeux Mario).

On peut estimer la viabilité d'un projet par le rapport ambition/compétences des personnes intégrées au projet. Quand on débute, les compétences sont plutôt minces, d'où l'importance d'avoir une petite ambition.

Il est nécessaire d'avoir une idée claire de ce que l'on veut faire aussi bien pour coder que pour commencer à recruter. En effet, l'hésitation est souvent mal vue dans les sujets de recrutement.

Si vous-même ne savez pas ce que vous voulez faire, comment voulez-vous intéresser vos lecteurs ?

Pour cela, pensez à noter vos idées sur papier pour ne pas les oublier et pour ensuite pouvoir les ressortir plus facilement.

Essayez de noter :

• comment le joueur gagne ou perd, si cette notion a un sens ;
• comment fonctionne votre système d'expérience ou de score ;
• l'apparence finale de votre interface graphique :
• les menus qui constitueront votre jeu ;
• les ambiances sonores ;
• les interactions possibles entre l'interface et le rendu graphique/sonore ;
• le gameplay : tour à tour ou temps réel ? Action ou réflexion ?

Tout ceci constitue les bases du game design.

À noter qu'il ne vous faut pas faire entièrement le game design mais juste poser les bases.

Le game design sera approfondi au fur et à mesure de l'avancement du projet, le game design n'étant jamais véritablement fini.

Comme vous n'avez pas à disposition une équipe de 50 personnes, il est important de ne pas créer un jeu nécessitant trop de contenu.

Pour ce faire, il existe plusieurs petites astuces :

• choisir un jeu n'ayant pas beaucoup de contenu (comme le Tetris ou le jeu de go) ;
• jouer sur le style graphique pour avoir moins de contenu à créer comme utiliser un système de tuiles (une image unique pour chaque objet, répétée dans tout le jeu, tiles en anglais) ;
• privilégier le multijoueur pour rentabiliser au maximum le contenu ;
• réaliser le minimum de contenu et laisser la communauté faire le reste (grâce à des éditeurs de cartes, par exemple) ;
• utiliser un système de création procédurale qui génère lui-même le contenu en augmentant la complexité, vous pouvez demander conseil à des communautés liées à la scène démo (demoscene en anglais).

Pour la génération de donjons, si vous êtes à l'aise avec l'anglais, je peux vous proposer trois liens assez intéressants :
- http://pcg.wikidot.com/;
- http://pcg.wikidot.com/pcg-algorithm:dungeon-generation ;
- http://dirkkok.wordpress.com/dungeon...rticle-series/ ;
Si par contre l'anglais n'est pas votre fort, voici quelques sujets qui pourront vous donner des pistes :
- Comment écrire un algorithme de génération de donjon ?
- Compétition de génération de niveaux Super Mario.
Et voici un exemple de générateur de donjon.

Le choix du langage ne doit pas se faire en fonction de vos compétences mais suivant les besoins de votre projet.

Pour de petits projets basiques, vous pouvez créer un jeu (le plus souvent par navigateur) Flash grâce à l'ActionScript.

Cependant l'AS3 et par défaut, Flash, ont été originellement conçus pour les animateurs et designers, ils ne sont donc pas adaptés à la création de gros jeux.

On peut aussi choisir d'utiliser du C avec la SDL, mais on préférera souvent utiliser un langage orienté objet comme le Java ou le C++ avec la SFML, le C nécessitant une plus grande rigueur dans le code.

N'utilisez pas de langage web si vous souhaitez proposer un mode hors-ligne.
Il est bien sûr possible de faire du hors-ligne avec un langage web (avec une QWebView de Qt par exemple), mais si vous utilisez du PHP, vous risquez de devoir faire un peu de « bricolage ». On a donc plutôt intérêt à utiliser un langage plus approprié dès le début.

Il est aussi nécessaire de connaître les limites et contraintes du langage (et des technologies) que vous utiliserez pour vous éviter toute mauvaise surprise : par exemple, les nombres en virgule flottante peuvent conduire à des bogues car ils renvoient des résultats approximatifs et certains nombres ne sont pas représentables. Notamment, le résultat du calcul 1 - 1/3 - 1/3 - 1/3 n'est pas forcément égal à 0.

Si vous faites par exemple un compteur allant de 0 à 360 par pas de 0,01, vous allez avoir quelques surprises (pour plus d'explications, consulter l'article Les nombres flottants et leurs pièges ).

C'est une option qui n'est pas assez envisagée par les programmeurs : rejoindre une équipe. Vous pourrez alors progresser rapidement tout en bénéficiant des conseils des membres de cette équipe.

Vous pourrez aussi observer son organisation interne et voir comment elle est gérée ainsi que les problèmes auxquels sont confrontés le chef de projet et l'ensemble de l'équipe afin de vous en inspirer et d'apprendre de leurs erreurs. De plus une fois ce projet fini, vous pourrez peut-être recruter d'anciens membres de l'équipe.

Il y a aussi beaucoup de gros projets qui sont lancés, mais ils nécessitent des graphistes inspirés, des codeurs ingénieux… qui sont beaucoup plus rares. Ainsi il y a beaucoup de projets dont une grande partie n'arrivera jamais à terme par manque de personnes pour y participer.