Zanac – 2015 Developer Interview

Takayuki “Jemini” Hirono – Designer

—You’ve been using the name “Jemini Hiroshi” since your early days at Compile.

Hirono: All the developers at Compile used their arcade score entry names, like PAC, Moo, and so on. I adopted Gemini (which means twin) because I liked the sound of it, but Japanese people would likely mispronounce the hard G, so I changed it to “Jemini”. I also liked how it had the word “gem” in it too.

—Please tell us how you got involved in the game industry.

Hirono: I’d been interested in computers since personal computers (“pasokon” and “maikon” as they were called in Japanese) first became available on the market. But they were really expensive then, so for awhile I could only admire them from afar and occasionally mess around with the floor models at stores. At that time in Hiroshima, the big name stores had “computer corners”, and you were free to use the machines there. They had all the newest models lined up, and all the so-called “Nai-kon kids”1 would gather there to mess around with the computers all day. It was a hotbed of excitement and enthusiasm, the likes of which you only see at the beginning of new things. Every city in Japan had a store like this back then.

And so I went along doing things in BASIC for awhile, but one day someone made fun of my programs for being written in BASIC. “What a jerk,” I thought to myself, but nevertheless I tried to study this machine language book I owned. I had to tried to read it before and failed to understand one lick of it, but for some mysterious reason, this time I understood it. I guess people really do have unlimited potential, as they say. (laughs) After that, I slowly started learning more complicated programming, and completed my own original game, Monster Panic. I sent it to I/O magazine, and they published it in one of their supplemental issues. This was the only time, before or after, that any of my submissions got published. Satoshi “PAC” Fujishima, a colleague I later worked with at Compile, was already famous for his many submissions to these magazines, published under his pen name Pakkuman.

Aside from the big name stores in Hiroshima, there were also places like Matsumoto Musen and Auburn Denshi, stores which were dedicated to computer sales, and these too became gathering spots for interested hobbyists. Masamitsu Niitani, who later went on to found Compile, actually worked at Auburn Denshi then. Each of these stores had their different regulars, but Fujishima used to go to Auburn Denshi a lot. My main haunt was the big retail stores, but I also made my rounds to the smaller places. I remember one time talking with this guy at Auburn Denshi, and I said “I heard Pakkuman himself lives in Hiroshima,” and he replied, “Yeah, that’s him right there!” (laughs) That was how I met Fujishima.

Anyway, then in 1982 Compile was founded, and they started scouting people around the area, seeing if anyone was interested in trying their hand at a part-time job making games. Fujishima and me jumped at the chance, and we ported Tranquilizer Gun to the SC-3000/SG-1000, as “Safari Hunting”. I did the programming, and Fujishima did the pixel art. Now which of us did the sound…? I can’t quite remember.

—The SC-3000 used the same z80 chip as the PC-8001, so I imagine it was relatively easy to port, but did you have troubles with the console’s dedicated sound chip, or the lack of hardware sprite support?

Hirono: At first we just used the sound chip without knowing what we were doing. As for the z80 chip… in the beginning, I didn’t have an assembler to compile the code. So not knowing what else to do, I took out a notepad and laboriously wrote out the code in hexadecimal (simulating how it would act in my head), and then after reaching a certain point, I would type that code in by hand—”hand-coded assembly”, as they called it. Programs were still very small back then, so it wasn’t as painful as it sounds. After Safari Hunting, we finally got a real compiler and coded in proper assembly language.

The first computer I used in those early days for coding the SC-3000/SG-1000 games was this huge machine equipped with an 8-inch “Mr Logic” floppy drive. It had an in-circuit emulator (ICE), which I believe could be used for debugging the SG-1000 CPU. However, we only had one of these computers, so in the beginning everyone first did their coding on their own personal computers, then transferred it over via the Mr. Logic floppy drive. Later we used the NICE-Z80 emulator, which was cheaper and could connect to a normal personal computer. That was what we used the most. I think we ended up having 6-7 units in the office. For our MSX development, too, we initially used an MSX development board with an attached NICE-Z80 unit.

For my personal work environment, after the PC-8001, I believe I used a Sharp MZ? My memory is a little shaky there, but as a reward for completing Safari Hunting, I bought a FM-NEW7, a z80 card, and a 5-inch disk drive, which I used for a long time, running the CP/M floppy drive OS. I believe I used that up to the development of Lunar Ball.

—How did you end up getting into sound programming?

Hirono: There was a classic technique to make music on the PC-8001 by controlling the on/off on the PC speaker (beep) sound. Sound is an indispensable element of making a video game, so when I learned machine language, I tried to learn that programming technique. You had to stop the screen if you wanted to play back the music cleanly… there were big limitations like that, but on the Sharp MZ and PC-6001 that I got later, it was a lot easier, and I had fun creating more musical sounds on those machines.

Before long, I got the chance to work with Sega’s SC-3000/SG-1000 sound drivers. I analyzed them, tinkering with the code until finally I was able to port them for use on the MSX. After that, by and by I started getting assigned more sound work until I basically became the sound driver guy at Compile. I never had any musical training, and to be honest, it probably would have been better if I’d been able to pass the baton off to someone who was more of a specialist in sound than me, but then again there wasn’t anyone who stepped forward for the job either! Technically, when we were making Musha Aleste, someone else did the sound programming, but unfortunately they quit shortly thereafter. Oh, and the PC-9801 sound drivers were also written by another person.

In the early days, the sound composers had their hands full writing the music, so I would create the sound effects myself—actually, on almost all the early Compile games, including Zanac, the sound effects were done by me.

For our sound development environment, I created a sound editor that ran in MSX-BASIC, and we sequenced the music there. The sound driver itself was written in assembly, and it ran in the background with the BASIC front-end. You entered notes in the familiar “MML” format. Regardless of the particular sound drivers for a console, they shared a nearly identical sequencing data format, so I could write music for the Famicom on the MSX too. Of course, the Famicom’s sound hardware had a different sound from the MSX PSG, so the final adjustments and fine-tuning would always be done on the target console.

At the composers’ requests, I eventually added a lot of different features to the drivers. Later someone created a MIDI-to-TXT converter as well, which allowed MIDI files to be played back in a format our sound driver could understand. Compared to the rest of the industry I think we were one of the first companies to have those kinds of sound features available.

—With Lunar Ball, you began programming for the Famicom. Did the differences in the CPU make the transition difficult?

Hirono: I had a Commodore VIC-1001 (which shared the Famicom 6502 chip), so I was ok there. I had previously programmed a simple demo for the VIC-1001, again using hand-coded assembler, and that turned out to be good practice. But we didn’t have a lot of documentation for the Famicom. We only had one book on 6502 assembly (written for engineers), and I remember how some of the examples were excruciatingly difficult to understand. In any event, I don’t think I was put in charge of Famicom programming because of my previous experience with the VIC… it was rather that, based simply on seniority at Compile, it was now my turn to lead a team.

For the development of Lunar Ball, we used a dedicated development machine that Nintendo gave us called the PROS80. It was connected to this box that looked like a white bento and housed the development-use Famicom, to which we transmitted our programs directly. The keyboard was really small and hard to type on, so I think we did a lot of the source coding on an FM-7 first, then transferred the files over via a 5-inch floppy drive we had hooked up to it.2

When we were making Zanac, the successor model PROS86 came out. It had mostly the same features. There was also the PROS80F that came after that, but all of them could not use mega ROM. The official Nintendo device that was supposed to support mega ROM ultimately never came, so later we used a DICE-6502 (an ICE that could be hooked up to a regular computer) instead. In terms of other official development hardware, for designing pixel art we connected a digitizer to a Fujitsu FMR.3

—The next game you worked on as lead developer was Zanac for the MSX.

Hirono: It was Masamitsu Niitani who oversaw the project as a whole. I don’t think he had much direct input into the development of the game, but he’s the one who was responsible for shepherding it across the finish line. The pixel art was done by Koji “JANUS” Teramoto, and Masatomo Miyamoto did the music. The Famicom version was also developed by nearly the same team.

—In the instruction booklet, there’s a note that says “This Game Took Over Three Years to Make”. It sounds the development had a long and twisty road…?

Hirono: I actually don’t know exactly how, or under what circumstances, the Zanac project first began. There was a developer who had done some initial coding on it, and for some reason he was unable to continue, and that was when Fujishima took over the reigns. Fujishima is honestly some kind of genius, so right away he went in and added the air-based mechanics: that included the power-up system where you collect the power chips, and I think he had added the Landers too. He had written detailed notes about them in his planning documents, but it didn’t say anything about shooting them to make them turn red. That was something I added on my own, and since Fujishima didn’t get mad or say anything, I guess he was ok with it! (laughs)

At this point it was starting to feel like a real game, but for various reasons, Fujishima ended up having to work on another project, so I was called into action. I created the rest of the game—the terrain features and enemies, the bosses, and all the special weapons (subweapons). The additional flying enemies for the Famicom version were also added by me.

So yeah, let me tell you more, starting with the special weapons. When I inherited the project, your ship had four different kinds of shots. The first three were different forms of the standard shot (which has three grades as you power it up), and the fourth shot was a torpedo-style shot that fired intermittently. I suspect that the torpedo-shot was originally intended as an air-to-ground attack, but since your normal shot could destroy both air and ground enemies, it seemed kind of pointless now.

So I got to thinking about what weird different weapons I could add, and if possible I wanted to add a big variety. To my thinking it was a kind of fan service for players, to have that many different shots. So I kept adding one after the other and eventually I came to the sub-weapon system you see today. By the way, the different subweapons in the MSX version are distinguished by different colors, but now I wish I could go back and ask myself if there wasn’t a slightly better way. (laughs) At the very least I should have used easier-to-distinguish colors.

The terrain sprites had mostly been finished before I took over, but those sprites had been arranged one-by-one in simple tilemaps to form the levels. I knew making the maps this way would take up too much memory and prohibit any expansive levels, so I completely re-wrote the terrain mapping system. I decided to appropriate the method we had used to generate the mid-air features: instead of placing the terrain in a tilemap, it would be generated via an algorithmic script. Take, for example, the terrain on the first stage, which has forest sprites with a river running through the middle of it. All the algorithm would have to do to generate that terrain was delineate the boundary points (as opposed to mapping them out individually by hand). Then the area within the boundaries would be automatically filled in with the appropriate sprites. It was a bit monotonous, but it allowed the maps to evolve over time, and be very expansive.

—Yeah, it was surprising how large they were—too big to be published in strategy guides even.

Hirono: The longer maps meant they had to be scrolled through at a faster speed too, so we made it zippy. The MSX could only scroll in 8-pixel increments, so slower scrolling looked very choppy, but if you went fast enough it looked smooth, and that was another consideration in mind for Zanac.

The way the scrolling will occasionally stop when you fight a boss—part of that was the influence of Xevious, as you can imagine. But the way the bosses are composed of individual parts you destroy, that was actually inspired by Exed Exes. I had also intended for the bosses to die in a nice clean explosion, with their parts flying off in the blast. I was able to achieve that in the MSX version, but it proved impossible to replicate on the Famicom, so ultimately I made the decision (for both versions) to have the boss ruins just remain on-screen like that after they’re defeated. I think this approach has it’s own appeal, besides.

By the way, in the early stages of its development, Zanac had a different name, Le Colonium.4 Later in the development it was changed to “A.I.” I guess from that title, the devs thought “hey, you know, since it’s named A.I., do you think we ought to put in some kind of artificial intelligence system?” And then around the time Fujishima joined the development was when the “Automatic Level Control” system, or “A.L.C.” was added. The enemy level would keep rising depending on the number of enemies you destroyed, the number of enemies you let escape, the number of shots you fired, and so forth. In this sense it felt kind of like an AI system, but I think here too, they were probably influenced by Xevious. Every STG back then was influenced by Xevious—it was almost impossible to ignore.

Anyway, later the name got changed again to Zanac, but I don’t exactly know how that happened. A likely enough explanation is that Teramoto wrote it, since he also wrote the story, if I recall. I added various little details to the story here and there too.

—Were there other STGs that inspired you? For example, the fact that you can shoot both ground and air enemies with your normal shot, that reminds me of Star Force. And ASO was another predecessor, in terms of the way you power up your weapons.

Hirono: I didn’t know Star Force very well. That game’s popularity coincided with a period when I wasn’t going to the game center very much. If I had to point to another direct influence on Zanac, it would be Konami’s Majou Densetsu (Knightmare). In that game if you pick up the same subweapon twice in a row, it powers that weapon up, and I took inspiration from that for Zanac. Speaking of the power-ups, I probably can’t say in good faith that Gradius wasn’t also an influence, but it is true that I wasn’t aware of ASO at all.

Oh, and for the Famicom version of Zanac, I added the feature where subweapon 5 becomes a laser at max strength, and that was influenced by Star Soldier. I didn’t play Star Soldier itself very much, but it got me wanting to make an equally pretty laser for Zanac. The reason the MSX version didn’t have a laser too was that I simply hadn’t thought of it then.

—Zanac embodies a high degree of technical programming expertise—do you think this was the fruit of all the in-depth hardware research and study you’d done?

Hirono: I think I did do a lot of research on the MSX. Unfortunately, the undocumented programming techniques I discovered on the MSX often wouldn’t work on every model. And I knew that if you couldn’t guarantee consistency then it was pointless. For that reason, I didn’t really invest much time learning the same kind of tricks for the Famicom. Instead it was Nintendo themselves who would sometimes share hidden programming techniques with us. As a company they did their best to recognize and disseminate that kind of info. And since they came straight from Nintendo, we readily adopted them without worry.

—It’s amazing that you were able to program something so sophisticated using only the standard, official documentation.

Hirono: Well, more than that, it was that compared with the MSX1 at least, the Famicom’s graphics capabilities were divine. Smooth scrolling! Color sprites! And we had much more freedom with how to draw the backgrounds too. From someone who came from programming the MSX1, it felt like you could do anything on the Famicom. That filled us with a “if you got it, use it” kind of swagger, and we stuffed everything we knew into our games. “Let’s add as much fan service as we possibly can”, that was our spirit.

—While the Famicom version of Zanac added a lot more features, it also was considerably easier. The MSX version had, overall, a very high level of difficulty, and the more narrow screen meant you always had to be on your toes.

The one thing we did make intentionally easier was the difficulty of the opening stage. People had definitely complained about the MSX version being too hard, and I felt the same way myself. The Famicom console itself was also aimed more at the masses, so it made sense to lower the difficulty a bit.

The mechanic we added for the Famicom version, where if you collide with a box with a chip in it, your main shot gets a full power-up—that was left in as another bit of fan service, but it was originally something of a happy accident. You see, in the MSX version, the boxes were all white, but by shooting them you could change their color to red, green, or blue, which let you know what they contained within. On the Famicom, however, changing the color of individual sprites like that on the fly was very difficult because of the way the Famicom handled color via palettes. So we changed it so the box would flash when it was shot, and while it was flashing you could see the chip within.

The problem was fixed… or so we thought! The new problem was, when there were too many sprites on the screen, you’d get sprite flicker, and that messed with the box flashing effect.

Say you shot a box, and it started flashing, showing you a chip was inside. The sprite flicker had the unfortunate effect of making that box disappear entirely—so the player thought a chip was there ripe for the taking, but when he went to get it he would die from the collision with the box. We were freaking out, but then an unlikely solution occurred to us. Why not make it so the player could just pick up the chips from a flashing box (without needing to destroy it completely)? That would fix the problem, but then a further idea came: what if we made it so it was ok to collide with any boxes that contained chips, regardless of whether they had been shot (were flashing) or not…? That would make it a gamble, of course, but if you won the gamble then we could reward the player. Just getting a single chip would make the gamble meaningless, so we made it give you 5 chips (a full power-up worth) at once. Anyway, that was how we came up with that, iterating on each idea in a logical fashion.

—The “instant power-up” mechanic was extremely helpful for recovering after a death. That kind of “lifesaver” was very rare for STGs at the time. I wanted to ask next about one of Zanac’s most striking features for the time, its high-speed scrolling. When the backgrounds are scrolling that quickly, past a certain speed a strobe-like effect occurs, which creates the appearance of parallax scrolling. Everyone was amazed by that.

Hirono: During the MSX development we did a lot of different testing, and we chanced upon that effect. I forget who noticed it first, me or the designer, but someone said, “Hey, that kind of looks like parallax!” I then worked with that designer and had him draw a number of background sprites for the final stage that would look natural with that pseudo-parallax effect.

I had really wanted to replicate the visual impact of that last stage on the Famicom, too, but when I tried to do 8×8 sprite scrolling on the Famicom, it looked ugly. The Famicom was all about single line scrolling, so it couldn’t be helped. We did some calculations on how much graphics data we’d need to send, and at what speed, in order to achieve the same quick scrolling on the Famicom. After a lot of optimizing, we finally were able to scroll 8 lines of pixel data in one frame. We used the same high-speed scrolling routine in Gunhed too. Gunhed wasn’t originally planned as such a high-speed game, but at the end of the development we were asked to include more acceleration, so we ported that scrolling routine over.

Zanac Q&A

—Which are your favorite subweapons?

Hirono: On the MSX, 7 was the strongest. But because of the larger screen on the Famicom, it didn’t hit as many enemies there. On the Famicom I personally am a fan of weapon 3. Defense, it’s all about the defense! It’s pretty rare to die with it at the highest level though, and I sometimes wonder about the wisdom of including a weapon that allowed for such safe gameplay… (laughs)

—Do you have favorite enemies as well?

Hirono: I like the Raster enemies, those purple ships that rush at you quickly from the side. For some reason I call them “Kitarou”. I like the arc of their movement; I used the same kind of movement for enemies in Gunhed too. Their attacks aren’t especially fierce, nor do they have a lot of life, but somehow they can still kill you very easily. I like enemies like that—ones that don’t look particularly imposing but for some reason are really hard.

—The Karura enemy (the one that’s invulnerable to all your shots, but you can destroy it by colliding with it) felt fresh too. I don’t remember seeing an enemy like that in any STG other than Zanac.

Hirono: We wanted to make enemies that you had to destroy in some creative way, as well as enemies that could nullify your attacks. And we wanted enemies that would make you waste your subweapons.

In terms of nullifying your attacks, more than the Karura enemies, I think the larger flying midboss enemies fulfill that role. In fact, the laser is the only shot that doesn’t bounce off them… but the reason for that isn’t because we wanted the laser to be so strong, but because we couldn’t program in a good graphical effect to show the laser reflecting. (laughs)

—Zanac takes place in a sci-fi setting, so what’s up with the fairy that comes to your aid…?

Hirono: I drew the pixel art for that, but I don’t believe I was thinking about the world or setting of Zanac in any way. It doesn’t appear in the MSX version… so I was probably just messing around in the Famicom sprite editor. One thing I do remember is how, back then, there were this silly trend with games where “the pilot is actually a girl!” I wasn’t into that. I wanted the pilot for Zanac to be a crusty old dude, so the fairy was probably me trying to put some “sex appeal” (…I guess?) somewhere else in the game or something.

I also drew the girl puppets that you throw in Touch, by the way. (laughs) There were other games I did the art for too—in Lunar Ball, for instance, I drew almost everything, including the text font. The background crater was Teramoto’s fine work, though. Now that I think of it, I think my pixel art only appears in the earlier Compile games. Later our quality standards went way up and I couldn’t compete.

During Lunar Ball, I used an official pixel art editor, where you actually entered the pixel data in with a Famicom controller. We had an easier tool to use by Zanac, I think.

Zanac’s Descendants

—It feels like Compile’s shmups always had very long stages.

Hirono: That’s largely my fault. (laughs) The final responsibility for balancing the game rested with me, you see. As for the Famicom version of Zanac, when you consider the game has 12 stages total, in that sense I don’t think first stage is too terribly long, but… in any event, I have a tendency with stage design to go and include every single thing in my head. When you’re deep in the midst of creating you can sometimes lose perspective and get desensitized to how things really are. It’s a bad habit.

—For better or for worse, after the late 80s, there was a tendency for STG games to get harder and harder. It eventually got to a point where STG games were seen as problematic because their difficulty actually drove customers away. What are your thoughts on danmaku (bullet hell) games?

Hirono: I understand that there is a demand for games like this from some players, but speaking as a developer myself, I don’t like them very much. I don’t like games that are about creating relentless stress and pressure with no downtime. That was a realization I made when I was developing a certain STG, when we experimented with putting more bullets on-screen than we had before with Zanac. It felt too restrictive and claustrophobic. When I made Zanac, you see, I didn’t know yet what kind of STGs I personally liked.

Enemy bullets in Zanac can only fire in 16 directions. We did that to conserve processing power. This did mean that during fortress boss fights, you could find safe spaces where you could avoid dying, but we stuck with the 16-way shots for the most part anyway. It was later games where we tried upgrading to 32-way shots, since the hardware processing demands had gone down somewhat. We tried out some spread shot attacks, and yeah… it just felt claustrophobic. Then when I played the game after the development was over, I realized that enemies themselves had too much life and their other attacks were too strong, and it all seemed way too hard to me. But I only realized that after the development. While we were making it, I never thought “this is too difficult” or “we’re going overboard”. In fact, I was initially the biggest cheerleader for those additions!

I don’t want to be misunderstood: it’s not a question of whether difficult games are more or less fun. There’s plenty of players out there who think some of those are also the biggest masterpieces. I’m only talking about the difficulty itself. Often what the developers think of as easy or middling difficulty, to the average person, it’s already more than hard enough. That dawned on me later in my game development career, but when I was making Zanac, I wasn’t aware of it at all. For the MSX1 version of Zanac, I really wasn’t consciously trying to make it hard, but afterwards people told me it was quite difficult, so now I look back and it’s like… thank goodness I didn’t deliberately try to make it hard then!

Because I wasn’t aware of the difficulty myself, my games were starting to get closer and closer to danmaku, until at some point I thought, “if I keep going down this path, it will lead to a blind alley.” And I pulled back, or at least tried to. Ok, we’ll use 32-way shots—but we have to make sure there aren’t too many dense bullet patterns on-screen at once. And if we do make a danmaku-ish pattern, we need to include “holes” in the pattern, or other ways for players to escape. Or we’d make it so you could avoid those patterns entirely by going to the other side of the screen. In these ways we tried to create a safety net for players.

In the end, it was largely thanks to my experience making Zanac that I never went too far down the danmaku design path. However, there’s also people who claim Zanac was an influence on danmaku STG. If Zanac really did influence those games, even a little, I guess what I’m saying doesn’t make a lot of sense.

I’m definitely not saying danmaku games are bad either. I know their fans love them. But to newcomers, they look completely unapproachable. That’s a reality that every person who makes STG games is aware of, 100%. But the overwhelming presence of danmaku games today, I think, ultimately comes down to the fact that the people making STGs today want to make those kinds of games. Anyway, I just think it would be a good thing if we saw different types of STGs out there too.

Compile’s Final STG: Zanac x Zanac

—Coming out in 2001, Zanac x Zanac certainly feels like something of a strike back against the reigning danmaku style.

Hirono: I didn’t have a lot of close input on the development of Zanac Neo, but I think it was a fairly balanced game, and they did a good job. It may not have received great reviews, but I personally loved the system where you used the charge shot to cause chain explosions.

I also remember being impressed anew by Teramoto’s genius as a designer. When they were developing Zanac Neo, in the first drafts of the pixel art, the bullets were very hard to see. Now you might imagine that because the Famicom had far simpler graphics, bullet visibility would have been a real problem on the original Zanac, but that wasn’t the case. Despite the limitations on color and the number of sprites, Teramoto managed to create a clear visual distinction between ground-based and air-based sprites. Seeing them struggle with that initially in Zanac Neo made me realize, wow, it really all comes down to the designer’s skill.

—I think the Famicom port of Zanac included on Zanac x Zanac was also incredibly well done and very accurate. It seems you achieved that without emulation…?

Hirono: It runs natively on the Playstation. It’s coded in assembler, which I think was pretty rare for a Playstation game. The sound drivers, too, were programmed from the ground up in assembler, which allowed us to read the Famicom sound data as-is. The Playstation’s on-board sound chip, however, could not reproduce the square wave of the Famicom very well. Sampling was an option but sampling a square wave sounds ugly. We tried a bunch of tricks, including sampling the wave at different intervals and octaves, but in the end we just couldn’t get it to sound right. So what we did was re-write the sound effect data completely, and tinkered with it until we got it sounding as close as possible.

Despite putting that much work into it, in the end players still criticized it for sounding different. (laughs) Being super obsessive doesn’t always pay off, I guess. If we’d just recorded the songs in full and played them back the quality probably would have been better, but we’d have lost the ability to control certain details that way… looking back now, I realize we were kind of screwed either way.

—A moment ago we talked about Zanac being seen as a predecessor to bullet hell games by some, but the score trial mode in Zanac x Zanac is something that definitely feels like a “bullet hell” version of Zanac.

Hirono: For those bonus modes, we were allowed to do whatever we wanted. In the original Zanac, the limits of the Famicom’s working RAM was actually a key part of the game’s balance (especially when fighting the fortress bosses), but I personally wondered what it would be like if that restriction didn’t exist… like how crazy could things get with no sprite limits?! Well, we tried it, and it was as ridiculous as I’d expected. As a matter of principle I’m not normally inclined to release games with a high difficulty, but since this was more of a bonus, I figured eh, why not.

—If you had the chance to make another Zanac game today, what would you want it to be like?

Hirono: Something I find fun to play myself, and something with a lot of fan service too, naturally. That’s been my personal policy for as long as I’ve been making games. Zanac was the result of that thinking, and it’s why there’s so many different enemies, bullet patterns, and flashy weapons to enjoy. But, as I said earlier when talking about danmaku games, as a designer if you keep going along this vector I think you eventually reach a dead end. The stronger the enemies are, the better the player has to be. It becomes little more than a bloody spectacle of masochism. So what is the right direction for the future of Zanac, then?

I feel like we didn’t find a clear answer to that in Zanac x Zanac, but if I was to make another Zanac game today, I think I’d probably try to return to its roots: a level of difficulty/rank that the player can clearly control through his actions, and a clear distinction between “dangerous” and “safe” aspects of the game… I’d like to focus especially on those two aspects. When we made Zanac, because of the hardware limitations, a lot of gameplay elements were actually products of necessity—the safe spots, and the sprite limit causing bullets to cut out during fortress fights are two examples—and I’d like to be able to control those things more intentionally. And finally, of course, I want to make it fun. I guess if I had to sum it up I want to make something carefully and with respect… but just saying that makes it sound kind of bland, right? (laughs)

If you've enjoyed reading this interview and would like to be able to vote each month on what I translate, please consider supporting me on Patreon! I can't do it without your help!