Bug et propositions d’améliorations pour l’outil All-Seeing Eye

Coucou. Voici un deuxième article dans le même mois !

Comme promis, j’ai envoyé 20 euros à All-Seeing Eye, pour remercier Joonas Hirvonen d’avoir créé cet outil permettant de modifier le jeu Eye Of The Beholder. Je m’en suis servi pour créer un challenge de Hacking pour la THCON. Tout est expliqué dans ce précédent article.

Ce fameux Joonas Hirvonen m’a remercié par mail et m’a encouragé à transmettre mes signalements de bugs. Je vais lui envoyer un document récapitulant tout ça, j’en profite pour le copier-coller ici. Ça ne vous intéresse peut-être pas, mais moi ça me fait un article à peu de frais. (Quelle blague ! Tous mes articles sont à peu de frais !)

C’est en anglais, vive le rosbif !

These bugs and improvement proposals are sorted from most important to less important.

Technical context :

Do what you want with these bugs, as I am not sure I will have the occasion to re-use ASE.

Modifying scripts provokes graphical bugs

Many wall images are scrambled when the game scripts are modified.

Here are steps to reproduce the bug.

  1. Start a game, create a party, go to the first drainage grate.
  2. Everything looks OK.
  1. Launch ASE.exe and set the folder
  2. Launch EOB1_Explorer.exe
  3. Add an instruction anywhere in the code, for example : F8 "I add a new message here." 00 02 00
  4. Press Ctrl-F9 to compile.
  5. You get a message box telling « Range check error. »
  1. Click the button « update INF ».
  2. Close and restart EOB1_Explorer.exe
  3. Add another instruction anywhere in the code.
  4. Press Ctrl-F9 to compile.
  5. This time you don’t get the error message.
  6. Click once again the button « update INF ».
  7. Start another game, re-create a party, go to the first drainage grate.
  8. This time the image is buggy. I do not know from where it was taken. It looks like a part of an attacking leech.

Other bugs appear on many wall textures. Once it happened, there is no hope to come back to a correct display.

I guess it’s a problem with memory offsets in the game information. It is quite annoying, it cancels all the involvement I would put in the creation of a totally new Eye Of The Beholder game.

Object sub-position cannot be redefined

Information related to objects can be modified in the tab « F4:Items ». But their sub-positions cannot be modified.

As we all know, an object on a square in the map has 5 possible sub-positions : the four corners on the ground, and the alcove carved on a wall.

The function ADD_ITEM shows it. It has 3 parameters : OBJECT_INDEX, POS_X_Y, SUB_POS.

The initial data contained in the .PAK files undoubtedly contains these supositions. When I modify existing object coordinates, they land on different sub-positions, depending on their index.

If the initial sub-position of the object is in an alcove, and if the object coordinates is on a square that has no wall, we have flying objects !

These flying objects can not be taken. Too bad.

I would say the tab « F4:Items » should have a field « sub-position », that allows us to read and write sub-position of each object.

A weird thing in the game engine : there is only one sub-position to define an object in an alcove, not one per wall side.

If you put a square with an alcove wall on each side, and if you put an object sub-positioned in the alcove on this square, then the object is visible from the four sides ! Logically, when you take it, it goes away from the four sides. In my opinion, this weird behaviour should be documented somewhere.

Encounter scripts should be editable, if possible

I do not know if it is possible at all. Some encounters seem to execute the same kind of instructions as the ones in the script :

  • speaking with Armun puts some objects in front of the party and sets a global flag,
  • there are movements automatically done before and after speaking with the dwarven cleric, and the previous global flag is checked to initiate the conversation,
  • speaking with Shindia spawns the monster « Shindia »,

I guess the dialogue texts, reply choices, player characters joining the party, etc. are all stored somewhere in the game files. If we could modify all this, it would be really cool, and we could make a totally-totally new Eye Of The Beholder game.

Some event parameters are not parsed in the script

Here is the code we usually have with stairs and ladders :

IF         TRIGGER_FLAG = 1 (on_enter)
ELSE_GOTO  $0473


IF         3 = 0
TELEPORT   TYPE = $E8 (party), SOURCE = <00,00>, DEST = <18,24>

IF         3 = 1
ELSE_GOTO  $0459
TELEPORT   TYPE = $E8 (party), SOURCE = <00,00>, DEST = <17,23>

IF         3 = 2
ELSE_GOTO  $0466
TELEPORT   TYPE = $E8 (party), SOURCE = <00,00>, DEST = <18,22>

IF         3 = 3
ELSE_GOTO  $0473
TELEPORT   TYPE = $E8 (party), SOURCE = <00,00>, DEST = <19,23>

IF         TRIGGER_FLAG = 4 (on_put_item)

IF         3 = 0
ELSE_GOTO  $0487
TELEPORT   TYPE = $F5 (item), SOURCE = <18,23>, DEST = <18,24>

IF         3 = 1
ELSE_GOTO  $0494
TELEPORT   TYPE = $F5 (item), SOURCE = <18,23>, DEST = <17,23>

IF         3 = 2
TELEPORT   TYPE = $F5 (item), SOURCE = <18,23>, DEST = <18,22>

IF         3 = 3
TELEPORT   TYPE = $F5 (item), SOURCE = <18,23>, DEST = <19,23>


The translated script shows comparrison between litteral numbers : « 3 = 0 », « 3 = 3 », … which looks really dumb.

This is of course not what the script does. These values corresponds to the direction from where the party comes, or the direction from where the object was thrown. It is used to reposition the party or the object from where it comes, because nothing is supposed to stay at the same square of a stair or ladder.

Some specific words should be used in the translated script to describe this process. For example, 3 = 0 should be replaced by FROM_DIRECTION = NORTH.

The direction identifiers are the usual ones : 0 = north, 1 = west, 2 = south, 3 = east.

Labels should be shown in the « Events » tab

The « F2:Events » tab shows the translated scripts, but the GOTO instructions have the litteral adresses.

The « F3:Scripts » tab shows GOTO instructions with labels, but the script is displayed with raw bytecode.

The text labels should also be displayed in the « F2:Events » tab, to have all the human-readable script in one tab.

It is quite painful to modify the scripts, I was always switching between the two tabs : write some code, check it is correct, and so on. A really nice feature would be a mode to display the two tabs side by side. The « F2:Events » would automatically updates while we type in the « F3:Scripts » tab. But maybe that’s too much to ask.

Texture atlas needed

I had to try different wall numbers in the map, then play the game to see the corresponding images, then repeat for the next level palette, etc.

Some identifiers are the same in many palettes, for example : with « brick » and « blue », the value 51 corresponds to a wall with writings on it.

Other identifiers exist only in one palette, or are different between palettes, for example : all the stone portal images.

That would really be helpful to have the complete list of wall images, with their identifier, for all the palettes. You don’t even have to integrate it in the existing software. Just toss an external document with the images and their identifiers, that would be perfect.

Command parameters should be documented

The tab « F5:Commands » lists all the existing commands, which is great, but not enough.

The parameters of each command should also be documented. Some commands, such as TELEPORT or ADD_MONSTER, have numerous, varied and complex parameters.

The documentation you linked to https://moddingwiki.shikadi.net/ is interesting, but really hard to read and to understand. I’m not sure it explains all the commands of Eye Of The Beholder.

Program crashes when writing coordinates with one digit

This one is simple to reproduce :

  • Go to « F3:Script » tab, go to the « event trigger points » zone.
  • Modify a coordinate of any event, write it with only one digit. For example, replace « 03 » by « 3 ».
  • Press Ctrl-F9.
  • You get an error message : « Access violation ».

Code size limit should be checked

When the script of a level is too big, it can lead to unexpected behaviours.

The last address value in « F2:Events » should be checked. If it is greater than $1AF0, there are risks to have unexpected behaviours. I’m not sure of the exact limit, it may be a rounded value, like $1B00.

This should be checked by EOB1_Explorer.exe, and a warning message should be displayed when updating/saving the INF file.

The unexpected behaviour seems quite random, and occur when the party arrives in the level having the INF too big.

Sometimes, it’s an immediate crash with a totally unrelated message :

Some other times, it’s a crash with a message « Far heap corrupt! » when you click on the button « CAMP » :

Race and class values are not completely documented

The file EOB1_Explorer_Notes.txt has an uncomplete list of race indexes. Here is the complete one :

  • 00 = Human
  • 01 = Elf
  • 02 = Half-elf
  • 03 = Dwarf
  • 04 = Gnome
  • 05 = Halfling

The Class identifiers are not correct and does not correspond to the HAS_CLASS function.

There are only 4 « base class »,

  • 01 = Fighter
  • 02 = Mage
  • 04 = Cleric
  • 08 = Thief

HAS_CLASS adds all the classes of your characters, by using the boolean « OR », and returns true if there is at least one set bit in common with the parameter given to the function.

Multi-class activates the corresponding bits of all the base classes.

For example, let’s say the party has a Fighter/Mage and 3 clerics (that’s a weird party).

HAS_CLASS(2) will return True. It evaluates to :

  • has_class_param & (classes_chara_01 | classes_chara_02 | ... )
  • 2 & ((fighter | mage) | cleric | cleric | cleric)
  • 2 & (fighter | mage | cleric)
  • 2 & (1 | 2 | 4)
  • 2
  • True

It is not possible to check if there is a ranger in the party. This class only lights the « fighter » bit.

It is also not possible to check if there is a paladin. This class lights the « fighter » and the « cleric » bits.

The way how the function HAS_CLASS works should be documented.

That’s all

Thank you once again for having created these tools. They are wonderful, even with those tiny bugs.

I used EOB_Explorer1 to create a hacking challenge that involves the game and your tools. This challenge was part of the CTF at the Toulouse Hacking Convention 2022. The people who tried it said it was really interesting (a few of them managed to solve it, though). I will submit it to root-me.org in the upcoming months and I will let you know about it, if root-me accepts it.

For the moment, I have not planned to create other challenges or other games with Eye Of The Beholder, so there may have no specific reason to fix these bugs. Anyway, I’m really happy to have « revived » this game in a quite uncommon way. It was an important part of my childhood, I took many years to finish it.

See you next time !

Voilà, c’était tout ce que j’avais à dire. Je l’envoie à mon nouvel ami Joonas ce soir. S’il me répond des trucs intéressants, je vous en ferais part.

Bien entendu, j’ai plusieurs autres idées de challenge « TUR-ROX », avec d’autres jeux. J’essayerais d’en concrétiser une ou deux pour la prochaine THCON.

Cet article est un rapport de bug.

Rapport de bug -> bug -> ladybug -> l’héroïne de dessin animé -> vêtements aux motifs de cette héroïne -> femme ronde !

Enjoy :

Pour le mois prochain, je me permettrais d’être moins blogalement productif. Je vous rassemblerai un package de commentaires de jeux du Ludum Dare, et ça devrait suffire.

D’ailleurs, faut que je vous annonce mon classement. Eh bien on fera tout ça en même temps.

THCON + Ludum Dare, ça a été un beau bazar ces dernières semaines. Peut-être que maintenant je vais avoir du temps pour faire la road-map de Squarity ?

On ne sait pas…

TUR-ROX-👁 Post-creationem-challengem

Heeey !

J’ai terminé la réalisation de mon challenge de hacking pour la THCON. Je l’ai soumis aux personnes qui organisent l’événement. Je ne sais pas encore s’il sera accepté. Dans tous les cas, je ne peux rien vous révéler avant la fin du Capture The Flag, qui aura lieu entre le 16 et le 17 avril.

Cependant, ça me démange de ne pas pouvoir vous parler de mon œuvre, alors je vais vous révéler son contexte et tout ce qui m’est passé dans la tête durant sa création. Ça ne devrait rien spoiler, je ne décris pas les énigmes en elle-même.

Le contexte

J’en ai déjà parlé un peu à la fin de cet article.

Il s’agit du jeu vidéo Eye Of The Beholder, dont j’ai modifié les plans des niveaux et les événements à l’aide de l’outil All-Seeing Eye et de son éditeur.

Pour résoudre le challenge, il faut jouer à la version modifiée tout en inspectant son contenu avec All-Seeing Eye. Il faut analyser les scripts et en déduire les actions à faire dans le jeu, pour obtenir le code secret permettant de valider le challenge. Je ne vous en dis pas plus.

Ce challenge, ainsi que les deux autres créés pour la précédente THCON, s’inscrivent dans un objectif plus global : l’instauration d’une nouvelle catégorie de challenge de hacking, que j’ai sybillinement baptisé « TUR-ROX ». Ça signifie « TURing-appROXi-complete video games ». C’est même pas un vrai sigle, c’est pas du tout les initiales des mots, mais j’m’en fous total, j’suis un ouf’ rebelle malade.

Principe des challenges de type TUR-ROX

Le principe consiste à trouver un jeu vidéo comportant un système de script intégré, à le modifier dans le but d’y implémenter un algorithme plus ou moins simple, et à faire en sorte que le flag ne puisse être découvert que lorsque cet algorithme est compris.

L’inspection et la modification du jeu peuvent être effectuées par un outil « officiel » (comme l’éditeur de ZZT), ou bien par un outil ne provenant pas des personnes ayant créé le jeu (comme All-Seeing Eye). Le système de script peut être plus ou moins élaboré. Au minimum, il doit pouvoir accéder à certains éléments du jeu. S’il comporte quelques structures algorithmiques de base, (if, while, …), c’est déjà bien.

En général, on fournira cet outil avec le challenge, afin de donner tous les moyens nécessaires à sa résolution. Mais on pourrait faire exception à cette règle.

Beaucoup de jeux actuels sont fortement moddables et scriptables. Les gens qui les développent ont réfléchi deux secondes et se sont dit qu’il serait bon de profiter des expériences du passé. Les scripts s’appuient maintenant sur des langages de programmations standards, multi-usages et documentés. Par exemple : Roblox utilise le Lua, Twine utilise du JavaScript, les gros moteurs de jeux comme Unity autorisent plusieurs langages (python, C#, …).

C’est la meilleure démarche possible, ça facilite les liens entre les personnes qui veulent créer des jeux vidéos et qui ne savent pas (encore) coder, et les personnes qui codent sans créer de jeux.

Mais ce n’est pas avec ça que je peux faire des chouettes challenges TUR-ROX. Du code à rétro-ingénierer dans un langage connu, c’est trop facile. Un foisonnement de documentation, d’outils d’analyse et de debugging sont à portée de clavier. Une solution serait de faire exprès d’écrire du code le plus incompréhensible possible, mais serait alors un challenge de type obfuscation, et non plus un TUR-ROX. Il existe déjà une foule de gens capable de créer des challenges d’obfuscation, et ce mieux que moi.

Un TUR-ROX est un mix entre un jeu vidéo et du code source à décortiquer, le système de script doit donc être spécifique au jeu. En revanche, il peut être obscur et mal documenté, ça fait partie du challenge de le comprendre avec les moyens disponibles. C’est pour ça que je préfère utiliser des jeux anciens ou exotiques. On est obligé de se plonger dans leur histoire, de retrouver comment pensaient les concepteurtrices de jeux à une époque où il y avait moins de standards.

Et cette année, j’ai choisi Eye Of The Beholder. Mais pourquoi donc ?

Attention : Turok ≠ TUR-ROX

Eye Of The Beholder, parce que nostalgie

Ce n’est pas la première fois que j’écris un article sur ce jeu. Il a marqué mon enfance. Je l’ai commencé alors que j’étais en sixième, en explorant un peu au hasard. Une solution a été publiée dans un magazine Tilt, j’ai demandé à mon frère de la photocopier. On a commencé à s’en servir avec mon autre frère, on est allé jusqu’au niveau 7. Ensuite, notre intérêt pour le jeu a diminué. De plus, ce niveau est graphiquement plus inquiétant que les précédents (très sombre, des symboles d’araignés omniprésents), et il commence par un difficile combat contre un groupe d’elfes noirs. J’ai douté de mes capacités à en venir à bout, j’ai laissé tomber.

Moustache ! moustache !

Je me suis fait engueuler par mon frère, qui m’a reproché que les photocopies avaient été faites pour rien puisque je n’étais même pas foutu de les utiliser entièrement.

Quelques années plus tard, j’ai recommencé le jeu seul. J’ai pris le temps d’élaborer une équipe bien équilibrée, couvrant le plus de classes possibles. J’ai tué tous ces tocards d’elfes noirs et je suis arrivé au niveau 10. Il comporte un générateur de Mantis Warrior. J’avais réussi à faire abstraction du générateur d’araignée géante présent au niveau 4, mais celui des Mantis m’a psychologiquement bloqué.

Ce que j’aime dans ce jeu, c’est le sentiment de « nettoyer » les souterrains. On explore partout, on tue tous les monstres qu’on rencontre et on prend tous les objets. À chaque fois qu’on finit un niveau, on peut se dire : « Voilà, il n’y a plus aucun danger. Je pourrais revenir me promener dans ce niveau sans aucune crainte ». Concrètement, on n’a pas besoin d’y revenir, mais j’aimais éprouver cette sécurité et cette impression de rendre le monde meilleur. Or, les générateurs de monstres enlèvent complètement ce sentiment.

Encore une ou deux années plus tard, je me dis que c’est quand même dommage d’être allé aussi loin dans le jeu sans le finir. Je détruis 4 Mantis Warrior à la suite dans le niveau 10. Je parviens à me faire une raison : les prochains seront générés dans longtemps, je peux toujours éprouver un sentiment de nettoyage même provisoire, et si il faut vraiment sécuriser entièrement les souterrains, eh bien les notables de la ville de WaterDeep n’auront qu’à envoyer des magiciens destructeurs de générateurs de monstres !

J’écume les derniers niveaux, je bute Xanathar à la bourrin (je possédais le « Wand of Silvias », mais je n’avais pas compris qu’on pouvait s’en servir pour le faire reculer jusque dans des pics où il se plante stupidement). Mon frère revient à la maison pour des vacances. Je lui annonce que j’ai terminé le jeu. Il est heureux pour moi, mais ne s’excuse pas de m’avoir engueulé des années auparavant. Il ne se souvenait certainement pas de ce passage de sa vie.

Maintenant que j’y pense, ce même frère m’avait soutenu lorsque je suis allé rapporter à la FNAC un jeu qui ne marchait pas. On a pu obtenir un avoir, ce qui n’était pas gagné d’avance, et je crois que je ne l’ai jamais remercié pour ça.

D’autres années plus tard, je commence un tout petit peu Eye Of The Beholder 2, mais je ne prends pas le temps de me lancer vraiment dedans. J’essayerais peut-être de le faire un jour, en live sur Twitch, avec vous.

Pour finir, j’ai négationné mes deux frères et je me sens mieux. Je ne détaille pas plus, je ne veux pas vous embêter avec des histoires idiotes.

Aujourd’hui, j’ai retrouvé la solution, sans faire de photocopies. Merci au site abandonware-magazine !

Eye Of The Beholder, parce que script

Je me souvenais d’énigmes et d’événements tellement étranges que ça laissait supposer la présence d’un système de script relativement générique. Quelques exemples :

  • Vous avancez dans un couloir et automatiquement vous faites un demi-tour, sans être prévenu.
  • Vous posez certains objets à certains endroits, ça déclenche l’apparition d’un monstre et/ou d’autres objets.
  • Vous entrez dans une pièce, vous ramassez une potion, vous sortez, vous re-rentrez par une autre entrée, une deuxième potion est apparue, vous la ramassez, ainsi de suite jusqu’à 4 potions.
  • Des rencontres avec des PNJ déclenchant des dialogues, des ajouts de nouveaux personnages, des attaques, etc.
  • Des téléporteurs, des murs qui disparaissent quand on appuie sur un bouton, des plaques de pression qui déclenchent des ouvertures/fermetures de portes, etc etc.

J’ai cherché un éditeur de niveau et je suis très vite tombé sur « All-Seeing Eye », créé par Joonas Hirvonen (je sais pas qui c’est). Il permet de modifier beaucoup de choses, y compris les scripts.

Au bout de quelques soirées et quelques week-ends, j’avais assez bien appréhendé le « EOB-script » (appelons-le comme ça) et j’avais une idée assez précise des énigmes que je pouvais créer.

J’ai été impressionné. Ça date de 1991 et c’est une machine virtuelle fonctionnant avec du bytecode. Son langage, comme dirait les Inconnus, est « souple et solide à la fois ».

Voici les fonctionnalités de l’EOB-script qui m’ont beaucoup plues.

  • 32 variables booléennes locales à chaque niveau + 32 variables booléennes globales.
  • Opérations booléennes complexes à l’aide de la notation postfixe .
  • Beaucoup de fonctions pour analyser l’état du jeu : présence de monstre à un endroit, type de mur d’une case spécifique, présence d’un type d’objet sur une case, position de l’équipe de personnages, classe et race des personnages, …
  • Et aussi beaucoup de fonctions pour agir sur le jeu : créer/supprimer des objets/murs/monstres, lancer un sort, émettre un son, infliger des dégâts, …
  • Branchement conditionnel (if – goto), mais aussi sous-fonctions grâce aux instructions gosub et return, dont j’ai grandement profité !
  • Gestion d’événements couvrant un large spectre : on peut exécuter un script sur une récupération ou un dépôt d’objet, une arrivée ou une sortie sur une case, un clic dans la zone réactive d’un mur (manette, serrure, rune, …).
  • Cohérence dans la gestion d’événements : une téléportation déclenchera le « on_enter » de la case d’arrivée, un lancer d’objet déclenchera le « on_put_item » de la case sur laquelle l’objet atterrit.
  • Robustesse : sur un seul événement, il est possible de déplacer des dizaines d’objets, modifier des dizaines de murs, exécuter des dizaines d’instructions, écrire des dizaines de messages (même si seuls les trois derniers sont visibles), tout ça sans problème, sans plantage, sans ralentissement.

En revanche, All-Seeing Eye n’est pas toujours à la hauteur de la magnificence de l’EOB-script. En particulier, on ne peut pas changer les dialogues et les événements des rencontres avec les PNJ. Je ne sais pas si c’est dû à un simple manque de motivation ou à une impossibilité technique. Je ne sais pas si ces événements sont écrits en EOB-script ou codés en dur. Je ne sais pas non plus où ils sont stockées, (pas forcément dans les fichiers EOBDATA.PAK).

J’ai beaucoup de remarques et de propositions d’améliorations, ce qui nous amène au chapitre suivant.

Ils sont meugnons !

Review de All-Seeing Eye (Pour plus tard)

Je vais faire un petit don de 20 euros sur le Paypal de Zorbus.net. C’est amplement mérité. S’ils n’avaient pas créé All-Seeing Eye, je n’aurais jamais pu créer ce challenge de hacking dont je suis assez fier.

Comme j’ai bien utilisé et exploré leur outil pendant plusieurs semaines, et que j’ai un peu galéré à cause de certains bugs, j’ai souhaité rassembler mes remarques dans un même document, que je leur transmettrais.

Et comme j’aime bien rentabiliser les textes que j’écris, je mettrais ces remarques aussi dans ce blog. Mais pas tout de suite, ce sera l’objet du prochain-prochain article. Il sera en anglais, mais vous vous débrouillerez bien.

Je vous laisse avec des yeux tatoués sur des seins. Je trouve ça très rigolo.