The wonder stuff
How remastering Wonder Boy III gave Omar Cornut new admiration for the 8bit era
How one man’s love of the 8bit era saw Wonder Boy III remade
“We’ve probably made 1,000 changes, but I wanted to make them knowingly, never accidentally”
The Sega Master System’s equivalent of Zelda and Super Metroid was 1989’s Wonder Boy III: The Dragon’s Trap. Deep, complex and full of mystery, this RPG-inflected platformer was on every owner’s radar – including that of Parisbased Omar Cornut, who went on to work as a programmer at UK studio Media Molecule on Tearaway and Dreams, at Q-Games on the PixelJunk series, and co-created the rather special Soul Bubbles on DS. In his spare time he’s cultivated a growing obsession for the Master System into running SMS Power, one of its principal fan websites, and has now established a new studio, Lizardcube, to remake its killer app with a beautiful new graphical style – albeit one that can be restored to its1989 state at the touch of a single button. Why did you choose to remake Wonder Boy III? It was the overlap of me loving this game, thinking there would be some people who would like it, and me being interested in 8bit history, preservation and emulation. I wrote a Master System emulator almost 20 years ago and I’ve been writing the definitive website for Sega Master System stuff. So it’s a longrunning obsession. When I left Media Molecule I wanted to start my own company, and I realised designing your own game is super tough. I won’t say it was a cop-out, but I wanted to make an easy game in terms of design, so I thought a remake would be a good way to achieve that, a pragmatic way of learning the ropes of making a business. But in the end, it was twice the amount of work that we expected in the beginning. Was reverse-engineering the cartridge part of why it’s taken so much work? When I started I only had the ROM image of the game, so I started reverse engineering the data and its structure. I wanted to find out if there were any secrets left in the game that I didn’t know about. It’s a game known for having many subtle secrets, like a specific enemy that sometimes drops something different; there are lots of weird rules and it feels very mysterious. Eventually I got far enough that I could display levels with my tools and my plan evolved from reverse engineering to intending to port every bit of the game. But halfway through it became very painful because it was very error-prone, so now it’s like I’m emulating the base layer but I have freedom over it so I can do what I want without having to bother about the limitations of the Master System. It’s this Frankenstein’s monster: it’s emulated, but it’s not. The original Master System game is 30Hz, so I had to patch all the hundreds of bits of code that use physics and count the time. I also have to make monsters and objects alive outside of the original 4:3 area. I don’t think it’s been done to this level. There’s a company called M2 in Japan, which is behind the Sega 3D Classics series, and they’re doing something of this kind, where they’re starting with a game and hacking it, but they change very little. How are you deciding what you can change from the original game? There’s no clear rule, but we don’t want to mess up the game too much while we’re improving it in many ways. We’ve probably made 1,000 changes; some are big, some are small and subtle, but I wanted to make them knowingly, never accidentally. When we add new animations we have to alter the timing, the collision boxes. We’re adding some bonuses, tweaking a lot of things, adding secrets. It’s 80 per cent the same game. How simple was it to make the Retro mode, in which you can instantly flip the graphics to the original 8bit pixels? It comes from the fact the game we’re making is very close to the original, except we’re using a lot of visual tricks to hide that it’s tile-based. When the game was originally emulated, the 8bit version was running by default and you could visually render the two versions, but the 8bit version had a lot of bugs because it wasn’t designed for widescreen. As I added new data and graphics the HD version steadily diverged. But because the same fundamental game is running, it’s all just visuals. Were you surprised by any of the programming techniques that made the original game work? It was a way for me to understand how games used to be made. It was driven by the programming constraints of the time, the CPU and the RAM. For example, we’re making a hard mode and as we added enemies and tweaked layouts we realised how as soon as you move something by five pixels, you realise it can’t work because the way it was coded wouldn’t allow for it; this monster only works when the ground is flat because they couldn’t code in collision for specific objects, things like that. Optimisation tricks like that are interesting, and through them you understand the differences between old games and new ones.