# Rogue (jeu vidéo)

Rogue est un jeu vidéo datant de 1980, conçu par Michael Toy, Glenn Wichman et Ken Arnold pour les terminaux Unix.

## Système de jeu

Le joueur doit descendre dans un vaste ensemble de souterrains pour y trouver l'Amulette de Yendor et la ramener à la surface. Pour chaque session de jeu, il ne dispose que d'une seule vie et d'une seule sauvegarde, empêchant les retours en arrière. Ce système de mort permanente est associé à un mécanisme de création de niveaux aléatoire, conduisant à des parties toujours différentes.
Le principe s'inspire des jeux de rôle « médiévaux-fantastiques » tels que Donjons et Dragons et des fictions interactives telles que Colossal Cave Adventure. Contrairement à ce dernier, qui décrit l'univers du jeu de manière purement narrative, Rogue utilise les caractères ASCII pour symboliser à l'écran le terrain, les trésors et les créatures (y compris le joueur) qui composent les souterrains.
Les mouvements de base (H, gauche ; J, bas ; K, haut ; L, droite) sont les mêmes que le contrôle du curseur dans l’éditeur de texte vi. Les autres actions nécessitent également l'utilisation d'une simple touche : Q (quaff) pour boire une potion, W (wear) pour porter une armure, E (eat) pour manger, etc.

## Développement

Rogue est développé par Glenn Wichman et Michael Toy en 1980 alors qu’ils sont encore étudiants à l’université de Californie à Santa Cruz.
Michael Toy grandit à Livermore en Californie, où son père travaille dans l’industrie nucléaire. Lors des visites annuelles du lieu de travail de ce dernier, il est autorisé à utiliser un ordinateur central et découvre ainsi le jeu de simulation spatiale Star Trek (1971). Il commence alors à s’intéresser à la programmation et tente de recréer le jeu sur d’autres ordinateurs comme le Sol-20 de Processor Technology (en) ou l’Atari 400. À la fin des années 1970, il intègre l’université de Californie à Santa Cruz pour y suivre des cours d’informatique. Grâce aux ordinateurs PDP-11 puis VAX-11 de l’université, il accède aux jeux disponibles sur le réseau ARPANET et découvre ainsi le jeu d'aventure textuel Colossal Cave Adventure (1976). Impressionné par ce dernier, il commence à programmer sa propre version du jeu. Il fait par ailleurs la connaissance de Glenn Wichman, qui étudie lui aussi l’informatique à l’université avec l’objectif de créer son propre jeu d’aventure en s’inspirant des jeux de rôle sur table comme Donjons et Dragons. Ils deviennent rapidement amis et commencent à collaborer$^,$. Ils découvrent alors la bibliothèque logicielle curses, qui est à l’époque incluse dans le système d’exploitation Berkeley Software Distribution utilisé dans la plupart des universités de Californie. Cette dernière permet de positionner facilement des caractères sur un terminal informatique et ils réalisent rapidement qu’ils peuvent potentiellement l’utiliser pour créer une interface graphique. Après avoir programmé quelques jeux pour se familiariser avec curses, ils imaginent un jeu d’aventure inspiré de Donjons et Dragons et décident d’y intégrer des éléments qui changent à chaque nouvelle partie afin de remédier au manque de rejouabilité des jeux d’aventures de l’époque. Ils inventent également son scénario centré sur un aventurier qui doit explorer un donjon à la recherche de trésors. Le nom du jeu est trouvé par Glenn Wichman à partir de l’idée que le personnage sera seul, et non en groupe comme dans Donjons et Dragons, et avec l’objectif de proposer un nom court et facile à taper en ligne de commande$^,$.
Plus expérimenté en la matière, Michael Toy mène la programmation en C du jeu, tout en apprenant ce langage à Glenn Wichman, qui se focalise plutôt sur le design$^,$. Les deux premiers aspects du développement qu’ils abordent concernent la manière de générer le donjon aléatoirement et de le représenter à l’écran. Limité par les options d’affichages offertes par les ordinateurs de l’époque, ils décident de s’en tenir à l’utilisation de caractères en ASCII comme des points pour le sol, des plus pour les portes et des barres verticales pour les murs du donjon. Ils choisissent également d’utiliser l’arobase pour représenter le personnage du joueur en considérant que ce symbole montre où celui-ci se trouve. Pour générer le donjon, ils essayent d’abord un système de génération entièrement aléatoire, mais celui-ci ne se révèle pas concluant. Ils se tournent alors vers la génération procédurale en créant chaque niveau à partir d’une grille de tic-tac-toe de 3x3 cases, chaque pièces occupant ensuite une de ces cases, puis en générant les couloirs qui les relient. Après avoir résolu ces deux problèmes, ils se penchent sur l’intégration des armes, des objets magiques et des monstres dans le jeu. Concernant les objets magiques, ils souhaitent que leurs effets soient initialement ignorés par le joueur. Ils décident donc qu’ils seront initialement présentés par une simple description (une couleur par exemple) et que leurs véritables effets ne sont révélés au joueur que sous certaines conditions, comme le niveau du personnage ou l’utilisation d’un moyen d’identification de ces objets. Concernant les monstres, leur objectif est initialement de les rendre de plus en plus intelligents au fur et à mesure de la progression du joueur dans le donjon. La mémoire limitée du VAX-11 ne leur permet cependant pas d’intégrer cette fonctionnalité, et ils se contentent finalement de rendre les monstres de plus en plus forts$^,$.
Après avoir terminé une première version du jeu, ils le testent avec d’autres étudiants de l’université qui les aident notamment à améliorer leur système de génération aléatoire des niveaux pour rendre la difficulté du jeu plus progressive$^,$. Le principal élément qui ressort de cette phase de test est cependant le concept de mort permanente. Après avoir ajouté la possibilité de sauvegarder une partie, ils se rendent en effet compte que les joueurs tendent à recharger régulièrement une sauvegarde afin de tirer le meilleur parti d’une situation, ce qui va à l’encontre de leur concept initial. Pour donner plus de poids aux décisions du joueur et ainsi offrir une expérience plus immersive, ils décident donc de rendre la mort du personnage véritablement permanente en supprimant les fichiers de sauvegarde lors du chargement d’une partie$^,$. Ils ajoutent également un tableau de score qui permet au joueur de comparer ses performances d’une partie à l’autre.
En 1982, l’attention que porte Michael Toy à Rogue se fait au détriment de ses résultats scolaires et il est renvoyé de l’université. Il est alors recruté par le laboratoire d’informatique de l’université de Californie à Berkeley, et il emporte le code source du jeu afin d’en poursuivre le développement. Glenn Wichman poursuit de son côté ses études à l’université de Californie à Santa Cruz. Il continue pendant un temps à participer au développement du jeu, mais l’éloignement rend le processus difficile et il finit par laisser l’entière responsabilité du projet à Michael Toy$^,$. Lorsque ce dernier arrive à Berkeley, il entre en contact avec Ken Arnold, le créateur de la bibliothèque logicielle curses, afin d’avoir des précisions sur son fonctionnement. Celui-ci connait déjà Rogue et, bien qu’impressionné par le jeu, il déplore le manque d’optimisation de son interface graphique qui utilise la bibliothèque logicielle qu’il a créée. Après avoir fait sa connaissance, Michael Toy lui donne accès au code source du jeu et il participe alors à l’amélioration de son interface graphique et de son système de génération procédurale des niveaux. La popularité du jeu sur les serveurs de l’université de Berkeley conduit à son intégration à la distribution BSD 4.2 en 1983. Le programme se propage ainsi par l’intermédiaire du réseau ARPANET et il devient rapidement populaire dans les universités et les entreprises qui utilisent BSD. Parmi ses fans, se trouvent notamment Ken Thompson et Dennis Ritchie, qui le décrit en plaisantant comme « le plus grand gaspillage de cycles de processeur de l’histoire ». La distribution BSD 4.2 n’intègre pas le code source du jeu, car ses créateurs envisagent à l’époque de le commercialiser. Ainsi, lorsque Michael Toy et Ken Arnold quittent l’université, ils emportent avec eux le code du jeu, ce qui rend difficile la reprise de son développement. Son code source est finalement intégré à BSD 4.3 en 1986.

## Adaptation et commercialisation

Michael Toy quitte l’université de Californie à Berkeley peu avant 1984 et devient consultant pour la société italienne Olivetti, qui développe à l’époque sa propre gamme d’ordinateurs. Il rencontre Jon Lane, un des administrateurs système de la société, qui connait Rogue et sa popularité aux États-Unis. Celui-ci lui propose de porter le jeu sur PC afin de le commercialiser, et ils fondent ensemble la société A.I. Design pour concrétiser leur projet. Bien qu’ils disposent du code source du jeu pour réaliser cette adaptation, Jon Lane doit reprogrammer de nombreuses routines afin notamment d’adapter son interface graphique. Il profite de la page de code 437 du PC, qui lui permet d’utiliser une plus grande variété de caractères que l’ASCII. Ils modifient également les éléments du jeu directement issus de Donjons et Dragons, comme le nom de certains monstres, afin d’éviter tout risque de procès pour copyright avec l’éditeur TSR$^,$. Ils financent initialement sur fonds propres la publication, la distribution et la promotion de la version PC du jeu mais, malgré des ventes correctes, ils ne parviennent pas à dégager des bénéfices.
En 1984, Rogue devient populaire auprès des employés d’Epyx qui suggèrent à leur direction de l’éditer. Bien qu’il considère que le jeu correspond à un marché de niche, Robert Borch, le vice-président d’Epyx, signe un contrat avec A.I. Design pour porter le jeu sur Apple Macintosh puis sur Amiga. Michael Toy se procure donc un Macintosh et prend en main l’adaptation du jeu sur cette plate-forme. Conscient du potentiel de cette dernière, il prévoit d’améliorer les graphismes de cette nouvelle version, mais ni lui ni Jon Lane n’a les compétences nécessaires pour réaliser de nouveaux visuels. Il contacte donc Glenn Wichman pour l’aider sur cet aspect. Ce dernier est initialement réticent, car il considère que les crédits de la version PC minimisent son implication dans le développement du jeu. Il finit néanmoins par accepter et par rejoindre A.I. Design pour participer au projet. Lorsque cette première adaptation est terminée, Epyx demande à Glenn Wichman de mener le développement d’une version Atari ST pendant que Michael Toy s’occupe de la version Amiga. Afin de créer les graphismes de l’adaptation sur Atari ST, il fait appel à Michael Kosaka qui travaillait jusque-là pour Epyx. Epyx finance ensuite A.I. Design pour adapter le jeu sur d’autres plates-formes dont le TRS-80 Color Computer.

## Système expert

Puisque les entrées et les sorties du jeu original utilisent une interface texte en ASCII, il est relativement facile de les rediriger vers un autre programme. En 1983, le logiciel "Rog-O-Matic" a été développé à l'université Carnegie-Mellon dans le but de jouer et gagner au jeu de Rogue$^,$$^,$. Considéré comme un "système expert militaire", "Rog-O-Matic" a été testé contre des joueurs champions du jeu et a souvent gagné. Ce programme est encore d'un grand intérêt dans le domaine de l'enseignement.
En 2005, un article de presse précisait :
   « Rog-O-Matic est différent des systèmes experts traditionnels car il a la capacité de travailler dans un environnement dynamique, par exemple avec un terrain et des adversaires générés aléatoirement. De plus, ce système a été créé pour fonctionner avec des entrées d'information réduites, en enregistrant les données et en développant ses connaissances au fur et à mesure qu'il les découvre »
— G. Henderson, E. Bacic, M. Froh, (en)"Dynamic Asset Protection & Risk Management Abstraction Study", Defence Research and Development Canada. novembre 2005
Un des auteurs de Rog-O-Matic, Michael Loren Mauldin, a ensuite travaillé sur le moteur de recherche de Lycos.

## Postérité

La popularité de Rogue conduit d’autres développeurs à créer leur propre version du jeu. Leurs efforts sont cependant initialement limités par l’absence d’accès à son code source, qui n’est pas diffusé avant son intégration à la Berkeley Software Distribution en 1986. Ces développeurs doivent donc se résoudre à repartir de zéro pour créer des jeux similaires à Rogue, auxquels ils ajoutent de nouvelles fonctionnalités. Ces derniers sont distribués avec leur code source, ce qui permet à d’autres développeurs d’en programmer des forks en y ajoutant de nouveaux éléments et fonctionnalités, ce qui conduit à la création de plusieurs douzaines de versions du jeu. Ce processus est facilité par le basculement sur des langages de programmations plus adaptés, dont des langages de script ou orientés objet, ainsi que par le nettoyage et la modularisation du code afin de faciliter le suivi et la réalisation de modifications. S’il existe des variantes uniquement basées sur Rogue, la plupart d’entre elles peuvent être classées dans deux branches distinctes issues de deux jeux clés du genre : Hack (1982) et Moria (1983).
Hack est développé par Jay Fenlason, Kenny Woodland, Mike Thome et Jonathan Payne alors qu’ils sont au lycée et avec l’idée de doter Rogue de nouvelles fonctionnalités dont la possibilité de sauvegarder l’architecture d’un niveau après que le joueur l’a quitté. Pour mener à bien leur projet, ils entrent en contact avec les créateurs de Rogue afin de récupérer son code source, mais ils essuient un refus qui les oblige à partir de zéro pour développer leur jeu. Jay Fenlason abandonne le projet après avoir quitté le lycée mais il partage le code source du jeu lors d’une conférence USENIX. Son développement est ainsi repris par d’autres programmeurs et il fait l’objet de nombreuses variantes dont notamment NetHack (1987)$^,$.
Moria est développé par Robert Alan Koeneke alors qu’il étudie à l’université d'Oklahoma avec l’idée de transposer Rogue dans l’univers du Seigneur des anneaux. Comme dans son prédécesseur, les niveaux du jeu sont générés aléatoirement, mais il se distingue de son modèle par l’implémentation d’un niveau prédéfini représentant une cité dans laquelle le joueur peut acheter et vendre des équipements. Comme Hack, le jeu fait l’objet de nombreuses variantes dont la plus connue est sans doute Angband (1990).