Gradius – 1996/1999 Developer Interviews
Hiroyasu Machiguchi directed the first Gradius and was involved in most of the sequels. In these two interviews, he talks about the origins of Gradius, its place in the history of Konami, and the tension between game design and the economic realities of arcade operators. A short interview with Nagata Akihiko linking Gradius’ development with western RPGs is appended as an extra.
Hiroyasu Machiguchi (Director)
Game Hihyou Interview – September 1999
I joined Konami sometime around 1982 or 83. When I joined I didn’t really like games that much… or rather, I didn’t know much about them. After being hired, I had to learn everything about games from step one. I learned most everything on the job as we went along, even basic things like what we call the element of “game play.”
I started out as a designer, but after awhile it was determined that I didn’t have any talent for that. (laughs) So I got reinstated as a programmer. When I was hired, Konami was working hard to transition from making medal games to video games, and a lot of projects ended up getting shelved. As a result, the first game I actually released publicly was Gradius.
I was given a team to work with, but since you definitely can’t make a game with only your own ideas, I started off by asking everyone what kind of game they wanted to make. To my surprise, everyone responded “STG!”, and with that we began planning. At that time it was the golden age of Namco’s Xevious, and everyone was driven by the enthusiastic sentiment that “If we’re going to make a STG, let’s surpass Xevious.” We made it a horizontal scroller because we had materials for Scramble and decided to reuse those as much as possible. In fact, Gradius originally started as “Scramble 2.”
As it was our first title, we didn’t have any confidence about what we were doing. We had a lot of anxiety. In any event, we started coming up with things, and we tested out idea after idea on the actual monitor screen. For example, with the Options, we must have tried out around 20 different movement patterns for them, proceeding by the process of elimination when something didn’t work. The development period for Gradius took about a year, and all the while it was a process of continual experimentation and refinement.
Another one of our goals for Gradius was to be able to express something that previous games hadn’t been able to do. That would be what we call “sekaikan” (story / world / setting) today. I think having a unique world and setting was one of Gradius’ defining points.
At the same time we were developing Gradius, Konami finished work on its first 16 bit PCB, the “Bubble System.” It was a huge step up in terms of display and processing power. Nowadays home consoles have 128bit CPUs, but back then a 16bit system was very powerful. Accordingly we had all sorts of wild ideas reflecting our desire to do something new that couldn’t be done before. The fact that each stage has a totally different image came from our desire to make a variety of different worlds for the game. For Gradius, this idea came first, and the gameplay followed from it.
For the world of the game, we were very influenced by science fiction movies. The popular sci-fi movies at that time were Star Wars and Lensman. (laughs) Lensman had just come out when we were thinking about what kind of STG we’d make, and we all went and saw it as a team. It had a huge impact on us. Not the story, but the way the plasma and lasers and such were drawn left a big impression. On the way back from the theatre we were talking, and we decided “Let’s add something like that plasma laser to our game!” And that was how the Laser weapon came to be.
We faced many difficulties, but one that stands out was the limitations of the memory. For its time it was a large amount, but it still wasn’t enough. When you die in Gradius, you’re sent back several screens to a checkpoint. That actually wasn’t in our original design plans. You see, the background data was loaded 3 screens at a time, but when that transfer gets interrupted by a player death, to allow time for the data to transfer we had to send the player back 3 screens.
We had to do that due to memory issues, but it ended up leading us to the interesting “recovery pattern” system, so it was all for the best.1
Another thing we struggled with was the power-up gauge. This was the most difficult. We also tried out a system where you pick up individual items, like a “speed up item” and “missile item”, but it somehow wasn’t very satisfying. We wanted to give the players freedom in their choices. Not just the choice of whether to pick up an item or not pick it up, but something more detailed. So we figured we’d have players pick up power-ups that they could store, but we really struggled with how they would be used and what kind of selection system there would be. We got a flash of inspiration from the way the function keys on personal computers of that time were laid out. It was their layout and arrangement that gave us the image for the power up gauge. After that we made the power up button. At that time there were almost no 3 button control panels. So we also made a 2 button version of Gradius, but as we expected, it wasn’t very fun. In the end, after thinking about the players’ responses from the location test, we decided on the 3-button setup.
I think Gradius’ success lies in the fact that we were able to take everyone’s ideas on the team, debate and discuss them, and make something that reflected the whole team’s intentions. Also, we didn’t pay much heed to ideas from the outside. The decision to use a 3-button setup is one example of that. Instead we forced our way ahead. (laughs) Of course, that was because we were confident that what we were making was interesting.
In the world of arcade games, you’re judged under two different standards: one is the strict question of whether the game made income for the operator, and the other is whether the players liked it. And sometimes there is a gap between these two. Its especially apparent lately. There’s various aspects of arcade gaming… there are games that draw a low income but are loved by players, and there are also games that are popular but have a low replay value, so their income ends up being low. Gradius was very popular, but it had a low replay value and didn’t draw much income. Still, I think it made on average 18000 yen in a day.
From our perspective as game designers, we felt that a game where “the better you are, the longer you can play” was best. But it's very difficult to do that now. So I think games you can play for a long time are being left to home console games. However, naturally we want those players who love arcade games to come back to the game center, so even if the profit falls a bit, and the replay value is low, I think games you can play for a long time are necessary. This was one of the motivations for us in making Gradius IV, as well.
Recently, due to the influence of games like DDR, the focus at game centers has been on casual players. That is, players who don’t know much about games but come to the game center to play anyway. If we don’t grasp this fact as designers, even if we make a good game, players will quit before they can even understand what’s interesting about it. I’d say that is the most pressing thing for us to consider now.
As I’ve been making games for a long time, in my view one of the greatest changes in game development has been the way we make games. When my generation worked as designers, we’d draw characters on paper with a marker, but now everything is polygons. Its a huge change. And this is my perspective of things, but I’d say that up till now we haven’t had to think much about production costs. There was a strong sentiment to just make the games we wanted to make. But that has changed now. Also, we used to think only about satisfying players, but now we have to think more about our original customers, the arcade operators. If we can’t make the operators happy, then the players won’t get to experience our games either. I think that has been the greatest change–having to strike a balance between the game as a creative work and a commercial product.
Gradius – 1996 Developer Interview
originally found at the GSLA archive
During the development of Gradius, I worked as a programmer and as the team leader. I was involved in Gradius, Gradius II, and Gradius III–the entire series. Originally Gradius was planned as “Scramble 2.” The famous STG at that time was Xevious… there had been many STGs released after it, but none had surpassed it. One of our development concepts for Gradius was to make a horizontal STG which would surpass the vertical scrolling STG Xevious.
The capsule powerup system was at first an item power-up system. It probably makes more sense if I call it the “Salamander” system. But we wanted players to be able to choose how to power up their ship, so we left it as you see it today.
Gradius was the first STG to use 3 buttons. Nowadays there are many 6 button arcade games, but at the time 2 button games were the norm. Until the location test, Gradius was also a 2 button game. But it felt too much like something ported from a Famicom game, and at the location test the development staff collected a number of surveys from the game center, and after much deliberating, they decided to make it a 3 button game in order to make it more strategic. At the time it was a very bold move. Various departments at Konami exchanged their opinions about it, but in the end we made it a 3 button game. We had a lot of anxiety about that choice, but I think players were happy about it.
Generally speaking there was no way players would enjoy playing something that we ourselves didn’t find interesting, so we came up with a variety of ideas for the stages as well. Some of those couldn’t be accomplished due to hardware limitations, but we brought them back for Gradius II and III. The fast scrolling stage and the ice stage in Gradius II, and the bubble stage in Gradius III are examples.
We originally added the Moai because we wanted to give a mysterious image to the game. Xevious had used the Nazca Lines, and we were inspired by that. But we had no idea the Moai would become a mainstay of the series like it has.
As for safe spots and such, we were able to confirm some of them ourselves, but most of them have been found by players. Simply put, they were bugs. We didn’t plan for them to be there. This goes for slowdown as well as safe spots, but I think for Gradius all the bugs ended up having a positive effect on the game, and I think we were extremely lucky in that regard. Although its definitely true that those were the boom days of “secret tricks” on the Famicom, from the developer’s perspective we’d rather not have had those bugs. But in the case of Gradius, we were lucky in that the players supported us, so those mistakes weren’t fatal. .
Our offices were in Osaka during the Gradius development, and after we released the first game a young kid of about elementary school age brought us 200000 yen and asked us to sell him Gradius. Since this was a large amount of money even to us, we called his parents to confirm, and they asked us to sell it to him, so we did. That we had a fan like this made me extremely happy.
Bonus! 1993 Nagata Akihiko – Konami STG Interview Excerpt
(non-gradius portions excised)
Around the time of the first Gradius, the concept of “power ups” in STGs had not yet been clearly defined. Games had systems where the weapons you started with stayed with you from beginning to end. But we thought that was boring. We thought that it might be interesting to add some kind of bonus items.
At that time, Western computer RPGs were coming into Japan, and “building your character” was a kind of new gaming buzzword. We were thinking of ways to bring that concept into the STG genre. Nowadays it seems rather obvious, but back then it was a combination no one had thought of yet. We also wanted to add other “adventure” aspects to Gradius. We planned a system where once you cleared a stage, you’d have a branching choice of where to go next. But in the end, due to memory space limitations, we couldn’t add that feature.
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!
According to a knowledgeable source, this limitation may have been because the bubble memory required the “bubbles” to be electrically pushed along inside the memory. It’s too slow to read a lot of data from one part, then go read another, and come back. The programming knowhow required to work around this may also have been lacking, as it was this particular team’s first game.↩