Editor's Note
This translation was commissioned with funds raised during ROMchip’s 2024 fundraiser. One of our stretch goals for that campaign was to support the translation of historically significant game writing.
We’re proud to publish Legend 7: Why Do 2D Games Usually Go to the Right? to fulfill that commitment. For more on our fundraising goals and initiatives, visit: https://donate.romchip.org/fundraising-mission.html
Translators' Introduction
What follows is a Japanese to American English translation of Hiromasa Iwasaki’s 2024 doujinshi, なぜ２Dゲームは右へ進むものが多いのか?, known in English as Legend 7: Why Do 2D Games Usually Go to the Right?. The translation was primarily undertaken by writer Brian Clark, while this introduction, editing, and contextual notes were composed by Heidi Kemps, a journalist and longstanding doujinshi collector and publisher. The term doujinshi has two parts: “doujin,” meaning roughly “like-minded people,” and “shi,” meaning “magazine.” Doujinshi are self-published book-length print publications made primarily, though not entirely, in Japan (the doujinshi medium can also be found in other East and Southeast Asian countries, such as Taiwan, Indonesia and Thailand).1 They are, in some ways, similar to the Western concept of zines: self-published print artifacts about a specific subject—usually something related to the personal interests of the author—sold and exchanged outside of traditional publishing channels, often at specially themed exhibitions.
The first doujinshi in Japan have been traced back to late 1800s, as a means of compiling and sharing literary works.2 In the post–World War II era, doujinshi experienced a boom thanks to the rising popularity of sci-fi media and fandoms, becoming a full-fledged phenomenon with the introduction of low-cost, small-run offset printing and the emergence of events such as Comic Market in 1975.3 Doujinshi encompass a wide variety of visual and textual forms: comics, illustrations, analysis, guidebooks, travelogues, historical research, and more. Though the terms doujinshi and doujin have garnered a reputation in the West of being exclusively illustrated content (and erotic in nature), the medium is by no means solely defined by such content. Gaming-related doujinshi has existed since the Space Invaders boom of 1978.4 Looking at even a small sample of the hundreds of thousands of books that have been published shows the form’s tremendous historical value. Doujinshi offer a glimpse of games, characters, and trends in gaming through the eyes of gaming’s most passionate fans, and they record stories and information unavailable through mainstream channels or more traditional periodical publications. Doujinshi is a unique kind of primary document, offering snapshots of Japanese gaming fandom and history.
Due to its limited means of distribution and self-published nature—as well as its eroticized reputation in the West—doujinshi have mostly gone under the radar of game researchers outside of Japan. I’ve been personally involved with doujinshi—collecting, archiving, attending sales events, and most recently publishing my own books—for over twenty years now. I’m pleased that ROMchip’s editorial group has given me the opportunity to showcase some of the work found in the doujin scene.
I selected this work by Hiromasa Iwasaki for translation because it serves as an introduction to Iwasaki-san’s career and massive body of work in the game industry. He has published dozens of doujinshi about his own work experiences at companies like Hudson Soft in the 1980s and1990s, and game history–related subjects he has researched. He has done significant work to preserve these valuable anecdotes and stories, illustrating the value of doujinshi as primary sources for game history. Iwasaki-san publishes doujinshi under the circle (the Japanese term for an indie self-publishing label) High Risk Revolution alongside his wife, Hiroshi Aizawa.5 Both Iwasaki-san’s game history and essay doujinshi and Aizawa-san’s erotic derivative manga are published under the High Risk Revolution circle name. Aizawa-san also contributes illustrations to Iwasaki-san’s doujinshi, such as the cover illustration for this book.
We are presenting a complete translation of the original, twenty-eight-page work, Legend 7: Why Do 2D Games Usually Go to the Right?, which covers a variety of topics related to Iwasaki-san’s expertise in the game industry. The Legend series doujinshi are shorter than much of Iwasaki’s other books, focusing primarily on specific topics within video game history alongside a few miscellaneous anecdotes, and sometimes expanding on his blog or social media observations.
This work begins with an extended section containing his research into why side-scrolling games tend to move rightward (from which the doujinshi derives its name). This is followed by other, shorter articles from the original publication: an anecdote about working at BEEP magazine and playing Mega Man for the first time, a look into the mysterious “menko” HuCards for the PC Engine, a dive into a popular rumor regarding Hudson’s Famicom port of Broderbund’s Lode Runner, and some appendix stories related to a doujinshi published about an early Hudson Soft history titled The Legend of Hudson 0.
Beyond the linguistic translation, this work also expresses both the benefits and limitations of web versus print publishing. Since there is no cost to using color on the web, we’ve been able to include color versions of many of the print work’s original black-and-white images, and at a much larger scale. However, many of the formatting particularities of the print publication are not transferable to web-based publishing in an academic journal. The original publication, which was laid out in Microsoft Word, uses a two-column page layout. There is also the occasional use of dashed or double-ruled lines to form boxes around some segments of text. As these design conventions are not transferable to web, and the segmenting does not convey significant meaning (in our judgment), we have chosen not to include them in markup. Additionally, images are inserted as figures in this online publication, and they may lack caption information in cases where there was no caption in the original text.
While most of Iwasaki-san’s work is sold primarily at in-person doujinshi-centric events, such as Comic Market or the retro-game–focused Game Legend event, some of his work is available through consignment sellers such as Beep Shop: https://channel.beep-shop.com/products/list?category_id=760. His blog, Colorful Pieces of Game, can be found at http://www.highriskrevolution.com/wp/gamelife/.
Author’s Introduction
I’m Hiromasa Iwasaki.
I entered the video game industry in 1988, making me a veteran of the field. For at least the past decade, I’ve rarely encountered colleagues older than me at most companies. My work often spans both game design and programming, and I frequently perform both roles simultaneously. My most notable work would be Ys Book I & II for the TurboGrafx-16 CD-ROM. In Japan, other well-known titles I’ve worked on include Tengai Makyō II, Linda Cube, and Emerald Dragon during the PC Engine era. However, since these were never localized for Western audiences, they’re likely not as well-known internationally. For mobile platforms, my notable works include My Little Pony: Friendship Is Magic, released by Gameloft, and Boku no Restaurant 3, released by ensish. Additionally, I recently learned that NAtURAL DOCtRINE is recognized in the West, so I can consider that another representative title.
Starting in 1997, I also created Dengeki PlayStation D, a magazine that came with CDs, which transitioned to the PS2 and ran for about ten years. During this time, I also launched Dengeki Online, MediaWorks’ internet service.
Since 1985, I’ve been a game journalist, contributing columns to game magazines for nearly thirty years and reviewing games for over a decade. Leveraging this experience, I now consider preserving the development history of Japanese companies like Hudson and Falcom one of my life’s works.
Currently, I serve as the lead game designer and lead programmer for a niche genre of games, while also acting as a consultant for several companies.
Translation
LEGEND 7: Why Do 2D Games Usually Go to the Right?
Figure 1
FOREWORD
After a year and a half, I’m bringing you another issue in the Legend series.
In addition to the newly written, lengthy piece titled “Why Do So Many 2D Games Move to the Right?,” I’ve included revised versions of articles that were previously posted on my blog. Altogether, the content covers topics about hardware and software from the 1980s.
At twenty-eight pages, this is a bit longer than usual for the Legend series.6
I hope you enjoy it!
· Why Do So Many 2D Games Move to the Right?
· Mega Man with the 1987 Beep Editorial Department
· The Story of the PC Engine Menko Card
· Did Lode Runner Get Rejected by Broderbund?
· The Hudson Legend 0.1
· The Hudson Legend 0.2
· Afterword7
Figure 2
Why Do So Many 2D Games Move to the Right?
Why Has It Become Normal for Game Characters to Move to the Right?
If I were to write down my own answer first, it would likely be that computers were developed in the West, where languages are written horizontally from left to right. And when starting a new line, the text structure goes from top to bottom.
But the fact that English is written horizontally from left to right is, in a sense, only a distant cause. The real reason lies in the logical hardware design for handling English.
This then formed the basis for game machines. And as a result, due to various hardware constraints, it became easier and more logical to create games where the player starts on the left and moves to the right.
That’s why moving to the right became the standard progression direction, and that’s the story I want to write about.
This issue has been discussed in various places, but almost none of them mention that moving to the right was technically simpler and more straightforward (although occasionally it’s mentioned as just one opinion on the matter). Instead, there are all sorts of confusing explanations, like “because the stick was on the left,” and so on. So here, I want to clarify that, back then, it was generally easier and more straightforward to make games that progressed to the right. As a result, if you just went ahead and created a game, it naturally ended up with rightward progression.
By the way, before diving into this topic, I’d like to define “right scrolling” and “left scrolling.”
Recently, I’ve had a few opportunities to talk about the history and technical aspects of games with university professors and graduate students, and I realized that if we don’t standardize terminology from the beginning, it can lead to confusion.
First, we’ll refer to games where the character moves to the right and the background scrolls to the left as “left-scrolling” games.
Figure 3
Right scrolling, of course, is the opposite: games where the character moves to the left and the background moves to the right are referred to as “right-scrolling” games.
This terminology fundamentally refers to the direction in which the scroll (like a scroll of paper) moves. In left scrolling, the background—the actual scroll—moves to the left, and in right scrolling, it moves to the right.
Similarly, for vertical scrolling, where the background moves downward, a vertical-scrolling shooter would be referred to as “down scrolling.” Incidentally, when the TRS-80 version of Battlestar Galactica appeared in ASCII magazine in 1979, it was described as “down scrolling.”8
Are you familiar with a type of video game called a racing game? It’s a game where you overtake other cars on the screen one after another. In games like racing games, where the screen scrolls from top to bottom, this is referred to as “down scrolling.” This is the simplest method to convey a sense of speed on the screen, but unfortunately, neither LEVEL-II BASIC nor GAME-Z80 includes such a feature. Therefore, using one of the powerful tools of the Z80—the block transfer function—we implemented scrolling in both downward and horizontal directions.
Figure 4
The article from ASCII during that time, published in April 1979
The above is a copy of the article from that time.
Since it may be hard to understand on its own, let me provide a bit of background.
First, the TRS-80 was a very successful personal computer developed by Tandy Corporation and sold in the US by RadioShack, a company that sold amateur radio and electronic components.
Figure 5
The full TRS-80 system. It cost over 1 million yen at the time.
Since it was a Z80 computer from Tandy Radio Shack, the initials were combined to create the name TRS-80. LEVEL-II BASIC was an extended version of BASIC. The original BASIC had limited functionality, so it was common at the time for expanded versions to be given names like “LEVEL-2.”
And what about GAME? This is not a game but the GAME language.
Created by Hiroshi Onishi and introduced in ASCII magazine in 1978, it was a minimal, high-speed language that replaced BASIC statement keywords with symbols.
GAME stood for General Algorithmic Micro Expressions—a highly condensed language for general algorithms. Adding the word language at the end makes the meaning understandable, but by today’s standards, it’s a rather forced abbreviation.
Why did something like this come about?
At the end of the 1970s, the biggest goal was to add a TV interface and run BASIC on one’s microcomputer. But back then, the amount of memory available to amateurs was around 4 KB, with 8 KB being quite large.
The smallest version, Tiny BASIC, was about 2 KB. Adding a work area brings the footprint to about 2.5 KB, leaving only around 1.5 KB of program space in a 4 KB memory setup, which made it difficult to write applications.
However, GAME required only 1.5 KB while offering nearly the same capabilities as BASIC, which expanded the free area and was overwhelmingly faster.
Figure 6
Declaration of GAME as a common language and benchmarks, published in the January 1979 issue of ASCII . The benchmarks show it was significantly faster compared to BASIC at the time.
Since it was small and fast, everyone wanted to use it.
Originally, GAME was a language written for the 6800 (Motorola’s 8-bit CPU), but it was then ported to the 8080, the Z80, and even the 6502 (specifically, the Apple II). A compiler was later developed, and while it wasn’t quite at assembler-level speed, it could routinely achieve speeds about ten times faster than BASIC. As a language with few dialects, it reigned as one of the main languages for various personal computing tasks from around 1979 to 1983.
In the article featured on the previous page, the Galactica game was written using GAME-Z80, the version ported to the TRS-80.9 It was here that the term down scrolling was used in a description similar to a racing game.
I’ve finally explained the background of the article that used the term down scrolling. In fact, up until the mid-1980s, the meanings of vertical and horizontal scrolling weren’t universally agreed upon. Some people called it “right scrolling” simply because the character moved to the right, or “up scrolling” if the character moved upward in a vertical scroll. However, I remember that with the rapid rise of the Famicom boom in the 1980s, the terminology quickly became standardized.
The reason I’m writing about this is because I was part of the “right-scrolling” faction. So, when I first joined Hudson and found that the terminology was reversed, I remember thinking, “Huh?”
Now that we’ve established the definitions for scroll directions, I’d like to move on to the history of how text came to be displayed on monitors.
In the early days of computers—the 1950s and ʼ60s, which could be considered the dawn of computing—computers didn’t have monitors.
To be precise, monitors did exist, but they were prohibitively expensive and not something everyone could use.
So, how did people input programs, and how did they get the results?
First, program input was done using something called punch cards.
Figure 7
A punch card
A punch card had an inconvenient specification of 1 card = 1 line, so a 100-line program would require 100 cards. But anyway, this is how programs were input. So, what about output?
Output was done with something called an electric typewriter—not a printer capable of printing images like today, but rather a printer that could only use the alphabet and some symbols.
IBM was a well-known manufacturer of these printers, and in the late 1970s, Hudson’s Mr. Takebe connected a junk IBM printer to his own microcomputer, enabling him to print out programs.10
Figure 8
An electric typewriter. This product was a huge hit for IBM at the time.
The legacy of these electric typewriters actually remains in systems like Linux, where the terminal name is “/dev/tty.” This “tty” comes from the initials of “TeleTYpewriter.”
Why it’s not “ttw” is unclear.
So, from the 1960s to the early 1970s, program input was done with punch cards, and output was done with electric typewriters. However, a revolutionary change came with the release of DEC’s VT50 in 1974.
“VT” stands for Video Terminal.
Figure 9
VT50
Unlike IBM’s expensive video terminals like the 3270, the VT50 was versatile and affordable, connecting via serial port (RS-232C).
As a result, it was a big hit, leading to the release of the improved VT52 in 1975, and then, in 1978, the VT100 with even better performance, powered by Intel’s 8080 processor.
Figure 10
VT100
The VT100 was an extraordinary hit at the time, so widely adopted that its screen control commands, known as escape sequences, became the de facto standard. These escape sequences are still used today in Linux terminal emulation, known as “termcap.”
To be precise, these escape sequences are used in both termcap and terminfo.
Figure 11
Rogue running on WSL2 uses termcap. (Michael Toy, Glenn Wichman Ken Arnold, [1980]) (Screenshot courtesy of author)
Moving on …
The VT series—video terminals—had monitors, and to display text on them, the connected computer would send simple commands like “display this character here,” specifying a location on the screen.
These commands were the escape sequences mentioned above.
In other words, the computer only needed to specify “place this character at this location (address) on the screen,” so the VT terminal required RAM to store and update the characters displayed.
This memory was called Video RAM, or VRAM.
The standard display mode for the VT100 was 80 characters wide by 24 lines high.
Each character corresponded to 1 byte in VRAM. As shown in the diagram below, the addresses (essentially the memory locations, which can be thought of as determined on a per-byte basis) advanced from left to right, following the direction in which the characters moved across the screen.
Figure 12
An illustrative diagram made by the author.
With this setup, for example, the address of the first character in the second line can be calculated as (row - 1) × 80 + (column - 1), allowing characters to be displayed at any desired position. For continuous writing, simply writing one character and then advancing the address by one repeatedly achieves the desired result.
This structure, where text is written from left to right and continues on the next line when reaching the right edge, is very logical and convenient for English.
The reason for writing “-1” is because, for most people, counting starts at 1 for the first character or first line. In the computer world, however, the origin usually starts at (0,0), just like in mathematics, so the “-1” isn’t applied.
Additionally, the VT100 had an extended mode allowing for 132 columns, so the calculation above isn’t entirely accurate. But here, I’m prioritizing clarity to make it easier to understand.
This screen structure, or VRAM structure, was very logical and easy to handle for English, so almost all terminals of this type emulated the VT100’s VRAM structure.
In fact, one could say that if you design VRAM in a straightforward way, there’s practically no alternative to this structure. It just makes sense, right?
So, it became standard for VRAM addresses to proceed left to right, and after reaching the right edge, to continue at the left of the next line down.
Moreover, being able to design things straightforwardly means lower costs, which is extremely important.
In the world of computing, the term straightforward refers to designing in a way that’s easy to implement using a particular hardware, CPU, or language and aligns with what the creator has intended or recommended. Building things in a straightforward way usually brings benefits like shorter development time, fewer challenges, and faster performance. On the other hand, when you diverge from this approach, it often leads to significant difficulties, which is why programmers tend to prefer writing things as straightforwardly as possible.
And here is where an important design choice comes into play.
The VT100, or rather any terminal, is designed to write characters from left to right and from top to bottom.
Terminals were modeled after typewriters, so their behavior mimics that of paper.
Thus, when displaying text on the screen, it starts from the top left and gradually moves downward.
When it reaches the bottom line, the screen performs a “scroll up” by shifting everything up one line, freeing up the bottom line for new text. This structure allowed for continuous display from top to bottom, just like writing on paper.
By translating this straightforwardly into coordinates, we get a structure where “0 is the top, 23 is the bottom,” and “0 is the left, 79 is the right.” Replacing these with X and Y, we arrive at a screen coordinate system with X = 0–79 and Y = 0–23.
Figure 13
An illustrative diagram made by the author.
In this way, the coordinate system for video terminals was established with the top-left as the origin, increasing downward and to the right. And so, the story moves toward the late 1970s.
By the way, a bit of a side note, this coordinate system is different from the typical Cartesian coordinate system—it has 0 at the top and increases downward.
There also exists a screen coordinate system where 0 is at the bottom and increases upward.
This is mainly used in 3D coordinate systems, but because it doesn’t align with the coordinates of textures and other elements, it can often be a source of bugs in rendering. It’s really a headache.
Equally troublesome, in my opinion, is the inconsistency between 3D coordinate systems where Y is the vertical axis in some cases, and Z is in others.
This exact difference exists between the two major game engines, Unity and Unreal, and it often leads to quite a hassle.
I really wish they would standardize it.
And so, the story moves to the late 1970s, when commercial video games began to appear.
The screens of video games transitioned from using general-purpose chips without a CPU in the early 1970s to being CPU-based around 1975, allowing for more complex games to be created through software control. However, this introduced a new challenge.
Returning to the topic of screens, the structure of video game screens was fundamentally no different from that of video terminals—only instead of characters, special graphics representing backgrounds or player characters were displayed.
So, what happens to previously displayed graphics when you overwrite any location on the screen with a new graphic?
Naturally, it disappears.
While this is convenient for displaying text, it poses a significant issue for games. Imagine a game where the player character moves left and right at the bottom of the screen while shooting upward.
Moving the character requires erasing it, and any background behind it would also disappear.
To prevent this, either you need to redraw the background each time to avoid erasing it or set a plain black background to eliminate the need for redrawing.
Both methods were actually used in practice. This was especially true for personal computers, where most systems didn’t have hardware sprites (which I’ll discuss later), making redrawing an essential technique.
Ideally, it should be possible to have player characters and projectiles move freely across the game screen independent of the background. That’s where sprites come in—a revolutionary invention.
That’s where sprites come in—a revolutionary invention.
Since their invention, sprites have been such a groundbreaking development that it’s safe to say no gaming machine has existed without some form of them up to the present day. So, what exactly is a sprite?
A sprite is a small object that can move independently of the background on the screen, with the following key characteristics:
· Managed separately from the background and displayed layered over the top of it.
· Rendered quickly by dedicated hardware, enabling smooth movement at the level of individual pixels.
· Allows parts of the sprite to be transparent, enabling it to overlap with the background or other sprites.
Figure 14
The image above shows the screen from SNK’s Sasuke vs. Commander , released in 1980, where multiple sprites are skillfully used to create the game screen
The ability to move objects without disrupting the background, thanks to hardware support for sprites, gave arcade systems an overwhelming advantage compared to personal computers of the time, which had to run games on graphical screens without sprite support.
So, who invented the sprite? That would be Atari.
This is the same Atari that brought the world the first commercially successful video game, PONG, and later dominated the US market with the Atari VCS.
Briefly tracing their history, sprites first appeared as “Motion Objects” implemented in hardware in TANK8 (1976). Later that same year, SPRINT2 introduced the ability to layer sprites, allowing them to overlap.
Figure 15
The flyer for Atari’s TANK8 . Remarkably, it was an eight-player multiplayer game.
And then, it is believed that Namco’s Galaxian (1979) was developed by studying Atari’s TANK8 and SPRINT2.
The multicolor sprites in Galaxian were groundbreaking, and this led to a race in the Japanese arcade industry to match and surpass it, ushering in an era where creating games with sprites became the norm.
By the way, although I’m using the term sprite in this text, Atari originally named them objects.
The reason for the different term has an interesting background.
The term sprite was actually introduced by Texas Instruments (TI) when they developed the TMS9918 video chip for one of the earliest home computers, the TI-99. The name was inspired by the idea that these graphics could “fly freely across the screen like sprites (fairies).”
The term sprite later became widely known with the popularity of the Famicom. However, there’s a fascinating twist.
Arcade companies at the time, like Namco, Taito, Sega, Konami, Capcom, Tecmo, and Nintendo, had already studied Atari’s hardware before the TMS9918 was introduced, so they knew sprites as objects.
As a result, developers in the arcade industry refer to sprites as “objects,” or abbreviate it to “obje” in Japanese.
For example, in The Famicom and Its Era, Famicom designer Masayuki Uemura uses the term object rather than sprite.
On the other hand, developers who came from a background in personal computers or home gaming consoles (myself included) had their foundations with the TMS9918, so we all called them “sprites.” In other words, whether someone uses “sprite” or “object” reveals whether they came from the arcade side or the home-gaming side back then.
Setting aside that diversion, let’s stick with the term sprite. Sprites are small squares (initially all were square-shaped), but when displayed on the screen, they align with the screen’s coordinate system.
Therefore, each sprite has a reference coordinate assigned to it, which determines its position on the screen. Here’s how that works:
Figure 16
As expected, sprites were designed so that the origin is the top-left corner, just like the screen coordinate system.
This design was the most straightforward in terms of memory access. If you wanted the center to be the origin, that was something to be handled in software.
Figure 17
Left Scramble , right Defender .
And as coordinates increased on the right side, the sprite would simply extend beyond the edge, but the left side posed various issues.
Firstly, some hardware did not allow sprites to extend off the left edge, meaning there was no way to specify a negative screen coordinate. Without a method to designate negative coordinates, the sprite couldn’t move leftward beyond the screen boundary.
In other words, some hardware restricted sprites from going off the screen to the left.
By the time of the TMS9918, this limitation was no longer an issue in the same way, but a similar constraint persisted: placing a sprite off the left side of the screen required a bit of special handling.
I haven’t personally worked with such hardware directly, but I’ve heard from veterans in the arcade industry that there was hardware capable of handling negative values where, the moment a sprite’s position turned negative, it would suddenly disappear from the left edge of the screen.
In short, with hardware from the late ʼ70s to early ʼ80s, handling sprites at the right edge of the screen was straightforward, but the left edge posed challenges.
Now that I’ve covered the basics of sprite hardware from the late ʼ70s, let’s move on to scrolling.
Horizontal scrolling games were developed nearly simultaneously in Japan and the US, with the modern examples being Williams’ Defender (1981) and Konami’s Scramble (1981).
Although Scramble is structurally closer to modern games compared to Defender, the fact that it used a vertical screen reflects the technological context of the time.
Just a quick note on the history: Sega’s Bomber (1977) was reportedly a horizontally scrolling game, but since I couldn’t find any screen images of it despite extensive searching, I refer to Scramble and Defender as the pioneers of modern horizontal scrolling.
Setting that aside, how exactly is the screen of a horizontally scrolling game structured?
Figure 18
A schematic diagram of 1980s scrolling hardware.
A virtual screen larger than the display screen was prepared, and scrolling was achieved by specifying the top-left coordinates within this virtual screen.
Since the example above allows for both vertical and horizontal scrolling, let’s now consider a left-scrolling screen with only horizontal scrolling, without vertical scrolling, in line with our current topic.
Figure 19
Please look at the numbers in the schematic diagram above in order from top to bottom.
1. The scroll register is incremented
2. The display screen shifts to the right
3. Resulting in a leftward scroll.
With this principle, the game progresses to the right.
New map sections are generated just outside the right side of the screen. The specifics vary by game: some generate an entire screen’s worth of content at once, while others generate small sections incrementally.
For example, in PC Engine games I’m familiar with, Ys I & II uses the method of generating one full screen at a time, while R-TYPE generates content in smaller segments, adding a few lines at a time.
In 1980s game development, addition was generally more straightforward than subtraction.
Negative numbers were handled using two’s complement, which was more cumbersome to work with.
Also, by default, an initial value of zero was easier to manage. With this in mind, the most straightforward approach was to structure the screen as shown below.
Figure 20
In other words, the scroll naturally moves to the left, making it simpler to place characters on the left side.
Why is this approach more straightforward? You can understand this by considering a game that scrolls to the right instead.
Figure 21
Take a look at the schematic diagram above.
For example, if the scroll register is set to 0, it will immediately become -1 with a single decrement, introducing negative values. Handling negative values adds complexity and can be cumbersome.
I forgot to mention that in left scrolling, the scroll register generally does not go negative.
Positioning the player character is also cumbersome. To display it at the right edge of the screen, you must set the value as screen edge [minus] the character’s X size.
But the most troublesome aspect is enemies appearing from the left edge.
Since the origin of a sprite is the top-left, managing this is already awkward, but it also means that enemies must pass through the left edge of the screen, where their coordinates transition from negative to zero. This transition point requires special handling for the sprite.
Clearly, having the player character move to the right with a left-scrolling setup is a much more straightforward approach.
Here’s my conclusion:
In the early days of video games, from the late 1970s to the early 1980s, left-scrolling games—where characters were positioned on the left and moved to the right—were far more straightforward to implement from a hardware perspective.
That’s why left scrolling became the de facto standard, in my view.
While it’s true that “because English is written from left to right” could be considered a distant factor, the real reason lies more in the constraints of the scrolling and sprite systems of that time, based on coordinate systems derived from this directionality. I believe attributing it simply to English being written left to right doesn’t quite capture it.
By the late 1980s, sprites could be displayed at negative coordinates, and reversing the scroll direction became only slightly inconvenient. Still, there was little benefit in doing so: even if you inverted the scroll by decrementing the scroll register, there was no significant advantage. I think games continued to be made with left scrolling simply because it was familiar, and right-scrolling games never really took hold.
Figure 22
One of the rare right-scrolling masterpiece games is Jungle King (1982). Due to copyright issues, its name was changed to Pirate Pete , and it’s now playable through the Arcade Archives.
Mega Man with the 1987 Beep Editorial Department
Figure 23
I remembered something that brought me to tears with laughter from back at the Beep editorial department, so I wanted to preserve it here.11
I might have posted about it once on Twitter, but I doubt that things like tweets will be preserved properly, so I want to make sure it’s captured in this book.
This story is about Beep, the very first game-dedicated magazine published by SoftBank, so it takes place in the Famicom era.
It was around fall of 1987, and by that time, I was already talking with Hudson, and everyone in the editorial department knew I was on my way to becoming a professional game developer.
It so happened that I was at the Beep editorial office with Kappe under the pretense of a meeting when one of the writers came back to the office exclaiming, “I got a new ROM from Capcom!” (I can’t remember who it was).
The game was the very first Mega Man.12
Back then, Capcom games were notoriously difficult, known for games like Ghosts ʼn Goblins and Commando, which were especially hard.
Ghosts ʼn Goblins in particular had become a byword for “difficult” in Marukatsu (a game magazine), where games like Family Boxing and Family Jockey were humorously referred to as the “Family series version of Ghosts ʼn Goblins” because of the difficulty comparison.13
So, naturally, everyone assumed, “It’s bound to be insanely hard,” as they popped the ROM in. To our surprise, there was a stage select screen!
Figure 24
The boss stage select screen.
Everyone was thrilled, exclaiming, “Capcom has finally had a change of heart!”
I remember TAKE ON shouting, “Hyo!” or something like that, but it might have actually been Miyabi (or maybe even Imokichi).14
Then, someone—can’t remember who—started playing [the] Cut Man [stage] first.
By default, the cursor was positioned on Cut Man, if I recall correctly.
They somehow managed to reach the boss but ended up dying.
“Looks like we picked a tough one,” they said, and then moved on to Guts Man.
They fell and died instantly.
Then they fell and died in Ice Man’s stage.
They kept going through each stage, but every single one was so difficult that they quickly hit game over.
Before they knew it, they had reached game over on every stage.
Everyone burst out laughing, saying, “So it is hard after all!”
But then, if I remember right, TAKE ON said, “No, let me try again,” and someone finally managed to beat a boss.
Everyone went, “Whoa!” and, before long, all the writers there started working together to figure out the game.
I had to leave around then for something, but my friend, Kappe—a.k.a. Toshiaki Takayama—stayed with everyone in the office all night playing Mega Man. Later, he told me,
“Wasaki, you definitely need to buy that game!”
Just a little episode from nearly forty years ago—so many memories.
I don’t think I’ve ever properly written about him before, so I’d like to take a moment to talk about Toshiaki Takayama.
To me, he’s much more affectionately known as “Kappe.” We met during our first year of university at a board-game shop in Kyoto, and we both became regulars at the café Solaris. We spent countless hours in arcades, playing games together and generally goofing around.
Later, he joined the same company as I did, and we’d head to Shinjuku nearly every week to play arcade games. Almost daily, we’d be at my place playing Famicom games.
But this daily routine came to an end in early 1988 when I left that company to join Hudson.
If we’d had cell phones or social media back then, things might have been different. As it was, once we went our separate ways, staying in touch became nearly impossible, and we lost contact.
Yet, a few years later, in 1991, we met again in the Marukatsu PC Engine editorial office.
To my surprise, he had joined Kogado Studio and was working on Super Schwarzschild.15
“You made this?” I asked.
“Yeah, it was tough, Wasaki,” he replied.
It was just a brief exchange, but the surprise of that moment is unforgettable.
He went on to stay with Kogado, working on games like the Power Dolls series, credited under the name Toshiaki Takayama, with “Toshiaki” written in hiragana.16
About ten years ago, I wanted to reconnect and asked someone at Kogado, only to hear that he’d left the company a few years prior.
Since then, I haven’t heard from him.
However, I’m sure he knows it’s easy to find me on social media, and he could reach out if he wanted to.
So, I think his silence means he likely wanted to step away from the game industry—that’s how I see it.
The Story of the PC Engine Menko Card
Figure 25
One day, a French acquaintance sent me the above image with a question: “This is something very rare, but what exactly is it?” (in English).
It turned out to be a paper dummy HuCard. I thought, “Oh, so it’s rare.”
Because these early HuCards, dating up to around 1988, were just lying around at Hudson or in the editorial department, and I probably even had a few myself. I never considered them rare.
But now that I think about it, these paper cards were likely promotional items, though I didn’t know exactly what they were.
In situations like this, it’s best to ask someone who would know. Arai, a former Hudson colleague who was on the sales side, would almost certainly have the answer, so I decided to ask him on Facebook.
Arai’s answer was as follows:
Arai:
I think it was for promotional use.
We handed them out at events like CSG and possibly in-store events as well …
They might have been distributed to retailers (toy stores) too.
Since cartridges were all there was before, it was probably to help people recognize that games could come in this card type (or cartridge?)—and also because it looked cool! For stores, it was likely to help with product awareness.
The first part was as I’d expected, but the second half made me think, “Oh, right!”
Back then, the standard [size] was around the size of a Famicom cartridge, so having a game in a card format was indeed something new.
For those unfamiliar with it, I’d like to add a quick note about CSG. CSG stands for Consumer Software Group.
At the time, Nintendo had organized a group called Shoshinkai, which was central to the distribution of games. However, Shoshinkai focused on the Famicom, making it difficult to handle other hardware and software.
It wasn’t impossible, but it was clear that showing PC Engine or Mega Drive software at Shoshinkai’s internal exhibitions (trade shows for wholesalers) wasn’t really an option.
That’s why CSG was created—to distribute software and hardware from companies other than Nintendo.
CSG held events across various locations, combining trade shows for business negotiations with public game shows. The event itself was also called CSG.
This group eventually grew, evolved, and was restructured into CESA, which went on to organize TGS (Tokyo Game Show).17
Knowing this history, it makes sense why Nintendo has kept some distance from TGS.
That side note aside, this was also a time when credit card–sized items were trending, including calculators, which were even available in credit-card size. This got us talking …
Mr. Tobita:
There were even card-sized calculators with game titles on the back.
President Sasaki said—
President Sasaki:
It says MENKO on it.18
It might be just the right size for menko, haha.
Mr. Arai:
That’s right, that’s right—I remember someone saying they played with it like a menko card!
By the mid-1980s, menko wasn’t exactly a popular game anymore, and kids didn’t really play it, but it was still a time when everyone at least knew what it was and how it was played.
The size is certainly that of a typical menko card, so having it double as a promotional item and a menko card makes sense … And then Sega’s Mr. Okunari shared some astonishing information.
Mr. Okunari:
Sega made a similar promotional item in 1985 (the one on the right is the actual item). This one doesn’t say “menko” on it, but it’s made of exactly the same material as a menko card. Probably because it’s almost the same thickness as the real thing. Also, I think there weren’t any variations—just this one. It was a promotional item for stores.
Figure 26
The real PC Engine HuCard is on the right, and the menko card is on the left.
An astonishing revelation: there were also promotional items for the Sega My Card!19
In the mid-1980s, Sega had a phase where they aimed to switch from cartridges to cards, and quite a few games for the SC-1000 and Mark III were released in this format.20
I should be able to find a few of those games myself if I dig around at home.
So, it turns out that promotional items like these were common for companies releasing card-based games at the time.
Incidentally, both HuCards and Sega My Cards were made by Mitsubishi Plastics, so they’re practically relatives … or more like siblings, really.
Did Lode Runner Get Rejected by Broderbund?
Figure 27
A blog post happened to come up mentioning, “During the development of Lode Runner, Broderbund initially had reservations, but Takahashi Meijin persuaded them.” Here’s the quoted excerpt:
In fact, Broderbund initially rejected the game, saying, “This isn’t a puzzle game.” However, it seems that Takahashi Meijin persuaded them, and it was approved as-is (though apparently, he doesn’t remember exactly how he convinced them) …[https://www.cobalog.com/entry/loderunner]
First of all, the claim that Takahashi Meijin persuaded them is incorrect. This blog post references Takahashi Meijin’s own blog, but in that post, Takashi Meijin writes about this incident as something he heard secondhand.
However, it seems that Broderbund initially stated, “This is not Lode Runner,” and were reluctant to approve it. [https://ameblo.jp/meijin16shot/entry-11495162323.html]
In other words, Takahashi Meijin only heard about the incident, so there’s no way he was involved in persuading anyone.
Moreover, Takahashi Meijin joined the company in August 1982, so during the development of Lode Runner, he was still in his first two years—a rookie. He wasn’t yet the famous Meijin that he later became, so suggesting that he convinced anyone is a bit far-fetched.
Now, what about Broderbund supposedly rejecting the game, as Meijin also wrote about secondhand?
Initially, I didn’t think such a story existed. However, Mr. Nozawa reportedly mentioned in a 2023 talk show that Mr. Nakamoto forced Lode Runner through to Broderbund despite their objections, and Meijin also mentioned hearing something similar.
So, while I can’t definitively say it didn’t happen, my stance is that Mr. Nozawa (and Meijin) likely have muddled memories and got some timelines mixed up.
This is a story from over forty years ago, so it’s certain that we’ll never know the full truth. That said, I think the likelihood of Mr. Nozawa’s account being entirely accurate is low. Here’s why:
During the development of Lode Runner, Mr. Nozawa was in Hokkaido, working with Mr. Kikuta to assist with Nuts & Milk.21 Even if something like this happened, it would have been Mr. Nakamoto handling the situation.
Mr. Nozawa was in Tokyo on a long-term business trip around early 1983 to assist Mr. Takebe but then returned to Hokkaido. According to Mr. Nozawa himself, interactions involving soldering and circuit work on the Famicom development kit were conducted via phone and fax.
While short-term trips to Tokyo may have occurred, it’s certain that he wasn’t in Tokyo for an extended period after that.
Therefore, even if Mr. Nozawa had heard about it, it would have likely been secondhand information.
That said, it wouldn’t be surprising at all if he heard about it during a drinking party or similar gathering.
Next, let’s consider the fact that none of the people I’ve interviewed—Mr. Takebe, Mr. Nozawa, Mr. Tobita, Mr. Okuno, or any other Hudson staff involved in development at the time—have ever mentioned such a story.
Since 2011, I’ve asked multiple times about Lode Runner and Hudson’s early Famicom development, but not once has anyone, including Mr. Nozawa, brought up the rejection issue.
Additionally, another Broderbund title, Raid on Bungeling Bay, underwent significant changes and turned into a very different game. Mr. Nozawa was also involved in that project, yet I’ve never heard of any similar complaints or issues.
Raid on Bungeling Bay even became a game for Nintendo’s VS arcade system, evolving into a vastly different version of itself. It wouldn’t be surprising if there were similar complaints, yet I’ve never come across any such stories, which I think serves as supporting evidence.
So, my first reason for doubt is that, despite asking multiple people over the past ten years, including Mr. Nozawa himself, I’ve never heard this story mentioned (at least until the topic came up in last year’s talk show).
The next reason.
When talking about game ports from that era, take for example Falcom’s Ys for the Famicom—it was significantly altered from the original. However, if you ask whether the original staff at Falcom were aware of these changes at the time, the answer is that they were not.
When you ask the staff about it, they often say things like, “Before we knew it, it was already released.”
As for what the president said, there’s testimony that he remarked, “They just port it on their own.”
Take Faxanadu, which caused a strained relationship with Hudson. Even though there was an initial meeting, afterward, Mr. Okuno, at least, was never shown the game again.
In other words, Falcom didn’t supervise these ports in the 1980s.
Similarly, with Nintendo’s Punch Ball Mario Bros. or Mario Bros. Special, there’s no record of them being shown to Nintendo during development.22
I’ve also never heard of Mr. Nakamoto showing Star Force to Tecmo, nor have I heard of Pooyan being shown to Konami.
Likewise, there’s no mention of Ghouls ʼn Ghosts being shown to Capcom, nor of Fighting Street either.
Even with Broderbund’s Diablo (a.k.a. Blodia), there’s no indication that the game was shown to Broderbund.23
Based on my own experience, I did provide Falcom with an explanation of the porting approach and interviewed members who were still at Falcom, but we never periodically showed them the in-progress version of Ys I & II.
At that time, there were no supervisory meetings like the ones held today. I was never told, “Make a ROM so we can review it.”
The only thing we might have consulted Falcom on was the staff credits.
In the 1980s gaming industry, there was no practice of showing in-progress work to the original creators for supervision. At least, there weren’t regular supervisory meetings with IP holders like the ones we see today.
So when someone says, “They rejected it,” the question becomes, “When would that have happened, if there weren’t even meetings?”
The only cases where in-progress works might have been shown for supervision were typically for anime or character IPs. In Hudson’s case, the only titles where such episodes have been mentioned are Hattori-kun, Doraemon, and Mickey Mouse.24 That’s the reality.
It’s certain that Shogakukan was involved in this process, and Disney also certainly did the same.25
Even with anime or other external IPs, I’ve never heard of anyone performing a thorough check for Necros no Yōsai, and the extent of supervision for the Mashin Eiyūden Wataru game is doubtful.26
For Cobra: Kokuryūō no Densetsu, it’s clear that Buichi Terasawa only gave a few suggestions and did a light review.27 As for Urusei Yatsura, the scriptwriter Takatsu casually wrote a scenario where Lum and Ataru kiss in the ending—something that would have been impossible if proper supervision had been in place.28
In short, it was entirely normal for IP holders to be lax about these things.
So, to conclude: no one I’ve interviewed has ever mentioned such a story, and there was no industry practice in the 1980s of showing progress for supervision.
Therefore, I believe the likelihood of Broderbund almost stopping the project is quite low.
To provide some context on current supervision practices: for games involving IPs, supervision typically begins at the planning stage. At the very least, there are supervisory meetings with the IP holder at a pace of once a month or more. Graphics, in particular, are always checked, and requests for revisions are made early on as a standard practice.
This is entirely different from the 1980s, when supervision was practically nonexistent.
That said, I don’t believe the claim that Broderbund raised complaints is entirely unfounded.
There’s a good chance that something along those lines did happen.
Here, I’ll outline three possible explanations for this scenario:
Hypothesis 1: The issue came up during the contract negotiations with Broderbund.
When the contract was being negotiated, it’s certain that Mr. Nozawa went to Broderbund.
During this time, Mr. Nakamoto might have explained the plans for the port, and Broderbund could have expressed reservations about it.
It’s possible that Mr. Nozawa later recalled this and mentioned it at the talk show, and that Takahashi Meijin also remembered hearing about it. However, the challenge with this hypothesis is that Mr. Nozawa himself testified that the contract negotiations were incredibly straightforward, with Broderbund simply saying, “100 yen per copy,” and it was settled quickly.
Despite this, I think this scenario is plausible.
Hypothesis 2: After completing the game, Hudson took the ROM around to wholesalers to secure orders, which were used to obtain financing from banks. During this stage, perhaps by chance, the ROM was shown to Broderbund, and they expressed reservations about it.
This scenario isn’t entirely impossible.
However, the fact that no one remembers such an event, despite how significant it would have been, is a major drawback.
Additionally, the time between the game’s completion and the finalization of the contract with Nintendo was around two months at most.
It’s a bit far-fetched to think this happened within such a short window, though it’s not entirely impossible and should still be considered.
That said, this theory has another major issue: Hudson’s contract with Broderbund had already been finalized during development.
The timeline for Hudson’s porting efforts for the Famicom went as follows:
1. A contract was signed for the ports of Lode Runner and Bungeling Bay.
2. Development of Lode Runner began in early 1984.
3. Around March 1984, Hudson started visiting wholesalers to collect orders.
Moreover, considering the nature of contracts at the time, it’s highly unlikely that there were defect clauses (provisions allowing the contract to be voided due to issues with the work). This means Broderbund wouldn’t have had the authority to revoke their approval.
Additionally, Mr. Nakamoto received the source code from Broderbund for the port, so it’s not possible that the game was developed first and the contract came later. Development only began after the contract was finalized.
Therefore, the claim that Broderbund expressed reservations becomes increasingly implausible.
Hypothesis 3: Broderbund expressed complaints during a meeting after the game’s release.
I think this scenario is highly plausible.
In fact, I suspect that this incident may have become conflated in memory with the later industry practice of showing games for supervision, leading to the misunderstanding that Broderbund was shown the game beforehand.
Let me outline my hypothesis about when this might have occurred:
After Lode Runner, Hudson released Championship Lode Runner. Naturally, this was because Lode Runner was a massive hit, leading to the development of a sequel.
The release date for Championship Lode Runner was April 17, 1985.
This was just nine months after the release of Lode Runner. Less than a year had passed.
Based on the production schedule for Nintendo’s ROMs at the time, as inferred from the payment and release date of Lode Runner, it seems they managed to complete production within about two months. This suggests the master ROM was likely finalized around February.
Championship Lode Runner can be described as a collection of high-difficulty additional maps, but there were numerous minor programmatic revisions as well. This suggests that development must have started by the end of 1984 at the latest.
Incidentally, there was already a PC version of Championship Lode Runner.
Given this timeline, it’s highly likely that between July and November 1984, Hudson approached Broderbund to secure a contract for porting Championship Lode Runner, based on the success of Lode Runner.
During this meeting, Broderbund could very well have expressed dissatisfaction, saying something like, “That scrolling approach is unacceptable,” and given the higher difficulty and stronger puzzle elements of Championship, they might have requested, “Please port it in its original, fully visible format.”
At this point, Hudson likely responded by explaining that the Famicom version of Lode Runner used scrolling, and they would keep that approach for Championship. This would be a perfectly logical conversation to have had.
This theory aligns well with other accounts, such as Mr. Nakamoto’s claim about having to argue his case or struggling to secure approval. It also fits the timeline, as this would have taken place less than a year after the release of Lode Runner.
It wouldn’t be surprising at all if memories of these events became intertwined over time.
From all the interviews I’ve conducted over the years, I’ve learned that the first thing to become unclear in development history is timing—differences of several months fall well within the margin of error. By that standard, Lode Runner and Championship Lode Runner can essentially be considered to be from the same period.
That’s why I believe this might be the real story.
To add to this, I think Mr. Nakamoto’s decision to implement scrolling at the time was a bold move. However, everyone involved in the project would have been familiar with the original, nonscrolling version of Lode Runner.
I’m certain that people must have said various things to Mr. Nakamoto about his decision to use scrolling, and it’s likely that memories of those discussions have also become mixed in over time.
So, in conclusion—
While the claim that Takahashi Meijin persuaded Broderbund is entirely incorrect, the story that Broderbund was on the verge of rejecting Lode Runner and that Mr. Nakamoto convinced them is a piece of oral history from forty years ago. Given the lack of concrete evidence, we can only discuss it in terms of likelihood.
With that in mind, my stance is this: based on the fact that (1) I’ve never heard such a story from other staff who were present at the time during a decade of interviews, and (2) supervision was almost nonexistent in the 1980s, it seems unlikely that Broderbund rejected the project and Mr. Nakamoto had to win them over.
Instead, I believe this story originates from a later event—when Hudson went to negotiate the contract for Championship Lode Runner and received complaints from Broderbund at that time.
As I’ve written, this remains a piece of oral history from forty years ago, and the truth will likely never be fully known. However, I think it’s important to lay out these possibilities for consideration.
The Hudson Legend 0.1
Here is an excerpt from The Hudson Legend Zero:29
The earliest games released for the X1 were not purely written in assembly language but were instead developed using a compiler. 30
A compiler is an application that translates programs written in high-level languages into machine code (assembly).
At the time, BASIC was the dominant language, so a compiler for BASIC was created.
Hudson Staff Member: I just remembered—during the early days of X1 game development, we used to compile BASIC into machine code (using a compiler developed by Mr. Motosako). However, since that approach made it difficult to port games to other platforms, we eventually switched to writing everything in full assembly language. That’s also when we started using ICE.
I checked with Mr. Motosako on Facebook to see if this was true, but …
Mr. Motosako:
A compiler for the X1? Did something like that exist?
As I dug deeper…
Mr. Tobita:
I think the BASIC compiler wasn’t made by Mr. Motosako but by Mr. Nozawa.
Mr. Nozawa enjoyed creating compilers.
The compiler was only used in the Sapporo development team; in Tokyo, we used assembly from the start.
Huh? Wait a minute …
So, I decided to check with Mr. Nozawa this time, and here’s what I found out …
Mr. Nozawa:
A BASIC compiler for the X1? The earlier Hu-BASIC compiler was Nakamoto-related...
But the X1 era was when Motosako was really active.
You should ask Motosako about it.
And just like that, I ended up going in circles. The truth remains shrouded in mystery ...
And so I wrote, but one of the unnamed legends remembered the compiler from that time!
Unnamed Legend:
I think the X1 compiler was made by Mr. Motosako. Maybe he just forgot about it.
When I joined the company, it was right when game development using the compiler had started.
I even developed one X1 game entirely on the compiler. At the same time, Tanaka was working on Bomberman using the X1 compiler.
And so, I received this statement!
The statement continued even further:
Unnamed Legend:
Most of the development tools for the Sapporo team were managed by Mr. Motosako, so it’s understandable if he doesn’t remember everything.
When we transitioned to machine code development, I think Mr. Motosako was the one implementing CP/M, WordMaster, and the assembler. I also believe he handled the X1’s hard-disk support.
In short, it turns out he had simply forgotten about it.
What’s more, the legend remembered quite a bit about the compiler itself. Below is a detailed account of the X1 Hu-BASIC compiler that was first used:
Unnamed Legend:
The compiler had a peculiar command structure, and I learned the details of what it could and couldn’t do directly from Mr. Motosako. While it already existed by the time I joined the company, so he might not have been the original creator, he was definitely responsible for maintaining it.
The compiler didn’t really improve development speed and had its limitations. It was entirely unsuitable for action games.
In conclusion, it remains unclear whether Mr. Motosako created the compiler, merely maintained it, or if it was a compiler originally developed for the MZ and ported to the X1 by Mr. Motosako, who then also handled its maintenance. However, what is certain is that between 1982 and 1983, Hudson’s Sapporo team was clearly using a compiler to develop games.
From this testimony and Mr. Tobita’s earlier statements, two things become clear:
First, the use of the compiler was limited to the Sapporo development team.
At the time (1982–83), Hudson’s operations were split between the Tokyo branch in Kojimachi and the headquarters in Hiragishi, Sapporo, with both locations handling development. Kojimachi focused primarily on games, while Hiragishi worked on both business software and games. However, it was only the Sapporo team that used the compiler.31
Second, the compiler had significant limitations and was neither fast for development nor efficient in execution.
Regarding development speed, it’s obvious that compiling on machines of the time wasn’t quick.
The compiler’s functionality was also constrained, as noted in Hudson’s catalogs from that era, which described restrictions on usable statements and a lack of support for anything beyond integers. These same constraints were confirmed by internal testimony.
Additionally, the code generated by compilers of the time couldn’t compare to human-written assembly code. There was no meaningful optimization, and while it was faster than BASIC, it was clearly unsuitable for action games. In some cases, poorly optimized compiler output could drop performance to only a few times faster than BASIC, as inferred from other software of the time.
In short, while compiler-based development may have been easier, it was far from efficient.
So, what happened next?
Ultimately, the limitations of the compiler made it clear that it wasn’t improving development speed. As a result, Mr. Nakamoto, who was in Tokyo, decided, “We’re switching to developing games in assembly and abandoning the compiler.” He created the TRANS package, a toolset designed to simplify porting in assembly.
Using this package, Mr. Nakamoto wrote Cannon Ball (and Kaeru Shooter) overnight, leading Hudson to make a significant shift toward developing games in assembly.32
Mr. Tobita’s testimony on this follows:
Mr. Tobita’s Testimony:
I believe the games Mr. Nakamoto created overnight were Cannonball and Kaeru Shooter (targeted for the X1).
At that time, he also created what was called the TRANS package.
It worked in a way similar to the BAT system on the PC Engine, where you’d have two frames of BAT—one from the previous frame and one from the current frame—and write updates only for the differences at the character level. Since it was based on X1’s PCG (programmable character generator), porting was relatively easy.
As long as you had the TRANS package and the key input routines, you could directly port the game.
We used filters to convert Z80 assembly code into 6809 or 8086 assembly code during the porting process. Back then, we were developing two titles per month and porting them to platforms like the X1, PC-88, FM-7, and L3. With all the ports combined, we were producing around ten games a month.
With the development of the TRANS package, game development was centralized in Tokyo. In Sapporo, only Mr. Nozawa (who was not working on games at the time), Mr. Kikuta, and the business team remained.
At the time, Hudson’s business division was not only focused on office software like HuWord and HuCalc, but also on system software, such as Hu-BASIC and H-DOS—areas where Mr. Nozawa excelled. This is an important detail to keep in mind.
In 1983, the Famicom was released, and in 1984, Hudson became the very first third-party developer to enter the platform. But here’s where things get interesting.
Game development in Sapporo began to grow rapidly.
One likely reason was that, during Japan’s bubble economy, it was easier to recruit talent in Sapporo than in Tokyo. By 1985–86, Sapporo had expanded significantly.
For example, the 1986 intake of new hires was centered in Sapporo, and it included future key members like Mikami, who became the driving force behind the Momotaro series, Kosaka, who developed the MSX version of Star Soldier and various PC Engine games, and Butchie (Iwabuchi), who built the sound driver environment. These individuals became central to Hudson’s later success.
In the spring of 1986, there was an attempt to consolidate development in Tokyo, but this was disrupted by the chaos surrounding the development of Doraemon. Mr. Nakamoto snapped and decided to relocate everyone back to Sapporo.
Ultimately, game development settled in Sapporo and paved the way for Hudson’s focus on the PC Engine.
The Hudson Legend 0.2
Figure 28
At Hudson, there was a lively atmosphere with major software being sold at bargain prices.
The image above shows Hudson’s booth at the Microcomputer Show held in May 1981, as featured in the July 1981 issue of I/O magazine, provided by Oh! Ishi. This particular Hudson booth from that year was incredibly significant from both the perspective of computer history and game history.
Let me quote The Hudson Legend 0 to explain why.
However, since Hu-BASIC had already been completed, it’s certain that Hudson participated in the 1981 Microcomputer Show for the first time. This confirms that Hu-BASIC was finished before May 1981.
Hudson Staff Member:
At our first Microcomputer Show, we sold Hu-BASIC as a product, and it flew off the shelves—it was a massive success, bringing in a huge profit.
This experience of strong success motivated us to keep participating in Microcomputer Shows. That said, as the name suggests, the Microcomputer Show was focused on the applications of microcomputers, so over time, the number of embedded system exhibits increased.
It’s true that Hudson participated in the Microcomputer Show almost every year, and even the first announcement of the PC Engine CD-ROM system took place there.
And this is where an astonishing encounter occurred.
Right next to Hudson’s booth was the booth for Carry Lab.33
This is where Hudson staff met Sasaki (later the president of Alfa System), Hasegawa, Mr. Yamamoto, and others who would later go on to found Alfa System.34 They hit it off right away!
In other words, this was the very first step toward the founding of Alfa System.
If their booths hadn’t been next to each other, Alfa might never have connected with Hudson. If that had happened, I might never have met Hasegawa.
And then, Alfa wouldn’t have been involved in Ys I & II or Tengai Makyō II. What’s more, Mr. Masuda might not have worked with Alfa, which could have affected his own works.
It’s truly astonishing how history weaves itself in such unexpected ways.
This fascinating glimpse into game history was shared with me, and while it’s certain that Hudson participated in the show, verifying the testimony is challenging because there are very few people left who can cross-check such memories.
Even Mr. Nozawa was still a junior employee at the time, and Hudson’s employee numbers were barely around twenty.
So, I thought that sharing Oh! Ishi’s post, which includes photos, might jog some memories. I posted the photos on Facebook and asked others to share their thoughts.
Here is testimony from Mr. Sasaki, the president of Alfa System:
President Sasaki:
I believe I met Mr. Nakamoto at this venue.
This moment confirmed the validity of the quoted account.
This encounter ultimately led to the founding of Alfa System, which in turn brought connections with me and Mr. Masuda. From a game history perspective, it’s undoubtedly a significant milestone.
Now, according to the testimony, Mr. Sasaki wasn’t the only one present at the time. So what does Hasegawa have to say? Here’s his testimony:
Hasegawa:
In 1981, I was still a second-year university student and had just started working part-time at Carry Lab, I think.
So, the testimony is likely mixed up with a later Microcomputer Show or is simply a case of mistaken memory.
That said, one thing is certain: the encounter between Mr. Nakamoto and President Sasaki at the 1981 show did indeed happen.
Additionally, here’s testimony from Mr. Tobita, who wasn’t yet with Hudson at the time:
Mr. Tobita:
They held it at the Distribution Center, didn’t they? I went there to observe at the time.
Haha, so Mr. Tobita was there as a visitor! (He joined Hudson in 1983.)
By the way, what about Mr. Nozawa, who was already a Hudson employee but still a junior at the time? What was he up to?
Mr. Nozawa:
I didn’t go, you know. That’s Nakamoto at the very front.
Since Mr. Nozawa was still a junior employee at the time, he likely wasn’t allowed to attend.
As for the person at the very front, I had thought, “That looks like Mr. Nakamoto,” and sure enough, it was confirmed through testimony from Mr. Nozawa and others.
It’s fascinating to think that even though I met him less than ten years later, he looks so unrecognizable without his beard.
Since this was the first time Hu-BASIC was being sold, it makes sense that the creator himself was there to explain it.
As for the person in the back of the photo, there was some debate—whether it was Mr. Saito from Hudson’s sales team at the time, or Mr. Matsumoto, the manager of CQ Hudson.
Unfortunately, that remains unresolved.
Incidentally, Mr. Ohashi from Denpa Shimbunsha also attended the 1981 Microcomputer Show.
Here’s his testimony:
Mr. Ohashi:
I was exhibiting there too. Publications like Radio no Seisaku Bessatsu: E de Miru Maikon Nyūmon (Radio Construction Special Issue: A Visual Guide to Microcomputers) were selling so well that I had to shout, “Please make sure you have exact change before lining up!” Such fun memories.
In 1980, the Basic Master Level 3 was released, followed in 1981 by the FM-8 and PC-8801, marking the arrival of a generation of computers capable of high-resolution graphics (640×200) and support for kanji characters. The following year, 1982, would also see the release of the X1.
These testimonies truly capture the fervor of the microcomputer boom during this era of rapid technological advancement.
Afterword
It’s been a year and a half since the last installment of the LEGEND series, so let me explain why a lengthy text on “Why is it so common for 2D games to progress to the right?” suddenly emerged.
To begin with, this topic has appeared in articles on the internet several times, but it’s always been a source of frustration for me.
For those of us who wrote code back then, rightward scrolling was easier because going left meant dealing with negative values, which was cumbersome. Moreover, having sprites enter from the left introduced additional complexities.
From both a hardware and software perspective, progressing to the right was simply more natural and straightforward—something any programmer from that era would find obvious. Yet, most of the articles ignored this entirely, instead offering explanations like “It’s more natural for humans,” or “It’s because the joystick is on the left.”
Of course that isn’t what it was! It was infuriating.
Then, around September, there was a commotion on X (Twitter) involving a certain subcultural scholar who had sparked controversy over Street Fighter II. Out of curiosity, I read that scholar’s collected essays and, once again, found that same misguided scroll-direction explanation. I was utterly exasperated.
By the way, that collection of essays contained numerous factual and technical errors regarding game history. It’s a secret, but I couldn’t help thinking, “Don’t they bother to fact-check properly?”
Then, someone involved in video game research at a university reached out, saying they were studying games but were amateurs when it came to hardware and software. They invited me to talk about such topics in a Discord gathering.
When I joined and said, “Sure, I’d be happy to,” what surprised me was their sheer lack of knowledge—both good and bad—about hardware and software.
When playing games, understanding hardware or software isn’t necessarily required, so it’s understandable. However, the problem is that many aspects of video games are absolutely impossible to comprehend without a basic understanding of hardware and software.
As I was explaining things that I think researchers should at least know, the topic of scrolling came up again. I saw it as a great opportunity to clarify: “Technically, left scrolling is easier to implement.”
This explanation, with some additional context and details, became the text for this article. That’s why this text suddenly appeared.
As for the title, the original draft was something clunky like, “Why is it standard for 2D games to progress to the right?” It was far too explanatory. Hiroshi Aizawa kindly pointed that out, saying, “That’s way too descriptive,” so after some back-and-forth, we settled on the current title.
Thanks!
By the way, for this year’s Winter Comiket, I’m tentatively planning to release Hudson Legend 6+, which will serve as a supplement or addendum to Tengai Makyou II.35
When I wrote Hudson Legend 6, it became clear that Tengai II was an unexpectedly massive game, and I left out far too much. That’s why I decided to put out an additional book.
It looks like this one will end up being about sixty pages long. Honestly, what’s happening here?
Thank you for reading all the way to the end.
I hope we’ll meet again somewhere.
Hiromasa Iwasaki
From Setagaya, Tokyo
Footnotes
1. ^ English-language academic scholarship on doujinshi largely focuses on its anime and manga subcultures, with their strong ties to studies of Japanese fandom and transmedia production, or what scholars like Mizuko Ito and Marc Steinberg term media mix. However, doujinshi’s potential as a primary document for game history has been largely untapped. For examples of work in this arena, see Mizuko Ito, introduction to Fandom Unbound: Otaku Culture in a Connected World, ed. Mizuko Ito, Daisuke Okabe, and Izumi Tsuji (Yale University Press, 2012), xi–xxxii; Mizuko Ito, “Japanese Media Mixes and Amateur Cultural Exchange,” in Digital Generations, ed. David Buckingham and Rebekah Willett (Routledge, 2013), 49–66; and Marc Steinberg, Anime’s Media Mix: Franchising Toys and Characters in Japan (University of Minnesota Press, 2012).
2. ^ 宮越, 勉, 2020, 日本近代文学史に果たした同人誌の役割について考える: 明治大学日本文学研究会, p. 5–6, https://meiji.repo.nii.ac.jp/records/5559.
3. ^ Kunihiko Iizuka, “Mini-Comics and Comic Fanzines: What Can Be Seen from Their Similarities and Differences,” Seikei University Faculty of Letters Conference (2017), 89–107, https://seikei.repo.nii.ac.jp/records/2000667.
4. ^ For further reading on the impact of Space Invaders in Japan, and the origins of the Japanese game industry more broadly, see Martin Picard, “The Foundation of Geemu: A Brief History of Japanese Video Games,” Game Studies 13, no. 2 (December 2013), https://gamestudies.org/1302/articles/picard.
5. ^ Doujinshi circles are labels under which an individual or a group publish books. Most in-person doujinshi events and many consignment sellers list doujinshi under circle rather than author names.
6. ^ Iwasaki-san has published several books of various lengths. The Legend series, which this text is part of, focuses more on a variety of short-form essays and subjects. Some of his other books, such as the Hudson no Densetsu (Legend of Hudson) history series, can be almost one hundred pages in length per publication.
7. ^ In the original publication, each bullet section was listed with a page number, like in a traditional table of contents. Since this translation takes the form of a scrolling web publication without pages, we have removed the page numbers.
8. ^ ASCII was a microcomputing magazine that began publication in 1977. It ceased publication in 2008. It began a lineage of magazines that includes the famous Famitsu.
9. ^ This is referring to the Battlestar Galactica game mentioned earlier; in the original text it was referenced on page 4.
10. ^ Junk is a term in Japanese that originates in English but doesn’t quite have the same meaning: it basically describes something that’s untested, missing parts, or perhaps in a state of disrepair, but may still have some value. In this case, the implication is that this was something of dubious functionality that was just lying around but turned out to be useful.
11. ^ Beep was an influential magazine covering PC, arcade, and console games published by Softbank starting in 1984. The magazine’s focus would eventually drift to Sega platforms, and it would eventually morph into Beep! Mega Drive, then Sega Saturn Magazine, then Dreamcast Magazine, before eventually becoming Gemaga. It ceased publication in 2012.
12. ^ The name used in the original text was the Japanese title Rockman, but for ease of understanding we’ve gone with the localized name, Mega Man.
13. ^ Marukatsu were a series of console-specific magazines published by Kadokawa Shoten that targeted elementary school and teenage readers. Both Marukatsu Famicom and Marukatsu PC Engine were published starting in 1988, with Marukatsu Famicom becoming Marukatsu Super Famicom in 1991. In 1992, several editorial staff members left to form the company Media Works and the Dengeki series of game magazines. During the N64 transition, Marukatsu Super Famicom would become Marukatsu Game Shonen.
14. ^ Takeon, often written in English script as TAKE ON!, was a writer at Beep magazine.
15. ^ Kogado Studio is a game and graphic developer that mostly works as an outsourcer these days.
16. ^ Hiragana is one of the three primary systems of writing Japanese. Most proper names are written in kanji, but it would not be too unusual for the sort of nicknames that would often appear in game credits of the 1980s and ‘90s to be written in hiragana.
17. ^ CESA stands for the Consumer Entertainment Software Association.
18. ^ Menko is a Japanese card game in which players compete by throwing cards at other cards placed on the floor and trying to flip them over. Special menko cards are used to play.
19. ^ My Card was the term for the small, card-based games that worked with early Sega consoles/computers. Some models had card support built in, others needed the use of a Card catcher adaptor to run My Card games. Some of these titles were released overseas as Sega Card games for the Sega Master System.
20. ^ While the SG-1000, an early computer/console hybrid from Sega, saw only limited release outside Japan, the Mark III is commonly known globally as the Master System.
21. ^ Nuts & Milk was an early Hudson Soft Famicom puzzle-platformer title, originally released on various Japanese microcomputer platforms. While not officially released outside of Japan, it frequently appears on unlicensed Famicom and NES multicarts.
22. ^ Japanese-exclusive Mario games were developed by Hudson and licensed by Nintendo for use on Japanese microcomputers. The games are somewhat notorious for feeling “off” compared to the originals, adding in several new elements.
23. ^ Diablo was a puzzle game published by Broderbund Japan. It was ported to the PC Engine under the title Blodia.
24. ^ Hattori-kun is a long-running children’s manga series by Motoo Abiko with numerous media adaptations.
25. ^ Shogakukan is a large Japanese publisher of numerous popular manga series, including the aforementioned Doraemon.
26. ^ Necros no Yōsai was a Japanese toy line of the late ʼ80s–early ʼ90s that spawned a PC Engine game adaptation; Mashin Eiyūden Wataru was a popular anime by Sunrise, the PC Engine game adaptation was localized and stripped of much of its original license to become Keith Courage in Alpha Zones.
27. ^ Kokuryūō no Densetsu is a popular and long-running sci-fi manga series first serialized in Shonen Jump by Buichi Terasawa. It has received numerous adaptations across different forms of media.
28. ^ Urusei Yatsura is a popular sci-fi romantic comedy manga series by Rumiko Takahashi that has received several anime and game adaptations. One of the key elements driving the humor is lead character Ataru repeatedly and stubbornly rejecting the romantic attentions of female lead Lum, which is why the scenario mentioned feels wrong.
29. ^ Hudson no Densetsu (Legend of Hudson) is a series of doujinshi publications by Iwasaki chronicling the history of famed Sapporo-based hardware/software developer Hudson Soft. These are intended as addendums to that text, though they are able to be read on their own.
30. ^ This refers to the Sharp X1, a line of proprietary microcomputers released in Japan from 1982 to 1988.
31. ^ Kojimachi is an area in the Chiyoda district of Tokyo.
32. ^ Cannon Ball was a 1983 Hudson Soft game for microcomputer platforms. It was released by ZX Spectrum under the name Bubble Buster. Kaeru Shooter was another 1983 Hudson Soft microcomputer title.
33. ^ Carry Lab was an early microcomputer software developer based out of Kumamoto, Japan.
34. ^ Alfa System is a developer based out of Kumamoto, Japan. They developed some of the first CD-ROM–based software for the PC Engine and would later develop critical and fan-favorite titles like Linda Cube and Gunparade March. Some of their titles released in the West include the Castle of Shikigami series and Elemental Gearbolt.
35. ^ This would be Winter Comiket 105 on December 29–30, 2024.
Cover of なぜ２Dゲームは右へ進むものが多いのか?, known in English as Legend 7: Why Do 2D Games Usually Go to the Right? , by Hiromasa Iwasaki (Image courtesy of cover artist, Hiroshi Aizawa)