Developer Used Fake Secrets To Sneak Games Through Sega’s Certification Process

Developer Used Fake Secrets To Sneak Games Through Sega’s Certification Process
To sign up for our daily newsletter covering the latest news, features and reviews, head HERE. For a running feed of all our stories, follow us on Twitter HERE. Or you can bookmark the Kotaku Australia homepage to visit whenever you need a news fix.

Getting a game through a publisher’s certification process can be difficult. Games are tested in extreme conditions and fail for the slightest error. In the ’90s, one developer snuck their games through Sega’s certification with a few clever tricks that disguised glitches as part of the game.

Traveller’s Tale founder Jon Burton describes his secrets in a new video (h/t Polygon) that explains the various ways he disguised glitches as random secrets. Sega’s certification process was notoriously stringent, failing developers if their games crashed for any reason. To get through this, Burton had glitches and crashes lead testers to fake bonus levels and select screens.

The process was devious but easy. Instead of having the game present specific error messages when it crashed, he would program his games to perform a certain task instead. In 1994’s Mickey Mania, instead of showing an error message, Burton programmed the game to throw testers to random levels while claiming they encountered a hidden “time warp”. He repeated the process the following year for the Genesis’ version of Toy Story. This time, errors sent testers to bonus levels.

Burton’s most drastic fix was on 1996’s Sonic 3D Blast. In order to disguise crashes as legitimate gameplay features, he made it so any error would redirect to a level select screen and congratulate players on finding the secret. This was never removed after testing, which means it’s possible to access the game’s level select simply by hitting the cart or system hard enough. When the cart disconnects from the machine, it triggers the level select.

All of these tricks are smart and fun ways of sliding through a process that was incredibly punishing. Plus, now we know that you can select any level in Sonic 3D Blast if you smack your console like the Fonz.


    • You need to know the location and cause of the crash to fix it. This is a catch-all, “if any crash for any reason is detected, play this level”.

      • I’m aware of how to fix crashes. What he’s done here is basically a custom assert message but instead of triggering an assert it’s playing a different level. I still think fixing the crashes would have been a better idea though.

        • Fix what crash? This is a catch-all, not a replacement for a fix; it’s there to provide intelligent behaviour in case of unknown crashes in the wild.

        • The issue was that finding those crashes is hard, and you might not discover some of them until you see them on the failed cert report.
          If that happens you have to try to reproduce the issue, hope you fix it, and wait a few more weeks for certification. It’s not like they could day 0 patch it back then.

          I’m sure they fixed every crash they knew about, this was just a backup to handle the ones they didn’t know about.

        • You might be aware of how to fix crashes, but you sound quite naive about the difficulties faced in getting 100% perfect code (first time) out into commercial environment.

          • Not really naive, I’ve been developing games for almost 15 years.

            100% perfect code is not possible. It can’t be done. No game has ever shipped bug free. However, fixing blockers like crashes can be done.

          • I’m not sure they WERENT hunting out the bugs and fixing them, just sticking in a Just In Case solution for any they miss. To use VBA as an example, I’m seeing this more as an On Error Resume Next type command, or If Err Then Call… setup.

            You’re right, they should be hunting out the bugs and fixing them, but as you say yourself, you aren’t going to get 100% of them, which means potentially a lot of fart arsing about thanks to Sega demanding that 100%.

            For example, that whacking the cartridge to force a “disconnect” (for want of a better word) isn’t something you can program for but Sega would demand it be solved before certifying.

          • Sorry man, I have to agree with Ewlkda, it’s naive to think you can fix the circumstance to every possible crash before release on a game with any mentionable complexity. There are always exceptional circumstances that didn’t occur to you during development.

            Could you share some links to your games? I wouldn’t mind testing how crashproof they are myself.

Show more comments

Comments are closed.

Log in to comment on this story!