On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
Screenshot of Segapede prototype (image from hiddenpalace.org)
In the 90s, there was effectively two Segas, Sega of Japan and Sega of America. Unlike with Nintendo though, where it’s fairly obvious that the Japanese division called the shots, Sega was a little more evenly split. Despite the company mostly being known nowadays for their Japanese productions, Sega was originally an American company, founded in Honolulu making entertainment devices for U.S. military bases. Indeed, SEGA originally stood for SErvice GAmes.
The Japanese branch began to pull out ahead when they started making home computers for that market, but by the time of the Mega Drive/Genesis there was Sega Technical Institute on the American side, which employed some talented developers, including Yuji Naka.
The story of STI is part of that of Segapede, a game created by Craig Stitt. Originally pitched as a Sonic spinoff, it would eventually be cancelled, but not before a demo ROM was created, which saw the light of day for the first time late last year. Not only available is the ROM image itself, but the story of its inspiration, development, and ultimate cancellation, all on its suitably-named home hiddenpalace.org.
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
Super Mario World is one of the most hacked games of all. There’s a whole website devoted to hacking it, SMWCentral. They do have Yoshi’s Island and Super Mario 64 hacks too, but SMW is the main attraction.
They’ve done a bunch of contests over the years, where different members compete in judged hacking competitions to make hacks to various criteria. In April they wrapped up their second “Questionable Level Design Contest,” QLDC. And the gimmick of the winner is… pretty special.
Please overlooked the glitchy title screen. In this one, the presentation isn’t the main attraction.
A long walkway to the right from the starting location.
What? Is this a troll hack? One that just makes you run everywhere and nothing ever really happens?
Hmm. This screen looks like it’s full of levels, but none of the circles or houses work. The object is to get to that red pipe.
You hold X or Y to run, or, as this screen mentions, don’t hold X or Y to not run. That Pirhana Plant is animated, and if you run into it while it’s in your way, you have to restart the screen. A fun gimmick, sure, but we’re just getting started.
In case you haven’t cottoned to the gimmick yet–there is no actual level. The whole game is played on a series of connected map screens. You’d think not a lot would be possible, but in this hack, Mario can actually “jump” on enemies if his feet touch them. On this screen, Bullet Bills enter from the right, and you have to use the curved paths, along with judicious running, to “stomp” them with the right timing. When you reach the OFF circles to the right you clear the green blocks, and then have to work your way back left to get to the pipe.
And on this screen, the Thwimps jump back and forth, and you have to avoid them as you pass around the screen. If you touch an enemy you don’t “die” so much as get sent back to the start.
Then you get to this screen, which is a remake of a portion of the first level, and you wonder how far they’re willing to go with this gimmick.
As it turns out, they’re (“they” being Faro and MM102) not even close to being done. This level introduces these Stars that, when you press A on them, cause Mario to do a spin jump. This jump, however, actually activates the standard SMW platforming engine. Mario can move around as if he were in a level. Here you have to use that jump to bounce off the Big Boo and land on the other Star, which puts you back into map travel mode and lets you go to the pipe. The following levels make extensive use of this feature, and there’s lots left to explore.
The creators made a playthrough video, embedded below (it’s about nine minutes), but they suggest that you try the hack yourself first. You can do what you want, but it’s a joy discovering how they unveil progressively crazier gimmicks as you go. Consider trying it our yourself first, if you have the mind and means.
From the article, a photo of the inside of an original Pac-Man game. The insides of most arcade games are usually a stark contrast to their externals, even upon release, but time is often unkind to them.
I’ve been working on diversifying our link game a bit, so here’s a more academic article, one with an actual bibliography no less, from the site romchip.org, by Kieran Nolan on restoring arcade machines. I’ll let the link speak for itself this time!
Wurm: Journey to the Center of the Earth is a Famicom/NES title with a lot of ambition, perhaps too much. Over on his self-named blog Kid Fenris posted a long article on it back in March. It makes it seem a lot more interesting than it otherwise would! We at Set Side B love experiments, successful or failed, and Wurm certainly was one, with shooter, side-scrolling platformer, first-person boss fights and even some visual novel elements. And protagonist lady named “Moby” is searching for her boyfriend named “Ziggy.”
Green-haired Moby wears the kind of outfit you could only find in something inspired by 80s anime.
The post mentions that designer Shouichi Yoshikawa, a.k.a. “Angela,” has an interview up at GDRI. It also mentions that Angela used to have a site devoted to their game, which while gone now has a backup on the Wayback Machine! Sadly the promised English version of the site never materialized.
Also–Kid Fenris mentions he once wrote about Wurm on GameSetWatch. My old stomping grounds!
There are a number of NES games that feel like they’re held together with paperclips and chewing gum. Some of them are almost endearing for their glitchiness. When it comes to janky NES games, a few that I tend to think of are those made by Micronics (who implemented Ghosts N’ Goblins, which has an awful frame rate) and Athena (where one boss has a death animation that causes it to flip through many of the sprites in the game).
A company that usually did a lot better with their internally-developed games was Capcom, makers of Mega Man, 1943, Bionic Commando, and all the Disney Afternoon games from the time, all of which have slick 60 fps update rates and smooth animation. One game they made of which that is definitely not true, however, is NES Strider.
If you’re only familiar with Strider from the beautiful arcade version, you might wonder what even NES Strider has to do with it. It’s not proper to say Famicom Strider, because Capcom never released it in their home territory, perhaps because they were too embarrassed to.
Other than the first stage being set in generally the same fictional location in Russia (even if it doesn’t look at all the same), its story has absolutely nothing to do with it. Jeremy Parish looked at it (and remarked on its glitchiness) in an episode of Metroidvania Works from a couple of weeks ago. Some people, like Kid Fenris of the self-titled blog, actually likes it, although acknowledges its many issues.
Behind the Code, one of the best game internals series on Youtube, had a look at the implementation of NES Strider. It’s an interesting 15 minutes to my taste, but if you want a tl;dr, NES Strider often doesn’t make its framerate target, and instead of slowing the game down as most games do, it plows ahead forward into the next frame, leaving the incomplete data in its update buffer to be copied into the PPU. This causes the individual hardware sprites that compose enemy characters to sometimes have only one of their coordinates updated, or even causing data remaining from previous frames to be copied over.
Why does it does this instead of just slowing the game down? Possibly the coding was so crappy that it would have caused excessive slowdown; the scene chosen as an example in the video has the problem occur when there’s only two basic enemies on the screen in the game’s first area! Not the best engine on the system there Capcom.
Here’s the kind of minor-yet-cool thing that I love to see, a crossstitch project based off of the first room of Zork, but with a little extra when viewed at night!
Dani Bunten’s classic economic simulation M.U.L.E. is one of the all-time greats, still fairly obscure even among people who know and talk about video and computer games, but hugely influential. Wikipedia tells us that Shigeru Miyamoto considers it an influence on the Pikmin games (although other than in theme I really don’t see it).
There are three current ways to play M.U.L.E. One is Planet M.U.L.E., an official port sponsored by Ozark Softscape, which is several years old, and I was certain I had posted here about before. It’s a proper update with new graphics and a lot of character. A thing about M.U.L.E. is that the original versions were intricately designed in a lot of ways, not just in game rules but the little details. The way the phase ending noise speeds up, the exact difficulty of catching a Wampus, the speeds with which players walk through terrain, the many details of auctions, even the time it takes to outfit a mule and leave/enter town, it’s all finely calculated. You can tell that Dani cared deeply about the game, and it’s a polished as any game I’ve ever seen, and that’s the old 8-bit computer versions. Planet M.U.L.E. isn’t as polished, but it’s still very nice, and you can tell its makers thought hard about it. It offers both local and online play.
Sadly, Planet M.U.L.E. seems to be on life support. While games can still be played, and the automated best player posts still go up on its blog, it’s not gotten an update in years, and it’s even possible they’ve lost the source code.
One legacy of Planet M.U.L.E. is a wonderful Youtube video they made that explains the game and how to play. It’s a great introduction:
M.U.L.E. Returns was a mobile port. It has a website, that’s still around, but apparently none of those versions are available. It’s got a page for a Steam version, but it’s not available despite the original game being released in 2013. The site claims it may come back some day, but it cannot be purchased currently.
Then there’s the new roboanimal on the block, M.U.L.E. Online, which is on itch.io for a very reasonable $5. It has the blessing of Ozark Softscape, and is a near match for the Atari 800 version. You won’t get any improved graphics or sound here, but you will get a game that copies the original very closely, which is perfectly fine in my opinion. It offers local single and multiplayer, as well as internet-based online play. They also promote a board game version of M.U.L.E, which I’ve long wanted to try!
Or there’s emulation. Back in college I played M.U.L.E. with roommates via an Atari 800 emulator burnt to a Dreamcast disk, a great way to play if you have the system, controllers and means to construct the disk because the Dreamcast has four controller ports. (M.U.L.E. is by far at its best when you have four people playing.) The Commdore 64 and IBM PC versions were also made by Dani and the others at Ozark Softscape. The C64 port is close to the Atari 8-bit version. I don’t know about the DOS PC version. I can say that the NES version made by Mindscape is a terrible version, while sadly possibly the most-played because of the great popularity of the NES. If you tried that version and wondered what the fuss is about, you should seek out the Atari 8-bit version and play it before writing off the game entirely.
World Of Mule is a fansite dedicated to M.U.L.E. in all its forms. For its 40th anniversary, they’ve published a long retrospective on the game, its history and the new versions. (That’s where the above image comes from.) It’s a fitting tribute to one of the most influential computer games ever made.
Long ago, on primordial wiki-like site everything2.com, I personally wrote a long examination and play guide to M.U.L.E. While my writing style back then was pretty crazy, I think the information holds up. If you have an interest, you may want to take a look.
NES Party and SNES Party are sites that do a think that would have seemed like magic 10 years ago: they make it easy to pick out NES and SNES games, load them into the browser from the Internet Archive, and not only let you play them yourself but share a room link with another person and enable internet-based multiplayer. It’s all as simple as that.
Well, mostly. When I tried using it, emulation was much faster than normal. The game load screen suggests, if this happen, that you reduce the refresh rate of your display, which seems like kind of a kludgy solution. But on the plus side, snes.party has Rampart!
Adobe (formerly Shockwave) Flash had a good long reign on the web as the premier means of presenting snappy interactive content without requiring repeated trips to the server. For ages, Javascript wouldn’t cut it for many purposes. Being tied to a full authoring environment helped it gain in popularity. Whole careers were built off of creating Flash content for the web.
Flash was easy enough to work in that many companies would produce Flash applets, even games, merely as promotional content, intended to be cheap and quick to make and ultimately disposable. Many of these games were lost when the websites they were a part of were taken down.
The Flashpoint Archive project, headed (I think) by BlueMaxima, has as its mission the preservation of these ephemeral creations. A post on Flashpoint will be coming eventually, but in the meantime I’d like to point out a 2021 Youtube video by (adjusts glasses) “Goober13md,” although I suspect that he may not actually be a medical doctor.
Goober13md’s beat is all things Monkey Ball. He made a video about the search for, and ultimate rediscovery, of three Flash games commissioned by Sega to promote the first Super Monkey Ball titles, as well as one for Super Monkey Ball Adventure (which Goober13md is understandably reluctant to mention by name). It’s an informative story about the difficulty of content preservation in a time, which is still ongoing might I add, where companies don’t see their web presences as anything more than transitory. Look look, see see!
In my teens I got started coding on my old Commodore 64s. Learning to program was a much different process back then, there was no internet to answer basically any question you’d have almost on a whim, everything I picked up came from some written matter, mostly programmer’s guides (including the definitive guide to using the hardware, the Programmer’s Reference Guide) or periodicals like Compute’s Gazette, Ahoy! and Commodore Magazine.
The C64 had a lot of graphics features, made possible by the machine’s powerful VIC-II chip. All of the home computers of the time had tricks one could use to get extra mileage out of their bespoke graphics hardware. The Atari 8-bit computers had display lists, for instance. The VIC-II had a powerful raster interrupt facility, the ability to share memory with the processor (at the cost of delaying the whole machine while it did so), eight surprisingly large hardware sprites (in double-width mode they could fill a whole scanline, something the NES’ sprites could only dream of doing), and a collection of interesting and flexible graphics modes.
Most of the time the C64 was in character mode, which was the standard kind of tile-based mode that pretty much all home computers at the time used by default, suitable for displaying messages, coding and some graphics. The ’64 three such modes: the standard mode where each character had a single color along with the screen-wide background color; a multicolor mode that gave a character its own color, up to two colors shared throughout the screen and that background color, and (mumble mumble). Sorry, what’d I say? I’ll get to that later.
The system also had two bitmapped modes that worked similarly, just directly viewing a region of memory instead of using each byte as an index into a character set. One mode was like the standard character mode, where the 1s in the bitmap were colored and the 0s were the background color; the other was multicolor mode, which similarly worked like it did in multicolor character mode: one color per 8×8 region, two colors shared throughout the screen, and the background color.
The problem with multicolor mode was, you had to trade horizontal resolution to use it. The big limiting factor to many computers’ graphics then was memory use: finding a way to encode the graphics information so the chip could access it and convert it into a video signal quickly enough to meet the needs of the display. So, to fit an 8-pixel-wide section of screen into the single byte it needed to be squeezed into, it could either use a one-to-one dot to screen ratio, or sacrifice two bits for one extra-wide pixel of up to four possible colors.
UNLESS
The Commodore 64 had a fifth graphics mode. The one I mumbled over earlier. The much-ignored Extended Background Color mode.
It was another character based mode that, instead of forcing you to make use of one background color over the whole screen, gave you up to four such colors. Every cell on the screen could display a character using its full 8×8 resolution, but could also pick which of those background colors it could have. Useful!
Well… not as useful as you’d think. There’s always a tradeoff, and Extended Background Color’s tradeoff was a dire one. How does the VIC-II chip know which background color to use for each character cell? It uses the two high-order bits of each character byte. Meaning, while you could decide which of two colors would be used in each cell with a lot greater nuance, you only had 64 characters to work with! A full screen of 1,000 characters is a lot to fill with just 64 possible tiles. A lot of repetition would be unavoidable, which is probably why it was so little-used.
It essentially was either this:
or this
These images are a little misleading, because I used the Commodore 64’s default ROM character set to make them, and the second half of its characters are just mirror images of the first half. But if you define your own characters, which basically any game worth its salt will do, it greatly reduces the number of tiles at your disposal. There may be some sneaky ways around it, sure, but they all involve their own tradeoffs.
I explain all this because Extended Background Color Mode is my best guess as to how Trap Door and Popeye do their graphics.
Here’s video of a playthrough of Popeye. It’s about 21 minutes, but it shouldn’t take long to get what I mean. It’s not Nintendo’s Popeye, it’s a completely different game.
And here’s a playthrough of Trap Door, with graphics by the same person:
Look at those huge characters! How could this be possible, and with that color depth? The C64 can have huge sprites, but only at the cost of making all their dots twice as tall and/or wide. And the pixels aren’t even multicolor mode wide. I can’t quite make sense out of it! Unless, maybe the games are displaying their large characters using the character set, which explains why they jerk along the screen? And the colors are using Extended Background Mode? That might explain the simplicity of the backgrounds, with only 64 characters to work with that means a lot of reused tiles.
This would ordinarily go into a Sundry Sunday post, but it’s interesting for historical value. Unlike the Switch’s spartan interface, the WiiU took some of its UI design inspiration from the 3DS, which was a bit more playful. The 3DS supported theming the main menu, which is a feature that never came to the WiiU, but they both did support StreetPass, with the WiiU still having its little-noticed StreetPass server settings among its rainbow-colored settings menu options. And of course both systems supported the Miiverse, Nintendo’s failed attempt at its own gaming-focused social media service, which let users make text and drawing posts, tied in with their Mii feature (still in the Switch although much declined in prominence), and allowed Nintendo to send users information directly to players. Miiverse is gone now, has been for years, but some people I hear are working on a fan-led revival. I shudder to think of what will get posted there without Nintendo’s moderators.
Back to the interface. Probably the quirkiest of Nintendo’s UI creations was an animation that went with the tool, downloaded fro the Wii’s Shop Channel, that transferred system and shop data from the Wii into an SD card package to be transferred to a fresh WiiU system. It could have been a simple progress bar, but they had their developers create a charming (gee I use that word a lot) sequence where Pikmin, at that point only those from the Pikmin 2 game that had last been seen on Gamecube, visually bundle up all of the transferable software, use a walkway to carry it into a waiting rocketship, and jet off to a nearby sun marked with the WiiU logo. At that point, the user would be prompted to move the SD card to the WiiU, where after installing a corresponding tool from the WiiU’s eShop, the process could continue, with a matching unloading animation.
If you never had the chance to see this sequence (easily possible given the WiiU’s low sales), or just want to relive the process, here it is, both of the Wii to WiiU data transfer animations, at about eight minutes:
This video only shows the animation. If you’d rather relive the whole process, including system menus, instructions and warning messages, here is a 15 minute video that records it. It also seems to have a couple of scenes that aren’t in the above video, including the one depicted in the head image.
A brief personal story. When the WiiU came out I got one. The WiiU’s fate was already sealed by that point, and I got it pretty cheap from a local Target. By that time my much-played Wii had been suffering from some serious issues. It had been hacked many times, the Homebrew Channel installed and its boot software replaced.
People will tell you that doing this is only for the purposes of piracy, and that’s really not true. We put the Wii to use as a general media player. It lived mostly at a friend’s house, and whenever I would go over we would use it to watch movies and things from SD cards. We even watched a DVD or two that way; while the Wii had a DVD drive installed, Nintendo didn’t spring for the licenses to play DVD movies, so it was purely intended as a data drive. You could bypass that restriction with the right homebrew software, although it wasn’t great and didn’t seem able to do menus, so we almost never used it.
My Wii had put into heavy use for game and media playing, and I put on and removed a lot of software over time, in addition of course to hacking it several times. As a result, it had gotten quite glitchy. Sometimes it wouldn’t boot, sometimes it would boot okay but wait until getting some ways into a game and freezing, and sometimes, weirdly, it’d show the opening Health warning screen, but the letters in the font would glitch out, individually. It was really a sight to see.
As a result I was really glad to get the saveable data off of that system and onto hardware that was reliable. I had to go through the whole sequence more than once, as the console froze along the way a time or two, but fortunately I got it, and our large Mii collection, all off and onto the WiiU, where it still lives today.
Collecting and saving Miis, from friends and the nearly-forgotten Check Mii Out Channel, and the Mii Parade of random Miis sent from Nintendo, is an aspect of the Wii that has not survived to the Switch. I hope whatever successor the Switch gets has something like it. And bring back StreetPass too!
The World Wide Web is now over thirty years old. In that time, more content has vanished from it than remains now, but some of it can still be dredged up from the shadowy archives of the Wayback Machine. This is the latest chapter in our never-ending search to find the cool gaming stuff that time forgot….
DHTML means “Dynamic Hypertext Markup Language.” The term is little-used now; it later got renamed AJAX, and now is pretty much just how websites are made if they have any interactive aspects. It was originally presented as an alternative to Flash applets, which were threatening to crowd out actual web pages at that time.
Lemmings, of course, is Psygnosis’ classic puzzle game where you grant members of a horde of suicidal rodent people specific skills to guide them to an exit while losing as few of them as possible to the hazards of their ridiculously dangerous world.
Back in 2004, DHTML Lemmings was a brilliant example of how much could be done with Javascript. Original Lemmings was released in 1991; we’re now further away from DHTML Lemming’s release than the original game was when it was published.
Its first home went away, although the server and even its page still exist. It says that the Lemmings page was taken down (and implies they did it to dodge legal liability), but promises something called The Pumpkins to replace it. It never did, but the promise survives. The game itself has been preserved, relocated as-was to a subpage of the site of Elizium, a dark rock band from the Netherlands.
Only the first ten levels of each difficulty, about one quarter of the original Amiga game, are presented. And this version has not survived the years unaltered: the distinctive sound effects and music appear to be missing. Still though, what’s here is playable, and fun. Enjoy, if you have the inclination and deliberation. And check out those requirements: IE 5.5 or better, or recent Firefox or Opera. And a 500 Mhz processor, wow!
