GAME DESIGN QUOTES

Andy Gavin & Jason Rubin

* Our motto was "bite off more than we could chew, then figure out some crazy complicated way to make it work."

* Internal criticism is essential, and as a programmer who wrote dozens of world class control schemes in the years between 1994 and 2004, I rewrote every one at least five or six times. Iteration is king.

* The F[un] word is the most important concept in making games. Too many forget this.

* A good designer has to both dread and seeks out other people's advice, especially those most likely to hate the work he has done. And the designer has to accept the third party opinion over theirs. Every time. Only when the noobs start completing challenges and smile WHILE PLAYING do you know you are getting somewhere.

* Our mantra became help weaker players without changing the game for the better players.

* Reaching the skill level to be a professional video games programmer takes years. There are no shortcuts. You can not possibly go from nothing to professional grade skills in less than perhaps 2-3 years - and for that you'd have to be an uber-genius - usually it takes 5-10.

* We tried very hard to make every level and every segment of every level evenly paced, addictive, and engaging. Every pile of boxes, every set of enemies, was carefully placed to try and build a rhythmic pulse to the gameplay.

---

[⇪]

Fukio Mitsuji

* I realized in those days that neither thrills nor pleasures should be allowed to dominate a game: good gameplay requires there be a balance between them. That would be the ideal kind of game, I thought. By "balance", however, I didn't mean that every section of a game should always be perfectly balanced between the two - some sections should be all about thrills, while others are more relaxing and just about having fun. But as a whole, viewing the game experience over time, there needed to be balance between the two.

* During a development, I'll lie down on my futon for bed, but suddenly an idea will come to me, and I'll get out a pad of paper to write it down so I don't forget. But once my brain gets cracking like that and the ideas start flowing, before I know it it's morning and I've spent the whole night like that, and my room is littered with memos and notes everywhere.

* To the aspiring game designers, the first thing I would say is that coming up with ideas for games is not as easy as many of you think it is! To be a developer, you of course need a love for games and an analytical mind, but to that one must also add the creativity to bring forth new ideas (and many of them) from nothing. I think a designer should also have above-average passion and curiosity, and a philosophy or "policy" toward game design that is their own.

* Every game promises some degree of conflict between player and enemy, but what would happen if the enemies simply ignored the player and refused to “play” with him? The player will assuredly leave the game due to boredom. In other words, it’s only when the game fights back that the player is motivated to continue

* Have you ever wondered why video games have score counters to begin with? Micom BASIC’s Kohji Kenjoh once wrote an article on this topic, in which he said something like, “Originally, scoring systems were meant as a means of quantifying and visualizing a player’s technique and advancement; however, there are many games produced today for which the purpose of the score counter is extremely unclear ...”
Some games give way bigger bonuses to secret items than genuine technique, rendering their game completely pointless to play at a serious level, and others allow for massive score by merely repeating some simple, monotonous task, and if a player who doesn’t know about this exploit is suddenly made aware of it, they’re likely to completely drop the game due to it being “solved”.

---

[⇪]

Fumito Ueda

* In the very beginning, of course, my ideas were related to the art and visuals, but overall I would have to say it was the desire to do distinguish myself and do something different. I wanted to create something no one had ever created. Whatever genre or type of game I made, I knew I wanted to do something unique.
I also had this feeling -how to put it- that the gameplay needed to be simple if it was going to reach out to non-gamers. I don't personally like very complicated games myself, either.

* Personally, I've never felt very motivated by the stories of video games. I rarely have that "I want to see what happens next!" feeling from the story itself. Perhaps I simply just don't have much interest in the stories of video games, but I also often wonder, "are other players really even paying attention... ?"
I don't think movie-style narratives, where "the truth" is gradually revealed to you as you reach the end, are really right for video games. I prefer giving the player some information right at the beginning, "this is how things might be", but then letting them play and discover everything else for themselves.
It's a little difficult for me to explain, but games like Flashback, Out of this World, and even Grand Theft Auto III... I'm not very good at English, so I don't really understand what's going on in those worlds very well. That's been the case with most games I've personally imported. And yet, it's precisely my not knowing that makes the experience exciting.

* For a long time, I was very worried whether a game created in this way would be accepted by players. There were no stats, no scoring... would players really accept a game that only had a story and a realistic map/world? But rather than take a left-turn into some compromised vision, I thought it would be best if we push ahead with the original idea as planned.

* When I'm deciding whether or not to put something in the game, I'm always looking for meaning behind it, no matter what. Like, does it make sense to put smaller enemies in the game just so you can get items and experience points? I had the idea of being able to warp through the use of an item, for example, but the huge field would have become pointless.

* First of all, I come up with a simple strategic idea, create a rough sketch and 3D models. With that model, without any detailed textures, I move the player and experiment with different movements according to the strategic ideas. If there are no major problems found, I go into the details. So the designing and modelling is related to the gameplay very much.

---

[⇪]

Gunpei Yokoi

* The word "game" means something competitive, where you can win or you can lose. When I look at recent games, I see that quality has been declining, and what I'm seeing more and more of are games that want to give you the experience of a short story or a movie.
This is most obvious with role-playing games, where the "game" portion isn't the main focus, and I get the feeling that the developers really just want you to experience the story they've written.

* The essence of games is competition, and I think that's a remnant of our past as animals, and the competition of the survival of the fittest.

* I first take the character (or characters) which you're going to control and replace them with a dot as a placeholder, then I think about what kind of movement would be fun. Basically I'm trying to put myself in the player's shoes and figure out what they would enjoy. Also, when I make characters I try to design them in a way that teaches players how to play the game. In other words, if an enemy looks too pretty, they won't seem like an enemy to the player. But if you give them an enemy-like appearance, then the player won't need to read the manual or anything to know "oh, I've got to avoid this guy."

* The interaction with the two screens in Donkey Kong itself is really quite simplistic. And yet somehow the simple act of splitting the screen had served to make the game 10 or 20 times more fascinating to players. Donkey Kong for the G&W taught me that in game design, there are sometimes mysterious, hard-to-predict interactions like this.
A game that wouldn't have warranted any special attention on a single vertical screen, suddenly became far more interesting on a split-screen. What had happened? Well, when the player glances up at the top screen, it creates an urge to look down at the bottom screen. This push-and-pull of your attention turned out to be a huge plus for the gameplay. Were the two screens joined, there'd be no such effect, but once separated, you found yourself more drawn in to what was happening on the opposite screen, and consequently having more fun.

---

[⇪]

Hideo Kojima

* I think that's still the most important thing: a good sense of direction. I don't mean it in the cinematic sense per se: game direction is more about creating situations that draw players in emotionally, and about creating atmosphere.

* One thing I'm a little worried about today, is that the current generation of young game creators has grown up on video games themselves, and I don't know if they've had time or room to absorb the influence of other arts and mediums.

* Whether it's a 2D game or a 3D game, I always try to create a believable world for that game. Even the text of a game can contribute to that world feeling alive, I think. Having text prepared for every place you investigate, and having that text change depending on the circumstances, I think really helps create the illusion that you are "in" that world.

* What kind of story is going to make the gameplay come alive? Likewise, what kind of gameplay is necessary to advance the story? I think "game design" is the practical work of reconciling and combining these two elements in a game.

---

[⇪]

Hidetaka Miyazaki

* We pursued two main avenues when designing Dark Souls: in the initial concept stages I gave each of the artists a few simple "image words" to use as a starting point and then they were free to develop these in whatever way they wished. We then took the images we liked, adjusted them where necessary and used them to begin shaping the world.
In cases where I had a clearer idea of what I wanted, the design process was slightly different. For example, this is going to be used in this place to perform this function or, the area is designed in this way so it must adhere to these conditions, for example the mimic and the gargoyles.

* It may sound strange, but it's quite common for the tutorial to be the last thing to be integrated. It's much easier to design it once you know what needs to be communicated, and found the best to explain it to the player.

* It's "story for the game" before "game for the story" for me, so as long as it meets the game's requirements in order to create immersion for the player, it's all good. I wanted the player to experience the story, so we did not focus on making a linear storyline. I don't want to tell the story: I prefer the players to unravel it by using their imagination and our hints.

* Number one, the difficulty is not dependent on the skill level of the user. We have not created a game where players who react faster or press buttons faster fare better than others. Second, when a player dies, we try to leave a sense of "maybe if I try a different strategy I can succeed". Things that you lose in death can be outweighed by what you gain by trying again. We try to give players lots of freedom to design their own gameplay style and we've implemented enough content to enable users to continue challenging themselves and continue making progress.
One more aspect is the difficulty based on repetitiveness. We don't want users to have to constantly carve away health from enemies. We've created all characters - including enemies and the player - to have high attack power but low defense. We don't want users to hack and hack and hack away to defeat an enemy. It's more strategic. We want users to think, "if I avoid this enemy, maybe I can overcome him." We don't want players to be frustrated by doing the same things over and over.

* We are always thinking of ways to tell the joy of classic RPG with modern technology. For example, long weapons will be hard to wield in small corridor or torch lighting up the dungeon in realtime. We want to express things that we have ignored in past generation and integrate it in the gameplay. By doing what Wizardry games did in commands by player's action, realism, speed, and immersiveness will be enhanced greatly.

---

[⇪]

Hironobu Sakaguchi

* We don't start out with a master plan for the setting/world of the game - those details get filled in as we go. "A world matched to a story"... I think that fittingly describes the Final Fantasy series.

* One opinion you hear a lot about RPGs, is "if there aren't distinct roles/classes, it's not an RPG". And it's true that many of our staff love those tabletop games like D&D, and some of them feel that way themselves. We do not adhere to that when we make our games, though. I don't think we should be bound by stodgy rules or definitions, of any kind. If something feels fun and natural to play, then it's good by me.

* As for warp magic that would let you move between towns... it would definitely be convenient. But if players use it too much, they'll never get familiar with the terrain or map. With the Final Fantasy series, we want both the story and the terrain of the world to remain in players' memories. So our solution was to include the airship vehicle.

* Players always love finding treasures and items, so we try to dole them out to players in a way that feels rewarding. For example, there might be a treasure in a location that 80% of players will probably find, but we try to place them in such a way that it creates the illusion in players of "Wow, I was the only one who found this!"

* 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."
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.

* 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.

---

[⇪]

John Carmack

* I had this really bizarre conversation once with a couple of lawyers and they were talking about "How do you pick your target market? Do you use focus groups and poll people and all this?" It's like "No, we just write games that we think are cool."

* I think that the people who create their own technology and produce the games will always be at the head of the pack and you are definitely better off there.

* The way we work our games here is that, instead of making desgin documents and saying this is the kind of game we want to make and then trying to do the technology... instead we try to figure out the most impressive technology that will have the biggest impact on the players and then mold a game around that.

* The game has to be fun as you're doing your actions, as you're sitting there doing your "bob and weave," "duck and attack" that's what has to be fun - not the fact that you are progressing through a story to some end goal. That's something that I'm making no excuses about, no slipping around saying "Oh, there is a story" and all that. Yes, there is a little back-story, but that's not the point. The point is that the game is fun to play. There's value to be had in story-driven games-it's another valid style. It's not like we're saying "this is the only way to do games;" but one thing we absolutely are coming out and saying is that this is a valid way of doing games, and we are not apologizing for the lack of story.

* I am really happy with the reward things we've got like the "impressives" and "excellents" that you get while you're playing the game that was a perfect thing to add because it brings a smile to everyone's face every time it happens, and it's not taking something away from other players. It's a really great game design aspect, because if you give the player a cooler weapon it takes something away from the other player- they get killed more easily, and it's more frustrating for them. But it's a free cookie when you can give something away like [verbal accolades], because the other player is already dead.

* There were behaviors you would start seeing from people where, a lot of time when you are playing on servers you're kind of just goofing off, having a good time, trying goofy stuff or just playing casually with you friends. When every frag was logged, people got a lot less friendly. You'd see people who would abort out of games they saw somebody tough enter the game, because they didn't want to risk having a fair fight. There was a lot more whining and complaining.

* It's not the one brilliant decision, it's the 500 smart decisions that really make things good. It's more a matter of being able to keep making smart decisions. Making one brilliant decision and a whole bunch of mediocre ones isn't as good as making a whole bunch of generally smart decisions throughout the whole process. And there's so many of them that have to be made.

---

[⇪]

Patrick Wyatt

* There are times in a project when a few sacrifices have to be made. If they're done well no one notices the evil compromises that had to be made. My idea was simple: whenever harvesters are on their way to get minerals, or when they're on the way back carrying those minerals, they ignore collisions with other units. By eliminating the inter-unit collision code for the harvesters there is never a rush-hour commute to get jammed up, and harvesters operate efficiently.

* For Guild Wars, when we built out the first datacenter for testing, we colocated the servers in Los Angeles, while our dev team was in the Seattle area. This meant that our entire development team played the game in similar fashion to the way our players would *four years later when we actually released the game*. Incidentally, we also gave all the developers "minspec" machines (800 MHz Pentium III with 512MB RAM - blech!) so that we would build a game that played well on that type of computer.

* You should expect that some percentage of your players will lose connectivity to the server - usually at a critical time in battle while they're completing a multi-hour-long epic quest. Build in a system to enable them to immediately reconnect to the game from the *start* of your development cycle instead of waiting until after launch and discovering how frequently it happens (... like we did in Guild Wars... boo hoo!).

* To ensure a great online game-play experience, your job as a game designer is to minimize the perceived latency between initiating an action and having that action actually take effect in-game, even though there may be 300-400 hundred milliseconds of actual latency between the game client and game server.
So here's the solution: provide instantaneous visual and auditory feedback, without making changes to the game simulation.
Remember all those funny voices in Warcraft: "Yes, milord"; "At once, sire", "Daboo", "Zug Zug"? While quite entertaining in and of themselves, their fundamental purpose is to immediately reassure players by confirming that their orders are being obeyed.

---

[⇪]

Peter Molyneux

* People told Lionhead we were perfectionists, but if we were, the game would never have been finished. It's not a perfect game. Our next game won't be, either. But because there's no such thing as a perfect game, we'll just try to do something different, and do it as well as we possibly can. Someone asked me recently what drove us to work so hard on this and to spend so much time thinking outside the box. The simple truth of my answer only struck me afterwards. With Black & White, we made the game that we wanted to play.

* It took me years, you know -- a ridiculous number of years -- to realize that adding more features actually took away from the game rather than added to the game. It's not the number of features you've got; it's how well-exploited those features are.

* It's not about easy and hard, it's about entertainment and tedium. Each moment in Fable is an experience. Sometimes it's an experience about feeling like you're about to fail and just succeeding. That's the ultimate that we want, rather than the experience of going in, failing, and finally succeeding. I wouldn't mind that once or twice but not over and over.

* The experience of being lost is not what you want. The experience of exploring is what you want. The argument I use is: if you go orienteering, you take a map. Humans like to know where they're going. The people who really like to explore are the uber-uber-good people who are very good at working out where they are in a 2- and 3-D world.

* We used to wait until the game got to a certain stage in development and then experiment. Now we experiment first - they're mad, crazy things - but they're small things that we can play around with. This means that after we've done these experiments, we have a palette of things that we are happy with, and the game then can then exploit these kinds of things.

---

[⇪]

Raph Koster

* Fun is the feeling you get when you are exercising your brain by solving a cognitive puzzle. Sometimes the puzzle is provided by a computer, sometimes by another player, but either way, your brain is basically trying to perceive a pattern; victory usually comes from identifying the pattern, then correctly executing on some action that the pattern does not account for.

* I've always leaned towards elegant systems, meaning ones with few variables and few rules to them. When you populate a game with many of these, they very frequently end up leading to emergent behavior, which can be quite fun. But when you lean on the creation of simple systems, the temptation is even greater to have lots of them in your game. And that can and will lead to most or all of them feeling unpolished and unfinished.

* Don't say anything when watching someone else play. Just watch and note down all the stupid things they are doing because you were stupid and didn't make the right thing to do really obvious.
They are always right about their experience. Telling them that it isn't actually that way is a waste of time. The question is why they think it is that way.

* Anything you do in the game "because you have to do it" should be cut or at the very least get a seriously hard look. Tedium is the enemy of fun.

* Rares were simply items that were incredibly uncommon. Often they were near unique. They couldn't be found via loot - they were only spawned once, really, when the server came up.
So if you forgot to mark that object as "no pick up," it would just get picked up again, and at next server reboot, replaced, and ...
The upshot of rares? Players started launching websites and forming communities around collecting, building lists and making real money and creating strategy guides around rares.
Players felt clever. They had invented a minigame out of our bugs, and it was a minigame people were willing to pay thousands of dollars a month to play.
Our wisdom was not in inventing an awesome cool collectible feature. It was in surrendering control to the awesome power of emergent behavior.

* People who tell you you're awesome are useless. No, dangerous. They are worse than useless because you want to believe them. They will defend you against critiques that are valid. They will seduce you into believing you are done learning, or into thinking that your work is better than it actually is.

---

[⇪]

Rob Pardo

* Some studios like to push the technology, and their gameplay mechanics come out of that. We're more kind of the inverse of that, we make sure that all the other disciplines, being art or programming or game design, are focused on the gameplay.

* Game design is susceptible to come up with cool ideas where the designers have the fun rather than ideas where the players have the fun.
We might come up with a cool boss encounter where the boss is complicated and intricate and we think we're being clever as designers, but in reality the players have no idea what's going on.

* I see all these studios out there that they'll build their singleplayer game in two years and in the last three months "let's just slap on multiplayer".
If you want to design something that's going to be out there for hundreds and hundreds of hours, don't you think it might take more development time to make that, than something that lasts for ten to thirty hours?

* We want to take everything to an eleven. Every unit, every class, everything in the game that we can think of, we want it to feel like can't be stopped.

* We found that many new players to a MMORPG really do not know what to do when they start the game. While some people do enjoy finding their own way in the world, we felt like most players want to immediately have purpose and goals to accomplish, like in most other gaming genres.
Having a large variety of quests lets you focus on goals rather than just finding monsters to repetitively kill for experience and levels. We called this philosophy "killing with a purpose," and it really allows players to focus on the game rather than their experience bar and level.

* The biggest mistake that other MMOs make is not spending enough time on the game before it launches. We took our time with World of Warcraft and iterated on each feature until we were happy with it. We also had a very long beta period, as well as two server stress tests. All of this was geared toward making a game that was very enjoyable at release rather than several months afterwards.

---

[⇪]

Roberta Heuer Williams

* What is the story? Who are the characters, especially the main character? What is he/she trying to do, i.e. what is the quest? In what sort of 'world or land' is this game going to be played? In other words, I always thought first of the story, characters, and game world. I needed to understand those before I could even think about any game framework, 'engine,' or interface.
Once I had a good idea of the basic storyline, characters and world, I could think about how I wanted the game to play, to run, to appear. Things like 'how many colors' (a real issue in the early days) could I utilize, how much and what kind of animation, first-person perspective vs. third-person perspective, how to accomplish communication with the game and/or game characters, how much, if any, 'physical' puzzles vs. 'thinking' puzzles, what sorts of animation/game play would be required for more 'physical' puzzles, how 'big' the game could be (in disk/CD size) which translated to how many 'lands' within the game world or how many places or 'rooms' within those lands and the amount of characters and animation, music or sound effect issues, etc.

* Each game is different and has a different audience. You have to have an understanding of "who" you are writing a game for ...and then write that game for "them." The flow of the game will follow the storyline, the puzzles, the characters, but more importantly for "who" you are writing the game for. If it's for beginners, the flow will be different than if it's for veterans. The basic idea, though, is to understand how to integrate a story into an interactive "game" format. I think that's partly intuitive talent, and partly a learned skill.

---

[⇪]

Satoru Iwata

* Programmers are like the faucets on a pipe. If the faucet is large, lots of water can flow through. But if the faucet is small, that flow will be reduced to a trickle. Design, planning, graphics, story, music... no matter how many great ideas you have, if the programmers say it can't be done, it won't get done: the faucet was too small.

* The job of a programmer is to produce good work, meaning that the planners and designers shouldn't feel the limitations of the hardware. I tell my programmers to think carefully before they say something "can't be done." There isn't that much that can't be done with a little ingenuity.

* Lately I've heard people say that game designers are to be praised, while programmers are less important. That is a warped way of thinking in my opinion. Both together are required to produce anything. No matter how wonderful a game idea or design might be, without solid programming, it won't be well received by its audience, the players. Programmers should take pride in that fact.

* Programmers have that kind of decisive power over a game. Accordingly, you won't succeed as a programmer if you don't like revisions and updates. If change bothers you, you shouldn't work in the game industry.

* Talent, in my view, is the power to continue persevering in your endeavors. Those people we look at and say "Wow!" are the people who kept on at their work without thinking how hard it all was. Those who can continually exert themselves in improving their own abilities are natural creators, I think.

---

[⇪]

Satoshi Tajiri

* Rules are the very lifeblood of games. whether a game is interesting or not depends entirely on the agreed-upon rules. Game design, then, when you boil it down, is simply the construction of those rules. I often get approached by aspiring game designers who want to tell me about their idea for a game. Usually all they can tell me is some vague story or plot outline, like "it takes place in outer space" or something... but that isn't game design - it isn't even a game. Only after you've devised a set of rules for your game, can you call it "game design."

* When you're a kid and get your first bike, you want to go somewhere you've never been before. That's like Pokémon. Everybody shares the same experience, but everybody wants to take it someplace else. And you can do that.

* I was really careful in making monsters faint rather than die. I think that young people playing games have an abnormal concept about dying. They start to lose and say, "I'm dying." It's not right for kids to think about a concept of death that way. They need to treat death with more respect.

---

[⇪]

Shigeru Miyamoto

* What I'm looking for in a development is, are they trying to do something new and original? When the originality reaches a certain level, that's when I give my OK for the project to proceed. If it's lacking in that regard, I ask them to think of ways to spice it up.

* I've noticed it sometimes happens that, at the end when everyone is flustered, there's a tendency for the developers to lose perspective and see everything as equally important. At that time, I think the most critical thing is that you stop, return to your "normal" self and mindset, and ask yourself what's really essential to the game.

* With Mario, each new gameplay element you want to add should be used 4 times in a stage: a place where players are introduced to and can safely learn the new element; a place where they get to play around with it; a place where they apply what they know about it in some novel way; and finally, a place where the idea is taken to an extreme.

* The important thing is how the game feels in the first 2 or 3 minutes. That's the window of time in which the player's heart is seized. For Nintendo, until we've finished that core nucleus of the gameplay, we don't add graphics. If the game is no good after we create that core, then we throw it all away. In any event, you can't know until you go through the process of making it.

* Its often said that the heart of a game is its story, but that's not the case. The story comes only after the core of the game system is completed. Then the characters come into focus and the world starts to manifest.

* During a test play someone looks at the monitor and says "this game is too slow!" That doesn't mean you should just immediately increase the scrolling speed. The real problem is that the player sprite doesn't appear to be running despite the player diligently pressing the buttons. If you understand that, there is another way. By increasing the speed of the sprite's running animation and making it look like he's moving faster, the complaint about speed goes away.

* I'm often asked for advice by children who want to become game creators, and my default answer for a long time has been: "When the weather is good, you should go play outside." If you dream of becoming a game creator, you shouldn't only play video games; I think you should try and have as many varied, diverse experiences in this life as you can.

* When we're doing an action game, we make the second level first. We begin making level 1 once everything else is completed.

* I believe that ideas are limitless. These days, the world is overflowing with them. It's a game designer's job to figure out how to compile and program them into a video game. I think that the ability to collect and organize things is even more important to making games than the power of imagination and creativity.

* Now that video games have come of age, we shouldn't try and imitate movies or novels. We should create something that can only be done with the medium of video games. It isn't about graphics or about stories, but about the exploration of virtual spaces.

* You're starting to see developers ask whether interesting, satisfying game development really lies in this march towards ever-increasingly precise and realistic technology. Take the popular Tamagotchi, for instance. It doesn't have any powerful technology. Its appeal and fun lies in a whole other realm. There's something there that can make games richer, and I think that will be a theme for developers in the future.

* It's been our thinking that for a game to sell, it has to excite the people who are watching the player - it has to make you want to say, "hey, gimme the controller next!"

* An eternal theme for me with game design has been to let the players create their own vision. I don't want to just hand players ready-made experiences - here you go, play this stage we made, solve this puzzle; rather, I want a game that allows players to try come up with their own solutions and playstyles and test them out there on the spot.

* Our thinking about that is the same as Namco's. In their development process, they always spend a lot of time in the final tune-up phase. They're very smart about programming there. So, in our own way, we too take a lot of time with game balancing: it's like, "ok everyone, time for the tune-up!"

* If you think of games as fashion, then 10 years from now, what is popular today will be outdated. But if you think of the inherent value and quality of a game - that doesn't change much in 10 years. When a high-quality game is made, it sets a standard.

---

[⇪]

Warren Spector

* The team and I certainly tried to do things that, frankly, a lot of people thought we were crazy to try. You have no idea how many times I heard, “Why don’t you just make a shooter?” or “How many people are really going to sneak? Why are you spending time and money on that?” Needless to say, that was incredibly frustrating.

* The key for me is creating linked sandboxes and letting players explore those little narrative chunks on their own. I'll determine why it's important that you get through a door, but how you get through it, what happens and whether you kill, talk to or ignore everyone on the other side belongs to the player. That concept of sharing authorship is where the sweet spot of game narrative is.

* The problem is that most people making games, especially story games, still rely very heavily on scripted sequences and interactions among objects. If the designer doesn't think of it, it can't happen.

* The games that are really well written tend to have too much writing in them and that's a problem. People don't play games to read or listen, they play games to act or do.

* Stop building movie sets and make a world we can interact with instead. These things are huge. There are all sorts of things we can do beyond pretty pictures.

* Done well, branching can provide a powerful illusion of freedom for players. But, that's all it can provide - an illusion. The reality is that, if we don't put something in the game, on the screen, in the mouths of nonplayer characters (NPCs), it doesn't happen - and no amount of branching can allow players to do things we don't allow them to do.

* In a real-world economy, more -isn't always better. The same is true in gaming. Just because you can offer players 4,000 weapons doesn't mean that you should. The choice should have meaning.

* In paper games, players can interact with anything in the game world - anything at all. Everything's a potential tool to be used in the solution of game problems. That just doesn't work in computer gaming. In paper gaming, you use things like character classes and die rolls because they're the only simulation tools available. In computer games you have a completely different set of tools - tools better suited to the medium - than those. You have to resist the temptation to fall back on paper-game design tropes.

* It's the people, stupid. Role-playing is about interacting with other people in a variety of ways (not just combat… not just conversation…).

* Have you patted your player on the back today? Constant rewards will drive players onward. Make sure you reward players regularly. And make sure the rewards get more impressive as the game goes on.

* What good is player control if all choices lead to the same result? Without real, predictable consequences, choice is irrelevant.

* Movies don't need nonhumans to be cool but the same cannot be said, apparently, for games. People seemed to want monsters and nasty bad guys.

* How do you know which of your core game goals are valid and which need rethinking? How do you know which game systems work and which don't? When is it possible to know what your game is really about? These questions are all answered by the "proto-mission." This is the first implemented mission, playable start to finish, the one that captures everything you want your game to be. Get this mission working as early as possible, so you can see all the things you thought would work that didn't. Then fix them.

---

[⇪]

Yasumi Matsuno

* I think breaking down the various conventions of pre-existing games is a good thing. But it's not just about smashing things: the goal is to create something more solid, a more fully realized game. If that ends up clearing the way to a new genre, all the better. My ultimate goal would be to make a game that people look back on and say it set a new standard, or was the predecessor of a new style.

* When I made Ogre Battle, at that time RPGs like Final Fantasy and Dragon Quest were huge hits, but many people were also starting to get tired of them. Players were ready for something new-the timing was right for a strategy RPG like Fire Emblem, something which was a midway point between extremely difficult simulation games like Nobunaga's Ambition and regular RPGs. So I first looked at the state of the market, and only then did I decide to make a strategy RPG. At that point I thought, ok, if we're going to do this, let's weave a really grand story into it, and that was how Ogre Battle got started.
As you can see, the initial impulse wasn't that I wanted to create a specific kind of game or world; it started from my personal estimation of the commercial value of the idea, and whether it would pan out given the current market and player demographics.

* The internet is connecting the world more and more these days, and players are writing reviews for all sorts of games online. I get sucked into stuff like that easily, so I always read them, and when I see criticism about our games, it makes me want to fix those flaws in whatever we're working on now.
To go back a bit, after we finished Ogre Battle, Quest was experiencing a staff shortage, and I had to do the user support by myself. People would call in and say stuff like, "This game doesn't make any sense! Who's responsible for this mess?! Put him on the line!" and I'd respond, "Ah, I'm sorry, that would be me." (laughs) In this way, for 4 long months, I got to hear it all straight from the horse's mouths... psychologically, it was exhausting, but it was also a good learning experience. I applied the things I learned from that in our next game, Tactics Ogre, and likewise, after that I built on the feedback for Tactics Ogre when I made Final Fantasy Tactics.

* The themes I've included in my games have usually reflected the people and the situations I was working in at that time.
For example, in Final Fantasy Tactics... the theme of the class-based society, of nobles and commoners, that came about because when I joined Square, as you can imagine, there were individuals there who were like royalty: their talent, and the social capital they had amassed... it made me doubt whether someone without those gifts could ever succeed there, no matter how hard they tried. And those ideas found their way into the game.

---

[⇪]

Yuji Horii

* If you want to make games, you can't simply study computers. The computer is not what you're addressing; it is the person on the other side of the screen who you're communicating with. In that sense, my advice to aspiring game designers is to look at the diverse world around you and then think of new ways you can bring people happiness.
Also, when you play games, there will be occasions when you think "oh, I'd do this differently here." Eventually you'll have accumulated a great number of such observations, and your work will gradually become more original.

* The term "RPG" has somehow been misunderstood by many of today's games; they think that increasing your stats is roleplaying. Originally you inhabited the role of another character in an RPG. I mean, game systems where you defeat enemies and collect gold do help sustain players' interest and ambition, but I feel something is being missed here.
The main policy for RPGs should be how to make the player feel like he has become the hero of the game. We could make things more realistic, but in doing so, we might lose half the appeal of the game. Being games, there are some things you just can't do away with. I want to make RPGs that let players experience new things different from their everyday life.

* It goes without saying that finding the right balance is key to a good RPG. And to adjust that balance there's no other way but to actually playtest the game, make some small adjustments, test it again, make more adjustments, and so on.
Naturally, game balancing isn't something you get right after one pass. We repeated this process over and over.

* Developments always begin with a wealth of different ideas, but when its time to actually get down to brass tacks, at some point one has to stop with the new ideas, and begin the phase of polishing and refining what you've got. Even then, it's hard to stop coming up with new ideas, because things often feel incomplete. When I actually play the games we've created, it's common for me to feel like only half of what I wanted to include is in there.

* I like manga and books, and in my free time I devour whatever I can. Then, when the time comes to think up new ideas for a game, I find that those things I've recently read and seen have been transformed within me, and I draw from there.

* In that final phase, I look at the big picture and focus my attention on balancing the most important elements. I also pay attention to how it feels playing, and the sense of volume/length. The most important thing is whether the game has "staying power": do you get bored of it after awhile, or does it remain fun even after long sessions? That's our top priority.

---

[⇪]

Classics

* Toru Iwatani: When I made Pac-Man, I strongly believed that the time had come for video games to become more than they were, and I wanted to express that in my new game. But the newer your ideas, the more work it takes to make others see your vision, and that really took up a lot of my time and energy.
All those things that people say are "useless" or "extraneous" in this moment, it is from the chaos of all those "unnecessary" things that light will begin to shine.
Hardcore game fans have a very deep understanding of games. I believe that. When developers create games mainly with them in mind, there's a tendency for those games to come out very complex. However, because of that, games today have become harder for the average person, and for women, to enjoy, and in my opinion that is regretful. There's been less and less games that are simple-but-deep, that anyone can enjoy.
Unlike other mediums in which there is no participation from the audience, with game design, you can tell very quickly if your ideas are being understood. This allows us, as game creators, to get continuous feedback, and therefore make continuous revisions to our work. A finished game is the product of many, many such revisions to the initial planning document.

* Kazunori Sawano: In Galaxian, the number of enemies never changes. The difficulty from one stage to the next is almost imperceptible; however, if you compare stage 1 to stage 10, it's very clear that stage 10 is harder. That's the kind of slow build-up I went for, where things gradually seem to get harder, but there's no apparent disjunction. I think it's a very important concept in game design.
As far as atmosphere in games goes, I believe that's the purview of the visual artists. What is important to game designers, is that the game be fun no matter what the sprites look like-or even without any sprites at all.
There are game designers out there who like to write long and involved stories, but I think that is actually more of a hindrance to good game design. There's no way you're going to make a good game if you're constricted by the needs of the story. Video games aren't novels, either.
Personally, whether I'm designing a video game or an electromechanical game, in both cases I'm trying to create "play".

* Yokoyama: I've often been asked what the "Namco essence" was, but all of the developers then had very distinct individual personalities - there was no central philosophy of game design. However, the one thing we did all share was a commitment to do things right, down to the last bit. That's why we playtested our games so thoroughly, both with others and by running simulations ourselves. Not wanting to do things half-assed wasn't some principle we had as craftsmen or anything; it was part of putting ourselves in players' shoes and imagining what would be fun for them.
Well, another thing that helped us was that we tried to do what other developers weren't doing. After Space Invaders came out, everyone tried to imitate its success, including us with Galaga and Bosconian. But we also made different games like Rally X and Dig Dug. If you do something unique, that other's haven't done, you'll find your market there. No one likes simple rehashes.
Nowadays you can specialize as a programmer, planner, designer, or musician, but originally a "game creator" was simply someone who wanted to make a cetain game, and he knew and did everything involved: design, music, programming, documentation. I think you grow a lot more as a developer that way.

* Kazutoshi Ueda: My sticking points were player satisfaction and fairness. No matter what idea I came up with, I always asked: is this going to be satisfying? That was my standard. In doing so, however, the playtime of my games kept getting longer and longer… I often butted heads with management about that.
"Satisfaction" in a game means having some kind of mechanic that you can gradually get better and better at. I also think good, responsive controls are a big part of that too. When I made Lady Bug, I made some mistakes there. The hit detection was pretty bad for opening the gates, so that if you weren't very precise, they wouldn't open. I had intended for them to be very easy to flip, but when the game was released, regular players told me how hard it was. "I've failed!", I thought.
As for "fairness", I think that hit box/collision detection is also a good example of that. It means making the player feel strong like he's got an advantage, while the enemies, in contrast, are at a disadvantage.
Another thing, I also make sure not to include "bad" items that only damage the player when he picks them up. All these things contribute to a sense of fairness for the player.

* Michishito Ishizuka: I try to design my games so that when you take damage or die, you don't simply think "the enemy killed me", but rather "I made a mistake here, and that's why I died." That's why, for example, I try to include lures in my games, places where if you just waited patiently everything would go fine, but I'll dangle out this little carrot in front of the player, and if they rush ahead and take it and die, they'll realize, "oh, it was my mistake."
If you put something in a really dangerous, hard to reach place, the player is going to want to try and get it. Then he goes for it, thinking he might die… and in fact he does. But that death feels fair because he knew the stakes.

---

[⇪]

Tidbits

* [MARIO 64] I think that is fine-tuning. Many, many, many hours and days spent actually sitting down and playing the game. If you don't play the game, you don't pick up on the little nuances, and the effects that you think should be there or shouldn't be there.

* [DIABLO] Both Diablo and Diablo II provide a constant source of simple pleasures, many of which are perhaps too basic and obvious to mention in evaluations and reviews, but which are fundamental to their success. We used the term "kill/reward" to describe our basic gameplay. Players continually kill monsters and get rewarded with treasure and experience. But the rewards don't stop there. We offer a steady stream of goals and accomplishments to entice the player to keep playing. There's always a quest that is almost finished, a waypoint almost reached, an experience level almost achieved, and a dungeon nearly cleared out. On a smaller scale, we tried to make every single action fun. Moving around inventory items produces pleasing sounds. Monsters die in spectacular fashion, like piñatas exploding in a shower of goodies. We strove for overkill in this sense, in that players are constantly on the verge of something great - only a few mouse-clicks away from a dozen interesting things.

* [DIABLO] Our initial priority was to get a guy moving around on the screen and hacking monsters. This is what players would be doing most of the time, and it had to be fun. We were constantly able to hone the controls, pathfinding, and feedback mechanisms during the entire length of the game's development. Most importantly, it allowed us to determine what was fun to do, so we could provide more of it, and discover what was awkward or boring, so we could modify or remove it. For instance, it became obvious very early that players would be killing large amounts of the same monsters, and those monsters would predominantly be attacking the players. This gave us the opportunity to plan for multiple death sound effects and additional attacking animations for each monster. If we hadn't experienced the core gameplay as early as we did, combat would have ended up feeling much more repetitive.

* [AGE OF EMPIRES] Sometimes we found that an algorithm, though optimal for the situation, was executing too often. In one case, unit pathing had been highly optimized, but it was being called too often by other subsystems. In these cases, we fixed the problem by capping the number of times the code could be called by other systems or by capping the amount of time the code could spend executing. Alternately, we might change the algorithm so its processing could occur over multiple game updates instead of all at once.

* [AGE OF EMPIRES] To make sure AoK worked on the minimum system, we had to shop for old hardware. We purchased systems matching the minimum system specification from a local system reseller - we no longer used systems that slow. When the "new" computers arrived, we decided not to wipe the hard drives, nor did we reinstall software and hardware with the latest driver versions. We did this because we expected that most AoK users wouldn't optimize their computer's configuration or settings, either.

* [AGE OF EMPIRES] To help correlate player responses with game performance in AoK, we used several on-screen counters that displayed the average and peak performance. Of these counters, the ones that calculated the average frame rate and lowest frame rate over the last several hundred frames were used most to determine performance problems. Additional statistics included average and peak game simulation time (in milliseconds) over the last several hundred game updates.
Identifying symptoms of play-testing performance problems and making saved games of these problem situations was very useful. We replayed saved games in the profiler, and routines that took too long could be identified quickly.
We also created scenarios that stressed specific situations. For instance, we stressed the terrain engine's hill-drawing by using a special scenario consisting of a large game map covered mostly with hills. Other special scenarios were created that included many buildings, walls, or attempts to path units long distances between difficult obstacles.
AoK has a feature that allows human or computer player commands to be recorded to a file. This data can then be played back later as if the original player were issuing the commands. These recorded games helped diagnose pathfinding problems when it was unclear how a unit had arrived at a particular destination.

* [DARKSUN ONLINE] >You can never allocate too much time for beta testing and debugging an online title. The sheer number of bugs found by the external testers was absolutely amazing - and the potential for each of those bugs to cause havoc was greatly magnified by the interactive nature of the game.
>Every morning I would spend hours reading and answering hundreds of messages. Some were suggestions, some were flames, but most were simple questions - and we quickly realized that we were seeing a great deal of them over and over. However, once I got the FAQ written and published, the flood relented... a little. Beyond that, though, the FAQ turned out to be a great promotional and educational tool; it even staved off our marketing department a few times by proactively giving them whatever information they were looking for.
>Although the basis of the game is player interaction, we found that having a strong random quest generator helped fill in the gaps.
>People want their name in lights, so the more recognition you give game players, the more they'll feed back into the system. No player wants to be the anonymous shopkeeper - but they'll be a lot happier about it if they get a big lit-up sign with their name on it! Players want recognition for their acts, be they good or evil. The more you let individuals stamp their name on the world, the more they come back - both to see their name in lights, and then to keep it there.

* [THIEF] The Looking Glass game design philosophy includes a notion that immersive gameplay emerges from an object-rich world governed by high-quality, self-consistent simulation systems. Making a game at Looking Glass requires a lot of faith, as such systems take considerable time to develop, do not always arrive on time, and require substantial tuning once in place. For Thief, these systems didn't gel until mid-summer, fifteen months after the project began full development, and only three months before we were scheduled to ship.

* [THIEF] As an element of the design, sound played two roles in Thief. First, it was the primary medium through which the AIs communicated both their location and their internal state to the player. In Thief we tried to design AIs with a broader range of awareness than the typical two states that AIs exhibit: "oblivious" and "omniscient." Such a range of internal states would be meaningless if the player could not perceive it, so we used a broad array of speech broadcast by the AIs to clue in the player.
Second, the design used sounds generated by objects in the game, especially the player, to inform AIs about their surroundings. In Thief, the AIs rarely "cheat" when it comes to knowledge of their environment. Considerable work went into constructing sensory components sufficient to permit the AIs to make decisions purely based on the world as they perceive it. This allowed us to use player sounds as an integral part of gameplay, both as a way that players can reveal themselves inadvertently to the AIs and as a tool for players to distract or divert an AI. Moreover, AIs communicated with each other almost exclusively through sound. AI speech and sounds in the world, such as the sound of swords clashing, were assigned semantic values. In a confrontation, the player could expect nearby AIs to become alarmed by the sound of combat or cries for help, and was thus encouraged to ambush opponents as quietly as possible.

* [THIEF] One of the Thief team's favorite games during development was Goldeneye on the N64. We were particularly struck by the manner in which levels of difficulty were handled. Each level of difficulty had a different overlapping set of objectives for success, and missions were subtly changed at each level in terms of object placement and density. Relatively late in the development of Thief, we decided such a system would work well in our game. Extending the concept, we added a notion that as difficulty increased, the level of toleration of murder of human beings decreased. We also allowed players to change their difficulty level at the beginning of each mission.
The system was a success in two ways. First, it made clear to the player exactly what "difficulty" meant. Second, it allowed the designers to create a very different experience at each level of difficulty, without changing the overall geometry and structure of a mission. This gave the game a high degree of replayability at a minimum development cost.

* [RAINBOW SIX] We'd retooled the renderer during the previous month, but our frame rate was still dragging. After running the code through a profiler, we figured that most of our time was going to collision checks - checks for characters colliding with the world and line-of-sight checks for the AI's visibility routines.
The problem was that every time the physics engine was asked to check for a collision, it calculated a very general 3D solution. Except in the cases of grenade bounces and bullet tracks, a 3D collision check was complete overkill. Over the next month, we reworked the engine to do most of its collision detection in 2D using a floor plan of the level. These collision floor plans would be generated algorithmically from the 3D level models.
The technique worked. In addition to getting the frame rate back up to a playable level, it also made collision detection more reliable. The game engine also used the floor plans to drive the pathfinding routines for the AI team members. Players would view these same floor plans as level maps in both the planning and action interfaces. By figuring out how to fix our low frame rates, we wound up with solutions to three or four other major outstanding engineering issues. Sometimes, the right thing to do is just throw part of the code out and start over.

* [JAK AND DAXTER] Practically all of the run-time code (approximately half a million lines of source code) was written in GOAL (Game Object Assembly Lisp), Naughty Dog's own internally developed language, which was based on the Lisp programming language. GOAL code, for example, can be executed at a listener prompt while the game is running. Not only can numbers be viewed and tweaked, code itself can be compiled and downloaded without interrupting or restarting the game. This allowed the rapid tuning and debugging, since the effects of modifying functions and data structures could be viewed instantaneously.

* [NEVERWINTER NIGHTS] In BioWare's past projects, we have generally found that if a task that could be automated by a tool was going to be performed more than once, then the tool saved time in the long run. Despite problems inherent in using a tool under development, having a large and robust toolset allowed for very rapid implementation of design and art content.

* [GOD OF WAR] Hit pause is when the game pauses for a second when something 'big' or 'important' happens. For God of War we use hit pause everywhere! When Kratos makes contact with the enemies or during the complex throws and all sorts of other sneaky places. Hit pause and slowdown are 2 different things and sometimes we use them together. I define slowdown as slowing the action down so you can take it al in. Hit pause is when the game pauses even if it's really minute and you barely notice it. Sometimes the pause can be used even longer for different effects.
Even though it's a really simple concept, the skill comes from where and how to use it. Same with slow down. The ability to change an animation from something that doesn't feel very powerful to something that is just like, 'damn...that hurt!' is just massaging the animation with all the right goodies until you get something good.

* [SUPER STREET FIGHTER II TURBO HD REMIX] Here's the Capcom Principle of Balance:
Give every character something "so good that it's broken." Include so much variety that by the time anyone ever figures out which broken thing actually does ruin the game...the game will be dead by then anyway.
Clever, really. They understand balance vs. variety well. They create as much variety as possible, making balancing so impossible that even they can't really be sure what's balanced. The saving grace is that the huge gaming audience is faced with a task that takes at least a year to sort out (or maybe many years!).

* [FINAL FANTASY XIV] I think the "Ideal - Reality = Problem" concept could be applied to any other division's work, or even self-diagnosis. Essentially, if you come up with how something should be, perform an accurate analysis of the current situation, and make improvements (no matter how gradual), you should be able to make steady progress towards your goal. Back then, I thought "in the end these are all obvious things," but at the same time, I realized that sometimes, "the obvious things" are the hardest ones of all.

* [FINAL FANTASY XIV] When people spend a long time becoming accustomed to their environment, changes to that environment are very stressful, regardless of whether the changes are good or bad. I deeply regretted leaving the game in such an unbalanced state for so long. It takes a lot of courage to make changes - they cause stress for the players and can lead to criticism.

* [COUNTER STRIKE] Single-player mapping is a lot like guiding a rabbit around with a carrot. The player is the rabbit, the carrot is some goal, and the werewolf is the big bad boss. Take the rabbit away and you're stuck with a confused werewolf with a carrot. Take the carrot away and the rabbit will do nothing then get devoured. Take the werewolf away and you end up with one big, fat, bloated rabbit, and lots of droppings.
The difficult bit is getting it all right. Lots of single-player maps fail at the carrot stage - it's one thing to have a set of good-looking maps, but it's no use if the player hasn't a clue what to do or where to go. Many maps fall into that pit, with players getting lost very easily, backtracking, getting even more lost, and only getting back on track through sheer luck and exhaustive searching. Usually, this doesn't go well.

* [DOTA] It was quickly realized that replayability would be the key to DotA's success; it was necessary for Guinsoo to make the game as deep as possible while still working within the limitations of the engine and tools to which he was bound.
This was executed by examining the "fun" elements of gameplay, and expanding on the game simply by adding more choices (and therefore more possible combinations of gameplay). Guinsoo began adding content at an extremely rapid pace, with each individual hero or item increasing the replay value of the game exponentially.

* [CIVILIZATION] Good games can rarely be created in a vacuum, which is why many designers advocate an iterative design process, during which a simple prototype of the game is built very early and then iterated on repeatedly until the game becomes a shippable product. As the number of times a team can go through this cycle is finite, developers should not waste time with small changes. Instead, when making gameplay adjustments, developers should aim for significant changes that will provoke a tangible response.
If a unit seems too weak, don't lower its cost by 5%; instead, double its strength. If players feel overwhelmed by too many upgrades, try removing half of them. In the original Civilization, the gameplay kept slowing down to a painful crawl, which Sid solved by shrinking the map in half. The point is not that the new values are likely to be correct - the goal is to stake out more design territory with each successive iteration.

* [CIVILIZATION] Creating story-based games can be an intoxicating experience for designers, many of whom go overboard with turgid back stories full of proper nouns, rarely-used consonants, and apostrophes. Furthermore, games based on complex, detailed simulations can be especially opaque if the mysterious inner workings of the algorithmic model remain hidden from view. As Sid liked to say, with these games, either the designer or the computer was the one having the fun, not the player.
Thus, in Sid's words, the player must "always be the star." As designers, we need to be the player's greatest advocate during a game's development, always considering carefully how design decisions affect both the player's agency in the world and his understanding of the underlying mechanics.

* [SID MEIER'S PIRATES!] We use an iterative prototyping process in making games in which we first create a fun playable prototype and then play and improve, play and improve the game throughout the entire production cycle. That way, we know that the game is fun from the very beginning and can make design decisions based on whether or not a feature adds to the fun. And, by constantly playing the game over the two to three year development cycle, we can be sure that the code is solid and the gameplay is smooth before we release it to market.

* [MEGAMAN] That was written into the planning docs, yes. It's a "hidden trick". In the old days, if your game didn't have any secrets, it was difficult to get it featured in the various gaming magazines.

* [EXILE] Personally I believe that the best creations occur if allowed to develop at least partly in this evolutionary way rather than completely designed from scratch at the outset. It takes much longer of course to produce something this way and you are in danger of never finishing if you lose sight of the goal, but is worth it in the end.

* [EXILE] It was all done by us. In those days there were no real development tools available and when for example a nose is one pixel big and one of only 4 colours there was no need for artists. It would have been near impossible to have non-programmer graphics as the interaction with the game code was critical because e.g. of the size of things fitting in holes in tunnels, and saving memory by careful positioning of the sprites in the graphics source area. Besides it was fun doing the graphics too. We had various tools we wrote in the wonderful BBC BASIC.

* [TOTAL ANNIHILATION] Preproduction is frequently overlooked and underestimated by publishers and game developers, even today. Taking the time to figure out tools, techniques and a look for a game sounds like good sense, but it is often written off as indulgent fluff. It gets a solid production pipeline in place, and makes it easier for a small core team to share the Kool Aid and quickly indoctrinate new recruits. I firmly believe that every week of preproduction saves at least three weeks of regular development time. It's true. I have notes.

* [TOTAL ANNIHILATION] Y'see, print ads for games almost always followed a time-honored format. This dates back to the time when game art was relatively crude, so some sort of swanky art or a big juicy photograph would be used to build an image for a game. Chris and I were adamant that we sell the game with the game. We insisted that the ad feature a full two-page screenshot. I did a rough layout then went to work creating a big, big screenshot. It had the desired result. Between this ad and our first preview coverage in PC Gamer, we went to E3 in 1997 with lots of good buzz around Total Annihilation. Several competing RTS games had print ads almost identical to this (including the landscape mesh) within a year.

* [TOTAL ANNIHILATION] For a normal unit like a tank we would cache off a bitmap that contained the image of the tank rendered at the correct orientation (we call this an imposter today, look up talisman). There was a caching system with a pool that we could ask to give us the bitmap. It could de-allocate to make room in the cache using a simple round robin scheme. We would store off the orientation of that image and then simply blit it to the screen to draw the tank. Units sitting on the ground doing nothing were effectively turned into bitmaps.

* [FF6] We really focused a lot on trying to make the effects more realistic. Our first step was to create the overall form of the graphical effect in a separate 3D software tool, then we’d add a visual overlay to that form, and then once it looked convincing and realistic, we’d import it to the Super Famicom sprite software and finish up there. Drawing everything by hand would have been ok too, but using the 3D tools allowed us to use light, shadows, and reflections in a way that wouldn’t have been possible otherwise.

---

[⇪]