|
|
|
|
|
|
From Pokemon to the Demoscene |
|
|
|
by Breakpoint of Brainstorm
|
Unlike most sceners, I "entered" the demoscene coming from a background working in the game industry -- rather than the other way around, where it seems sceners are always looking to get into the game industry. I use the word "entered" rather lightly, since I really became interested in the demoscene back in 1993, when I first saw Unreal by Future Crew released at Assembly '93. However, I've only really watched the scene from afar, and never released any prods of my own -- until recently, that is.
Breakpoint on Programming
I've always been a person who enjoys programming as close to the hardware as possible. Back in the DOS days, I enjoyed tweaking VGA registers, writing a fixed point math library completely in x86 assembly, making my own small 386 protected mode extender, and doing simple software 3D rendering, but I never wrote the "glue" to put it all together and make it actually do something interesting. This changed when I got interested into emulation, and started writing Project UnReality, a N64 emulator.
My first goal with Project UnReality was to emulate the CPU, then work on the hacking the opcodes for the graphic and sound processors. Since everything about the N64 was proprietary, all I had was some sparse information on the Internet and my trusty V64. After many months of hard work and lots of trial-and-error, Project UnReality was finally able to display the graphics from most N64 demos at that time, and even one commercial game: Mortal Kombat.
It was at this time that I was contacted by a game company, asking if I would be interested in doing 3D engine work. Although development of Project UnReality had to be stopped (for obvious reasons to avoid legal issues with Nintendo), my dream of working at a game company had finally been achieved.
I really enjoyed my work at the company I worked for. My first title was "Space Invaders", where we paired together with Namco to do a next-gen version. I primarily worked on the PSX side, and having opcodes to do vector and matrix math was serious fun for the low-level person like me.
However, I felt that I still needed to achieve something greater, so I set my sights on Japan (being the American that I am). By a sheer chance of luck, I found a company who wanted a PS2 engine developer, and they were willing to hire me even though I had very limited knowledge of Japanese. Nonetheless, most programmers at that company were actually foreigners: people from England, Canada, and Sweden. But what I didn't expect was that this is actually very typical in Japan -- even today.
After doing PS2 work for a couple of years (I loved doing VU assembly), I read in an issue of Famitsu that Nintendo had established a child company in Tokyo to develop the next-gen Pokemon titles on GameCube. I sent off my resume, had an interview, did a test, and got the job.
Since Pokemon was Nintendo's big seller, I had the opportunity to work on a team with about 50+ people. There were about 10 programmers, 20 graphic artists, and the rest were mostly script developers. However, there was one thing that I finally realized: most Japanese programmers are not very good programmers.
Breakpoint on Programmers
Most Japanese programmers who are interested in developing games usually go to a school to learn how to program, probably much like DigiPen in the US. There is nothing really wrong with this, but most Japanese programmers lack the creativity to "poke-and-learn". They learn what they are taught, and they use those skills to their fullest, but most do not really ever try to learn something on their own. Nowadays, most Japanese programmers would know how to use OpenGL or DirectX, but if you asked them how they would render polygons without either API, and to do the rasterization themselves, they wouldn't know where to begin. The same thing applies with realtime mixing of sound data -- ask them how to play multiple sounds simultaneously, and they'll say "use DirectSound", but ask how DirectSound actually does the mixing and they don't really have any idea. All they know is how to use the APIs, and there is very little interest in learning how the APIs actually work internally.
I once explained S3TC texture compression to one of my friends (one of the better Japanese programmers that I know), and while he understood what I explained to him, he said he'd probably never need to know the details involved, because he just uses the API functions provided to him. Some of the other Japanese programmers I have worked with tend to suffer from "copy/paste syndrome", where they write code by copying someone else's code (usually an example provided by an engine programmer) and just change a few parameters to get the desired effect. They have a general idea of what blocks of code do, but usually do not understand in detail what any particular function does.
This is probably why most game companies in Japan have foreigners as engine programmers, and employ Japanese for the game/logic code. Programmers who write code using "copy/paste" are fine in a non-performance critical area such as game logic, but are completely unacceptable when doing engine development.
However, twenty years ago, Japan had the only game programmers. Now, it seems they're slowly being replaced by foreigners who have the motivation and creativity to learn on their own. What happened?
After talking this subject over with some of my friends, the general consensus is that programming, in general, is viewed as being very difficult. The amount of resources and manpower required to develop a successful game in the industry now is many times higher than it was back in the days of the Famicom or Super Famicom, where a small team of five to ten programmers could make a game within a span of about a half a year. It seems this difficulty factor puts off many Japanese people who would probably make decent programmers.
I also believe that this is why there is not much of a scene in Japan. There are plenty of great graphic artists, but the programmers who have the ability to actually write a demo are few, and those who actually finish writing the demo are even fewer. This is fairly noticeable when looking at the applications of programmers who have graduated from a game development school and apply to a game company as part of their curriculum. While it is easy to pass off most demos as being fairly simple, one of the main things we look for is originality. Usually the originality we see is from a game idea perspective, and if the person is hired, he/she is most likely given a position doing game logic code, not engine development. It is only those demos with technical originality that usually get an engine development position, and these demos are very rare.
Return to the Demoscene
Recently my interest in the scene began again, and I met up with Axel/BRS. I helped him out with hacking the data out of some old Amiga .adf files, and he asked me if I wanted to join. At first, I was a bit reluctant since I didn't have much of an engine at the time, but when Breakpoint '07 rolled around, I had a 96k game ready. Even though it was a bit of a rush job and I didn't expect it to do very well, I also didn't expect it to come in last place. While the rendering engine was certainly not the best, the game flow and logic was designed based on my experience of programming games from the last 10 years.
After seeing what game (if one could even call it a game) won the 96k compo, I watched the comments on pouet, and learned that the demosceners who play games (at least 96k games) are different than the majority of gamers who would buy a game and play it on a system other than a PC. Since the 96k game I did for Breakpoint '07 was my first production, I consider it a learning experience, and plan to make a comeback for next year.
Go back to articlelist |
|
|
|
