Autor: Martin Haring

The game.lua script consists of three parts – player, graphic and input data. Input data depends on the console, and needs no major changes in this project. Graphic data depends on the sprite list, which has already been dealt with separatly. Player data is the main focus of this and the next blog – changing this part will require knowledge about the game as well as some hacking. Knowledge in this case means things to look out for when playing – which should always be displayed on the user interface.

In this blog, I will go over the essential elements of the UI of Super Metroid.

The game.lua script serves the purpose of keeping track of every piece of data in the game that the player can directly affect or interact with. Metaphorically, it can be seen as the screen that the AI looks into as well as the controller that the AI is holding. The next step of this project is to adapt this script from Super Mario World logic to Super Metroid logic – which takes more effort than it seems at first sight.

In this blog, I will explain go over the essentials of the game script (by example of MarI/O).

Having found the right tool that opens the door project, it is now time to go through it. Metaphors aside, writing the sprite list is still a difficult process, since the tool alone is not enough. The tool might provide most of the hex codes, however, there is no way to identify what the sprite does. There are five different kinds of sprites; and they must be differentiated properly.

In this blog, I will briefly describe my process of mapping sprites to hex codes.

Last week I tried to figure out a way to determine the hex codes of sprites by looking at Super Mario World – by searching through the key sprite, which was metaphorically supposed to open the door to the project. However, I forgot that, in Metroid, one does not need a key to open doors – one needs just the right tool.

In this blog, I cover hacking tools specifically made for Super Metroid.

Last week I found a tool that can be used to edit the graphics of SNES ROMs. However, it is still unclear how to get the exact hexadecimal address of each sprite. To find an answer, I try to reverse-engineer MarI/O and take a look on how the sprite addresses were determined there. More precisely, I will try to find the ‚Key‘ sprite, that has the position 0x80 in the pointer table. I am certain that this key will unlock the next door to the spritelist.

In this blog, I will explain the differences between HiROM and LoROM SNES cartridges and I will go over some more tools used for hacking ROMs, specifically Super Mario World.

For the spritelist script, which metaphorically represents the eyes of the AI, requires precise information about all sprites in the game. In the game’s files, a sprite is referenced by a so-called pointer. To make the spritelist I need the pointers of all important sprites – and to do so, I am using tools made and used by ROM hackers.

In this blog, I will go over all important information on pointers, graphics editing methods and its respective tools.

This project is inspired by MarI/O – which in essence boils down to five scripts and a pool of states. For the AI to work, it requires structure – which is why the code of MarI/O was split into five seperate scripts. First, I want to write the spritelist script, which represents the eyes of the AI. Instead of logic, the script contains lists of sprites, sorted by their effect and nature. However, to do so, a dive into a new whole world is necessary – the world of ROM hacking.

In this blog, I will go over the essentials of rom hacking, describe its methods and go over some tools.

This blog marks the beginning of the largest sub-project of my topic. Inspired by MarI/O, I aim to develop an AI that learns to play Super Metroid. To get it working, I will first try to stick to the same methodology as the one used for MarI/O and make changes to the scripts as the project develops.

In this blog, I will introduce the project, take a first look on the game and its mechanics and point out potential ’sticks and stones‘.

This blog serves as an overview about my project.

„A pole is attached by an un-actuated joint to a cart, which moves along a frictionless track. The system is controlled by applying a force of +1 or -1 to the cart. The pendulum starts upright, and the goal is to prevent it from falling over. A reward of +1 is provided for every timestep that the pole remains upright. The episode ends when the pole is more than 15 degrees from vertical, or the cart moves more than 2.4 units from the center.“ – Source: https://gym.openai.com/envs/CartPole-v0/

In this blog, I will  describe the most important parts of the code and show some test results.