WE DISCUSS VANA’DIEL
#6 Akitoshi Kawazu Part 2

Mr. Kawazu, what were your thoughts when you heard the eleventh game in the FF series would be tackling the MMORPG genre?

There were already games like Ultima Online* and EverQuest*, so there was a common awareness in the company like, “We have to try our hand at MMORPGs too.” I also felt that we should go all out if we were going to make one, and it was just a question of what kind of online game it would be.

Did you have any ambitions to create an online game yourself?

I don’t think so, since I personally don’t really like online games.

Why’s that?

I just couldn’t get used to the feeling of time constraints... I particularly disliked having to coordinate times with other people.

Did you feel like that back when you actually tried playing online games?

I played the bare minimum but still felt they just weren’t for me. The fact that there were loads of other players already made me feel like I didn’t want to be there. I don’t really like crowds to begin with. (laughs wryly)

That’s understandable, some of us do feel reluctant to play games that involve interacting with other players.

There’s also how MMORPGs have some players who enjoy PvP*, while there are others who don’t. I’m personally okay with PvP elements, but having both groups of people in the same game didn’t feel quite right to me. It’s a game after all, so I think it should pick a side. Claiming “Either way is fine!” feels like dodging the subject, which I’m not fond of, and I feel doing so makes a game less interesting.

So you didn’t feel comfortable with the freedom that allowed players of both extremes to co-exist.

Of course, online games are a technical feat that should be challenged, and I understand they have their own unique enjoyability. Even from a design perspective, it looks like it’d be fun to consider. But if I were asked to make one, I’d refuse. Even if I did make one, I’d probably make something you could play alone without forming a party. (laughs)

FFXI must’ve been a monumental project, considering it was spearheaded by staff members like Mr. Tanaka* and Mr. Ishii* who worked on the original FF, but how did you feel about that sort of team composition?

During FFVII’s development, essentially every team aside from the SaGa team was working on it with Mr. Sakaguchi* at the helm. It was like that with FFXI too, where everyone aside from my team was working on either PlayOnline or FFXI. That sort of “all hands on deck” type of development is what I considered “Sakaguchi-ism,” but I’m not included in there.

I’m the type of person who starts by considering what an online game would have to have, which is fundamentally different from Mr. Sakaguchi's way of thinking. His way was more, “I’m going to create whatever I want!” and I would’ve responded, “It’s not about what you want to make, Mr. Sakaguchi, online games have to be a created a certain way!” so I imagine he didn't want to go through that. (laughs)

I see, so you would’ve been in a position to reason with him pragmatically, in some ways.

By the way, Mr. Tanaka mentioned he agreed to make an online game purely because it seemed like fun.

No, no. At first, Mr. Tanaka was also like, “Online games? Are you sure?” (laughs) In response, Mr. Sakaguchi recommended everyone to set up internet at home and give EverQuest a try, and in the end, even Mr. Tanaka became absorbed in it.

Mr. Tanaka was really engrossed in EverQuest, wasn’t he? (laughs)

How did you feel about the immense development cost required in creating an MMORPG?

It’s not only the cost that’s troublesome, but the operations as well. Aside from technical problems, there’s also all kinds of issues that can arise from communication between people, which was an area where Square lacked experience and knowledge in at the time.

On top of that, the PlayOnline project seemed never-ending as its finish line kept moving further and further, so I wanted to stay away from it. (laughs wryly) It wasn’t something where I could just work on it and be like, “The project’s finished, that’s it for me.”

It’d be nice and clean if we could just say, “I did what I was supposed to do, I’ll leave the rest up to you,” and move on. With FFXI, there’s always been a mountain of unfinished tasks we had to do, and before I knew it, I’d been working on the game for almost 20 years.

What did you think when you saw the completed version of FFXI?

When Square started working on an MMORPG, I had mixed feelings like, “I’m sure they can make it, but will it really turn out okay?” Not to mention that they were working on a Windows version in addition to the PlayStation 2 (PS2) version, which must’ve been quite the technical hurdle. After all, internet connections were far worse back then compared to what we have today. There probably were all sorts of other difficulties too, like the processing power of the servers. But everyone in the FFXI team overcame those hurdles together, and I watched in awe as their game gradually took form.

Mr. Tanaka mentioned that the Business team members assigned to the project flew all over Japan for network-related matters.

I was particularly impressed by how the designers created the game’s graphics.

The trend at the time was a shift towards realism, which was slightly different from how 3D models were designed up until then. During the PS2 era, texture designers also handled character modeling, and they used clever techniques to make characters look beautiful even with limited polygon counts. To exaggerate, these techniques were capable of making blocky polygon models look round. It’s gradually becoming a lost art, since you can just make round 3D models nowadays.

Because FFXI was created back when everyone had those kinds of masterful techniques, the game’s 3D models look amazing even today.

Although the transition from the PS to the PS2 meant better hardware, it didn’t necessarily allow us to go all out with polygon counts. Since we were making an MMORPG, we wanted to display as many characters as possible, and we could never predict what player characters might be wearing, we had to ask the designers to limit memory usage as much as they could. Textures take up a lot of memory, so we really had to ask them to somehow make ends meet, and I’m sure it caused them a lot of headaches.

Their ability to give things a three-dimensional appearance with shaded textures is truly phenomenal, even when we look at it today.

They were certainly very skilled. Nowadays, lighting is baked* in real time. It’s not like baking wasn’t a thing back then, but the two methods are a little different in terms of technique.

Nowadays, since lighting and other graphical elements are manipulated in real time, drawing the shadows directly into the textures may be detrimental. Is shading the textures directly now a thing of the past?

Real-time processing is preferred when there’s enough memory to work with, but it tends to weaken the movement. Choosing which technique to use is something you decide based on what you want to convey, as well as limitations of the hardware.

Mr. Kawazu, what were you up to when FFXI was released in 2002?

While everyone was working their hardest on PlayOnline, I was doing something completely different. I think I was creating games for the WonderSwan*.

Mr. Kawazu made Wild Card*, which was a masterpiece. Didn’t you make it with a really small team?

Aside from the designers, I think we had three members in the development team, including myself.

That’s astounding. I imagine that was an unusually small team, even back then.

It might’ve worked for us since we were developing for the WonderSwan, but a team of that size was pretty rare.

So while the rest of the company was working on FFXI, you were quietly developing games you wanted to make.

Our company was also looking into i-mode* and was visiting DoCoMo right before i-appli was launched. We’d already decided to make a cellphone RPG, but we consulted them on how to provide it and I remember them advising us, “Wouldn’t it be better to use PHS* instead, considering the amount of data required for this?” I remember also agonizing over how high I should set the price, and whether users would really be willing to purchase the game at those prices.

It’s interesting how you were working in a completely different direction despite being in the same company.

I can’t necessarily claim it’s the right way, but back then, Square had an air of developing games and forming teams based on individuals. There were also variations based on the teams and the people joining them, like the Kawazu team could be one way while the Ishii team was another, and I think in the end, it turned out to be the most effective way of assigning members to teams.

I’m sure there were preferences on what games to work on and compatible member personalities. Did each team within Square have a distinctly unique style of conduct?

I’d say that it wasn’t like the teams consciously chose to work differently, but passively adopted a certain style. Since each one had different core values, it was only natural that the teams ended up with their own unique styles.

Back when we had fewer employees, there was something like “the Square way of doing things,” and those would get passed down at a bare minimum from programmer to programmer, and from game planner to game planner.

But as Square gradually grew larger, it became harder to maintain the same style of conduct across the entire company. As a result, after we were split into teams, each one slowly developed their own different styles. After that, it became difficult for members to rejoin with other teams because they operate in completely different ways. Most projects don’t require multiple departments, and each team writes their project proposals in different ways. Even programming conventions also vary wildly, so the practice of sharing the same style itself has become difficult too.

Sounds like things have changed from back when you all worked on the same office floor.

An example of programming conventions would be including the programmer's name and the date the file was first created at the top of the code. Some teams have those kinds of orderly conventions, whereas others don’t have any rules at all. That’s how different they are from each other, and so there always ends up being a cultural difference between different teams.

What's your personal preference when it comes to having those kinds of rules in place?

I’m quite forgetful, so it helps when the code is tidy and easy to read. It’s convenient to have a specified format to follow.

There’s also cases where the leader’s personality influences the entire team.

Are there any rules that have stuck around since the days of the “Kawazu team”?

I personally don’t think we have anything that’s clearly defined. Sure, things would be easier if we did, but the easy way isn’t always the best way. Personally, I just do things in way that works for me, but that doesn’t mean it always works for everyone else. So sometimes I do think it might be better for the other members to follow a little more standardized method. There’s always a reason why something is considered “standard,” and it’d be logical to follow that.

On a different topic, I have the impression that you have a logical method when it comes to creating battle and other systems. On the other hand, what do you do when coming up with a story?

I don’t work on stories often, but in the past, I’d brainstorm a scenario and how it’d progress based on triggers, then start by designing the triggers. For SaGa II: Hihou Densetsu*, I just added a simple script to all that and asked Mr. Tanaka to handle the rest of the implementation.

Nowadays I write the whole scenario from start to finish, so my methods have gotten pretty wacky. I kind of just wait for characters to “move the story forward on their own,” so to speak.

I see, so you’re not really writing the plot on its own anymore.

With that said, it’s actually not a great way to do things, since I have to wait for the characters to move the story forward.

In that case, do you simultaneously work on the script and triggers, instead of just planning the script by itself first?

That’s right. Due to the technical nature of games, anything that can’t be written into the game as a trigger can’t be experienced by the players as part of the game. Otherwise games would be no different from just reading a story, in which case they couldn’t compete with other storytelling mediums like novels, comics, or movies. The good part about games is how players can experience them for themselves, and when it comes to game elements that players can control to have a certain outcome, I try to make them interesting or feel good.

That reminds me of something that surprised me when I joined the SaGa team.

Up until then, I’d thought of triggers as just 0s and 1s. However, the SaGa team had triggers that ranged between 0 and 15, which they used like, a character would appear in City A if a certain trigger was set to 2 through 4, but would appear in City B if it was set to any other value.

Having the same character show up in multiple different locations at once is embarrassing. But using triggers like this can keep things very orderly, though I did think it must’ve been a rough time for whoever designed it.

Ah, that was Mr. Adachi’s* idea. For instance, when you want to manage a trigger with four bits that are individually turned on or off, you can only create four states: 0001, 0010, 0100, 1000. But if you treat them as the binary number “0000,” then you can create 16 different states. This allows us to organize chronological events in an intuitive manner using very little memory, so we’ve been employing this method ever since.

I see, you’d still need 16 bits if each event was independent, but if they’re supposed to occur one after another, the events can be bundled together and managed with less space, and only a few bits would be necessary to handle large values.

Those are the kind of discoveries I learned about when I went to the SaGa team, and it was really enlightening. I gained all sorts of techniques that came in handy in my next project, so I was really grateful.

But managing triggers like that would mean keeping track of the player’s current state from the start of the game to the end, which means you’d have to design everything based on the game as whole. Wouldn’t that be really hard on the game planners?

I don’t think it’s too bad once you get used to it. Anything that the programmers can’t code can’t be added to the game to begin with, so it all comes down to your ability to convey your ideas to the programmers and have them formulate your ideas into code. That brings us back to what I mentioned before about, “You don’t need to understand why, just do as I ask.” (laughs)

Mr. Matsui, you seem like the type that enjoys learning about these kinds of new techniques and ideas.

That’s true.

Regarding what Mr. Kawazu just explained, you could design using 16 bits for greater flexibility, but I think in the end, you’d end up having to cut out certain parts of the game to make it 4-bit anyway. But this method requires envisioning the entire game from the beginning and deciding what elements to keep or discard, and I was always in awe while I worked with them.

Because of the limited amount of memory available back then, we inevitably had to start from “What will we use these 4 bits for this time?” Using them in the same way each time would only lead to the same results as before, so if you wanted to create something with a different kind of enjoyability, you had to completely overturn how those 4 bits were used.

On the other hand, you can do just about anything nowadays, so you first have to consciously decide what you’re going to make. I believe that’s made game design more difficult. After all, if you ignore development costs, anything and everything you decide to do can all be added to your game.