beginnings at square
In elementary school I learned to play Piano, and in middle school folk guitar. In high school my dream was to be a musician. At that time I didn’t like video games at all, and never touched them.
So then I found myself, this guy who hated video games, enrolled in classes at the Electrical and Computer Science Department of my college. I started playing the adventure games Wizardry and Ultima on the Apple II computers, just casually at first, but before I knew it they had ensnared me. I had editor tools for Ultima that allowed me to remove and alter the save data. I could give myself as much money as I wanted, and as I fiddled with this and other variables I gradually came to understand the structure of the program. I thought, “I could this myself.” And that was how I started making games. My first games were adventure games written in BASIC.
Then one day I was looking through a part-time job magazine, and I saw that Square, a new company, was taking applications. I could program BASIC, and I figured I couldn’t cut it in a top-class company, but maybe something like this would work out. (laughs) And I applied.
My very first game plan didn’t make it, but later I made software for the 98, 88, 7, and 77 computers. In the beginning I was just intending this to be a part time job so I could save some money.
a team endeavor
Games like Tetris and Sim City were made by a single programmer. However, with recent RPGs, its important to have both team power and individual abilities. I did basketball in middle school, and with regard to experienced and less experienced players, the philosophy was “each man’s time will come to do what he must do.” The Final Fantasy team also had the feel of a sports team. Making a game is a marathon that takes over a year, and even if one person is fired up and ready to go, if you aren’t coordinated with others you won’t produce a good game. It takes a large variety of talents to make a game, after all: graphics, sound, and more.
I also want to say this. When I had colleagues who would come in at 1 or 2 in the afternoon, I’d tell them the following: “Be here by 11AM! Don’t leave before 10PM! Come in on Saturday! Come in on Sunday! If you’ve got the free time to think about dates or movies you can think of events for the game!” I rapped my knuckles on their desk with each admonition, and after that we’d end up making our deadlines. (laughs)
When new people joined the Final Fantasy team I’d tell them “we’re all aiming for Koushien here.” That passion and power would find its way into the game.
design plans not included
I also never wrote game design plans out. With such plans, you’d write something out and it would sound interesting, but when you’d turn it into a game it would turn out to be not that fun. Design plans are written on paper, but games take place on a tv screen, not a piece of paper. It has to be interesting on the screen. I always say “If you’ve got the time to write a spec sheet on your idea, you should program it and put it on the screen instead.”
I use a Macintosh to make the tools we use at Squaresoft, and I also use it when making SFC games. Our team is also connected on the local network, and we pass ideas around via e-mail. This way when one person has an idea, it can be shared with everyone.
In Final Fantasy IV we use the SFC mode 7 scaling on the world map, but that actually wasn’t something we initially planned. But along the way someone said “hey, if this is an SFC game, we need to add mode 7!” At first, we used very simple scaling. But one day, one of our programmers, influenced perhaps by racing games, made the screen look like it was collapsing or falling inwards. When we saw it everyone went “Wow, that looks great” and it took the shape you see today. And my point is that there was no design or plan sheet for that. Everyone understood it when they saw it on the screen rather than written on a page. I think that kind of an environment is important for making games.
I don’t make general planning documents either. 1 About 6 months before a game is due for completion, we have a sales announcement meeting, and at that time we hurriedly put something together that resembles a planning document. (laughs)
to aspiring developers
I really enjoy smashing older ways of doing things. For example, if the story and setting have previously been done by one person, then this time I’ll try letting 3 people create the story. Or I’ll take a position we’ve had for awhile and assign it somewhere else, and create a new position. Creating games, after all, is still a developing field. If you change the way things are made, or the roles to which people are assigned, then you should end up with a different final product, too.
When people come to me saying they want to make games, I ask them this: “Why haven’t you completed a game on your own yet?” If you can forgo buying 10 games, then you can afford to buy a computer. If you want to express your ideas in a programming language, you should learn C or BASIC. Programming is the most fundamental level of game making, after all.
Those who want to write stories for games shouldn’t just write a few scenarios and call it a day. That won’t be helpful. As practice, game writers should try their hand at every part of game creation: design, screen layout, pixel art, programming… if you don’t have at least a passing understanding of these things, you won’t produce an interesting game.
And remember, its important not to be bound by the hardware limitations of this generation, but to dream of what the next thing could be.