Introduction

Recently, good reception at GDC received stories about classic games, but there were very few stories about the tools for their development. In this series of articles, we will try to fill this gap by interviewing people who have played an important role in the history of game development tools.

In the first two parts of the series, we talked with John Romero (about TEd Editor) and Tim Sweeney (about Unreal Editor) .

When writing the third article, I was privileged to speak with Chris Norden about the tools he was developing for an FPS / RPG hybrid called Deus Ex . I talked to Chris in San Francisco at GDC 2018.

To Ion Storm: Origin and Looking Glass

David Lightbone: How did you start working on Deus Ex in Ion Storm?
')
Chris Norden: In 1994, I was a Origin programmer in Austin. My first paid project was Jane's Combat Simulations AD-64D Longbow from Jane's Combat Simulations. Initially, it was an arcade game called Chopper Assault. Together with Andy Hollis, I worked on it for two years.



After the release of the game, the last thing I would like to do is take up another military simulator, because I absolutely do not like everything military. From time to time I talked with Warren Spector, who also worked at Origin. He really liked plot role-playing games. I thought to myself: “I also like these games, I want to work on something similar!”

In 1996, Warren left Origin and headed Looking Glass in Austin, the existence of which no one then knew. This studio made ports for Mac games, such as Links 386 Pro . She was also in the process of developing her own golf game called the British Open Championship Golf.

In Origin, the development of Ultima Online was still ongoing. It was called Multima, and it seems to have used the Ultima VII engine. I experimented a bit with him until I quit Origin and joined Warren in Looking Glass.

[Author's Note: Looking Glass's main studio was located in Cambridge, Massachusetts, near Boston.]

Warren wrote a design document, and for some time we worked on an AIR abbreviation (from Austin Internet Role-Playing) role-playing game, which was supposed to be an online project. We wanted to do something in 3D, because while 3D accelerators started to appear. We got a prototype of Voodoo 1 and wrote a small engine on GLide.

We collaborated with Looking Glass in Cambridge. After the release of the British Open, I helped Mark Leblanc and Doug Church with the Thief engine, which was called the Dark Engine .

For financial and other reasons, Looking Glass did not feel very good at that time. The company had great games, but they were rather weak. Therefore, about a year later it was decided to close the office in Austin.

[Author's note: Chris is absolutely right about the games - Ultima Underworld, System Shock and Terra Nova were taken very well by critics, they were among the best games of the 1990s]

At the time of the closure of the office, there were few of us left: Warren, I, Al Jarusso, Harvey Smith, Steve Powers. We all still wanted to work on this role-playing game. After the office was closed, we held each other for about six months, hoping that we would be able to start a new company and do something. We had a very good design document, we began to “sell” it to publishers and communicate with different people. I do not even remember all the publishers with whom we contacted. One of these people was John Romero and Tom Hall, who, together with Eidos, were working on creating a new studio in Dallas called Ion Storm.


I knew John from his early years Id. In 1991, in Dallas, MTV threw a huge party on a ship dedicated to Wolfenstein 3D. There were two cars VR Virtuality Arcade Machine . At that time I was a child and thought, “God, this is the coolest thing in the world!” I met with John back in the days when he lived in the style of “I am too rich to worry about anything”.

John is a wonderful person, I worked with him at Monkeystone Games, helped develop the game for the Gameboy Advance, but that's another story.

[Author's note: the game was called Hyperspace Delivery Boy. For Gameboy Advance, Majesco was to publish it, but at the last moment the company refused to release it.]

We talked to Romero and Tom Hall, and they are: "Warren, you're cool, let's make this game!". And Warren replied: “There is a snag. We will not move to Dallas. We will not move to California. We won't move anywhere at all. We will keep the studio in Austin. So we will remain completely autonomous. You will give me complete control over everything. You will give me money, and everything will be fine. " They replied: “Well, we are satisfied. Resolved. "

[Author's note: obviously, this is too simplistic version of the negotiations, but it gives an idea of ​​what happened]

At the time, Warren had an excellent design document for the game “Troubleshooter,” which gradually turned into a design document called Deus Ex.

So, the six of us founded the studio Ion Storm Austin. At that time, I was the technical director, head of IT, HR, security, and lead engineer. We did not have enough people to do all these things. Therefore, it was necessary to quickly conduct interviews and recruit staff.

The team was tiny. We had three engineers: I myself, Scott Martin and Al Yarusso. Sheldon Pakotti was hired by the writer. We had two design groups of three people. One was led by Robert White, the second by Harvey. It seems that there were still six artists who were led by J. Lee.

Oh yes, and I also hired Alex Brandon because I was a big fan of his music for Unreal. Now we are great friends with him. I introduced him to his future wife, because we were friends in high school. He is a great guy: an excellent musician and well versed in technical details.

Then we hired an administrator, and that's it. And then we had to work hell for two and a half years! [laughs]

Choosing between Unreal and Quake engines

JL: So while the rest of Ion Storm worked with the Quake engine, you chose Unreal. Can you explain how you came to this decision?

KN: No matter how I respected the Quake engine, I knew that we wouldn’t have support at the time. We created a very specific game in which we wanted to be able to do anything. Quake was a shooter, and nothing more. If we tried to do something other than FPS on it, then it would take a lot of work, and we wouldn't get support from Id. They simply burned a CD with the code, gave it to the developers, and left them alone.

JL: In my interview with Tim Sweeney, he called the licensing model of the Quake engine of that time "a xcopy operation for a quarter of a million dollars."

KN: Yes, that's right! I agree, the engine was awesome. At that time he made a revolution, but we knew that a team of three engineers could not rewrite the engine and could not write their own. We simply would not have enough time.

At one time I was a big fan of the Amiga demoscene, C64 and PC. I started watching a video game called Unreal and thought, “My God, is there RGB lighting and full 3D. The engine uses MMX, SSE and 3DNow. He looks very cool! ”But we could not find detailed information about him, so we planned a trip to Digital Extremes in London (Canada). We met with Tim and his team, they showed us all the features of the engine. I also met with Carlo Vogelsang , with whom I now work at Sony - he is in the Playstation department. He wrote the Galaxy Audio Engine: almost everything in assembler, superhardcore guy. In the engine, there was a particle system called Fire. It was all inside the engine. I thought, "Guys, I like your approach."


At that time, they focused on creating super-convenient tools that no one had done before. The Quake tools were good, but to non-technical users they didn’t seem particularly friendly. We had designers who had no engineering skills, and they had to figure out how to use these programs.

So we decided: “These guys have good tools, they all help us a lot, there are a lot of old school guys who wrote hardcore things in the 80s. And how is your licensing arranged? ”They replied:“ We have never done this before, it’s something new for us ”. I think that at that time they did not understand how to create a licensing model. We said: "We have Warren Spector, and he wants to create a game on your engine." When they heard this, it became clear that they really wanted to work with us.

Honestly, I do not remember the details of our license agreement. Tim probably remembers. I don’t remember how much we paid, but I don’t think very much. "

DL: Probably comparable to how much Id was asking for Quake at the time?

KN: I think less! And it was another plus. Their engine was relatively new, but we were not the first licensees. One of the first was Wheel of Time and Klingon Honor Guard.

[Author's note: more details about the Unreal Engine licensing history can be found in my interview with Tim Sweeney about the Unreal Editor ]

Therefore, we decided to choose it. The developers gave us the source code and said, "We will support you as soon as we can." We always talked one on one. If we had a question, we sent an email: there was no technical support system.

We had a lot of problems, because they had never done it before. We sent them a lot of code and questions, had a long correspondence and received updates. But I think it was the right decision. I think if we chose Quake, the game would be much more difficult to create.

In addition, I became a member of the Unreal Tech Advisory Group. We came up with the idea of ​​the first technical meeting, where the heads of all companies that became licensees (there were four of them at that time), got together, discussed ways to improve the engine, scolded Tim for uncomfortable aspects, went over alcohol and food, well, everything usually. I still keep in touch with all these people.

DL: Have you shared with other members of the Unreal Tech Advisory Group?

KN: I think we mainly shared the improvements to the Unreal Editor. The engine was great, but it still had a long way to go. Then, when we were able to hire even more designers and artists, they also began to make suggestions for improving workflows. We either implemented them ourselves, or sent them to the Unreal team, or asked the Unreal team if they could do it faster than we could.

We made many changes to the main editor, but most of them only related to our game. We shared part of the improvements, but most other developers were engaged in completely different games.

I had to write a bunch of systems that I thought were the first of its kind. At least I have never seen them. For example, the animation mixing system; in essence, this is what is today called morph targets or blend shapes. I do not remember that at that time someone did this in games. It may have been implemented somewhere, but it was very difficult to exchange information before the widespread use of the Internet.

JL: Can you talk about the changes you made to the Unreal Editor?

KN: One of the systems, which for no apparent reason at the time was not in the editor, is the visualization of the camera splines.

In the first versions of UnrealEd, you had to drag the camera and set the points of its path. In this case, it was possible to see the points, but not the connections between them, which determined the path of the camera.


JL: It's like a game “connect the dots”, but without numbers!

KN: Exactly! The spline had control points and designers could not always understand what the path would look like. They wanted to know exactly how the camera would move along the way. So I added this system, and they liked it.

It was very simple. I mean the simplicity of the code: draw the coordinate axes at each main control point, and then draw the control point to actually see where it went. It really helped the designer, and to make such a system was very simple. I do not know why we had to add it. Probably Tim did not think she would really need it.

JL: It's funny, because if you recall the first demonstration of the Unreal game to the public, the first thing people saw was the camera flying around the castle, that is, it didn't seem like Epic had created any camera paths.


KN: I think the reason was that many of their level designers were super-techies and they used to model things like that in their heads. But the video game industry was gradually growing, so it was necessary to create tools for people with different levels of experience. Not every designer was an engineer, and even more so today! This was the exception rather than the rule. Therefore, the tool had to be convenient and simple.

By the way, I still do not know why Pawn is indicated by the head of a dinosaur.

JL: [laughs] Yes, Tim and I discussed this in an interview! By the way, have you regretted any technological decisions you made?

KN: We used UnrealScript too actively. This was one of the mistakes. UnrealScript was very flexible, but too slow. We needed to write much more on native C than on UnrealScript.

True north and phony crashes

[Author's note: at this stage of the interview, I opened the Deus Ex Editor (version for UnrealEd), as well as the documentation of the Deus Ex SDK]

DL: In the installer of the Deus Ex SDK there is a Docs folder with a couple of documentation files that you wrote, Robert White, Sheldon Pacotti, Al Jarusso and Scott Martin. Can you tell who these people were and what they worked for?

KN: Al worked on the dialogue editor. Scott worked on AI. I did ... everything . [laughs] Among other things, I was an assistant director and lead programmer. But we did a little bit of everything, because there were only three engineers in the entire project from start to finish.


Chris Norden (bottom left), Al Yarusso (right and top of Chris, with the clock on his hand), Robert White (in the middle row, slightly to the right of the center, in sunglasses), Sheldon Pacotti (bottom right) and Scott Martin (in the second row, rightmost, also in sunglasses)

JL: There is a section in the documentation for the editor that says, “Unreal does not have native support for vertical ladders, but they are added to Deus Ex.” Can you tell us more about this?

KN: There is an interesting story with ladders, because we needed to move around the whole level, and in first-person shooters of that time, inclined ladders and smooth lifts were traditionally used for this.

In one of Warren’s decrees (because design is the law!) It was said that the player must be able to perform any mission in any way. The key idea of ​​the game was that if you wish, you can go through it entirely, without ever having fired. In fact, we did not quite succeed - there are several zones where you need to shoot a couple of times, but we were very close.

JL: I think in the sequels, the developers did succeed.

KN: Yes, I guess.

So, the player should have had the opportunity to go through the whole game, never having fired. In addition, he could go through the whole game without doing anything other than shooting. The player could go through the whole game so that it was never discovered by the enemy. It was possible to pass it in completely different ways.

JL: Was the lack of vertical stairs one of the topics you discussed with Tim at the Unreal Tech Advisory Group meetings?

KN: To answer, I need to find and see in the script code if it says “Fuck you, Tim!” [Laughs], because that's exactly what we did when we were angry — we wrote down comments to remember this later.

When we began to think about how to add support for vertical ladders, we initially argued "let's create the geometry, and then, perhaps, we can do some clever physical tricks so that the player can grasp the crossbar with synchronized animation." But after we decided - well, it's all to hell, too complicated.

JL: [laughs]

KN: We needed to do it very quickly, because the designers required to create this mechanic.

So as a result, I had to go to hellish hacks. In the engine was the concept of "texture groups". In essence, this is a string label assigned to certain types of textures to make them easier to sort. We could request them in code. Therefore, we thought: “why don't artists simply make some textures so that you can climb them?” After that, we simply added them to the texture group, performed a raycast to recognize them, and then simply with some restrictions stuck the player to them in the direction of its movement. It worked well, but not always perfectly, because when the player climbed to the top of the texture, the beam was no longer emitted into it, and we had to push the player up and onto the platform. That is, the solution is not ideal, but as a result it worked. It was a cheap and simple hack.

Today's readers may think: why there were no stairs in the engine, is this generally logical? But in those days there was nothing. They were just BSP fragments, we had no static meshes, nothing like that.


JL: In UnrealEd there was a very cool generator of spiral steps [laughs], but there were no vertical ladders.

KN: Yes, that's right ... It seems that we scolded the designers for using it, because it created holes in BSP. The staircase looked beautiful if nothing was around. But as soon as you start to make angular cuts in the BSP, you can get small holes in the BSP, through which you can fall through, but the holes themselves are not visible. This function caused a lot of pain and we forbade its use. She looked good, but was broken ...

JL: The documentation also describes a class called DeusExLevelInfo, containing information about the map (for example, whether it is multiplayer), the name of the author of the map, the location of the mission, the number of the mission, and so on. But I would like to ask you about TrueNorth.

KN: [laugh] It was a type of BAM engine Unreal: Binary Angle Measurement (binary angle measurement)!

JL: What are these crazy numbers ?!

KN: At that time, performing floating point operations was very expensive. The iron was weak, and the memory was not enough. 360 degrees were not described by an 8-bit number, which would provide 255 units of accuracy, that is, about 1.4 degrees per unit, which would not be enough. Tim used for orientations a 16-bit number, which gave greater accuracy.

For a programmer, all these numbers are quite simple. These are only powers of two, no problems, you can calculate them all in your head. But designers and artists had difficulty. Therefore, we have come up with small simplifications that help developers remember them.

[While we were working with the editor, Chris got to the Decorations class]



KN: Decorations was also a huge class. All the meshes with which you can interact are decoration. That is, almost everything in the game!

JL: In the Decorations section of the documentation, it’s written "We warn you that when changing some of the fields that are not listed below, the editor may fail." Do not remember why it happened?

KN: [laughs] Honestly, I don’t remember. I think, because Decoration was such a large class, and it had so many Epic functions that interacted with the engine in a strange way, that instead of explaining to a designer who does not understand technical subtleties why a certain field can lead to unexpected behavior, we simply they said "do not use it, otherwise the editor will crash".

JL: [laughs]

KN: Something like scare tactics. At the meetings of programmers, we wondered: how to explain to users that this would damage the BSP chain, and we need to do this and that? Let's just tell them that the editor will crash.

I should study the code again, but it seems that we are even guilty of hiding intentional failures in some places in order to scare away too deeply climbing users.

JL: Come on. In the ParticleGenerator section it says “One of the main functions is that it can be turned on and off with the help of triggers and unTriggers”. That is, in the version of the Unreal engine with which you worked, it was impossible to turn particles on and off?

KN: At the time, no. If you inserted a particle system, it was constantly present and never turned off. It seems to me that this is a strange oversight.

The rest of the Unreal particle system was awesome. Most of it was written in assembly language. It was procedural, and was written very well compared to everything else. Designers loved her. In fact, even too much. It was possible to kill the entire frame rate, but they went crazy, adding more and more transparent layers.

At that time, we still had to support software rendering, then hardware rendering was not yet widely distributed. Tim had amazing programming skills and wrote a great software renderer, he was great.

[Considering various objects in the game, I noticed in the Properties panel a category with an unusual name]

JL: What is this Smell property?

KN: The scent was needed by animals to take a trail. In fact, dogs can track the smell nodes. If I remember correctly, then moving through the levels, the player could leave the smell nodes that operated for a certain time.Therefore, we made it so that dogs could smell it.

JL: That is, if you hide behind a box, people will not find you, and dogs can ...

KN: That's because it happens in reality, and we thought it would be an interesting gameplay aspect. However, it seems, in the end he was cut out. Since there was no graphic feedback, this concept has proved difficult to explain to the player.



[We are opening the Intro level, in which there is one of the most iconic objects in the game - a big frightening hall with a statue of a huge hand holding a rotating globe. She is shown in the introductory video of the game]

DL: I have a question. I do not see the mirror of this geometry under the floor. In other games, mirrors were simulated by placing duplicate geometry on the back side of the floor ...



KN: No, the mirrors were real! They were very slow, so we asked designers to use them rarely, however, these are real mirrors.

In fact, when I wrote the laser code ... [laughs]

DL: [laughs] I see what you are driving at ...

KN: ... I actually had to check for the presence of mirrors. I had a test level where I tested the code for all devices. When I wrote the laser pointer code, I created a reflective mirror disco ball, and then built a room with mirrors at both ends. I took the laser pointer, sent it to the disco ball, and it worked!

Of course, the frame rate fell below nowhere, because you had to trace all the lines ...

See the light wave: command line tool LWO23D

[Author's Note: LWO stands for Lightwave Object. This is the 3D geometry format of Newtek's Lightwave 3D software package , also in Texas, just like the Deus Ex team at the time]



Screenshot from Tack's Deus Ex Lab

JL: Why did your team decide to use Lightwave?

KN: Our artists knew him well. Therefore, we had to adapt.

DL: Tell me more about why you wrote the exporter as a command line tool.

KN: At that time, and even now I often write small command line tools to automate tasks. I’m an old school programmer and I don’t like unnecessary complications. I mostly don't like C ++. I do not like templates. I do not like all that time is wasting.

When I write command line tools, I create a Win32 batch file, get rid of everything built in, start with an empty file, with int main() , and just move on. It is a fast and portable solution that doesn’t cause problems.

JL: I think exporting static meshes was a fairly standard process. But tell us how you exported the animation.



Screenshot from Tack's Deus Ex Lab

KN: There was no skeletal animation in the game. I do not know a single engine of the era in which it is implemented. Therefore, everything was done by mixing vertices. At the time, skinning was very expensive. No GPUs, everything needed to be calculated on the CPU and to avoid floating-point calculations by any means.

Inside Lightwave, the designers created skeletal animation, and then displayed its keyframes. It was necessary to create a T-pose, because in order to mix animations it was necessary to start from a common basis. That is, for proper mixing, the animation was essentially offsets from the T-pose. Mixing was performed on the side of the engine.

JL: So in the Unreal game, everything was the same?

KN: Probably yes. I don’t think Tim added skeletal animation to the next version.

Talking heads: ConvEdit and Lipsink

[Now we open the folder ConvEdit]


JL: Tell us about ConvEdit

KN: It was Al's brainchild, he wrote it in Visual Basic.

JL: Like UnrealEd at the time.

Yes, in those days there were not many possibilities for a simple interface implementation. There was Delphi and several other UI frameworks. If you do not use them, then you have to write it all natively, for example on the Win32 API, GDI, and all that. It was a huge problem.

That is, Visual Basic, which today seems rather primitive, was very good at that time - a simple visual framework with its own programming language, similar to Basic, the predecessor of C #. He allowed us to very quickly prototype functions and write tools.

[Note: If you are interested in how Visual Basic was used in game development tools of that era, then read my interview with Tim Sweeney about the Unreal Editor ]

Sheldon basically used it. He needed tools to control the camera, tools to control the sounds. He wanted to use many cinematic tools that no one had used before. I first learned what a rostrum zoom is when working on this game with Sheldon.

I think even today this tool is still in use.

By the way, Sheldon had carpal tunnel syndrome (RSI, Repetitive Strain Injury), so the seal became a torture for him. He worked almost entirely on Deus Ex using voice transcription in the Dragon Dictate package, which at the time was much worse than today. Sheldon even had to wear orthoses, because the syndrome was very strong.




JL: Wow! I did not know. The game had a lot of dialogue and a bunch of branches ...

KN: A huge amount of data even for one mission.

Sheldon wanted to have strong control over the game and many interactive dialogues. He wanted the player to make a meaningful choice. He and Warren hated when it was necessary to click dialogs without having a choice. They wanted the player to interact with the characters and choose meaningful things, so that the game would flag and remember how he communicated with the characters and behaved when passing.

JL: From the first passage of Deus Ex, I remember Anna Navarre's briefing at her office. As usual in any video game, I began to run around the office, doing all sorts of nonsense, while the NPC finished their dialogue. Suddenly she stopped her dialogue, turned to me and asked: “What the hell are you doing?”

KN: [laughs]

JL: For a second I froze, and asked myself: “Did this really happen?” It was such a significant event for me from the point of view of immersion in the game. None of the games before this did not occur. I suspect this is partly due to the Conversation Editor.

KN: One of Warren’s commandments said: “If a player is in someone’s office, behaves like a cattle and smashes things, then the character must say something! He should not ignore the player because it is unrealistic. ”

JL: Were there any aspects related to cutscenes for which it turned out to be particularly difficult to create tools?

KN: We had a lot of dialogue, and they were all voiced. We spent weeks in a recording studio, recording dialogues with actors. This meant that we needed to think about synchronization of lip movement (lip liner). I thought: “How to create a lip-link for such a number of dialogues?” After all, we had not only a bunch of phrases, but also several languages.

At that time there were not so many tools to help in lip-liners. Most developers performed pre-processing: they ran the dialog in the tool, output the data file, and then reproduce it. But I decided: "We will not have time for this, and if we have to re-record the voice, then we will have to rework everything again."

So I began to think that there must be some way to do it in real time using dynamic sound analysis. In college, I studied electrical engineering, and decided to sort it out myself, without telling anyone.

JL: [laughs]

KN: I thought: "See if I can do this and surprise everyone." Again, I do not think that someone has done something similar before, but today this technique is found everywhere.

At that time, of all that I saw, Half-Life was the closest to such a system. The developers used the Envelope Following technique, which literally was this: open and close the mouth depending on the volume of the sound. The system worked, but it didn’t look very realistic.

JL: In fact, it was a jerking twitch.

KN: Yes, exactly, exactly.

I remember, I once discussed with Gabe Newell how they did this task, and he said: “Oh, just use the Envelope Following , and that will be enough. Everything else will be too complicated. ”

Then I returned home and began to figure out mathematical calculations, and then I wrote a system that performed FFT ( Fast Fourier Transform ). Once again, floating-point calculations were very expensive at that time, and I probably wrote a simulated integer approximation.

She analyzed in real time a short excerpt of audio recordings and extracted the main frequency components, and then tied them to six or seven different phonemes.

I secretly asked one of the artists to model several blending shapes: I needed “o”, “a”, closed lips and the like. He asked why, and I answered that he would just do it and give me the data.



Fast Fourier Transform (Wikipedia image) and a series of Preston Blair phonemes

JL: [laughs] Looks like this solution ideally suited the mix of animations that you used in Deus Ex.

KN: Yes, exactly, perfect.

So, he gave me the data, I wrote mathematical calculations and, as I could, I manually attached the forms. I did not conduct serious research, and the system was quite expensive in terms of performance.

I created a test level with a huge head in the middle, and fed her a couple of lines. I checked the phrase in German, in English, in French, and everything was synchronized perfectly. I thought, “Damn, this is awesome! Actually it worked! ”

I found Warren and told him: "I want to show you something cool." Looks like he was dumbfounded. [Laughs] He asked me: “What the hell can we put this into the game? It's just awesome! ”

As a result, we released a game with this system, but for the sake of performance I had to cut it down severely, which caused a decrease in visual quality. But my first test level was great. I still think that it was the very first real-time lip synchronization system. I do not remember that before someone did something like that.

Perhaps it was worth patent it. But I do not believe in software patents, because I think this is a vicious practice ...

I also had a big argument with one of the artistic directors in Dallas, who wanted to use this system in Anacronox. She should have quit before our game. I said: "I will not mind sharing, but I want Deus Ex to be the first game in which it will appear." He said: “No, you must give it to us!” He practically yelled at us in the hall. I replied, “No, I shouldn't,” and Warren supported me. It turned out that we released the game first, so it didn't matter anyway. In fact, I think that as a result, they independently implemented their own version of the system, because we did not want to give it away. It may have been selfish, but I wanted us to be the first to be able to demonstrate this function.

All the rest, produced by Ion Storm, was developed in Dallas: Dominion: Storm Over Gift 3 , Daikatana , Anacronox - everything is made in Dallas. In Austin, only Deus Ex was created, and there was only our team, no one else. We were in a bubble, quite isolated from the office in Dallas, and this was done on purpose. We did not want to mess with a bunch ... I will be frank, with a bunch of all their garbage. This separation was completely intentional and very important for us. Our team and their teams did not exchange technologies, no real contacts.

Conclusion

DL: So, to summarize, I want to ask: if you could give advice to tool developers reading this article, what would you say?

KN: Listen to your customer. Never write tools "in vacuum". As an engineer, you can think: “I can use this tool in this way, and this method is most effective, so I’ll write it that way.”

But almost always you are mistaken. You should listen to designers and artists because their work process is very different. They work completely differently than others. The tool will not use you, most often it is for them.

JL: Have you ever met with such a mentality in the teams with which you worked? And how did you deal with it?

KN: You just need to tell the programmers: “What do you think, why does the user have this problem? What do you think the problem is in the code? Or maybe the problem is in the structure of the screen? Maybe the font is too small? Wrong button color? Perhaps you are doing something non-standard? "

Because if you look at most of the tools with a professional design, they are usually quite consistent. There are design guidelines for how things should work.

A creative team should be able to use these tools. It should not be so that they had to read the documentation. In an ideal world, everything should be obvious.

Today, there are designers of UX / UI, but at the time they were not, so we had to create the interface design ourselves, but with feedback from users.

Therefore, sit next to users and see how they use the tool. We watched them work in Lightwave. When we wrote the first version of the tool, we sat side by side without prompting what to do, and looked at them, making notes, such as “there were difficulties with this” or “they constantly have to climb into the menu to find that”, or “maybe it’s worth the hot key. ” Just look at them, learn and adapt.

So you really need to think about the workflow of designers. It is necessary to minimize unnecessary movement, minimize crawling on the menu, try to add hot keys. We actively promoted shortcuts for all functions, because they speed up the workflow. In the process of studying the tool you greatly speed up the work with the help of hot keys, and you do not need to climb the menu.

You do not need to fall into the classic trap for engineers: “I know better, I wrote down the instrument, I know how it works. If you can't use it, then you're just an idiot. ” This is the worst thing to do when designing a tool.

JL: Excellent advice. Thank you very much, Chris!