Pro Strats : X-COM (1994), auteur du guide stratégique David Ellis sur l'assurance qualité et la rédaction de guides

Je collectionne des guides de stratégie depuis que je suis enfant. En fait, ma collection m’a causé des ennuis plus d’une fois. Je glissais un guide entre les dossiers de mon Trapper Keeper et le faisais entrer clandestinement en classe, où j'absorberais des conseils de pro et des stratégies d'experts derrière un mur de manuels. Oui, j'étais ce cinglé qui lisait des guides de stratégie comme des romans. J'ai admiré le talent artistique de leurs mises en page et de leur texte, et j'ai été fasciné par les informations organisées de manière si colorée sur leurs pages brillantes.

C'est ce qui a fait de discuter avec David Ellis, auteur de guides stratégiques pour de nombreux jeux, parmi lesquels Sid Meier's Civilization II et UFO: Enemy Unknown, un tel plaisir. Il est également l'auteur de Civilopedia, l'énorme encyclopédie intégrée au jeu de Civ II, ainsi que d'une construction de jeu qui a eu un impact énorme sur le développement de X-COM.

[Note de l'auteur :Monstres dans le noir : la réalisation de X-COM : Défense contre les ovnisraconte l'histoire des premières années du légendaire concepteur de jeux de stratégie Julian Gollop et de la réalisation du X-COM original, et estfinancement maintenant sur Kickstarter. Cet extrait est issu de l'édition spéciale du livre, disponible exclusivement sur Kickstarter.]

David L. Craddock : Qu'est-ce qui vous a amené à vous intéresser aux jeux informatiques ?

David Ellis :J'ai joué à mon premier jeu vidéo à pièces quand j'avais neuf ans, Atari's Breakout, dans un bowling où je jouais dans une ligue. C'était vers 1974. J'ai été immédiatement fasciné par les jeux vidéo et j'ai finalement acheté un Atari 2600 en économisant sur l'argent du papier. Je suis devenu accro à partir de ce moment-là.

Craddock :Avez-vous toujours voulu devenir designer ou étiez-vous heureux de travailler dans n'importe quel poste dans l'industrie ?

Ellis :Lorsque l'engouement pour les jeux vidéo s'est installé à la fin des années 70 et au début des années 80, j'ai vu un segment de 60 minutes sur Atari. L’une des choses dont ils ont parlé était de tester des jeux vidéo. À cette époque, j'étais un véritable accro aux jeux vidéo et j'ai dit à mes parents que le travail que je voulais était de tester des jeux vidéo. Pas particulièrement réaliste à l’époque.

En fait, je voulais finalement faire carrière dans la production cinématographique ou télévisuelle. Je n'avais vraiment jamais pensé sérieusement à une carrière dans le jeu vidéo avant de travailler chez MicroProse.

Craddock :Comment en êtes-vous arrivé à travailler chez MicroProse ?

Ellis :Pendant mes études universitaires, j'avais un emploi dans la vente d'ordinateurs dans un petit magasin de détail. J'ai pu jouer à beaucoup de jeux sur un tas d'ordinateurs différents : nous avons vendu des machines et des logiciels compatibles Commodore, Atari et IBM. Après avoir quitté le commerce de détail, j'ai trouvé un emploi pour le gouvernement de Washington DC en tant que « spécialiste des télécommunications », ce qui équivalait à un opérateur téléphonique glorifié qui envoyait également des télex occasionnels. Vous vous en souvenez ? L'argent était meilleur que le commerce de détail, mais je détestais les déplacements et le travail était ennuyeux. J'ai commencé à parcourir les annonces d'emploi dans les journaux tous les lundis matin.

Un jour, j'ai vu une annonce pour un représentant du service client chez MicroProse. J'adorais les jeux MicroProse et j'en savais beaucoup sur eux, et j'avais beaucoup d'expérience pratique dans le service client informatique, alors j'ai postulé. J'ai pensé que c'était quelque chose que je pouvais faire, plus proche de chez moi et plus amusant, jusqu'à ce que je comprenne ce que je voulais faire à long terme. Ce travail s'est transformé en carrière.

Craddock :Quelle était la culture et l’atmosphère chez MicroProse ?

Ellis :Sans égal. Si vous demandez à presque tous ceux qui ont travaillé chez MicroProse, ils vous diront que c'était le meilleur travail qu'ils aient jamais eu. Je n'ai jamais travaillé dans un environnement plus créatif et amusant. Nous avons travaillé dur, et parfois de longues heures, mais, surtout, nous l'avons fait parce que nous aimions absolument ce que nous faisions et que nous étions fiers de participer à la création de grands jeux. Nous faisions tout le temps des choses ensemble en studio, du paintball aux rallyes de camions monstres télécommandés en passant par la constitution d'un groupe impromptu pour jouer à la fête de Noël de l'entreprise.

Nous avons également pu faire beaucoup de choses sympas directement liées au travail, comme visiter et visiter la base aéronavale d'Oceana tout en travaillant sur Fleet Defender Gold.

Comme je l'ai dit, nous avons travaillé dur, mais nous avons eu du plaisir à le faire. Il s’agit d’une partie importante du développement de jeux qui est souvent perdue dans la période critique d’aujourd’hui par les studios de développement de jeux.

Craddock :Votre premier emploi était dans le service client, je crois. Qu'impliquait le travail ?

Ellis :Répondre au téléphone et au courrier (le vrai courrier – nous n'avions pas de courrier électronique à ce moment-là, même si nous avions un BBS géré séparément du service client). Les gens appelaient ou écrivaient pour nous signaler des problèmes et nous leur parlions du problème ou leur envoyions un disque de correctif pour résoudre les problèmes connus. Nous étions trois ou quatre au service client. Nous étions toujours très occupés.

Craddock :Pouvez-vous partager des anecdotes sur vos journées de service client ? N’importe quelle saveur : bizarre, humoristique, frustrante, etc.

Ellis :Windows était le fléau de notre existence. C'était alors assez nouveau : tous les jeux de MicroProse étaient des jeux DOS jusqu'en 1995 environ, si je me souviens bien, mais les machines étaient livrées avec Windows 3.1 préinstallé. Le problème était que les jeux DOS nécessitaient une certaine quantité de mémoire de base pour être libres – jusqu'à 600 Ko (sur 640 Ko – c'est beaucoup si vous ne vous souvenez pas comment c'était à l'époque), et les jeux ne fonctionneraient pas si Windows était en cours d'exécution. La moitié des problèmes que nous avons rencontrés avec les gens incapables d'exécuter un jeu ont été résolus en les faisant démarrer sous DOS plutôt que sous Windows.

La compatibilité était également un problème. Il y avait tellement d'ordinateurs compatibles IBM qu'il était difficile de savoir quelles combinaisons de matériel fonctionneraient ou non avec nos jeux. Il y avait aussi des ordinateurs Tandy, qui n'étaient PAS particulièrement compatibles IBM. C’était une période vraiment déroutante pour les consommateurs et leur frustration était compréhensible.

Cependant, ma meilleure histoire en matière de service client est celle qui m'a incité à trouver un emploi dans le domaine de l'assurance qualité. Un jour, j'étais le seul au téléphone et j'ai reçu un appel d'un homme afro-américain très contrarié par le F-117A [Nighthawk] – en particulier, il a dit que le jeu était raciste. J'ai demandé calmement en quoi une simulation de vol pouvait être raciste, et il a répondu qu'on n'avait vu un pilote afro-américain que deux fois dans le jeu. Lorsque vous échouiez une mission, un pilote afro-américain a été vu en train d'écrire "Je ne planterai pas mon F-117" sur un tableau.

Lorsque vous avez gagné, il y avait une photo de célébration où le pilote afro-américain était en arrière-plan célébrant la victoire d'un pilote blanc. J'étais calme et serein et j'essayais d'être aussi sympathique que possible. L'appel a duré 45 minutes et, lorsque le reste du service est revenu (ils étaient à une réunion d'entreprise et j'ai tiré la courte paille en m'occupant seul des téléphones pendant leur absence), j'ai dû m'éloigner d'environ une demi-heure. les téléphones pour retrouver ma raison. Cette nuit-là, j'ai parlé au responsable QA de la possibilité de passer du service client au QA.

Craddock :Tous ceux à qui j'ai parlé et qui ont travaillé dans l'industrie dans les années 80 et 90 ont parlé de porter plusieurs chapeaux. Était-ce votre cas lors de votre passage au service client ?

Ellis :Pas du tout. J'ai commencé en 1992, et MicroProse était alors très importante : environ 120 personnes à Hunt Valley et des bureaux au Japon et au Royaume-Uni. MicroProse regroupait tout sous un même toit : développement, marketing, ventes, assurance qualité, service client et même l'entrepôt était sur place. En réalité, les seules personnes qui portaient plusieurs casquettes étaient les développeurs qui étaient là depuis longtemps, comme Sid Meier, Scott Spanburg et Andy Hollis, qui étaient à la fois programmeurs et concepteurs. Presque tout le monde s’en tenait à son propre truc.

Craddock :Comment êtes-vous passé au QA ?

Ellis :Terres sombres. C'était le premier (et le seul) RPG de MicroProse, et c'étaiténorme. J'ai commencé à travailler des heures supplémentaires à temps partiel au contrôle qualité après le travail pour aider à tester le jeu. C'est ainsi que j'ai entendu dire qu'il y aurait des postes à temps plein dans le département QA. J'avais déjà prouvé que je pouvais passer des tests au moment où j'ai demandé un poste à temps plein, ce qui me permettait de faire le changement assez facilement.

Craddock :Comment vous souvenez-vous de l’environnement de travail d’assurance qualité chez MicroProse ?

Ellis :Le contrôle qualité était surtout très amusant. Nous étions tous entassés à des tables dans ce qui était en réalité censé être un couloir. Eh bien, c'était un couloir et il était utilisé comme tel. Il se trouve que nous travaillions là-bas. Finalement, nous nous sommes agrandis pour reprendre la moitié arrière de la salle de repos des employés ; il y avait un mur de séparation qui pouvait être fermé. C'était très rapproché, ce qui signifiait qu'il y avait beaucoup de camaraderie. Cela signifiait également que si une personne tombait malade, tout le monde tombait malade. Une fois, la majeure partie du département était atteinte de mono. Nous avons partagé un téléphone. C’était une véritable fête des germes.

Quant aux horaires, ils variaient d'un projet à l'autre. Comme je l'ai dit, Darklands était un jeu énorme, donc beaucoup de prolongations ont été travaillées sur ce jeu. Il était encore en test un an après mes débuts en QA ! Sur certains jeux, il y avait toujours une pression de la part de la direction, en particulier du marketing, pour que nous restions en retard dans les tests, même s'il n'y avait pas de nouvelle version disponible pour les tests.

Quand je suis devenu testeur principal, j'ai toujours résisté à cette tendance : je ne laissais pas mon équipe faire ce que j'aimais appeler des « heures supplémentaires politiques » : travailler tard juste pour les apparences. Mais parfois, on n'avait pas le choix. L’un de nos testeurs – aujourd’hui concepteur sonore chez Vicious Cycle Software, où je travaille actuellement – ​​aime se vanter d’avoir travaillé 25 heures par jour au contrôle qualité – c’était le jour où les horloges ont changé à l’automne.

Ce qui est génial avec le contrôle qualité chez MicroProse, c'est que, pour la plupart, les équipes de développement ont travaillé en étroite collaboration avec nous et ont respecté nos opinions et nos idées ainsi que nos rapports de bogues. Nous avons beaucoup appris sur le processus de développement dans MicroProse QA. Beaucoup des responsables du contrôle qualité avec lesquels j'ai travaillé sont devenus designers.

Craddock :Quel a été le premier jeu que vous avez testé ?

Ellis :Darklands version 3.0, la version originale. Mon premier grand jeu en tant que testeur principal, presque un an plus tard, était également la version 7.0 de Darklands, la version finale.

Craddock :Quelles sont les différences entre les tests de jeux de différents genres ?

Ellis :Il y a une grande différence. Comprenez qu’il n’existait pas de système de test automatisé à l’époque. En fait, tout consistait à jouer encore et encore à des parties d'un jeu pour trouver des bugs.

Les jeux les plus faciles à tester étaient les aventures graphiques animées. J'ai travaillé sur les trois : Rex Nebular, Return of the Phantom et Dragonsphere. C'étaient des jeux longs en termes de temps de jeu, mais ils avaient l'avantage d'être divisés en salles distinctes et le nombre d'actions que vous pouviez effectuer était limité. Ainsi, un test systématique des systèmes de jeu pourrait être effectué en faisant une liste de contrôle de toutes les pièces et de toutes les actions, puis en demandant aux testeurs d'aller de pièce en pièce en poussant, tirant, en parlant, etc. avec chaque objet avec lequel le joueur pourrait interagir. . Cela a facilité le test des fonctionnalités du jeu. (Le déroulement et les éléments de connexion du jeu devaient encore être testés, bien sûr, mais les commandes et les fonctionnalités étaient simples.)

Les Sims étaient beaucoup plus difficiles à gérer. Je n'ai testé qu'une ou deux simulations, mais celles-ci voyaient généralement l'équipe se diviser entre ceux qui testaient les performances du véhicule simulé tandis que d'autres testaient le déroulement des missions, les missions individuelles et les scénarios. Tester un scénario dans une simulation pourrait être l’un des types de tests les plus fastidieux. Vous avez joué le même scénario encore et encore, en essayant de trouver différentes façons de le tester (c'est-à-dire de le casser). Après environ 20 heures sur le même scénario, vous pourriez proposer des choses vraiment créatives à faire juste par pur ennui.

Les jeux de stratégie ont été les plus difficiles à tester. Les systèmes de jeux comme Civ étaient généralement testés et perfectionnés pendant le développement, à la fois par les développeurs eux-mêmes et par les testeurs d'assurance qualité. Ainsi, lorsque le jeu est arrivé au contrôle qualité, la plupart des tests consistaient à s'assurer que tous les systèmes fonctionnaient correctement ensemble.

Lorsque Civ II était en cours de développement, Bryan Reynolds envoyait des versions tous les quelques jours à plusieurs personnes compétentes en Civ pour obtenir des commentaires sur les nouvelles unités, les nouveaux systèmes, etc. Au moment où le jeu est arrivé au contrôle qualité, une grande partie de l’équilibrage était déjà effectuée, ce qui rend la tâche plus facile à gérer en termes de tests.

Craddock :Comment définiriez-vous l’objectif du QA ? S’agit-il davantage de suivi des bugs, ou l’équilibre du jeu est-il un problème tout aussi important, voire plus important ?

Ellis :Quand j'étais en assurance qualité, les deux étaient tout aussi importants. Comme nous étions sous le même toit que les développeurs, nous pouvions parler directement aux programmeurs et designers. La plupart des concepteurs et des programmeurs ont pris très au sérieux les suggestions d'équilibrage et de gameplay du contrôle qualité. Nous étions tous investis pour rendre le jeu aussi bon qu'il pouvait l'être.

Aujourd'hui, c'est très différent. Nous utilisons généralement soit les services d'assurance qualité des éditeurs, soit des groupes externes, et ils s'en tiennent pour la plupart entièrement au suivi des bogues.

Craddock : Y avait-il beaucoup de structure dans le département QA à cette époque ? Par exemple, aviez-vous des listes de bogues et une procédure pour éliminer les bogues ? Ou s’agissait-il plutôt de dresser une liste de choses à faire et de parcourir chaque élément ?

Ellis :Il n'y avait pas vraiment de plans de test spécifiques à cette époque, mais chaque jeu avait un testeur principal qui coordonnait les tests, définissait les tâches pour chacun chaque jour et contrôlait la liste des bugs. Les bugs étaient écrits à la main à l’époque. Il existait un programme principal de liste de bogues, mais le testeur principal était celui qui y enregistrait tous les bogues et imprimait la liste des bogues chaque jour. Les temps ont changé.

Craddock :Selon Mobygames.com, vous avez écrit le « fichier d'aide Windows » pour Civ 1. Comment avez-vous eu cette opportunité ?

Ellis :L’une des façons dont je suis passé de l’assurance qualité à la conception a été de saisir toutes les opportunités qui se présentaient. Lorsque nous avons converti Civ en Windows 95, j'ai suggéré que, comme les autres programmes Windows, nous ayons un fichier d'aide Windows pour le jeu. Personne n’a eu le temps de l’écrire, alors je me suis porté volontaire.

J'étais le testeur principal sur Civ Mac et le responsable adjoint sur Civ Windows. À ce moment-là, j'étais encore relativement nouveau en tant que testeur principal, et il s'agissait de projets plus petits (simples conversions vers Mac et Windows), il n'y avait donc que quelques testeurs dessus. Il était assez courant que les testeurs qui débutaient dans des postes de direction se voient confier au début des projets plus petits.

J'ai adoré Civ, et je l'aime toujours. Civ II était mon préféré de la série et j'ai vraiment apprécié Civ Revolutions.

Craddock :Vous avez écrit la Civilopedia pour Civ II. Qu’a impliqué ce processus ? Je ne peux qu'imaginer combien de temps il a fallu pour retrouver toutes les informations dont les joueurs pourraient avoir besoin pour un jeu impliqué.

Ellis :C'était un assez gros projet. La recherche était un peu plus difficile en 1995 qu'elle ne l'est aujourd'hui (pas de Wikipédia), donc il s'agissait en grande partie de recherches de livres et de coordination avec le responsable de la conception, Brian Reynolds, sur les choses qu'il essayait de transmettre avec certaines avancées [dans le jeu] . (Je me souviens que « Machines-outils » était un concept difficile à aborder.) Ensuite, nous avons dû retrouver et obtenir les droits sur les images que nous utilisions dans la Civilopedia. Le « multimédia » était un mot à la mode dans l'industrie à cette époque, la Civilopédia devait donc être une « Civilopédia multimédia ». Par conséquent, des photos plutôt que de l’art.

J'ai également programmé Civilopedia à l'aide de Macromedia Authorware, l'outil de script que nous avons utilisé pour ajouter du contenu multimédia à Fleet Defender Gold, sur lequel j'ai également travaillé. Les programmeurs du projet ont dû faire quelques astuces de programmation assez astucieuses pour que l'exécutable Authorware fonctionne de manière transparente avec le jeu lui-même.

Craddock :D’une part, de nombreux joueurs aiment Civ parce qu’ils peuvent lire des volumes et des volumes d’histoire fascinante. D’un autre côté, certains joueurs souhaitent simplement trouver les informations dont ils ont besoin et recommencer à jouer. En écrivant la Civilopédia, quel était votre objectif en termes de style et de présentation de l'information ?

Ellis :J'ai adopté une approche encyclopédique que je n'adopterais probablement pas aujourd'hui. À l’époque, il y avait des joueurs qui aimaient lire. Aujourd’hui, la plupart d’entre eux ne peuvent plus s’en soucier. Dans tous les cas, le joueur pouvait cliquer au-delà de la Civilopedia sans la lire. Je soupçonne que la partie la plus utile de Civilopedia était l'arbre technologique interactif, que j'ai trouvé plutôt intéressant. Vous pouvez cliquer sur Advances et voir où ils vous mèneront. Chacun était hyperlié aux entrées de Civilopedia pour leurs avancées, unités, bâtiments et merveilles associés. Je suppose qu'au moins une partie de cela était intéressante/utile pour le joueur. Je l'espère en tout cas.

Craddock :Qu’avez-vous le plus apprécié dans le test de Civ II ?

Ellis :Même si j'étais concepteur au moment où Civ II est entré dans le développement, j'ai pu être l'un des sujets de test de Brian Reynolds lorsqu'il était au début du développement du jeu. J'étais l'un des "experts civils" qui lui faisait part de ses commentaires sur les unités, les avancées, etc. qu'il ajoutait au jeu.

Craddock :Pour aller un peu plus loin, comment avez-vous eu l’opportunité de concevoir Civ II : Multiplayer Gold Edition ?

Ellis :À cette époque, j'étais concepteur principal au studio MicroProse à Chapel Hill, en Caroline du Nord. Chapel Hill avait réalisé CivNet, la version multijoueur du Civ original, pour lequel j'ai écrit et programmé le didacticiel interactif, ils ont donc eu le feu vert pour faire Civ II multijoueur. En tant que designer du studio – et en tant que personne connaissant très bien Civ II – je suis devenu le designer. C’était une formidable opportunité.

Craddock :Civ 1 et II étaient des jeux conçus pour les expériences solo. Quels types de modifications de conception ont été apportées pour rendre Civ II amusant et intéressant en tant qu'expérience multijoueur ?

Ellis :La principale chose qui a dû être modifiée était le début du jeu. Tant que vous n'avez pas lancé vos villes et déployé quelques unités, vous ne faites pas grand-chose au cours des premiers siècles, à part appuyer sur la barre d'espace pour passer au tour suivant. C'est bien en solo, mais en multijoueur, vous avez 7 personnes qui appuient simplement sur la barre d'espace et attendent assez longtemps avant que les choses ne démarrent vraiment. Ensuite, il faut beaucoup de temps (surtout sur un monde plus vaste) pour s’étendre suffisamment loin pour rencontrer un autre joueur.

Ma solution à ce problème consistait à proposer l’idée de l’option Double Production. Lorsque vous avez sélectionné cette option, chaque case de terrain produisait deux fois plus de ce qu'elle produisait normalement, doublant ainsi la vitesse de tout dans le jeu : recherche, production d'unités, construction de bâtiments, etc. Cela a rendu la première partie du jeu (et le jeu entier) beaucoup plus rapide. Le seul effet secondaire négatif était que les joueurs finissaient souvent par produire de la pollution avant d’avoir les moyens d’y faire face. Même ainsi, il s’agissait d’une considération mineure qui était largement contrebalancée par les avantages.

La seule autre chose que j'ai faite a été de déplacer le texte de Civilopedia vers une version non multimédia de Civilopedia. La version multimédia était trop lourde et trop lente pour les jeux en réseau.

Craddock :Comment avez-vous eu l’opportunité d’écrire le guide stratégique X-COM ?

Ellis :C'était une autre de ces opportunités que j'ai saisies lorsqu'elles sont devenues disponibles. À cette époque, il y avait en fait un rédacteur chez MicroProse dont la tâche principale était de rédiger des guides stratégiques. Quand le moment est venu d’écrire le guide X-COM : UFO Defense, il a été submergé d’autres travaux. Il savait que je pouvais écrire grâce au fichier d'aide Civ Windows et à quelques autres petites choses que j'avais écrites à ce moment-là, alors il m'a demandé si je serais intéressé.

Craddock :Quelle était votre familiarité avec le développement de X-COM avant de commencer ce guide ?

Ellis :Je connaissais déjà assez bien le jeu à ce moment-là. En fait, le guide stratégique UFO Defense n'a même pas été lancé avant la fin du jeu, et il n'a été publié que six mois après la sortie du jeu, donc le jeu avait déjà fait l'objet d'un contrôle qualité à ce stade.

Histoire parallèle intéressante : X-COM UFO Defence a failli ne pas être publié aux États-Unis. Les jeux développés au Royaume-Uni étaient presque toujours exécutés via Hunt Valley QA avant de recevoir le feu vert pour une sortie aux États-Unis. Il s'agissait d'une évaluation de base du gameplay plutôt que d'un test complet : en gros, « Ce jeu plaira-t-il au public américain ? » La réaction de la direction de l'assurance qualité à l'époque était sceptique : ils pensaient que les graphismes étaient primitifs (je me souviens très bien de quelqu'un disant : « Pas aussi bon que Darklands ») et que le gameplay ne semblait pas amusant. Les testeurs qui l’ont évalué se sont toutefois montrés très enthousiastes. En conséquence, le jeu a reçu le feu vert pour une sortie aux États-Unis.

Craddock :Je n'avais pas réalisé que les développeurs et les concepteurs rédigeaient parfois des guides stratégiques sur les jeux développés/publiés par leurs entreprises. Quelle a été la relation entre MicroProse et Prima pour le guide stratégique ?

Ellis :Je ne sais pas si c'était la même chose pour toutes les entreprises, mais Prima et MicroProse avaient un accord quasiment exclusif. Je ne sais pas exactement quand cela a changé mais, au moment où j'ai écrit le guide stratégique de Civ II, je traitais directement avec Prima. Cependant, pendant que je travaillais chez MicroProse, je n'étais encore contractuellement autorisé à créer que des guides pour les jeux MicroProse.

Craddock :Pouvez-vous nous donner un aperçu général de ce qu’implique l’élaboration d’un guide stratégique pour un jeu aussi complexe et complexe que X-COM ?

Ellis :En y repensant maintenant, le guide stratégique de défense OVNI est à moitié manuel, à moitié guide de stratégie. Je me souviens avoir adopté l'approche consistant à enseigner les bases du jeu et à développer le manuel parce que je pensais que le manuel n'était pas assez clair pour enseigner le jeu correctement. Pour la partie stratégie proprement dite, je comptais beaucoup sur le fait de parler aux Gollops, qui se sont mis à ma disposition pour toute question, et d'obtenir d'eux des données brutes de jeu. J'ai également discuté avec les testeurs américains qui ont le plus joué au jeu pour compiler leurs stratégies. Finalement, j'ai beaucoup joué et j'ai écrit mes propres stratégies.

Mon approche des guides stratégiques a beaucoup changé après le premier couple. Plus de stratégie, moins d'instructions. Mais je me suis toujours beaucoup appuyé sur les commentaires des concepteurs des jeux lorsqu'ils étaient disponibles, ainsi que sur mon expérience personnelle en jouant au jeu.

Craddock :Puisqu'il existe de nombreuses façons pour les joueurs d'aborder X-COM, comment avez-vous procédé pour documenter les stratégies permettant de remporter les nombreux types de missions au sol ? que rechercher en premier, en deuxième et en douzième ; etc.?

Ellis :Je ne pense pas vraiment avoir fait un très bon travail dans ce guide sur la défense des ovnis. J'ai opté davantage pour une approche basée sur les données brutes : donner aux joueurs une vue de la façon dont tout fonctionne sous le capot et les laisser décider de la meilleure façon d'élaborer leurs recherches pour obtenir ce qu'ils veulent le plus rapidement possible.

Craddock :Le guide comprend de nombreux graphiques, tableaux et autres graphiques. Comment avez-vous procédé pour compiler ces données et les organiser dans un format que les joueurs trouveraient utile ?

Pour UFO Defence, c’était aussi simple que de demander les données à Julian et Nick Gollop. Ils m'ont envoyé un disque avec tout ce dont j'avais besoin. Je l'ai ensuite mis dans des tableaux d'une manière que je trouvais utile et j'espérais que d'autres joueurs le trouveraient également utile.

Craddock :Qu’est-ce qui vous a semblé le plus difficile dans la rédaction d’un guide stratégique ?

Ellis :Tout comme pour tester des jeux, le type de jeu auquel vous avez affaire détermine la difficulté de rédaction du guide. D'après mon expérience, les jeux de stratégie et les jeux de tir en temps réel constituent les guides de stratégie les plus simples : lorsque vous pouvez tracer des niveaux pour le joueur et indiquer les lieux et les compositions des rencontres, cela représente la moitié de votre guide sur place. Les jeux de stratégie comme Civ II sont beaucoup plus difficiles car il existe de nombreux styles de jeu potentiels et chemins vers la victoire. Cela signifie beaucoup plus en termes de stratégies viables et d’approches potentielles du jeu.

La chose la plus difficile au moment où j’ai arrêté d’écrire des guides stratégiques était le respect des délais. Sur les premiers guides que j'ai écrits, j'ai eu plusieurs mois pour les rechercher et les rédiger. Mais finalement, les délais sont devenus de plus en plus serrés. J'ai écrit le guide stratégique de X-COM Interceptor en 28 jours, ce qui n'était pas trop mal puisque j'étais le game designer ; Je connaissais toutes les stratégies. Mais certains guides ultérieurs que j'ai réalisés ont dû être recherchés et rédigés en trois semaines.

Ce n'est tout simplement pas assez de temps pour jouer au jeu et développer des stratégies significatives. C'est pourquoi j'ai arrêté d'écrire des guides de stratégie. Trop mouvementé et stressant.

Craddock :Qu’est-ce qui vous a le plus plu dans la rédaction du guide ?

Ellis :Jetez un œil aux coulisses des statistiques du jeu. C’était vraiment pédagogique en termes d’apprentissage du game design. Et bien sûr, j’ai beaucoup joué à UFO Defense. C'est toujours une bonne chose.

Craddock :Avec le recul, que signifie pour vous ce jeu phare aujourd’hui ?

Ellis :UFO Defense est un bon exemple de la façon dont un gameplay puissant peut rendre un jeu intéressant même deux décennies après sa sortie. Le jeu n’a plus grand chose à voir de nos jours, mais il est toujours aussi amusant à jouer aujourd’hui qu’il l’était à l’époque. Le fait que le jeu Firaxis XCOM soit si similaire à l'original en termes de mécanismes de base témoigne de la qualité du jeu. C'est la marque d'un bon jeu : il résiste à l'épreuve du temps.

David L. Craddock est l'auteur du best-sellerRestez un moment et écouteztrilogie détaillant l'histoire de Blizzard Entertainment,Chevalier à la pellepar Boss Fight Books, et plus d'une douzaine d'autres livres sur la culture du jeu vidéo. Suivez-le en ligne@davidlcraddocksur Twitter.Monstres dans le noir : la réalisation de X-COM : Défense contre les ovnisestfinancement maintenant sur Kickstarter.

Divulgation : David L. Craddock est l'auteur deMonstres dans le noir : la réalisation de X-COM : Défense contre les ovnis, et l'éditeur de lectures longues sur Shacknews.com. Ce message n'est pas considéré comme une approbation de son livre ou de sa campagne de financement participatif.