Recently I’ve been working on a getting-started guide on what I think is one of the most interesting games in UFO 50, Pilot Quest. (Other games I’ve really enjoyed, though I’ve by no means tried every game in the collection yet: Magic Garden, Waldorf’s Journey, Planet Zoldath, Attactics, Kick Club, Onion Delivery, Porgy, Valbrace, Grimstone and Mini & Max.)
Guides take time, so in the meantime here’s an hour-long talk by Ed Logg on the creation of Gauntlet, from GDC 2012!
An internal Nintendo metaphor for the Wii’s UI was “more channels for the TV.” It’s a particularly Old Dad idea for the Wii really, as even at that time broadcast TV was beginning to decline in popularity, but it may have made more sense in Nintendo’s home territory.
The experiences of these channels, the Mii Channel, the News Channel, the Weather Channel, the Shop Channel and the like, are receding in memory, although there are fan efforts to revive them and connect them to new information sources. But at the other end of their development life, of their pre-release development very little has ever been known. Early Wiis had stubs in their place, that only directed the user to installing a launch-day update. (I experienced this myself! I drove 140 miles in order to wait in a line for a Wii on its launch day, November 19, 2006. I’m objectively insane.)
Those stubs weren’t the true original versions of the Wii Channels, they had been in development within Nintendo for some time. Those development versions of the Wii software have never been leaked outside the company, but there exists footage of them from various sources. Bjohn on Youtube has compiled what we know about the development Wii Channels into a 21-minute video. Here it is:
There’s a fair amount there, including early versions of the Internet Channel and early evidence of plans to include DVD support. (The Wii has a fully-operational DVD drive, but to avoid playing a license fee to the DVD Consortium it cannot play DVDs without hacks.)
The name of Ikegami Tsushinki Co. is a bit better known nowadays. For a long while Nintendo was content to just let the world believe they were entirely responsible for their early blockbuster arcade hit Donkey Kong, but eventually word got out that all of its program, and large portions of its design, were the work of a number of uncredited employees of that company. While Nintendo owns the trademarks over the game, the copyright of the arcade game’s code appears to be owned by Ikegami Tsushinki, or perhaps held in joint between them and Nintendo.
One of Shireru Miyamoto’s original notes for the design of Donkey Kong, at that time envisioned as a Popeye game.
Which is it precisely? Look, when you write a daily blog you don’t have time to hunt up Japanese legal records. What is important though is that this is why Nintendo doesn’t have the rights to just rerelease arcade Donkey Kong willy-nilly. To date, they have used it once since the classic arcade era: an inclusion in the N64 Rare title Donkey Kong 64. Mind, there has been an Arcade Archives release from Hamster; I presume they got the rights from both Nintendo and Ikegami Tsushinki. It’s for this reason that Nintendo almost always presents NES Donkey Kong in compilations, which is similar but differs from the arcade game in many important ways.
Hirohisa Komanome was one of the people at that company that worked in concert with Nintendo’s Shigeru Miyamoto, and several other employees of Ikegami Tsushinki, to complete the design and implement Donkey Kong from Miyamoto’s notes, finishing it in only around three months. Donkey Kong came out in July of 1981, meaning it was probably began around the beginning of the year. The quickness of their work would prove to be essential: remember, the American arcade industry collapsed in 1983, when many promising games would be abandoned or released to greatly diminished profits. If Donkey Kong had been released a little later, it may not have become such a fondly remembered hit.
Kate Willaert commissioned the translation by Alex at Shumplations of an article written by Hirohisa Komanome that was published in 1997 in the Japanese publication bit. It’s up on their site here. Given that Nintendo tends to be very tight-lipped when letting their employees talk to the press, it’s probably good for us that Donkey Kong was implemented by an outside company, or else this account of the game’s creation may never have seen print, or our eyes.
Found by cortex over on Metafilter was this 2022 talk where someone noticed that the value of the constant pi in the source code of Doom was slightly incorrect. It’s a very tiny difference, and the results aren’t really visible in the game. So Luke Gotszling got the idea to compile the game with different values, and to see what the results are. They gave a talk about it! It’s 19 minutes long, and may be interesting if you’re of that frame of mind.
For this perceptive podcast, I interviewed self-taught indie developer Lee Easson about working on his first game Odd Infinitum. We discussed what it’s like to learn game dev today and how that has changed over the years and the challenges it brings to indie developers.
Owner of Game Wisdom with more than a decade of experience writing and talking about game design and the industry. I’m also the author of the “Game Design Deep Dive” series and “20 Essential Games to Study”
Awesome Mario trivia blog Supper Mario Broth noted on Mastodon that Super Mario World is extremely inefficient in displaying Mario’s score.
There is more information on SWMspeedruns.com, but in brief, SMW stores the player’s score as a 24-bit value as hexadecimal digits, and converts that value to decimal when it’s time to display it. There is no good way to do that that doesn’t involve figuring out the entire arithmetic, but Super Mario World does it particularly slowly: it starts with a copy of the score, then sees if it’s over 1,000,000. If it is, it increases the millions digit of the displayed score by 1, subtracts a million from the work value, then repeats. When it runs out of millions it repeats with the hundred-thousands, and repeats until it finishes with the tens. At least it doesn’t try it with the 1s, seeing as how nothing in the game awards single points!
In a worse-case scenario, with a score of 9,999,990, the code goes through this whole process every frame, consuming up to 8% of the time available for game logic.
What could the game have done to accomplish this better? It could have found out how many of each digit there was once instead of looping and incrementing. It could only figure out the score when the value changes. Or it could save the value as the digits themselves in decimal, just increment them by the right values when its needed, and then copy that figure to the screen. That’s largely what 8-bit games would do.
Even worse, if Luigi is the active character, the game does this twice: it figures out and prints Mario’s score, then it does it again for Luigi’s score, placing it onscreen in the same place.
While printing the score is just one thing the game does each frame, the effect is great enough that complex scores can lag the game, enough that speedrunners take the score into account to avoid it.
This adds to the evidence that Super Mario World development was rushed. It’s already known that a lot of the code in SMW is buggy, allowing for some truly heroic exploits like programming a text editor in SRAM purely by manipulating objects in an early level.
We presented Displaced Gamers’/Behind the Code’s video on the jankiness of kusoge disgrace Dr. Jekyll and Mr. Hyde back on Saturday. They did another video on that game, that delves into why the game’s frame rate is so inconsistent. In summary, its engine throttles its framerate in a terrible way, using long delay loops. It’s a pretty awful idea! It’s 19 1/2 minutes long. The video claims it’s even geekier than their first video on the game, but I think it’s actually slightly less technical, at least it doesn’t fill the screen with as much 6502 assembly code.
Another fact about J&H: the Japanese version had two full levels that were cut from the U.S. version, which replaced them with replays of other levels. It made a bad game even worse!
Now, because of Behind The Code, you know more about the Dr. Jekyll and Mr. Hyde game than many much better NES titles. Congratulations!
It’s 19 minutes long, and is even geekier than is usual for us, going into a disassembly of the game’s machine code in its quest to make the game marginally less awful.
While we’re on the subject, did you know that Jekyll & Hyde has a secret ending? Both endings are shown here (4 minutes):
The “bad” ending is the normal one, and shorter, but is arguably a happier conclusion to the story. To get it, all you have to do is get to the end of Stage 6 with Jekyll. That’s all.
To get the other ending, get to Stage 6 with Jekyll, then turn into Hyde and get to the end of his version of the stage. Usually, if Hyde gets as far into his level as Jekyll has gotten into his, he’s struck by lightning and dies. But in this level he’ll be allowed to reach the end of his version of the level for some reason, where there’s a boss! Beat it, and when you return to Jekyll’s world the enemies will be gone, and he’ll be free to finish the level without harassment. However, ending events will be different….
No image this time. There’s nothing to take a screenshot of! SjASMplus is, simply, a cross-platform assembler targeting the Z80 platform, the processor that runs many classic arcade games. (I refuse to say “powers,” that’s not what that word means!) If you have interest in writing new games for old arcade platforms, it’s something you’ll need.
It’s the holidays still, and I’m trying to unwind a bit. I’m failing, but at least the effort is there: the effort to reduce effort. Maybe someday.
Events often resist efforts to package them up and stamp a Convenient Narrative on them, but it’s really tempting to me to say the history of the internet in this era is that of many people rejecting the hegemony of large corporations and doing things for themselves.
Social media has seen the rejection of Twitter, for reasons I really don’t want to hash out again here, and while some ran directly to Threads or Bluesky, a good number realized it was eventually just going to happen all over again, and that helped to increase the update of open source, federated work-alike Mastodon.
Another piece of this narrative vase that we might be able to fit into place, with creative thinking and a whole lot of glue, is the downfall of Unity and how it helped the effort to create the free open source gamedev replacement Godot. And lo, after a fairly recent release of 4.0, yesterday they already released 4.2. The changelog is here. Here is GDQuest’s rundown of the changes (22 minutes), and here are Lukky’s five favorite new features (3m), which are:
FSR 2.0 support (upscaling higher resolution output from lower resolution rendering)
Color-coding of folders in the file hierarchy within Godot’s UI
The ability to “bake 2D navmeshes”
When resizing 3D objects, the UI no longer resizes symmetrically around the object’s origin by default, but instead only the side you’re changing is modified
And, within the code editor, you can now create special comments to define a code region, which can be independently collapsed to reduce clutter, and expanded when you need access to its contents. And the Ctrl-K Comment Out feature works better now.
To get back to talking about software philosophy…. There are unique problems with using fully open tools to create games. Console manufacturer devtools are still locked in a mode where the maker hands you proprietary libraries, which they are unwilling to make freely available because of their economic desire to preserve trade secrets and control their platform. Most developers get around this by going through a third party, who has independently created a system of working between the open development framework and the publisher’s libraries, and then licenses it to a studio so they can get their project working on consumer hardware.
Godot is subject to this limitation, with 4.2 being no exception. But there is a sense, with it, that it’s the brightest hope for free and open game development going right now. They don’t ask for any license fees, they don’t try to count how many installs you have and they don’t track user behavior. But because they don’t try to claw in income through direct means, fair or foul, they must survive off of contributions. If you find Godot useful to your work, please consider using their donation link and signing up for an entirely voluntary plan.
Pixelfont is a neat web tool that will take an image you provide, laid out in the proper format (which you have some control over, like character width and height) and will turn it into a pixel TrueType font for you to use! The gamedev applications of this should be obvious.
This isn’t the first free online font-building tool of this nature. The classic in the field is Fontstruct, which can also produce pixels that aren’t square, and can even extend outside of their cells, but also shows ads (although unobtrusive ones) and doesn’t let you import an image. Still, both are rather of use, or at least are fun to play with!