Hi, “Critical Kate” Willaert here! I commissioned the following translation for my video on the origins of Mario, and I’d like to give a big thanks to everyone who donated to make this happen, as well as to the folks at Hit Save and Gaming Alexandria for helping to organize the fundraiser, and of course to Alex at Shmuplations for doing the translation.
I’d also like to acknowledge the people who came across this article before I did: Japanese game historian ぜくう, who tweeted about the article in 2016; Tweakbod in the Gaming Alexandria Discord, who made me aware of it; and French game historian Florent Gorges, who discovered the article even earlier and briefly summarized it in the second issue of Pix’n Love magazine in 2007.
Arcade Game Technology
Donkey Kong: A Record of Struggle
By Hirohisa Komanome
Donkey Kong is an arcade game released by Nintendo in 1981. It was a huge success, shipping over 85,000 units. The Famicom port is also famous as the game which propelled that console to stratospheric heights. Donkey Kong was subsequently made into a franchise series, and it continues to this day as Super Donkey Kong (US: Donkey Kong Country) on the Super Famicom. Donkey Kong also bears the distinction of having given birth to Mario, Nintendo's flagship mascot character who appears in the launch title of their newest console, the Nintendo 64.
Although Donkey Kong was the game that led to Nintendo's big breakthrough in the arcade and home video game markets, it was originally developed to liquidate Nintendo's excess PCB stock. For the programming, Nintendo reached out to Ikegami Tsushinki; I was put in charge along with three other people who had joined Ikegami at the same time as me.
The Donkey Kong development was my first major job since joining the company. It was a very memorable job for me, for it provided me with a wealth of experience and influenced my later work in no small measure.
It was my co-author Miyazawa (currently employed by Namco) who suggested that I write this account of the Donkey Kong development, so I have included it here as an extra chapter of this Arcade Technology series.
Although it was 15 years ago and my memory has faded, some of the development documents from that time still remain, and I will be referring to them as I look back on the project. The subtitle I've chosen for this chapter, "a record of struggle", was actually taken from the title of a contribution to the company newsletter written by the four software engineers (myself included) who worked on the program at the time.
The Donkey Kong development began as a means of clearing out the extra printed circuit board (PCB) inventory of Radar Scope (1980/Nintendo), an arcade game which Nintendo had subcontracted Ikegami to develop.
From our perspective as the programmers, the Donkey Kong project began rather abruptly. On April 6, 1981, then-manager Mr. Masayo Oka instructed Minoru Iinuma, Mitsuhiro Nishida (currently president of MediaWave), Yasuhiro Murata (currently employed by Sony), and myself to stop what we were working on and assemble together in the meeting room, where we were ordered to begin this new project. He explained that the purpose of this development was to use up the large amount of leftover PCB inventory and create a new game that made the most of the hardware capabilities. He then made a copy of the game plans Nintendo had sent over and handed them to us.
The plans consisted of three A4-size sheets briefly explaining the game's content and characters, about five game screen sketches, and a one-sheet diagram of the final animation. The documents were stamped with a seal dated "55.3.30" (3/30/1980) by Nintendo's creative section chief Shigeru Miyamoto. At this point, no one dreamed that a mere three months later, Miyamoto's game idea would become the smash hit Donkey Kong.
However, Miyamoto's ideas were not immediately greenlit. At this initial meeting we considered various issues: could Miyamoto's ideas actually be realized on this hardware? Was it a suitable idea for a game? In order to answer these questions, we were instructed to identify any problems with his plans and to consider other game ideas as well.
A rough schedule was also decided at this point: the development was to be completed in mid-June… giving us only two and a half months! In other words, the due date was our summer vacation. The four of us had only been with the company for one year, and we had no idea how demanding this schedule would be. On the contrary, we were very excited about this job--the first we had been entrusted with since joining Ikegami. The next three months (the development went about a half month over schedule) would prove to be an incredible challenge for all four of us.
Miyamoto's game proposal was at that time called "Popeye's Beer Barrel Attack Game." The sketch showed the character of Popeye as the player and Olive as the girl, just as the name implied. With Popeye and Olive, you would naturally expect the antagonist to be Bluto. However, the mock-up sketch featured Kong (a gorilla). Being close in shape to a human, a gorilla had been chosen to make it more interesting and add a humorous touch.
Later, Miyamoto would change the Popeye character into the famous Mario we all know and love. I remember that it was hard to faithfully represent Popeye's character due to the small size of the sprite (16 x 16 dots), and there were also copyright issues.
"Popeye's Beer Barrel Attack Game" was set in a construction site of a steel-framed building. Kong has snatched Olive and climbed to the top of the girders, and Popeye has to rescue her by climbing the ladders and dodging the barrels Kong throws down at him. In addition to the barrels, other characters such as the "ojama-mushi" ("Bother Bug", localized as "Fireball" in English) try to stop Popeye.
Our first impression of this game proposal was that it was "like Crazy Climber and Pac-Man added together and divided by two." Dodging barrels while ascending the steel girders was similar to the gameplay of Crazy Climber, where you climb the front of a building while dodging falling obstacles; likewise, the way the ojama-mushi blocked your path reminded us of Pac-Man.
In any event, the four of us worked together to identify the potential problems with Miyamoto's proposal (assuming it was made exactly as he described it in the documents). The issues we identified then were:
1. Movement of the obstacles is monotonous.
The barrels simply roll.
2. Complexity of the controls (ergonomics of the joystick controls)
Initially, Miyamoto imagined you would clear the stage by lifting up the topmost steel girder with a jack, causing the barrels to flow backward towards Kong, effectively making him destroy himself. However, this idea would have required a special joystick to implement, and we were worried this would be too complicated and confusing for players.
3. Uninteresting stage design
The stages have no individuality. Each stage needs to be unique enough that you could describe it in a sentence or two, such that someone who has never played it before could easily understand it. There's an opportunity here with the stages to do something that really catches people's attention.
4. Comicality
If this is to be a "character game", the characters themselves need to appear lively, animated, and funny.
5. Varying up the Stage Design (screen composition)
It's very important that players feel excitement: "what's coming next?!" ... "I wonder what the last stage will look like." More distinctive stage design (screen composition) is needed.
6. Timers and Urgency
Since this is an arcade game, we've got to find ways to increase the income it brings. In order to let players feel like they've had a satisfying experience within a short playtime, we should use time limits to impart a sense of urgency and pressure.
7. Storyline
The game is about the player trying to rescue a girl kidnapped by Kong, so we should make sure the presentation emphasizes this storyline.
8. Sense of Speed
Same as the Timers and Urgency above.
9. Uninspiring; "no dream"
The setting is a construction site, which brings to mind laborers--there's no sense of beauty which inspires you to dream about the future.
10. No centerpiece feature
If we don't include some kind of unique, eye-catching feature that other games don't have, it'll be seen as an imitator. Accordingly, we need an idea that breaks free from the preconceived notions found in other games.
11. No Stage Select
A game needs to be intellectually stimulating. Considering that the later stages won't vary much in their stage design [composition], in order to make the game deeper we should have a stage select.
...the above 11 problems needed to be addressed as much as possible in order to make the game more appealing. Even then, that didn't mean the game would necessarily be a hit. Such are the challenges of game design.
In addition to identifying these problems, we also considered other new game ideas. The four of us, led mainly by Iinuma, came up with 13 brand new game ideas which we each considered in turn. I can't list them all here, but some of the major ones were a "Jack and the Beanstalk Game" based on the children's fairy tale; a "Fishing Game" for hobbyists; "Space Shuttle" (a space station construction game), which was a hot topic in newspapers at the time, and "Save the Patient! A Micro-Battle within the Human Body" based on a story from a movie.
In the end, after identifying the issues listed above, we were inclined to work on improving Miyamoto's original Popeye Beer Barrel Attack idea.
As we worked to turn Miyamoto's plans into a real game, we attempted to solve the eleven issues above. In this section, I'll discuss three of them.
(1) A Centerpiece Feature: The Jump
The first idea we hit upon was something that, at the time, was not common in video games: the jump. In the first draft game plans, when a barrel rolled down, the player had to climb up to a nearby escape ladder (a short ladder with a break in the middle) and wait for the barrel to pass by. At the top of the escape ladder you could grab a hammer and smash the barrels. However, it was pointed out that this was basically a "running away game", which was stressful. To solve this problem, the idea was put forth to let the player jump over the barrels.
I remember that there were few games back then that incorporated jumping as a basic movement of the player. We therefore considered this unique jumping movement as the "centerpiece" of this game. Being the main attraction, we wanted the jumping to feel more realistic. So we decided to use actual physics to realistically calculate the trajectory and arc of the jump.
Unfortunately, video game PCB hardware back then used the z80 chip for the CPU, which did not have floating-point arithmetic instructions. Although integer multiplication instructions were available, they couldn't be used because they took too much processing time. We thus had to use second-order derivatives, which required only bit shift and addition calculations. Mr. Nishida created the program and adjusted the parameters. The following is a brief description of the calculations.
First, recall the equation of a parabola: since the speed along the x-axis is constant, the following equation is obtained by considering only the y-axis.
S(t)=v₀t-½gt²
(S: position of object, v₀: initial velocity, g: acceleration of gravity)
We take the first-order difference of this equation (the difference is taken because it is a discrete value).
S(t+1)-S(t)=v₀(t+1)-½g(t+1)²
-v₀-gt-½g
=v₀-gt-½g
Then, we take the second-order difference, which becomes:
S(t + 2 )-2S(t+1)+S(t)=-g
From the above, the y-coordinate value S(t) of an object on a given screen frame (the game screen updates every 1/60th of a second) is:
S(0)=0 (reference position)
S(1)=v₀-½g (initial velocity)
S(t+2)=2S(t+1)-S(t)-g
Thus, the value of the previous screen frame (t+1) is added twice, the value of the screen frame before that one (t) is subtracted, and the constant g is subtracted.
If S(t) were precisely computed for each screen frame, it would require three multiplications, but by taking the second-order difference, the computation can be done with one bit shift and two additions. This calculation is used all over the place, including the trajectory of Mario's jump and the way a barrel bounces as it rolls off the steel girders. It's what makes Donkey Kong such a richly expressive game.
(2) Complexity of the controls (ergonomics of the joystick controls)
Many shooting games in those days used a basic control scheme of "joystick (up, down, left, right) + multiple buttons". I remember that most of them had two buttons rather than one.
In Western games, it was common to see more buttons, and some games even required four. Many had over-complicated controls where you had to read the instructions in order to play the game. Although these games were popular among certain enthusiasts, we rarely hear of them achieving wider popularity.
In contrast, Pac-Man, which was a big hit at the time, had only one joystick and was exceedingly simple to play. Moreover, since shooting games were the mainstream back then, I remember that Pac-Man was the only game that women and small children could enjoy. We on the development team took note of Pac-Man's simple controls, and we also wanted our game to have easy controls with a single joystick. Our thoughts about the appeal of the Pac-Man controls could be summarized as follows:
(1) It uses a single joystick (simple and clear).
(2) The function of the joystick is simultaneously for movement, offensive actions, and defensive actions (moving is both offensive and defensive)
(3) Girls can also play (expansion of market share)
In the initial plans for Donkey Kong, there were four input actions: moving the player; using a "jack" to beat the level; using a hammer to attack the barrels; and jumping. Having that many actions, however, would have made the controls too complicated.
In order to simplify the controls, we removed the "jack" and made it so the stage would automatically be cleared when the player climbs up to a certain point. We also eliminated the need for a separate hammer input by making it so the hammer would automatically attack for a set period of time when you touched it. We therefore settled on having just a joystick and single jump button, with the following controls:
1) The joystick only controls the player's movement.
2) The push-button only controls the jump.
3) Simultaneously pressing the joystick left or right and the push-button controls the jump direction.
Actually, we considered having the joystick control jumping as well. However, that would have meant that climbing the ladder and jumping would have the same input, so we ultimately decided to add a separate jump button. I remember there was a lot of contention on this point. You may be thinking, "what's the big deal? it's just one button!" But these were the kinds of things that would have a major impact on the way the game played (though looking at today's console systems and their complicated controllers, it probably wouldn't be an issue nowadays).
(3) Varying up the Stage Design (screen composition)
In the initial plans, the first stage would repeat numerous times, and only the final stage had a different layout.
A popular game in those days was Scramble, a shooting game by Konami. The way the stage scenery unfolded, as the screen scrolled left to right, was very fresh for its time. As I wrote above about the importance of having that "what's next?!" excitement factor, this aspect of Scramble piqued the player's interest and created a buzz around the game.
For Donkey Kong, therefore, instead of just monotonously repeating the first stage, we decided that we needed unique stages. We made a list of the various equipment and items that exist at construction sites, and thought about how we could use those elements as part of the stage design. We also wanted the stages to be designed in such a way that would make good use of the jump action.
As a result of these considerations, we decided to have a 4-stage loop: this would also coincide with and convey a clearer sense of story development, in the classic kishōtenketsu style. We then decided on certain characteristics for each stage: the first stage would be a barrel dropping game, the second stage a maze game (the conveyor belt stage), the third stage a jumping game (the lift stage), and the fourth stage would be the climax.
After the above determinations were made we held further discussions with Miyamoto about how to make the game more interesting, and then we drew up the actual game planning docs for Donkey Kong--at this point, it had only been 10 days since we started the development.
After that was prepared, at the end of April we began working on the programming flowchart, and by the end of May, we began the actual coding. Then, in early June, we started debugging. After making adjustments in mid-June, ROMs were shipped for the location tests in late June. In July, the ROMS for mass production were shipped. All told, the entire development was completed in just three short months.
Although the above description makes it sound as if the programming proceeded smoothly without any deviations, there were in fact a mountain of changes and additions. Miyamoto also offered up various ideas and points of improvement. The most memorable of these, for me, was a change to the fourth stage. Originally, the stage would end by dropping a bell on Kong's head and knocking him out. Miyamoto had the idea of making it more comical by having all the structural joints in the building be removed so the girders would collapse, and Kong would fall and be knocked out that way.
Ultimately we kept making small changes and additions right up until the game was about to be shipped in July. We crammed in every element that we thought would make the game more interesting, and I remember it being a very challenging exercise in programming. Later, all these changes caused a number of bugs that plagued the programmers to the very end.
Finally, after all these changes and bug fixes, the resulting program did not fit into the initial estimate of 16 KB (a large size for those days), so the next step was to reduce and shorten the program. This inevitably meant removing something from the game, and it was a real headache deciding what to cut. After weathering these many hardships, the program for Donkey Kong was at last completed.
Here, I will briefly discuss the hardware of Donkey Kong. The details of the display mechanism of sprites and background images are described in the first and second articles (bit, Vol. 28, No. 12, Vol. 29, No. 1) of the "Arcade Game Technology" series.
The screen composition of Donkey Kong consists of a composite of two display screens: the sprite layer and the background VRAM layer. Their characteristics are shown in the table below.
The sprite layer is assigned to moving objects such as players, cones, and barrels. The VRAM layer is allocated to objects that can be represented by still images, such as the steel girders in the background, messages such as "1 UP" and "2 UP," and scores. Since the color is fixed per line instead of per pattern, the color representation in VRAM is limited. In Radar Scope, this layer was only used for messages and the score display; they never considered using it for the background.
Back then game boards used a 3 MHz z80 chip as the control CPU, and interrupts were inserted at every 1/60th of a single screen's processing time. This meant that, to animate a character in real time, all screen processing operations had to be performed within 1/60th of a second (16.6ms). From the programming side, the question therefore was how many program instructions could be run within this timeframe. Naturally we used assembler for its speed.
Since the clock speed is 3 MHz, the number of clocks that can be executed in 16.6 ms is approximately 49,800 clocks.
This is the maximum number of clocks to process one screen, including the time required for DMA transfer to set the sprite pattern (3,600 clocks) and the time required for collision detection processing (12,000 clocks: calculated in advance from the number of characters to be detected). The remaining 34,200 clocks are the number of clocks allocated to the game program. At the time, the average number of clocks for a single z80 instruction was considered to be 10 (6~7 clocks for an actual program), so it was necessary to create the program in 3,420 instructions. It was therefore necessary to always keep the number of instructions in mind when writing the program.
When creating game programs in those days, the first requirement was processing speed, the second was capacity (memory), and the third was a program that could run quickly.
Collision detection turned out to be a major problem in programming Donkey Kong. In the past, one only needed to check the collision between moving sprites, but in the case of Donkey Kong, due to the screen composition, it was necessary to check collisions not only between sprites, but also with the steel girders that made up the background. This not only increased the number of targets for collision detection, but also posed a problem with the different address structures of the two screen layers (sprite and VRAM).
The address of the sprite layer was delineated in units of individual pixels, while the address of the VRAM layer was one address of 8 x 8 pixels (32 x 28 for the screen display area). For the purpose of collision detection, comparing addresses used up a lot more time than comparing sprites.
For the sprite collision detection, we must check several sprites against the player sprite: the barrels, the fireball, and others. For comparing the player and the VRAM patterns, we have the player x girders, the barrels x girders, and the fireball x girders. Since all these detections must be performed, when there are lots of sprites on-screen, it puts a large strain on the CPU (which must perform all those checks within 1/60 second). In the beginning, our original code was nearly 50 bytes long, and the processing could not be completed in 1/60 second if there were too many sprites.
After several in-depth examinations of the z80 instruction code table, Murata finally succeeded in reducing the size to 25 bytes and 110 clocks. Being able to process a large number of sprites on-screen allowed us to make Donkey Kong a harder game.
All of this would probably be unthinkable for game developers today. However, in order to process the screen at 1/60 on the 3MHz z80 chips of that era, sometimes a single clock could make all the difference--especially when you considered that additions and changes would be required in the debugging phase. It took extraordinary effort to optimize the code.
Unlike today, back then the software development environment left a lot to be desired. Because computers were very expensive, there was only one computer available for the development, and we used this one machine for everything from punching the program source to debugging on the target machine. Since the four of us shared this machine, each of us had to be efficient with our debugging, and we basically worked in shifts, setting up a schedule of usage time. The normal process was to do "desk debugging" 1 and then check that it works on the actual machine; however, I remember how the programming often wouldn't work the way I thought it would, and I had a hard time adhering to the usage schedule. Nevertheless, Donkey Kong reminded me once again of the importance of being able to perform desk debugging.
The development machine at that time was called "MOSTEC" (I have forgotten the exact name). There was no hard disk, and it had a proprietary OS that used 8-inch floppy disks (I think it was a single-sided, single-density, 128-kilobyte disk). Those floppy disks cost 3,000 yen per disk, and I remember they were difficult to purchase.
I also had a hard time outputting the compiler list.2 At that time, there were no inexpensive printers available, so we used a Casio "Typuter" to output it. The paper we used, therefore, was was not stock form paper but roll paper, which caused many problems such as paper jams and inkjet head malfunctions.
The compiler list printing was done late at night, since the machine was in use during the daytime. When I left the office (it was always close to midnight) I would enter the print command, and the compiler list would be completed around 8:30 a.m. the next day. Each morning, the first thing I did after coming to the office was to cut the list into individual pages. Because it was such a pain to print out, we couldn't make a lot of immediate modifications or corrections to the code. We would patch the program, check its operation, and when the compiler list showed bright red everywhere (meaning it had a lot of bugs/errors), only then would we correct the source and re-print the list. This work went on and on, but as a result, all four of us memorized nearly all of the z80 machine code instructions.
In addition, as anyone who has used an in-circuit emulator has probably experienced at least once, there were several times when the cable of a probe broke or the leg of a probe broke off. I re-soldered them, but ultimately, to prevent them from breaking I had to take more drastic measures, such as attaching a CPU socket to the probe legs and inserting that into the on-board CPU. This was possible because the clock speed at that time was only 3MHz.
The most notorious example of these challenges, though, was the procedure we employed for converting the program to ROM. At that time, the ROM writer machine was shared within the company, so paper tapes (which may not exist today?) were the common interface. It was therefore necessary to convert the binary code to intel hex to pass it to the ROM writer, which we would then record to a paper tape. When I think about it now, I'm amazed we used to do that!
Back then, the only dedicated tool for game development we had was MOSTEC. For other, non-game devices there was a whole different set of development tools, which also contributed to the difficulty. Overall, you couldn't call it a good development environment. I think other companies may have had a slightly better setup than ours.
I should talk a little bit about the pattern ROM here.3 Since the sprites and VRAM characters were displayed by the hardware, we created a dedicated pattern ROM for Donkey Kong. Back then, there were no scanners or painting software available, so the pattern ROM was created entirely by hand. As shown in Figure 2, the original character pattern was converted to 2-bit color data, and each bit plane (planes 1 and 2) was converted to hexadecimal data. This hexadecimal data was then directly input to a ROM writer to create a pattern ROM.
The sprite data consisted of 128 patterns (16 x 16), which is 4 kilobytes. The VRAM had 256 patterns (8 x 8), or 2 kilobytes, for a total of 6 kilobytes of data, which we input manually.
We then inserted the pattern ROM into the game board, displayed them in the center of the screen, and checked the patterns for errors; if we found any mistakes we re-calculated the addresses and fixed them. However, the patterns displayed on the screen were so small that it was difficult to find single-pixel errors. We also kept making mistakes with the hexadecimal calculations which further slowed things down. It was exhausting work. Shigeru Kudo and Kenzo Sekiguchi, who were new to the company at the time, were put in charge of this grueling task. The Donkey Kong pattern ROMs couldn't have been created without the patient effort of those two men.
Such was the challenging environment in which Donkey Kong came to be.
One day during the summer vacation in August, a month after the program development had been completed, we received a report of a bug in Donkey Kong, and the development team was promptly summoned to the office. At the time, I was relaxing in the countryside of Yamagata, and I was surprised at the sudden call.
The bug was that, on the first stage, when a player jumped from the right end of the second steel girder to the right side, the player would fall and the lower body of the player sprite would appear at the top of the screen. Then the first stage would abruptly end as if you had cleared it.
We immediately went to look for the bug, and we fixed it by modifying the limit address of the right screen by one pixel, as I recall. This was one of the cases that made me realize once again that players will always do things that the developers had not initially predicted.
Once we received a telex from an overseas company inquiring about the program of Donkey Kong. Although I do not know the exact contents of the telex because I don't have the documents, I remember that it was a request to modify the program, to change Donkey Kong to their company's brand. While that might seem like an outlandish request, there is a reason why we received such a direct inquiry, which I will relate below.
Unfortunately, back then there was not a legal framework for copyright protection of programs, and bootlegs that changed the game title and company name were rampant. As such, game developers were at pains to find ways to delay the creation of bootlegs after shipment.
After the location tests, it was time to manufacture the official ROMs for mass production, and we laid several traps there. In particular, I remember inserting the word "NINTENDO" everywhere in the source. It was easy to disassemble program ROMs and dump them in ASCII code with the development tools available then. Knowing that the bootleggers would begin their analysis of the hardware by disassembling and dumping the code, we inserted the following message at the end of the program as a joke.
"CONGRATULATION ! IF YOU ANALYSE DIFFICULT THIS PROGRAM WE WOULD TEACH YOU. * TEL…
The company that sent us that telex had read this message, and they contacted us directly. All four of us were surprised. Naturally, we refused the request. But this is a good example of what the game industry was like back then, when bootlegs proliferated freely.
One Donkey Kong bootleg that comes to mind is FALCON's Crazy Kong. I first learned of the existence of Crazy Kong at an amusement show held that year. In those days, bootleg games were shamelessly exhibited at the trade shows.
I remember Crazy Kong as being a cut above your typical bootleg. The game itself was not as good as the original due to the difference in the hardware's sprite display capability, but they'd added a scene to the attract sequence in which Kong escapes from his cage, making the story easier to understand. In the original Donkey Kong, most of our time was spent on developing and debugging the game itself, so we couldn't put much energy into the Attract Mode. All of us involved in the project felt that we had been "beaten" by the bootleggers there.
Although I was involved in the development of Donkey Kong, in truth, I'd had almost no experience with video games before joining Ikegami. I remember that Shigeru Miyamoto at that time had never developed a video game before either. Donkey Kong was therefore a game created by people who were not experts in video games, who pooled their knowledge together. There's a sort of freedom that comes from that inexperience, and it was this, along with a bit of extra "flavor" that we imparted to Donkey Kong which made it break the existing mold of arcade games and become a smash hit.
After developing Donkey Kong, the four of us were asked by Sega to develop a game called Zaxxon, which was in a completely different genre. It was a shooting game with a diagonally-tilted screen that attempted to evoke a 3D perspective. Although Zaxxon was not a hit in Japan, it was a big success in the U.S. and was later ported to various consoles. I remember they even made a full-scale 3D CG commercial for it, which was very costly in those days. Actually, at the time of its development, opinions about Zaxxon were sharply divided at Sega. But it received extremely positive reviews at its location test, and after the issues from the location test were addressed, the game was shipped without incident.
From the beginning, Zaxxon was developed for enthusiasts. At that time, 3D games mainly used wire-frame line drawings. That made color expression difficult, and characters were a combination of simple geometric shapes, which only appealed to certain enthusiasts.
Game companies certainly wanted to create games with full-fledged 3D graphics, but the hardware technology and cost made it prohibitive. One idea that emerged that could be easily realized with the current hardware and had never been used in games before, was employing an isometric perspective to give the graphics the illusion of depth. This was a novel idea at the time.
We also added shadows to increase the 3D effect. When you move behind or above objects on the ground, the shadows are depicted realistically, lending a special appeal to the game. Our efforts were well-received by the game market of the time, and Zaxxon became a big hit.
Today, we are living in the age of the console game craze. Major consumer electronics companies have entered the console market, and it is said that more than 500 software developers are competing with each other to develop games.
Currently, the home video game industry is said to be worth 700 billion yen in the Japanese market and 8 billion dollars in the U.S. market, and has become a big global business. Game software itself has become huge, and developments today employ a division-of-labor system to manage their scope, with teams of more than 10 people and games that take over a year to develop. For those of us who worked nearly 15 years ago, developing simple arcade games in small teams, it's an almost unrecognizable landscape.
In particular, the hardware technology has advanced dramatically. I hear that arcade PCB hardware is now being used in home consoles, and what's more, the latest home console, the Nintendo 64, has the same capabilities as Silicon Graphics' high-end graphic workstation of seven years ago… and it can be had for as little as ¥20,000! Such technological advances in game hardware is nothing short of astonishing. Though I admit that, as an engineer, I also feel a sense of sadness that such a powerful machine is used only for games.
In closing, I hope this essay gives readers a small glimpse into the painstaking efforts and attention to detail of the developers then, over 15 years ago, and that it helps readers appreciate our contribution to making video games more fun and interesting.
(Hirohisa Komanome,
Ikegami Tsushinki Co.)
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!
from Hacker News https://ift.tt/J10Vp5a
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.