Making a Mod/fr
January 2024
Cet article est censé vous apporter des tuyaux pour créer votre Modification du Source Engine. D'une part il permettra de vous donner quelques conseils quant à la mise en route de votre MOD et à la constitution de votre équipe de développement.
D'autre part, il regroupe toute une collection d'astuces bien utiles pour bien comprendre les différentes étapes de la création d'un jeu. Pour finir, l'article contient un guide pas-à-pas pour vous amener sur le chemin de la réussite, ce qui n'est pas chose facile!
Ne vous leurrez pas, si vous voulez vraiment avoir du succès, gérez votre MOD comme une affaire sérieuse et non pas comme un jeu. C'est clair que si vous voulez faire simplement un MOD pour le fun, alors cet article ne vous sera pas très utile!
Contents
Pour commencer
On va d'abord s'intéresser à la constitution de votre équipe. L'idée phare à vraiment retenir, c'est de garder une petite équipe. Il ne faut pas vous faire d'illusions, manager une équipe c'est un boulot à temps plein, que les membres de l'équipe soient dans un même local ou sur Internet. Ainsi, n'espérez pas manager votre équipe tout en faisant des maps ou des models à côté. Soit vous managez, soit vous éditez, ne faîtes pas les deux en même temps, au risque de bousiller votre projet ! Notez que le fait d'avoir plus de personnel ne signifie pas que vous produirez plus de contenu, ni plus vite! Plus vous avez de monde dans votre équipe, plus vous passerez de temps à les manager et plus vous risquerez de vous emmêler les pinceaux. Pour vous donner une idée très concrète, l'équipe de Team Fortress comptait à l'origine 3 personnes, et celle de Counter-Strike en comptait... une seule!
Lorsque vous recrutez, ne recrutez seulement, et uniquement, les personnes dont vous ne pouvez pas vous passer. En général, ce que tout le monde fait, c'est de recruter n'importe quelle personne qui sait coder, n'importe quelle personne qui sait modeler etc. Le pire est que beaucoup chefs de projets inexpérimentés recrutent même des gens qui débutent... grossière erreur!
Notez bien la chose suivante: lorsque vous mettez en ligne la première beta de votre mod, vous n'aurez normalement besoin - au maximum - que d'une personne de chaque type ( code, sons, models, maps ). Peut être que vous n'aurez même pas besoin de nouveaux models, sons ou de maps pour le premier essai.
Ne recrutez jamais quelqu'un sans avoir déjà vu son travail et être sûr qu'il vous convient pour votre projet. Assurez vous également que cette personne a systématiquement terminé son travail, et non pas fait les choses à moitié! C'est pas la peine de vous embarrasser avec quelqu'un qui fait 20 models à moitié achevés, laissez tomber cette personne et allez voir ailleurs!
Design du mod
En tant que créateur de modification de jeu ( aka "mod" ), la question la plus importante est de vous demander "Pourquoi les gens auraient-ils envie de jouer à mon jeu?" Ce n'est pas évident de répondre, hein? Si vous n'avez pas trop de mal à le faire, vous êtes sur la bonne voie. Dans le cas contraire, retravaillez l'ensemble du concept jusqu'à que vous ayez bien au moins 5 bonnes raisons. Réfléchissez également quels MODs existent déjà, et ce qu'ils proposent. Qu'est-ce que votre MOD offre de plus aux joueurs? Est-ce que votre MOD est assez prenant pour que des gens déjà occupés à jouer autre part puisse s'y intéresser? Si vous ne pouvez pas répondre à cette question, ne baissez surtout pas les bras, reprenez l'ensemble du concept pour pouvoir répondre à ces critères. N'allez pas plus loin tant que ces critères ne sont pas remplis, sinon vous risquez de commencer quelque chose dont vous n'êtes déjà pas sûr d'aller au bout. De plus, les mauvaises langues pourraient y trouver des arguments pour vous casser et vous faire abandonner votre projet.
En tant que créateur de MOD, vous avez un avantage sur les professionnels: vous n'avez pas besoin de vous soucier de l'attrait du gameplay, contrairement à eux: ils doivent s'assurer que leur produit puisse se vendre. Pour vous il ne s'agit pas de vendre, ce n'est donc pas un problème! Ainsi vous pourriez très aisément expérimenter plusieurs modes de jeu! Comprenez donc que c'est sur le gameplay qu'il faut se focaliser. Chose importante, ne passez pas tout votre temps à recréer ce qui existe déjà dans des jeux commerciaux ou des MODS. Prenez bien note de la chose suivante: la plupart des MODs ne peuvent généralement pas assurer un contenu d'aussi bonne qualité que les professionnels, et c'est normal car ces équipes de développement ont des années d'expérience derrière elles! Gagnez le combat en proposant un gameplay bien meilleur, servez-vous de votre créativité! En règle générale les joueurs préféreront un MOD innovant et marrant qu'un MOD statique, plat qui se contente d'un simple ajout de contenu. Personne ne s'imagine que Team Fortress - premier du nom - n'avait pourtant presque aucun nouveau contenu un an après sa première sortie.
En tant que moddeur, vous avez un autre avantage sur les professionnels. Vous pouvez sortir des nouvelles versions bien plus vite et bien plus souvent qu'eux. On a décidé de résumer cette notion de développement par la phrase suivante: "Sortez une première beta le plus vite possible, et mettez à jour fréquemment!". Les professionnels bossent en moyenne 2-3 ans sur un projet avant de le sortir en magasin, et ensuite ils prient fort pour que les gens achètent leur produit. Ce genre de choses ne vous concernent pas. Vous pouvez très bien penser à la totalité de votre scénario, bosser sur 25% de l'histoire, et ensuite sortir une démo jouable de qualité: ainsi vous pourrez obtenir des conseils & des suggestions aussi sec. Ensuite vous pourrez progressivement ajouter de nouvelles pièces au puzzle, tout en prenant compte des avis de la communauté afin d'améliorer votre projet et sortir de nouvelles versions tous les mois voire tous les deux mois. L'avantage de cette méthode est que vous restez constamment en contact avec la communauté de votre MOD, ce qui permet de vous éviter des mois de travail soldés par la sortie d'une version dont vous n'êtes même pas sûr que le public va apprécier. On vous recommande de découper votre projet en plusieurs parties. La première version doit absolument être sympa, innovante et jouable, mais elle n'a pas nécessairement besoin d'être bourrée de toutes les nouvelles fonctionnalités auxquelles vous avez initialement songé. Attention, ne faîtes pas la grossière erreur de confondre "Vitesse et précipitation". Sortir une version rapidement ne veut pas dire sortir quelque chose de bâclé. Ça veut simplement dire sortir un projet qui propose quelques innovations que vous vous devez de peaufiner pour frôler la perfection ;o). Pour rappel, la première bêta de Counter-Strike n'avait même pas la moitié des gadgets qu'il a maintenant. L'équipe de CS a préféré faire un petit truc de grande qualité plutôt que de la masse sans intérêt. Au fil du temps, ils ont ajouté de nouveaux éléments pour en donner le jeu d'aujourd'hui. Ceci leur a ainsi permis d'augmenter régulièrement leur base de joueurs.
"Faire Autrement ne signifie pas faire systématiquement Mieux". Lorsque vous bossez sur le design du jeu, ne commettez pas l'erreur de croire que "Faire Autrement signifie faire Mieux". Ça ne sert à rien de réécrire la totalité du code du Fusil à Pompe ou d'avoir un nouveau model car ça n'avancera en rien votre jeu. Rappelez-vous, "Pourquoi aurait-on envie de jouer à mon MOD?" La réponse, "Mon MOD a un nouveau système de combat et une nouvelle manière de se déplacer", n'est pas nécessairement la meilleure réponse. Bon ton système de combat est différent que dans Half-Life... ouais, et est-ce qu'il est forcément mieux ton système de combat? Comment peux tu en être sûr? Est-ce que ton MOD sera plus marrant avec ton système? Et tes déplacements, ils changent quelques chose, ils rajoutent du fun au jeu? Vous savez quoi, les joueurs sont des être humains, ils aiment donc se reposer sur des habitudes. Or ils ont pris l'habitude d'un système de combat et de déplacement particuliers, et ils n'auront pas forcément envie de se tracasser à apprendre un tout nouveau système de visée ou de mouvements pour un MOD. Ce qu'il faut comprendre, c'est que si vous voulez vraiment modifier quelque, assurez-vous que c'est absolument nécessaire pour rendre votre jeu meilleur et plus drôle, sinon, laissez tomber! Il ne faut pas croire que votre MOD sera mis au fond de l'abîme parce-qu'il conserve un système existant.
Pour arriver au bout de votre projet, fixez-vous des objectifs réalistes. Réfléchissez au temps que pourrait mettre un développeur professionnel pour créer un jeu avec 10 armes. Si votre MOD doit intégrer 40 armes, vous allez vous compliquer la vie. Notez bien ceci: "Misez sur la Qualité et non pas sur la Quantité". Les gens préféreront avoir 10 armes bien modélisées, bien équilibrées et sympa que 40 armes faîtes par dessus la jambe!
Il ne faut pas hésiter à supprimer du contenu inutile. Si le MOD ressemble à un truc pas près de se terminer, ou si vous vous rendez compte qu'il y a des éléments qui n'ont strictement aucun rapport avec le reste du MOD, alors commencez à purger. Pendant le développement de Half-Life, au moins 30% du contenu d'origine a été supprimé parce-que l'on s'est rendu compte qu'on en finirait jamais et qu'on ne rentrerait jamais dans nos temps pour la sortie du jeu. Comme on l'a dit, maintes fois déjà, "Misez sur la Qualité et non sur la Quantité". Les joueurs préféreront 3 maps très bien réalisées et bien équilibrées que 10 maps bâclées et sans intérêt. Si vous suivez ces conseils, votre MOD aura très vite la réputation d'un MOD de Qualité. Ne souillez pas votre réputation en montrant aux autres votre plus mauvais travail!
Familiarisez-vous avec le moteur. Il est impératif que vous lisiez la documentation incluse dans le SDK. Ce que vous apprendrez en faisant ce geste, ce n'est pas comment faire un X avec le moteur mais plutôt comment un X devrait être conçu pour bien fonctionner. Vous pourrez toujours faire une arme qui tire 50 roquettes par seconde, mais si vous ne pigez strictement rien au fonctionnement du moteur, vous gaspillerez un sacré paquet de ressources réseau et le jeu lagguera à mort. C'est donc extrêmement important que chacun dans votre équipe fasse ce travail préliminaire, sinon vous risquez d'être confrontés tôt ou tard à de sérieux problème que vous serez incapables de régler. Par exemple, si vos mappeurs ne connaissent rien au moteur Source, ils feront d'énormes maps avec pleins de props -inutiles en plus - sans même savoir comment fonctionne le réseau dans Source, par conséquent les joueurs blâmeront votre code alors que le problème provient initialement des maps.
Si vous êtes programmeur, il serait très judicieux de rejoindre notre "HL Coders mailling list" car vous pourrez discuter avec des programmeurs expérimentés et quelques employés de Valve. De plus la mailling list contient des archives qui vous permettront de voir si d'autres ont pu avoir des problèmes similaires aux vôtres. Sinon posez des questions, d'autres se feront plaisir de vous aider à faire un excellent MOD pour Half-Life 2
Pour terminer
On voit tous les jours des projets qui démarrent comme du tonnerre, qui montrent des tonnes de contenu tout beau, tout mignon, et qui finalement ne voient jamais le jour. Cette section va tenter de vous éclairer sur le sujet afin de vous éviter ce genre d'échecs: ce serait dommage de devoir rajouter un nouveau nom à la liste.
Pour cet exemple, on estimera à environ 5 semaines le temps nécessaire pour mettre en ligne une première version jouable d'un projet. Cette tâche deviendra un jeu d'enfant pour vous à force de pratique. Si vous développez un MOD à l'international, vous aurez sûrement des membres à l'étranger, auquel cas il faudra compter plus que cinq semaines pour ce travail, toutefois, les étapes devraient rester à peu près les mêmes.
Si possible, essayez de négocier pour que chaque membre passe plus de temps chaque jour sur le projet pendant cette période. Si quelqu'un ne peut pas s’acquitter de la tâche, mieux vaut le supprimer de la liste de ceux sur qui vous pouvez compter. Transférez la tâche à quelqu'un d'autre qui sera disposé à l'accomplir dans le temps imparti. Donner vie à votre projet n'est pas chose facile, et cela demandera un minimum d'efforts sans quoi vous risquez vite de ne pas atteindre vos objectifs.
Il y a probablement plein de choses dans cette rubrique qui vont vous sembler rudes. C'est malheureux à dire mais c'est le seul moyen pour que vous compreniez à quel point créer un mod n'est pas une tâche simple. Les conseils que l'on vous donne là sont une compilation d'expériences que l'on apprend dans le développement de nombreux produits, et la plupart de ces conseils sont tirés d'erreurs qui nous ont coûté cher et qui ont été soldées par un retard dans nos plannings. Vous pourriez vous demander l'intérêt de ce qu'on vous raconte, mais finalement le fait de ne pas avoir pu en bénéficier nous a valu des semaines de retard dans la sortie du jeu. Le but est donc que vous ne commettiez pas ces mêmes erreurs.
Sachez qu'aux yeux d'un employeur - et Valve le sait encore mieux que n'importe qui ;o) - c'est très valorisant d'avoir affaire à quelqu'un qui a su créer quelques petites choses sympa; c'est encore plus valorisant si votre MOD est sorti et qu'il a su se trouver un public. Toutefois, la meilleure map/model/son etc. n'a aucune valeur si vous n'allez pas au bout de votre projet.
Première semaine
Centralize Ownership
Vous devriez désigner un unique membre en tant que Shipping Leader (SL). Cette personne sera responsable de la progression du MOD pour les cinq prochaines semaines. A partir de maintenant, tout changement sur le MOD devra être ordonné uniquement par le SL, et toute requête pour modifier quelque chose devra être adressée à cette personne. Aucun membre ne pourra faire quelque changement qu'il soit - mineur ou non - sans que le SL n'en n'ait donné l'ordre. Ça ne veut pas dire que tout le reste de l'équipe perd le contrôle du MOD... le SL est toujours un membre de l'équipe comme un autre, ainsi il se devra d'écouter toutes les suggestion de l'équipe. Seulement, il est le seul maître à bord, c'est lui qui prend les décisions. Ceci permet d'éviter des soucis tels q'un mappeur qui chamboule tout en faisant un changement de dernière minute juste parce qu'il n'était pas au courant que le code a été modifié. Le SL sera ainsi au courant de l'état d'avancement de chaque élément du jeu (code, maps, models, textures, etc) à tout moment pendant les cinq semaines. Ceci permettra d'éviter ce genre d'inconvénient.
Choisir le SL n'est pas facile. Voici quelques conseils:
- Ne pensez pas que le leader du mod est systématiquement la meilleure personne
pour ce genre de tâche, notamment si le projet est en cours de développement depuis des mois et qu'il n'est toujours pas prêt de sortir.
- Les programmeurs sont souvent les meilleurs prospects pour cette mission. Lors d'un processus de pré-sortie d'un MOD, beaucoup de bugs & ajouts mineurs doivent être corrigés sur le code. Un programmeur représente donc un sujet idéal pour s’acquitter de la tâche.
- Le SL doit être hautement motivé, discipliné, organisé et pas trop centré sur son égo ("moi, je..."). Le SL devra se consacrer 5 semaines à temps-plein - ou presque - à cette mission.
- Enfin le SL devra être capable de prendre des décisions dans l'intérêt global du MOD. Il devra comprendre que cela implique de nombreuses purges de contenu inapproprié afin de faire une "release" propre.
Établir le Processus de Compilation
Vous aller avoir besoin de créer un Processus de Compilation de votre MOD. La compilation est le fait de rassembler tous les éléments et de créer une version stable et installable du MOD (généralement sous la forme d'un programme d'installation ou d'un fichier ZIP). Ce processus ne devra être effectué que par le SL lors des cinq semaines à venir. Le SL à tout intérêt à suivre une méthode extrêmement rigoureuse: la rigueur lors cette phase assure une économie de temps et évite l'accumulation de résultats inattendus.
Le SL sera le possesseur de la version la plus à jour ( on appelle cette version la "release candidate" ). Tout changement devra lui être exclusivement envoyé, et il incorporera lui-même les changements uns par uns dans sa version du MOD. N'oubliez donc pas de vous mettre à jour régulièrement auprès du SL.
Le SL doit absolument compiler une nouvelle "release candidate" chaque jour pour rendre plus efficaces les playtests. On en reparlera un peu plus loin.
Verrouillage du Contenu
A présent, il faut effectuer une tâche qui consiste à verrouiller des portions de votre MOD. "Verrouiller" veut dire que vous ne devrez dans plus aucun cas toucher à ces portions du MOD. Tous les bugs rencontrés dans ces portions-verrouillées devront être pris en grande considération. Toutefois, à moins que le bug ne soit vital pour le jeu, il faudra simplement le noter et il sera corrigé lors des prochaines versions. Malgré que ça soit tentant de corriger des bugs - même mineurs - il est extrêmement déconseillé de déverrouiller des portions déjà verrouillées.
A ce stade du processus de pré-sortie, vous êtes censé avoir verrouillé la totalité des fonctionnalités de votre MOD. Ceci veut dire que vous ne devrez plus ajouter aucune nouvelle fonctionnalité quoi qu'il arrive. Si d'autres membres de l'équipe, qui ne font pas partie du de ceux qui bossent sur la pré-sortie, veulent continuer et ajouter d'autres éléments, il faudra qu'ils procèdent sur une copie séparée du MOD c'est à dire sur un code séparé, et un contenu à part. La plupart des systèmes de contrôle de code source (source code control) permettent de rassembler des versions de codes différentes (Oui, on recommande fortement l'utilisation de contrôles de code sources). A partir de maintenant, toute modification effectuée devra être uniquement une correction de bug. Même si un programmeur à l'idée d'ajouter une "super méga-cool-top fonctionnalité" qu'il pourrait incorporer en 10 minutes, peu importe, ça attendra plus tard! Même si ce têtu programmeur envoie le code débuggué au SL, ce code ne doit pas être ajouté au MOD. Gardez ce code pour les prochaines versions.
Il est vivement conseillé que le SL procède selon cette règle: si quelque chose doit s'ajouter au MOD à partir de maintenant, il retarde de deux jours la sortie du MOD.
Playtester
A présent, vous devrez faire des playtests tous les jours, ou tous les deux jours si ça fait trop. Les playtests doivent être basées sur une version installable du jeu, compilée par le SL. Ne laissez jamais vos partenaires jouer avec leur propre versions du MOD... tout le monde doit tester avec une seule et unique version du MOD fournie par le SL, au risque sinon de faire apparaître des bugs liées à une incompatibilité de versions.
Pour simplifier les choses, le MOD doit être prêt-à-jouer à n'importe quel moment. Faîtes vraiment très très attention à la jouabilité du MOD. Soyez vigilant: si un programmeur ou un mappeur apporte une modification, le SL doit absolument s'assurer que ce nouveau contenu ne fait pas tout planter ou n'apporte pas de bugs supplémentaire. Si le SL n'est pas attentif, le MOD risque de devenir très vite instable. Et c'est très mal, car combien de temps le restera t-il? Combien de playtests risquez-vous de rater à cause de ce désastre? Songez au nombre de membres qui ne pourront plus continuer à cause d'une version instable. Avoir une version parfaitement stable devrait être une religion dans votre équipe!
Lorsque vous effectuez des playtests, assurez vous qu'un maximum de membres de l'équipe soient présents. Toute personne qui bosse sur le projet devrait jouer un maximum. Pensez à avoir quelques testeurs externes sous la main. Activez le logging de la console (dans le fichier server.cfg assurez-vous d'avoir la commande "log" sur "on" ). Ceci permettra d'inscrire tout ce qui se passe sur le serveur dans un fichier texte situé dans le dossier "monmod/logs". Le nom du fichier reprendra la date de la partie jouée. Lorsqu'un joueur rencontre un bug lors d'une partie, demandez lui de reporter le bug en utilisant touche "parler à tous" (Y par défaut) et d'écrire "BUG: description du bug". Ainsi, lorsque la partie est terminée, vous pourrez ouvrir le fichier log et rechercher tous les bugs en recherchant le mot "BUG".
Bugs /Modifications
Le SL devrait créer une liste complète de tous les bugs et de toutes les modifications apportées et leur statut actuel (exemples: "FIXED" (corrigé), "TODO" (à faire), "FIXME" (à corriger), "ADDED" (ajouté), "REMOVED" (supprimé, enlevé), "MODIFIED" (modifié), "UNDONE" (encore non fait) etc. ). De préférence, utilisez une sorte de codification établie pour tout le monde pour vous y retrouver dans le fichier log. L'utilisation d'e-mails est vraiment trop inadaptée pour le traçage du bugs: c'est vite fait qu'une image ou autre se perde lors des envois etc. Après chaque playtest, tous les bugs et modifications à apporter doivent être ajoutées à la liste par le SL. Chaque correction doit être assignée à chaque membre correspondant. Lorsqu'un membre à corrigé ou modifié un élément, il doit aussitôt le soumettre au SL, qui doit ensuite vérifier que tout est en ordre. Le SL met après ça la liste à jour en signalant que la correction / modification est effective.
La liste de bugs est un outil efficace pour voir à quel point vous progressez rapidement et efficacement. Cette liste permet aussi de voir si quelqu'un n'est pas surchargé par la masse de travail, ou inversement, ou encore qui ne fait pas son boulot, et enfin la liste permet d'observer la progression de chaque partie du projet ( maps, code etc. ). Ne supprimez jamais quoi que ce soit de la liste, même si c'est déjà corrigé ( par contre vous pouvez toujours marquer chaque chose qui a été corrigée, ça vous permettra de vous y retrouver plus facilement ). C'est très utile de voir quels bugs ont pu être corrigé au cours de l'évolution du projet. Parfois les choses peuvent se compliquer, un bug peut en causer un autre, et le fait de savoir qui à corrigé telle ou telle chose pour la dernière fois permet de retracer l'origine de ce bug. A la fin du projet, vous devriez être capable de voir tous les bugs et modifications qui ont pu être corrigés tout au long du développement. Le SL ne devrait pas autoriser quelque correction de bug ou modification qui soit dans la copie du jeu principale du SL à moins que ce bug / cette modification n'ait été inscrit(e) dans la liste de bugs. Il y a un programme qui pourra vous aider dans la tenue de cette liste de bugs. En théorie, une grande feuille de papier ou un bloc-note devrait faire l'affaire. Encore une fois, évitez d'utiliser les e-mails pour créer la liste, c'est un mauvais choix.
Coupage / Report des fonctionnalités non fonctionnelles
Le plus dur, le plus pénible, et malheureusement l'étape la plus indispensable du processus de réalisation est le fait de devoir être réaliste, c'est à dire de couper des morceaux inutiles. On a un dicton à Valve, chacun verra son oeuvre favorite supprimée dans le jeu final. En attendant, autant préparer tout le monde: que chacun s'attende à voir son oeuvre d'art favorite, ou un bitonio sur lequel il aura passé énormément de temps, supprimé dans la version finale. Ça va de soi que votre jeu ne pourra pas accumuler toute et n'importe quelle fonctionnalité aussi sympa soit-elle! Auquel cas vous risquez de perdre énormément de temps et de retarder la date de sortie. Le SL doit ainsi décider de qu'est-ce qui dit sortir et de qu'est-ce qui doit rester, tout en se basant sur le temps qu'il reste avant la date de sortie du jeu.
Plus vous être proche de la date de sortie, plus vous devrez vous concentrer sur les bugs que vous trouvez. Est-ce que ce bug parasite une fonctionnalité clé du projet? Combien de jours seront nécessaires pour que l'erreur soit réparée? Est-ce cette fonctionnalité sur laquelle porte le bug peut être coupée, ou reportée à une prochaine version?
Travaillez intelligemment, pas dur
Comme on l'a déjà dit encore et encore, le processus de réalisation est dur, est il l'est encore plus si vous n'attachez pas la plus grande importance sur ce quoi vous travaillez. Travailler des masses ne veut pas dire faire attention à ce qu'il faut corriger, reporter ou couper. Le SL doit être extrêmement vigilent sur quels bugs ou modifications doivent être retravaillés, et par qui. Ne passez pas une semaine complète à corriger un tout petit minuscule problème qui porte sur une fonctionnalité mineure. Réparez les erreurs critiques, les bugs qui font crasher le jeu (showstoppers). Corrigez les erreurs qui posent souci à la réalisation du jeu. Corrigez ceux qui empêchent les autres membres de l'équipe de corriger leur propres bugs. Le SL à tout intérêt à développer des catégories pour classer les bugs, ce qui aiderait à faire les bonnes décisions. Une échelle adéquate pour classer ces bugs serait: IMPÉRATIF, CRITIQUE, MODÉRÉ, MINEUR, NUL, REPORTE.
Comme le projet est de plus en plus proche de la sortie, le SL devrait évaluer précisément chacun des bugs qui se présentent. Rappelez-vous, chaque bug corrigé nécessite de faire plus de playtests, et risque de générer de nouveaux bugs. Si vous vous trouvez à deux semaines avant la sortie, et que vous avez un bug qui demanderait trois jours et 500 lignes de code pour être corrigé, vous ne pourrez jamais être dans les temps, à moins que vous ne coupiez ou reportiez cette portion du jeu.
Deuxième semaine
Contenu verrouillé
A présent, vous devriez, si ce n'est déjà fait, avoir terminé l'ajout / modifications du contenu. Ceci veut dire que tout le contenu du projet devrait être verrouillé, excepté le code lui-même. Toutes les maps, models, textures, sons, graphiques du HUD, etc. devrait être terminé et inclus dans la copie du jeu principale du SL.
Pour terminer
Çà a déjà été mentionné dans la partie "première semaine", mais c'est encore plus important dès maintenant. Le SL est la seule personne qui peut toucher la copie principale du jeu, et il devrait seulement toucher aux portions qui doivent être corrigées et le code. Seul le SL décide de quels bugs doivent être corrigés, les autres attendront plus tard.
Playtester
Le MOD devrait être testé chaque jour, pendant au moins deux heures. Entre maintenant et la date de sortie, il vous faudra autant de gens que possible pour tester votre MOD. C'est trop tard à présent pour faire quelque changement que ce soit - ne soyez même pas tenté.
Dernière semaine
Plus de changements de dernière minute
Le SL devrait évaluer tous les changements qui devront être effectués, et il devra décider de si il faut le reporter ou non. Encore une fois, garder comme ligne de conduite que tout changement - même mineur - retarde de deux jours la date de sortie.
48h d'assurance
Une fois que tous les bugs ont été corrigé, et que tout le reste a été reporté, il y aura encore du boulot. Maintenant vous attendez au mois 48h, pendant lesquelles vous devriez playtester un maximum. Essayez de récupérer un maximum de monde pour les parties le plus de temps possible. Si vous trouvez de nouveaux bugs, corrigez les, et recommencez le processus des 48h.
Si votre MOD passe ce délais de 48h de playtests intensives sans qu'aucun nouveau bug n'ait été décelé, vous êtes prêts pour la release!
L'après sortie
Ainsi vous avez sorti votre projet, tout le monde en est tombé fou amoureux et on parle partout sur le Net de votre super MOD amusant et innovant! Vous êtes à présent rôdé, c'est à vous! D'après nos expériences, un MOD multijoueur reste populaire tant qu'il est soutenu, mis en valeur. Ça n'a pas d'importance de savoir ô combien votre MOD est génial, ça ne fera pas grossir votre public pour la première version.
La quantité de joueurs grossit avec la quantité de mises-à-jour que vous faîtes, des bugs que vous corrigez, et évidement du soutien de la communauté. Counter-Strike et Team Fortress ou tous deux commencé petit et ont grandi peu à peu. A chaque fois que leurs auteurs sortaient une nouvelle version, le public augmentait.
En sachant ce qu'il faut corriger, ce qu'il faut modifier, et surtout comment écouter la communauté est un processus d'apprentissage continu.
Bonne chance!
January 2024
