04/07/2025 - Cette page est issue du site de David Flor, l'auteur du Mod "Painrift", un mod que vous pouvez retrouver dans la section "Quake 2 & Mods". Il y raconte des anecdotes et ses mésaventures sur la création de son Mod "Painrift". Je tiens à le remercier de m'avoir permis de traduire et de publier cette page.

David “Nighthawk” Flor
Software developer and game designer in Miami, Florida.
Currently working on content for Dungeons and Dragons 5th Edition, Pathfinder, 13th Age and other systems.
Twitter: @BrainClouds
Facebook: A Walk In the Dark
http://brainclouds.net





03/04/2012 - L'histoire suivante a été publiée par moi même (David Flor) sur mon ancien site PlanetHalfLife. Je la republie non seulement par nostalgie, mais je pense aussi que les leçons apprises ici pourraient être utiles à d'autres.

D'après la "Wayback Machine", cet article a été publié le 8 octobre 1999… il y a une éternité. En le lisant, on constate qu'il est extrêmement ancien – il fait référence à des sites comme GameSpy, PingTool et ICQ – et qu'il n'a donc peut-être pas beaucoup de sens, sauf si vous avez vécu à cette époque.

Deux anecdotes sur PainRift qui ne sont pas mentionnées dans l'article d'Octobre 1999 un peu plus bas.

1) L'AirFist

L'image de droite offre un rare aperçu de l'une des meilleures armes de tous les temps : l'AirFist. C'était une "arme" qui ne tirait rien d'autre que de l'air comprimé. On entrait dans une pièce et tout ce qui n'était pas cloué (joueurs, objets, etc ) était projeté dans tous les sens. C'était incroyablement amusant de n'utiliser que cette arme, et je suis devenu particulièrement habile à renvoyer des roquettes vers quiconque les tirait.

Il y avait aussi des roquettes et des grenades AirFist. Imaginez une roquette volant dans les airs, émettant un jet d'air chaque seconde, semant la destruction sur son passage.

Une quantité spectaculaire de code a été consacrée à la prise en charge de l'AirFist, et cela reste l'une de mes plus grandes fiertés dans le domaine du jeu vidéo.

1) La soirée de lancement

Le jour de la sortie de PainRift, nous avons décidé d'organiser une sorte de "Soirée de lancement". Nous avons hébergé notre propre serveur dans un espace de colocation où je travaillais à l'époque (et c'était la première fois que je sature un T-1), et tous les membres de l'équipe se sont connectés quelques minutes avant la publication du lien sur FilePlanet.

Et nous avons attendu.

Dix minutes après la mise en ligne du lien, deux joueurs ont rejoint le serveur. Je ne sais toujours pas qui ils étaient, mais ils venaient de télécharger le jeu, n'y avaient jamais joué, n'y connaissaient rien et venaient de rejoindre un serveur avec huit membres de l'équipe qui l'avait développé. Je me souviens m'être dit : « Ça va être intéressant ! »

Et puis le carnage a commencé.

Ces deux joueurs anonymes et inexpérimentés ont ensuite écrasé l'équipe de développement – ​​moi y compris – de la manière la plus spectaculaire et humiliante qui soit. Dans notre propre jeu. J'ai même eu recours aux cheats du mode développeur… et ça n'a servi à rien. Dès qu'un membre de l'équipe apparaissait, nous étions frappés par une grenade ou propulsés en orbite grâce à l'AirFist.

Et aussi vite qu'ils sont arrivés, ils ont été déconnectés. L'équipe de développement ne savait pas quoi faire : était-ce un défaut de conception du jeu ou étions-nous tout simplement nuls ? Personne ne le saura jamais.

Une description complète du mod est toujours disponible sur PlanetQuake . En cherchant bien, vous pouvez même le télécharger via FTP !

Quoi qu'il en soit, je voulais juste le garder à ma manière.

-=O=-

Publié sur le site Web de Mach III Enterprises, anciennement hébergé par PlanetHalfLife, vers le 8 octobre 1999

Il y a environ un an (à peu près au moment de la sortie de Quake II 3.17), j'ai rejoint un groupe appelé Razor Entertainment qui planifiait une conversion totale appelée « Fracture ». Les plans étaient pour le moins ambitieux, et leur ampleur aurait pris un temps considérable ; nous avons donc dû les réduire considérablement. C'est de là qu'est né le concept initial de « PainRift ».

Travailler sur une conversion totale ou partielle est une tâche ardue en soi, une tâche qui demande bien plus d'implication que la plupart des gens ordinaires. Je suis devenu programmeur principal et j'étais vraiment impatient de faire fonctionner ce projet de la meilleure façon possible, mais j'avoue que je n'avais pas tout le temps nécessaire pour le faire au mieux. Les autres membres du groupe avaient apparemment moins de temps à consacrer, et très vite, les membres ont commencé à partir. À la fin de Razor, nous n'étions plus que quatre du groupe initial.

Mais nous ne voulions pas voir PainRift disparaître. Grâce à des contacts, nous avons rejoint RMD Software, l'une des entreprises les plus talentueuses avec lesquelles j'ai eu le privilège de travailler. Ils ont créé des cartes et des modèles plus rapidement que je n'ai pu mettre en œuvre le code, et très vite, nous avons eu une version jouable avec toutes les fonctionnalités. C'était génial !

Tout le monde dans le groupe était ravi de la beauté du résultat final et impatient de le diffuser avant que la fièvre Quake ne s'éteigne (comme si c'était possible). Tous les membres de RMD ont donc déclaré vouloir le publier à une date précise, quoi qu'il arrive. Je n'étais pas particulièrement emballé par cette idée, car je sentais qu'il n'était pas prêt, mais comme je pensais que tout le monde l'avait suffisamment testé pour être à l'aise, j'avais fait mon travail.

Mais il y a beaucoup de choses que nous n’avons pas prises en compte :

Nous ne l'avons jamais testé en profondeur sur un serveur. J'avais un serveur qui fonctionnait avec, et il fonctionnait parfaitement en réseau local. Mais la plupart des employés de RMD sont en Australie, tandis que je suis à Miami. Soyons honnêtes : impossible de faire plus éloigné géographiquement, et les pings étaient terribles. J'ai constaté un nombre considérable d'erreurs de "débordement" sur le serveur et j'ai travaillé d'arrache-pied pour réduire la bande passante générée, mais je n'ai pas pu reproduire facilement le problème en réseau local. Avec plus de 600 pings vers l'Australie, je ne m'attendais pas à des miracles. Nous aurions dû installer plusieurs serveurs pour tester sa stabilité, et comme nous ne le savions pas, vous savez tous très bien que PainRift plante extrêmement fréquemment.
Nous n'avions pas prévu de portage Linux ; nous n'avions jamais imaginé le flot de demandes qui en résulterait. PainRift a été conçu à l'aide de ce que j'appelais mon "API DLL", qui permettait de charger plusieurs DLL comme des plug-ins dans PainRift. Le code était entièrement propriétaire de Windows, et je n'avais aucune connaissance des bibliothèques dynamiques sous Linux (en fait, je ne possède même pas Linux), mais au moment de la sortie, ce n'était pas vraiment un problème.
Nous n'avions pas prévu de "bots". Je travaillais sur mon propre bot, mais la demande pour des bots comme Eraser dépassait largement mes possibilités.
Nous n'avons jamais proposé de configuration serveur complète. Les utilisateurs s'attendaient à des options de configuration comme Lithium et des produits similaires.
Nous ne l'avons jamais testé avec GameSpy et PingTool, et certains d'entre vous se souviennent peut-être que ça ne fonctionnait pas du tout avec eux. J'ai découvert un bug qui faisait planter GameSpy si on définissait trop de "cvar" de serveur dans Quake ! Comment étais-je censé le savoir ?
L'option « Désinstaller » de la version initiale désinstallait également Quake II. J'avais reçu plusieurs courriels de personnes se disant extrêmement furieuses, car, je cite : « … maintenant, je dois l'acheter et le RETOURNER ! »
Nous en avons fait beaucoup trop de publicité, compte tenu de tous les problèmes mentionnés ci-dessus. Quand nous avons annoncé sa disponibilité, tout le monde l'a récupéré et a découvert les problèmes trop facilement.
Ce n'était PAS une version bêta. Avec tous les éléments mentionnés ci-dessus, c'est une version bêta par définition, n'est-ce pas ? Bien sûr, l'étiqueter comme telle aurait réduit les attentes du public, et en ne le faisant pas, celui-ci s'attendait à un produit impeccable. Ne l'ayant pas reçu, ils ont pété les plombs.
Après la sortie initiale de PainRift, j'ai reçu au moins 100 e-mails par jour me signalant tous les problèmes mentionnés. J'ai fait de mon mieux pour les résoudre, réduire la bande passante, etc. Il m'a fallu une semaine pour résoudre le problème de GameSpy… C'était tout simplement trop. La sortie a été un désastre.

Puis sont arrivées les versions 1.01, 1.02 et la dernière, la 1.03. Au fil de ces versions, j'ai commencé à avoir de moins en moins de nouvelles des membres de RMD. Finalement, toute communication a été interrompue, et j'étais un peu perdu. Ils semblaient contrariés que la sortie soit un tel désastre, mais j'étais le seul à être mal à l'aise. Comme ils ne communiquaient pas avec moi et que je ne recevais quasiment aucun compliment ni remerciement, je me suis dit à quoi bon continuer ? Si le reste du groupe n'apprécie pas le travail fourni et ne comprend pas que ce n'est pas la bonne façon de sortir un produit, j'ai arrêté le développement et le support.

Alors, qu'est-ce qu'on peut apprendre ?

Ne vous fixez pas des objectifs inaccessibles. Si vous avez un seul programmeur, ne créez pas 20 monstres différents, chacun doté d'une IA unique (à moins que le programmeur ne soit un millionnaire autodidacte). N'oubliez pas que chaque monstre ou arme implique beaucoup de code, de modèles, de sons et de tests.
Testez-le à fond. Installez-le sur plusieurs serveurs. Testez-le sur un réseau local et, si possible, à l'international. Testez-le avec plus de trois personnes au total. Testez les choses les plus stupides qui vous viennent à l'esprit. C'est le principe même des bêta-tests : ne testez pas ce que vous pensez efficace, testez ce que la plupart des gens normaux n'essaieraient pas. Exemple : un bug majeur des premiers PainRift provoquait un crash du serveur lorsque deux roquettes entraient en collision en plein vol. Vous n'y penseriez pas, n'est-ce pas ?
Si vous pensez que votre produit est prêt à être distribué, ce n'est probablement pas le cas. Si vous pensez qu'il est prêt à être publié, ajoutez au moins deux à trois semaines et continuez à travailler dessus et à le tester.
Quelle que soit votre version, même après l'avoir testée minutieusement, étiquetez-la toujours comme bêta. Ce n'est peut-être pas bon pour le marketing, mais cela vous laisse une marge d'erreur. On s'attend à ce qu'un produit non bêta soit parfait ; aucun programme ne l'est jamais à sa sortie.
Lors de la sortie, assurez-vous que votre groupe dispose de temps libre pendant les deux semaines suivantes. Si votre mod est superbe, mais qu'il contient un bug catastrophique inacceptable pour le grand public, il doit être corrigé immédiatement. Attendez-vous à corriger les choses en profondeur pendant les deux prochaines semaines. De plus, si vous ne pouvez pas tout corriger, montrez au public que vous faites tout ce qui est humainement possible. S'ils insistent encore, rappelez-leur qu'il s'agit d'une « bêta »…
Restez en contact avec vos collègues. ICQ est indispensable de nos jours, et IRC est fortement recommandé. Si possible, organisez une réunion IRC au moins une fois par semaine pour savoir qui fait quoi.
Assurez-vous que chacun fasse quelque chose. Si certains membres du groupe ne sont pas productifs, cela nuit à la performance de tout le groupe. N'hésitez pas à demander à quelqu'un d'aller se faire voir ; le temps passé à expliquer à un nouveau comment faire est bien moindre que d'essayer de convaincre un individu inefficace de faire de même.
Merci et cordialement…

David Flor, alias Nighthawk
, programmeur principal,
président de l'équipe de développement de PainRift, Mach III Enterprises