How do tech artists make an impact? Everywhere I‟ve been, the successful tech art team makes useful stuff for artists over and over and learn as they go. The unifying talent is the ability to present simple and intuitive interfaces to complexity.

TA如何产生影响？在我所到之处，成功的TA团队都为美术创造有用的东西，并且不断学习。一致的特长是可以把复杂的问题用简单直觉的交互解决。

In building the Tech Art team at Turn 10, I found that in the battle between game features and artist tools, there is only sadness to be had. It‟s tough to prioritize the two in the same bucket.

在搭建Turn10的TA团队时，我发现增加美术效果和制作美术工具之间的矛盾。很难给他们的重要性排序

Instead, it is much easier to justify the need for tech artists when you present the fact that you can spend two weeks writing a tool that would save a man year‟s worth of time over the course of a project. Splitting up the problem by looking at separate cost savings helped justification of my team vs. arguing in the apples to oranges comparison of game features to artist tools. It also helped that allocating some resources to the Tech Art team enabled our studio to take artist support and various existing art problems off developer plates.

然而，证明TA存在最容易的方式是，花两星期写一个可以节省项目中一个人一年时间的工具。应该分解问题，发现可以节省时间的工作，那可以证明我团队的价值，而不是争吵和比较应该增加游戏效果还是美术工具。这样也可以让TA组获得一些资源，给工作室美术提供支持，并为程序分担负担。

In the end, presenting this information to our studio management, we have a Tech Art team that‟s made up of myself, 2 traditional tech artists and 2 tools developers. I‟m sure there will be evolution of this balance, but the important thing is that looking at things with this lens helped us establish a tech art group.

最终，我们的TA组有两个传统TA，两个工具程序和我，我相信团队会成长的，但重要的是这个时间帮助我们成立了TA组

In thinking about what I‟d talk about for a more technical contribution, I thought about the diverse mix of skillsets I knew would be represented here. What can a tech artist who calls himself a rigger have in common with a VFX artist? As I mentioned before and you‟ll hear throughout the day, the common thread binding us all is our ability to solve a wide range of problems with technical fundamentals. For me, having been involved in numerous portfolio reviews for riggers and other TD roles at Disney, what differentiates the great from the mediocre is the demonstrated ability to dive into at least basic programming to enhance your skillset or productivity.

我觉得我要聊聊技术上的事情，叫自己TA的rigger和特效美术有什么共同点？共同点是我们能用技术的基础解决广泛的问题。就我而言，参与评审争夺rigger或者disney的td的经理，伟大和平庸的区别是学会基本的编程并提高技能点或生产率

In our industry we have mediocre Batman‟s and awesome Batman‟s. You become an awesome Batman by continually adding tricks and new weapons to your toolbelt. In the spirit of my topic, you have to “start somewhere”. For the remainder of my section, I wanted to demonstrate how a small investment in basic scripting can make you a more powerful tech artist, regardless of what you consider your primary focus. These fundamental skills are core to the

functionality of my team.

在这个行业中有平庸和伟大的蝙蝠侠，你通过不停为自己增加trick和武器让自己成为伟大的蝙蝠侠。但你得从一个地方开始。我会展示一点小小的编程技巧如何让你成为更强的TA，无论你的主要关注是什么，这些基础技能是我们团队功能的核心。

I don’t think there’s a domain in game development that I haven’t heard of a Tech Artist infiltrating. We’re no longer holding things together from the shadows- we’re taking on mission critical roles and features from start to finish

我不认为在游戏开发里，有领域TA没有涉及过。我们不再在阴影中做事，而是自始至终承担重要的角色和特性。

Better tools, better pipelines, better workflows, a better type of development for artists and all members of our teams. And over the last few years our efforts have been a resounding success. I get the feeling for the first time that studios are by and large starting to understand us. This is important. Part of the reason Jeff Hanna organized the first TA Bootcamp last year was to address this issue of developers in general not knowing what to make of this uncategorizable phenomenon called Tech Art.

更好的工具，更好的流水线，更好的工作流，为美术和团队人员更好地开发。过去几年我们的努力相当成功，我有一种感觉，整个工作室第一次开始理解我们。这很重要。Jeff Hanna去年第一次组织TA Bootcamp的原因大概是解决开发者中常见的，把这种无法归类的现象叫做TA

The first key is to get a process for support tasks into place. Unless your Tech Artists can focus and have room to breathe, they are never going to learn any of the other necessary skills.

The second key is to set up code review. I don’t think any subject has caused so many headaches for me but it is absolutely essential, and I’m going to talk about the how and why of reviewing code.

The last area is collaboration. Collaboration both in working on common projects, and team cohesiveness. To develop those big tools and systems effectively, you need to be able to apply more than one or two people to a single problem.

首先是要把支持流程放到位，除非TA能专注并有空闲呼吸，否则他们不能学到新的技能。其次是设立代码review，没什么比这更头痛了，单也尤其重要。我会讲如何和为何做代码review。最后是合作，合作在同一个项目中，以及团队凝聚力。有效开发大型工具和系统，你需要一个问题上投入不止一两个人。

Providing support has side effects. The codebase grows. It grows much faster than it should, because code is rarely shared properly and is often copied and pasted, or existing code is unknown and unused. And the relationships TA’s have with customers is different for every group. What we develop when we work like this is not shared property, and we never develop a shared identity. We don’t develop cohesive practices, a unified style, a vision or architecture. So every step further down the individualized support path we go, the more redundant work we do, the harder things are to unwind. The stack of debt grows and grows.

提供支持有副作用。代码增长比预想更快，代码没有很好地共享，而是复制粘贴，现有代码位置和无用。TA和用户的关系在每个组又不一样。我们这样开发共享的不勾，没有开发共同的identity。无法形成有凝聚力的粒子，一个统一的风格，事业或架构。因此我们每一步前行，都让支持更加独立，越来越多冗余的工作，越来越多的困难需要解放，债务越来越多。

This works as long as your TA’s have time and success. But I’ve seen it with every competent TA I’ve worked with. You build up this stack so you can work effectively. And eventually it turns to shit, and takes all your effort to support it. And now you can’t really develop new features properly. Your truck factor becomes high. Your code becomes brittle. Andyour genius and ethic can keep things together for a while. But at some point, you run out of hours in the day. Until then, you can give high quality support, which is expected- you’re a skilled bunch and ours is a labor of love. But as soon as you hit that wall, you start to stumble, you fail hard. The end goal of a support process- what all the changes I propose hope to achieve- is to have the most productive Tech Artists possible.

但我在每个合作过的有能力的TA上见到过，你增加这个栈，因而工作的更有效率，最终它变成了屎，需要花费你所有的经历维护它。这样你再也没有时间开发新特性了。你的负重越来越大，代码越来越脆弱。你的天才和伦理可以为之一段时间。但到某一时刻，你用尽了每天的时间，直到那时，你还可以提供高质量的支持，这是期待的。你是一捆技能和工作狂。但到达那之后，你开始跌跌撞撞，狠狠摔到。支持的最终结果，也是我期望的，是拥有最高效的TA

Realize how much support you do, and trust others to do it. That‟s it. Most people don‟t realize just how much time they spend supporting artists and designers, answering programmer questions, adding features, fixing bugs, twiddling around with stuff. A support process forces a reckoning with this behavior.

理解到你做了多少支持工作，相信别人去做，就这样。大部人人没有意识到花费了多少时间支持美术和策划，回答程序的问题，增加新效果，修复bug。支持性工作要这样做。

And the idea is, once you realize how much time you actually spend in support, and once you have a process where other people can actually cross over and help you, you can start to breathe again. It is the first step down a long road to building technology.

意思是，一旦你意识到在支持性工作上花费了多久，一旦有一个流程可以让别人帮助你，你可以喘口气了，这是制造技术漫漫长路上的第一步。

My recommended support structure is something like this. There is of course the direct feedback, via face-to-face or other channels. That is not going away. But important here are the technical mechanisms. Build a way to catch when errors happen in your tools, and get those errors, along with callstack and logs, reported to your team as emails, or into a bug tracker, or whatever. I’d also suggest giving users a big shiny ‘HELP’ button when you can’t do it automatically. These things are not hard to set up.

我建议的支持性结构是这样，如果有直接反馈，无论通过面对面还是其它渠道。那还是如此。但更重要的是有技术机制，创造一种在工具中捕获报错的机制，获取那些报错，以及堆栈log，向你的团队汇报，或放进bug跟踪列表。我也建议给用户一个善良的帮助按钮，当它不能自动工作时。这些不难设置。

Everything goes into a single task list. Let the Tech Artists draw from this list, and manage it internally. Do not involve management or gate tasks by assigning them out in some bureaucratic fashion. And use daily standups and the task list to keep track of what people are doing.

每件事都进入一个任务列表，让TA从这之中抽取，并内部管理。不要卷入管理，或者官僚式的不知。用每天站会和解决的列表来跟踪每个人在做什么。

A successful culture of review creates a mind meld between your team. You have shared domain knowledge, you feed off of each other‟s skills, you develop a single cohesive set of standards and idioms. There are a hundred benefits to code review; and being here at GDC, at the forefront of the industry, probably means these benefits are obvious.

成功的review文化在团队中创建智慧的融合。你们享有共同的知识，增加各自的技能，开发一致有凝聚力的标准。代码review有几百条优点，能出现在GDC，在行业前沿，意味着这些益处时明显的。

And herein lies the problem. It takes at least a few weeks for code reviews to start reaping benefits. It takes even longer when you have a team that has never built technology properly and, quite honestly, don’t care much for software and project management theory. So code review sounds great, people start doing it, but it takes time, and causes tension. Because they cause tension,

someone decides to make them optional as a way to diffuse the tension. Now because they’re optional, people don’t do them thoroughly or at all, so they have much less benefit. And if they have less benefit, they become more optional. This is a vicious cycle that results in people not doing reviews at all.

这里有一个问题，至少花费几周时间才能让代码review起到效果。甚至更长的时间，当你的团队从没建造过合理的科技，或者不关心软件和项目管理理论。因此虽然代码review听上去很好，人们开始做，花费时间，并造成冲突。因为造成冲突，一些人决定把代码review变成可选的，以消解冲突。既然已经是可选了，大家就完全不做了，因此收益更少。收益更少，也就更加没有意义。恶性循环使得大家不再review了。

And there is a cure but it is a hard pill to swallow. Code reviews are mandatory, and a single Tech Artist has the final word. Let me be clear about this and state in no uncertain terms: I have never seen or heard of code reviews being successfully implemented on a Tech Art team without them being mandatory and without a single arbiter of correctness. It doesn’t matter who the arbiter is- it can be the lead, or a senior member, but there needs to be a single person responsible for the process and the quality of the reviews, at least at first. And it doesn’t matter whether you do over the shoulder reviews, or have software, or use email, you just need to make sure every Tech Artist is getting their code reviewed, and reviewing other people’s code. Just remember though that making code reviews mandatory allows them to be successful, it does not cause them to be successful.

良药苦口。代码review时强制的，有一位TA有最终决定权。让我说的更明确些。我从没见过在TA组里成功执行，如果没有强制也没有单一人决定正确性的话。无论是谁决定，leader还是资深，但要有一个人负责起这个流程和review的质量，至少是第一个。无论是身后review，还是软件或者邮件，至少要让代码review的，以及review其他人的代码。记住这能让他们成功，但不能使他们成功。

But over the past few years, this myth has largely disappeared in the professional programming world. But we have our own version of it in the Tech Art world. We have the animation guy, the character guy, the environment guy. The guy that wrote system A and the girl that wrote system B. Each of us love the idea of being a badass Sherlock Holmes in our field of expertise. We love having the freedom to do what we want to do, to not really have to answer to anyone, to do amazing things and get the silent glory. But as fun as it is, we need to be the police force as well. We need to be clever like Holmes, yes, but we also need to give out parking tickets and we need to be able to respond to crises or operate in force. There is a time and a place for us to act as a solitary genius, but it must become the exception, and not the rule.

在过去几年，在职业程序员的世界中神话逐渐消失，但TA世界中还有。我们有动画的人，角色的人，环境的人。A写了一个系统，另一个写了另一个系统。没人都很享受在自己的领域里程为福尔摩斯。我们享受做自己想做事情的自由，不需听命别人，做美好的事情获得安静的荣誉。但尽管有意思，我们也要做警察。我们需要福尔摩斯，但也要发停车票，应对灾难或者应急。有时需要像天才一样工作，但那是例外，不是规则。

But the support splits our focus- we need to provide support, and develop new tech. And when it comes down to it, support is going to win every time.

So we‟re stuck providing full time support, but we all love doing those bigger things as well. So we work 50, 60, 70 hour weeks, and develop those bigger things in our spare time. And then something terrible happens. The new tech we develop comes with its own support burden, and suddenly we‟re working overtime just to provide support.

但是支持分散了我们的精神，我们需要提供支持，开发新技术，但当它来临，维护会占据所有时间。我们卡在提供全职支持上，但我们也爱做大事情，所以我们工作50 60 70小时，在空闲时间开发更大的事情。突然可怕的事情发生，新工具有自己的负担，忽然我们必须超时工作来提供支持。

I‟ve been guilty of it and I‟ve seen it time and time again. So not only is collaboration a requirement for building technology, it is also a requirement for keeping your own sanity. Being able to share responsibility means you can load balance your

team effectively.

我很愧疚，我见过它不断发生，在制造科技上，合作时必须的，也是让人省心的方式。分担责任使得你的团队高效工作。

So we come back to fixing our support process. Remember this unique stack-per-TA? This is an impediment to collaboration. So we need to get rid of it. Now we have people that are actually sharing code. This is a form of collaboration, to be sure, but it is a reactive, not creative, form. It finds code that should be shared, and shares it. When problems come in, they can be fixed or informed by multiple people. It is collaboration for support. This is important but this isn’t the creative form of collaboration I’m talking about here.

我们回到自己的支持流程，记得每人一个stack嘛，那是合作的累赘。我们需要共享代码，这是合作的形式，但这是反应性的而不是创造性的，我发现代码需要共享。当问题来临，它能被很多人修正，这是支持的合作，这很重要但不是创意性的合作。

But if we combine that sort of reactive collaboration with code review, we reinforce the ability of the team to work together, grow and learn together. In my experience, I’ve found that it isn’t until a team establishes code review that they establish a ‘team identity,’ where they turn from a group of individuals who have the same job title, into a team that can collaborate together to create new things, as a team, and handle the burdens of tech art, as a team.

但我们如果把这些反应性的合作和代码review结合起来，我们增强了团队协作的能力，共同成长和学习。在我的经验里，直到建立了代码review，才建立了团队的认同。把一群一样title的人组建成一个创造新事情的团队，处理TA的重担。

So we combine these two things- reactive collaboration, and team unification- and something marvelous happens. We move past the point where we can only load balance support, and we can start to load balance new features, new tools, internal work, everything. Suddenly we have the bandwidth to build technology.

我们结合了反应性的合作和团队凝聚，奇迹发生了，不仅减少了负担，又开始创建新的特性/工具等等。忽然我们有了建造科技的宽度。

Collaboration is your ultimate weapon against the likelihood of failing as your team succeeds. As you get higher on this pyramid of responsibility, there is a rapid increase of the skills and amount of work required in the tasks you are asked to do, and want to do. And a Tech Art team, as a rule, rarely has the experience with the sort of tasks that are at the tip of this pyramid. These are studio-wide features and tools that usually have very little to do with the specific expertise of Tech Art. Or they are super-critical, paradigm-shifting, fundamental changes to art pipelines, that can hose a team if not executed properly.

合作是对抗失败的终极武器，当你在金字塔越高时，需要的技能和工作越多，想做的越多。但团队很少有这种金字塔尖的工作，有工作室范围的特性和工具跟TA的特殊只能无关。只有对美术馆先特别关键/范式转移/基础挑战，如果执行不好会困住团队。

I‟m going to be straight with you. Making the changes I‟m advocating for is going to rub some people the wrong way. Changing how they interact with artists, forcing them through procedural hoops for code reviews, putting them into collaborative projects where they feel awkward- there‟s no way to get around the fact that this is going to have a negative impact on morale. You have to go into this with the belief that the suffering is temporary. Making these changes has led to huge gains, but I can say personally they‟ve caused hardships, for me and for others. I‟ll talk about some of those difficulties in a bit, but in all cases, we came through it together and were better off for it.

我会很直白，这些改变会让一些人生气，改变他们与美术交流方式，使得他们必须要日常review，把他们放进合作团队让他们感到尴尬。如果不能解决会对团队造成很大冲击。你必须相信困难时短暂的，这些改变带来巨大成功。我必须要说这造成了痛苦，对我和其他人。但最终我们克服了。

But the goal of this presentation isn‟t to encourage you to become a programmer. We. Are. Tech Artists. We need to respect that history and who we are. If you‟re uneasy with these changes, I‟m not asking you to forsake what you love. I‟m asking you to sharpen or relearn your programming skills, so that you may become a better Tech Artist. You can know how to program without being a programmer. And knowing how to program well will allow you to get stuff done quickly, which makes you a better Tech Artist.

最终的目的不是让我们变成程序员，我们是TA，我们需要尊重历史。这些改变不容易，不是让你放弃所爱，而是让你增强程序技能，成为更好的TA。你可以不做程序员但知道如何变成。知道如何编程让你做的更快，成为更好的TA。

The reason I feel like this is a valuable topic is that well, everyone is writing foundation code in the Tech Art world today, from students and jr Tech Artists, all the way up to old men like myself, so I get the impression that everyone understands how to write tools and build pipelines for artists, but what I feel like we‟re missing is conversation around how to build tools and pipelines for Tech Artists. This can be a bit of an uncomfortable topic, because it really is the drab, unsexy work that you can‟t really convince a producer to let you do, and you‟re not gonna get that appreciative feedback from artists for writing the Big Red Button, and I know as Tech Artists, we like to dive in, we like to just get our hands dirty and go. But having worked on both ends of the spectrum, I can tell you right now that I don‟t think I could ever work in an environment that DIDN‟T have a Tech Art infrastructure, and I hope this is something we can all start to take to heart as a discipline if we aren‟t already, because otherwise…

我觉得这是一个很有价值的话题，每个人都在TA界写代码，从学生和初级TA，直到像我这样的老人，似乎每个人都知道如何给美术写工具和建立管线。但是我觉得缺少如何建立工具和管线的对话。这可能是一个令人不安的话题，因为它真的是单调乏味的，你不能真正说服制片人让你做，也不能获得美术的赞赏的反馈，我知道作为TA，我们喜欢深入，喜欢禽兽参加。但是我已经在频谱的两端工作了，现在我可以告诉你，我不认为我可以在一个没有TA基础设施的环境中工作，我希望这是我们可以开始把它当作一门学科。

Jump back to today though, and I feel like things like this have been pretty well settled and the idea of Tech Artists as programmers is definitely not quite the foreign concept it was back in those dark times. So That‟s the big overarching premise here is that we are very much software engineers nowadays, and we should start thinking, acting, and working like software engineers.

我认为作为程序员的TA相如今当能被接受了，巨大的前提是我们很像软件工程师，开始像软件工程师一样思考行动和工作

At some point in your career you may have written a really quick, dirty, one off tool, in the privacy of your own cubicle and of course you washed your hands afterwards, all the while thinking to yourself “ah, it‟s just a one off, we‟ll just fix this content and call it good.” This in and of itself isn‟t a bad thing, and it‟s not even a bad thing if you write a lot of one-off tools and scripts. What differentiates between good and bad one-offs is the underlying framework on which the tools are built. Much in the same way that we like to think of/design UIs in our tools to be layers on top of separate core functionality, we can abstract that idea out to tools in general, what we call tools should really just be layers on top of our infrastructure and frameworks that manipulate content and data, and it‟s bad infrastructure that keeps you from writing those one-off tools while preserving process and data integrity…

在生涯的某点你必须要写很快很脏一次性的工具，只有你自己知道，之后洗的干干净净。你一直在想，反正一次性的，我们修好然后就行。这本不是坏事，坏事是写了一大堆一次性工具。好的和坏的区别在工具的框架。和我们思考UI布置时一样重要。我们可以抽象工具，工具应当是基础设施和框架上操纵内容和数据的。如果基础设施让你写一次性的工具还保留流程数据完整性。

…what ends up happening instead is that without that roadmap of infrastructure to follow, each tool potentially becomes its own little mini-pipeline with its own data model and execution patterns, so as we write more of these little one-off sovereigns, we end up diverging the content and data paths so much that when we try and wrangle things back in, we end up with these huge tools that are trying to account for every one of those little forks in the content path we created and so we get this thing that‟s more akin to a rube goldberg device than…say a waterslide, we‟re standing at the top dropping content into one end and hoping it comes out one of the chutes that we can see the end of. And while that‟s all well fun, or at least it sounds fun, the real tragedy here is that we‟ve totally engineered flexibility out of the pipeline because our content has to be conditioned so specifically, and likewise scalability, because even small changes require massive amounts of code, again to account for each one of these diverging content paths from all of our pipelines-in-a-tool

最终结果是如果没有基础设施的路线图，每个工具可能成了自己的小流程，有自己的数据模型和执行逻辑。小工具越来越多，内容和数据逐渐分离，当想整合时，结果还是巨大塞满空间的机器而不是水花到。我们塞入资源，期待正确出现，尽管听上去很有趣。悲剧是尽管很有灵活性但内容必须特别特殊，很小的改动都要巨大的代码工作量。使得很多不同的内容都可以适应。

So all the bad news, fire, and brimstone from the repercussions of bad infrastructure behind us, now we can focus on happier things, like how a good infrastructure can not just make life for Tech Art, but can in fact affect the whole production all the way through ship. This actually has to do with how we think about/approach pre-production, as well as what we actually end up implementing, and the way to think about that is to never lose sight of production. One of the…I don‟t want to say mistakes, but maybe one of the less pragmatic approaches we tend to take in tech art sometimes is to get caught up in that whole headiness of pre-production along with our friends on the art team, so we do things like create these amazing shaders for example that in no way are going to run at frame rate, but it‟s cool because it‟s pre-pro and it‟s throwaway…until it‟s alpha and we have to ship with it so were stuck trying to optimize this thing that…really wasn‟t built to be optimized. But if instead, we approach everything with that infrastructure first mentality, sure we can build those crazy shaders, but, we‟ll build them in such a way that we can take it apart and reconfigure it when we need to get some cycles back. The same high-level paradigm should apply to our pipelines, and of course that starts with…good

尽管之前都是不让人开心的事，这十分影响我们pre-pro，以及最终实现。条条框框最少的时候就是prepro时和朋友们制作酷炫的效果但达不到稳定帧率，这很棒直到alpha时我们需要正式使用它并费劲优化。因为它并不是生而可以被优化的。但是如果我们先从基础设施思考，我们就可以分解它，慢慢迭代，这种高层次的范式应该应用，

Now, if we‟ve gone through pre-pro infrastructure first, we set ourselves to go into production in such a manner that we should have a pretty good idea of what kind of game we‟re making, which means we know what content we‟re going to be building and from this we should have an idea of what the pipelines might look like, and while that might not be enough for us to dive in and start building tools yet, it puts us in a position where all the big questions should be answered and we can at least start asking the smaller questions now, like…what should the tools look like. And if we‟ve taken the opportunity in pre-production to start putting down some very rough infrastructure, that being gathering external libraries, experimenting with different SDKs and patterns, I think we‟ll find that developing our production infrastructure becomes a fairly simple task, along with our tool and pipeline development.

如果经历过prepro的基础设施，我们就很明确在做什么游戏，我们会生产什么样的资源，管线大概长什么样。尽管这不足以支持我们开始制造工具，至少大问题都解决了只剩小问题了，就像，工具应该长什么样。如果pre-pro时花精力组装了一些基础设施，包括搜集外部库，实验SDK和模式，之后的开发会很简单，包括工具和管线。

Building a new pipeline and toolset just becomes a matter of…writing more one-off scripts against our battle tested infrastructure, and if our infrastructure was such that our content pipeline wasn‟t the divergent, branching nightmare from our previous conversation, we even set up art and design to start in that same strong position, since they‟ll have tons of content that they can easily strip down and re-purpose for the next project.

制造新管线和工具成为在基础设施上写很多一次性脚本，如果资源管线差别不太大，我们也让美术和策划有一个搞得起点，因为下个项目有很多资源可以重用。

So what IS a Tech Art Director? Well, let‟s first look at what a Tech Art Director shouldn‟t be. The biggest fallacy I‟ve seen is putting the Tech Art “Director” in a role that‟s really more akin to just a more experienced Tech Artist. You tend to see this a lot at companies that start by hiring junior Tech Artists to fill the gaps, not to disparage junior Tech Artists at all, but the expectation becomes that a more experienced Tech Artist is just someone who can solve bigger problems faster, but is never really given that authority to set down the parameters of those problems. The issue there is that Tech Artists are suited to tackle a very unique set of problems, which like Tech Art itself, doesn‟t fall entirely in the domain of art or engineering, so what ends up happening is a potentially production-changing resource is not leveraged properly often times at the expense of the production. And that doesn‟t make anyone happy.

什么是TA主管？最大的荒谬时TA主管是比较有经验的TA，你会发现大量公司开始雇佣初级TA来填补缝隙，不是贬低他们，越有经验的TA越能更快解决更复杂的问题，但很难量化。问题是TA一般适合解决一些很特殊的问题，不在艺术或工程范畴中，最终结果是经常变化的资源无法适应，牺牲了制作周期。

So we still haven‟t answered the question, and sadly it‟s not as simple as just taking what a Tech Art Director is not and flipping it around. A good place to start is with the idea that Tech Art is a bridge, that Tech Artists have feet in both the disciplines of art and engineering. That said, a good Tech Art Director needs to be both production artist and software engineer. Now, within the lower ranks, it‟s probably permissible to be more focused in one direction, but by the time one gets up to the directorial level, you really need to be able to not just understand the conversations on both sides of the fence, but you also need to be able to contribute and even push back. The corollary to that is that the Tech Art Director needs to be seen as an equal in management to both Art and Engineering Directors, as opposed to this catch all for the whims the two. Ultimately, the Tech Art Director needs to understand that the needs of the many outweigh the needs of the few, or in this case, sometimes art has to take a back seat to the overall scope of production.

我们还没回答问题，讲讲TA主管不是什么很轻松。好的起点是TA是桥梁。好的TA主管不仅是美术也是软件工程师，低级别的时候可能专注某个方面，但时间增长，逐渐理解双方对话的意义，甚至需要反击。TA主管需要在管理上与美术和程序主管评级，而不是捕捉双方的异想天开。最终TA主管需要理解多数的意见而不是少数的，有时美术需要为整体生产让步。

Now when I talk about writing documentation, I don‟t mean putting it on the wiki or whatever other systems that often get set up with the idea that people are going to update it and of course people are going to read it, right? Because everyone reads the freakin manual, and I‟m sure you guys who have worked with Wikis or any sort of other communal documentation know that they come with…let‟s say varying degress of success. No, I‟m talking about dedicated documentation systems like Robodoc, or doxygen, serious documentation generators that use markup languages and hook into IDEs and build processes but produce professional looking documentation. As a Tech Art Director, lead, or otherwise an infrastructure builder, writing documentation should be a required task, if nothing else for the educational benefit. I remember when I started writing a style guide about 9 months ago, my thought was, “Oh this‟ll be easy, I‟ll take some of the google style, some PEP-8, change a few things that I don‟t like, and we‟ll be good to go”…and it‟s when you actually step back and try writing code against your style guide, you start to realize it‟s not that easy,

当我讨论写文档时，我意思不是放wikui上或者认为人们会更新它，别人会阅读它。因为每个人都会阅读吓人的文档，记录wiki或者其他文档是另一种程度的成功。我讲的是文档系统比如robodoc，doxygen，严肃的文档编辑器，使用markup语言，勾住IDE和构建流程，产生专业外观的文档。作为TA主管，或者基础设施建设者，写文档时需要的任务，为了便于教育。当我开始写风格文档9个月前时，我认为那很简单，抄一点google风格，一些pep8风格，改一些不喜欢的就好了。当我开始后退、写不符合风格文档要求的代码时，会发现那一点不简单，

So it was one day when I was writing these unittests that I realized I was writing tests that I knew would pass, because I knew the code worked, and about an hour into writing a test, I realized exactly what I was doing, that was I was writing my setup methods to create specific environments in which the test would pass, and the complexity of my test cases made me realize that…aha!…this code is too complicated. So from an infrastructure standpoint, this is one of the things we use unittests for, we don‟t necessarily use it to catch bugs (well, not all the time), but instead we use to keep our interfaces simple, and in doing so we provide an extra layer of documentation, in the form of common use cases.

当我有一天开始写单元测试时，我意识到这些测试我必定会通过，因为我知道代码会工作，当谢了一个小时后，我意识到我在干什么。我再设置方法来创造特定环境使得测试通过，我测试的复杂度让我意识到代码过于复杂，从基础设施的角度看，这是我们使用单元测试的原因。我们不是为了获取bug，而是让接口间接，我们也提供了文档的附加层，一些普遍用例

The easiest way to know for sure how to handle an error is to setup a system wherein you always know exactly what the error you‟re handling is. Sorcery? Blasphemy? Well, not quite. By coupling a good logging API with custom exceptions, we can pretty much catch, handle, and redirect any undesireable results in such a manner as to be able to provide USEFUL feedback to both the user and the developer. Since we went to the lengths of setting up unittests, we should also be able to pare out the more common cases of built-in exceptions, which we could also handle ourselves. So for instance, we have a bit of functionality that we know is going to raise a ValueError sometimes in situations that may be beyond our control (just for the sake of this conversation), based on our unittest. Since we know what the case is that raises that exception, we could create our own subclass of ValueError that handles our specific case and returns useful data. Obviously this is a very naïve and ideal situation, but you get the idea.

处理异常最简单的方式是知道在处理什么异常。写有好的Log的API和自定义的异常，可以更好地捕获异常，给用户和开发者提供有用的反馈。因为我们跑过了单元测试，也可以写出常见的异常并且处理掉。比如有时数值异常，我们可以创建有用的子类来处理特殊情况返回有用数值。当然这是很简单的情况。

…And with all that in place, we‟ve now created an error reporting structure that starts with a user knowing exactly what‟s happened, and maybe even how to talk to Tech Art about it. Once Tech Art steps in, we can very easily look at the traceback and know that we‟ve caught one of our own exceptions. Couple this with our carefully built development sandboxes, and we can iterate with the affected artist directly, off-line, to resolve the issue while the rest of the team continues to work. We fix the problem, we merge that fix into the head branch, and production rolls merrily along.

一切就位后，我们可以创建异常报告框架，这从知道用户在干什么开始。一旦TA接入，我们可以清楚的抓到堆栈和异常信息。用测试沙盒可以迭代而不影响美术，在其他人正常工作时解决问题，merge进主干。

This year, I’ve chosen to talk about a different kind of challenge that we faced at Bioware – and this is more of a social problem than a technical challenge

在Bioware面对的挑战中，我会讲更多的社会问题而不是技术问题。

Our programmers considered the art in the game to be the main cause of the performance issues because it was implemented in an inefficient way.

我们的程序认为美术是性能的罪魁祸首，实现的效率不佳

美术认为这是程序的锅，工具很难使也会造成很多问题

We joined the dark side! Two technical artists were chosen to move their desks into the room where the programmers worked and to work together with them in adding new features and tools, and in optimizing the game. In this talk, I’m going to share my experiences as an artist living and working among the programmers on our team – and show how this simple act of moving into the programmer space was a major part of the solution to our social issues.

我们加入反派。两个TA选择把工位挪到程序旁边，讨论增加新的特性和工具、优化游戏。这个对话中，我会分享作为美术再程序工作中的经验，这一举动是社会问题的主要解决方法。

Designing and building complex systems requires constant communication and collaboration between art and programming.

设计和构建复杂系统需要美术与程序的长期交流和合作。

With tech artists embedded with the programmers, we changed this process around. First, I would collaborate with the artists to create a prototype tool that met all of the artists’ requirements. Through this collaboration with the artists, I would become familiar with what they really wanted and how they intended to use the tool. I was also able to control (to a certain extent) the size and scope of the system to make sure that it wouldn’t hurt the performance of the game and that the artists’ expectations for the tool didn’t get so high that the concept would be too complex or require too much programmer time.

作为程序中的TA，我们改变了流程。首先和美术协作创建原型满足美术需求，通过与美术的合作，我了解到他们需要什么以及想怎么使用工具。我也会控制系统的尺寸和口径使得不影响程序的性能，美术对工具的七大不要太高，概念不要太复杂，占用太多程序的时间

Once the artists were happy with the prototype, I would document the requirements for the tool and show it to the programmers.

Once development started, since I was sitting with the programmers, it was a very natural for me to watch and guide the process, ensuring that the original vision was maintained. Often, the programmer would come up with his own ideas about what the tool should be. Sometimes these ideas were improvements, but sometimes they changed the nature of the tool. We would discuss changes to the original prototype and I would make sure that the original intent was maintained and that the artists would get the tool that they asked for

一旦美术满意这个原型，我会用文档记录工具的需求，并给程序展示。一旦开发开是，我会和程序坐在一起，观看和指导整个流程，确保最初的特性得以保留。但有时会改变初衷。我们会讨论对原型的改变，确保最初的意图仍然保留，美术获得他们想要的。

Once the tool was nearing completion, I wrote documentation for the tool and helped the artists learn how to use it. Since I had been involved with the original prototype of the tool and involved during the tool’s development, I was the best qualified to write the documentation and it was easy for me to teach.

一旦工具接近完成，我会写文档教美术用，因为我参与了最开始的原型，我最有资格写文档和教学

I’d like to stress that this step – educating the artists – is important. It needs to be more than just an email that says “Hey, we have a new tool. Go read this document that I wrote about it.” You really need to sit with the artists and show them the tool, and then watch them use it. By doing this, you can make sure that the tool is doing what the artists need AND that the artists are using the tool correctly.

我要强调这一步，教育美术，而不是发一封邮件说我们有这个新功能，看看文档。你需要和美术坐在一起展示给他们，观看他们试用，这样确保这是美术需要的并且他们正确使用。

No matter how well a tool is designed, if you don’t teach the artists how to use it properly, they’ll find a way to make a mess with it – and it’s always easier to teach first than to clean up the mess later.

无论工具设计的多好，如果不教他们正确使用，他们会搞砸。开始教学总比后面擦屁股好。

Having an art representative in the programmer area helped the artists in a couple of other ways too. When the programmers wanted to make an optimization to the game that might make an impact on the art, I was there to stand up for the artists and help the programmers know when an optimization was going too far or when the performance benefit out-weighed the small loss in quality.

在程序中有一个美术的代表也帮助美术，当程序希望优化游戏，需要对美术产生影响，我会为美术站台，帮助程序了解哪些优化太远了，性能优化超过了效果的损失

Also, since I worked with the programmers every day, I was aware of all of the projects they were working on to improve performance and quality. When new builds of the game engine went out, I sent out an email to the art team to help them understand the new improvements in the build that would impact them. This increased visibility helped the artists to see that the programmers were working hard to improve the game.

自从我每天和程序工作，我了解到所有提升性能和质量的部分。当引擎的新版本出来，我会给美术发邮件告诉他们哪里有提升，会如何影响他们。这帮助美术了解程序如何提升游戏。

As a result of these changes, the artists got tools that matched and sometimes exceeded their expectations and their ability to create game art was improved. hey also had more information about what the programmers were doing to improve the game. Their trust in the programmers increased.

结果是美术获得了想要的工具，他们创造资源的能力提升了，了解到程序做的事情如果提升了游戏，让他们相信程序。

Now I’d like to switch gears and talk about how the programmers benefited from having embedded tech artists join them. As I mentioned earlier, the major concern that the programmers had is that the artists were creating art that was wasteful and inefficient. They believed that the main cause for the low frame-rate was that the art was too heavy. One thing that I had noticed before moving into the programmer area was that the programmers often found specific examples of bad art and said things like, “Man, this texture is huge. They need to fix this.” or “This model is super dense and you only ever see it from a distance.

现在我要换个方向，谈谈程序如何受益于TA加入。程序员主要的抱怨是某个资源太浪费或者低效，认为帧率低的原因是美术太浪费。我注意到的是他们经常抱怨某一特别的资源说，这个贴图很大，需要修一修，这个模型很密，但很远才能看到。

Since no one from the art department was present, these off-the-cuff complaints were basically just getting thrown out there with no one to respond to them. The programmers had a lot of built-up frustration at seeing in-efficient assets and no one seemed to be fixing them. After moving in with the programmers, I made it a point to jump up and respond when ever I heard a programmer complain about the art. I’d make a note about the asset in question and either fix it myself or pass it along to the right artist to optimize.

因为没人美术部门的人在，这些抱怨越来越多，没人响应。程序只能沮丧的看着低效的资源无人处理。搬过去以后，我来接受程序的抱怨，记下来有资源的问题，我自己处理或者让正确的美术来优化。

I basically become the programmer’s complaint department. Even if things didn’t get fixed right away, the programmers at least felt like someone was listening and responding to their complaints. This served to ease a lot of the tension that the programmers felt toward the artists.

我基本上成了程序的抱怨部门，尽管没有立刻处理，程序还是感到有人听他们的抱怨，减少程序对美术的紧张程度。

We went several steps beyond just responding to off-the-cuff complaints. One of our major initiatives was a full audit of all the assets in the game.

我们走得更远来去掉这些抱怨，一个主要的提议是对资源完整地监控

We created frame-rate and memory usage heat maps of all of the planets, created lists of textures that were too large, and models that used too many triangles. We put a lot of effort into gathering all of the information that the art team needed to make the game run faster using less memory. Some of the items we were able to go in and fix ourselves but most of the time we would create a report of actionable items and pass it along to a lead artist so that the work could be divided up among his team.

我们创建了帧率和内存的热点图，列出太大的贴图，太多面数的模型，收集信息让美术团队知道如何让游戏更快内存更少。有时我能处理，有时需要创建一个列表交给主美，把任务分解进团队。

With the right information in hand, the art team was able to reduce texture memory usage significantly and increase frame rate.

有了正确的信息，美术团队可以减少贴图内存使用和增加帧率。

Beyond texture size and triangle counts, we also investigated other resource drains such as the density and clip distance of terrain details, the complexity of our cloth simulations, and LOD settings on our character skeletons. In one case, I found that reducing the draw distance on the grass by about half raised our frame rate by 10 frames per second with no noticeable visual difference. It’s pretty exciting when you can find that kind of improvement.

除了贴图尺寸和面数，我们还探讨了其它，比如地形的密度和裁剪距离，布料模拟的复杂程度，角色骨骼的LOD等，我发现减少草视距的一半可以提高10帧，但看不出什么差别，能发现这些很令人激动。

once saw that the tech artists at Crytek created t-shirts for themselves that said “Digital Janitor” on them. I think this describes this project pretty well.

After all of our work optimizing the game’s art, we wanted to make sure these optimizations would remain that way and that future assets would be created in an optimal way. Basically we wanted to avoid having to do this type of clean-up project again.

有次我看到Crytek的TA穿的衣服叫数字清道夫，我认为这相当好地描述了项目。这些优化以后，我们想确定未来的资源也会用这种优化的方式创建，避免再做这种清理。

The first thing that we did was to educate the artists. This mostly took place during the optimization process. As we passed list of assets along to artists to optimize, we would also take some time to explain the metrics that we were hoping to improve. We would show them the heat maps and help them understand what it was that caused the problem. Teaching the artists how to make efficient art, and how to check the on-screen metrics to make sure that their work was within budget was half of the solution.

第一件事是教育美术，这在优化阶段发生。当把资源交给美术时，我们需要解释优化的标准是什么，展示给他们热点图，帮助他们理解这造成了问题。教美术制作有效率的资源，如何在屏幕上检查他们的作品是否在预算内，是一个方法。

The other half of the solution was to build smarter export tools. Our tech art team is responsible for the tools that export all assets into the game including models and textures. This means that we have a point in the pipeline where we can add checks to see if assets are optimal. We took advantage of this opportunity mostly with texture maps. Our exporter already had some context for how each map would be used, so we taught it the dimensions that a texture should be for each usage case. When a texture is exported, the size defaults to our optimal size or the original size, which ever is smaller. We also have a maximum size built into the exporter. This prevents textures from getting exported at insane resolutions.

另一个方法是制作更聪明的导出工具，我们负责导出所有的资源到引擎，包括模型和贴图，这意味着我们管线的某一点需要检查资源是否优化。我们主要处理贴图，每张图如何使用，大小如何。还有最大尺寸的限制，防止过大。

In addition to optimizing the art assets, I was also given the task of writing the low-end shaders for the game. In the options, the players can select to use low or high quality shaders. The low-end shaders are mostly for people that have weaker hardware. This was an ideal task for me, for several reasons. First of all, as an artist, I had a strong understand of what features of the shaders were core to the look and style of the game, so I could remove the right set of things without the art team going up in arms against me. Second, I was able to off-load this large task from the programming team and free them up to do other

除此以外我还负责写低配shader，用于较弱的机型。这对我很合适，因为做为美术我理解哪些特征对效果影响最大，我可以去掉对的部分而美术团队不怼我。我也能让程序减轻负担。

Finally, on a personal note, I had a laptop at home that barely met our minimum hardware requirement and I wanted to be able the run the game on it. I set a personal goal to improve performance enough so that the game could run on my laptop, but without losing the distinct artistic style that we had defined.

最后，我有一个笔记本满足最低硬件要求，所以我给自己定了个目标让我们游戏在它上面跑起来，而不丢失美术风格。

After working on the project for awhile, I was able to reduce many of the shaders to around a quarter of their original instruction count by removing optional features, moving some math into the vertex shaders, and simplifying core functions. On our low-end target hardware, the game ran an average of 20 frames per second faster when using my optimized shaders. And most importantly, it ran well on my laptop.

工作一阵以后，我发现能减少1/4的指令数，指令移到顶点着色器，简化核心函数。在低端机上，能够提高20帧。当然主要在我笔记本上。

Here, I want to pause for a minute and talk about the importance of measuring things. Your worth as a tech artist is determined by your ability to solve problems. Making the game run faster and making the artists’ work more efficient are two examples of the types of problems we solve. If you want to show your worth – and thus build the value of tech art as a discipline within your studio, you need to be able to put a number on it and use cold, hard facts. Before you start any project to solve a problem, try to measure the results as they currently stand. Figure out how long it takes the artist to accomplish his task with his current tool. Make a list of how much texture memory each level is using. Write down what the instruction counts are on all the shaders. Once you have this initial data, go to work to make things more efficient. When you’re done, take your measurements again. With this data in hand, you can show the team and the company – hey, I saved a week of artist time. Or – I increased the frame rate by 50%. Or – All of the levels are now within the memory budget – and the visuals still look as good as they did before. Having this type of fact-based information to share goes a long way toward increasing the respect that your company will have for the tech artists.

这里我想暂停一下，你作为TA的价值是解决问题，让游戏更快，让美术更有效率。有两个案例。如果你想展示你的价值，在工作室内把TA当成一个工种，你需要冰冷的数字。在你开始项目时，尝试测量结果，发现美术用现有工具要多久完成，列出当前关卡的内存，写下shader的指令数。当有了这些基础信息，开始优化。完成后再衡量一遍。有了这些，就可以展示给团队和公司，我节省了几周美术的时间，提升了多少帧率，多少关卡在内存预算中，但效果还跟以前一样。这类基于事实的信息增加在公司受尊重的程度。

I believe that the programming team learned to respect the art team more when they saw all of the effort that we were putting in to optimize the art and the shaders in the game. The artists earned the respect of the programmers by being an active part of the solution.

我相信程序会尊重美术团队，如果看到他们优化的努力。美术也会因程序积极的解决而尊重他们。

 

In summary, moving technical artists in to work with the programers had several key benefits. First of all, the artists gained direct representation on the programming team. This was beneficial because we were able to participate in and guide the development of new tools, help the artists see what the programmers were doing to improve the game, and protect the interests of the art team from over-optimization. As a result of these changes, the artists now have a greater respect for the programming team and are more willing to work together and collaborate with them.

结论，把TA放到程序一起工作有很多益处，首先在程序中有了美术直接的代表，因此能参与到新工具的开发中，让美术看到程序如何提升游戏。防止美术过度优化，折让程序和美术团队互相尊重并合作。

Second, the programmers gained direct access to the art team. Since I was sitting right there with them, whenever they had a question about the art, they could just ask. As we worked to improve the efficiency of the art assets and optimize our memory usage, the programmers saw the work that we were doing and experienced the performance gains that we achieved. I was also able to complete a couple of shader projects that the programmers would have had to do and free them up for other tasks. These changes helped increase the level of respect and trust that the programmers had for the artists.

其次，程序有了对美术团队有了直接的接触，当有美术的问题是我会立刻回答，当我们提升效率和优化内存，程序看到了我们的成果。我也写了一些shader解放了程序的时间。这增加了互信。

This increased level of confidence and trust that the teams had for each other is important – because it means that they are more willing to work together. I’m not going to say that the relationships between the teams are perfect. We still have room for more improvement in some areas. But we have made significant progress – and that progress shows in the product that we shipped. I also don’t want to take the credit for these improvements. I was in the middle of the process, but it was really the willingness of the programmers to allow an artist to be a part of their team, and the willingness of the artists to work hard to improve performance that made this happen. So unlike in the movies where joining the dark side leads to hate, misery, and suffering, in our case joining the dark side led to greater trust, confidence, collaboration, and in the end – a better game.

增加互信很重要，我不会说关系很完美，仍有很大的提升空间，但很有进步。这不完全归功于我，我在这个过程中。是双方积极的态度使得这可行。不像电影中，加入反派会导致仇恨和痛苦，我们这里加入反派带来了互信、自信和合作，以及更好的游戏。

So, after sharing some of my experiences working together with the programmers for the past two years, I’d like to leave you with four key ideas. The first is guide. When working to design a new tool or solution to a problem, you need to guide the artists so that their expectations for what the tool will be able to do don’t get out of control. Then you need to guide the process of creating the tool so that the end results matches the original vision and so that the tool accomplishes the intended task.

The second is teach. As a tech artist, it’s your job to make sure that the artists on your team know the pipeline, know the tools, and know what’s acceptable and what isn’t – in terms of creating art that will perform well. If you end up with a mess to clean up at the end, you can only blame yourself for not being a better teacher.

分享完这两年我的经验，我想为你提供四个想法。首先是指引，引导美术让他们对工具的期待不会不受控，引导创建工具的流程。其次是教授，确保美术团队了解管线，了解工具，了解在创作过程中什么可以接受什么不可。如果最终搞砸了，你必须责怪自己不是好老师。

Next – measure. Capture data both before you begin a project and once you have completed it so that you can show the company – in hard facts – what benefit your efforts have achieved.

And finally, build trust. This one is the most important. Artists and programmers that trust each other, will work together and collaborate to build incredible games. Artists and programmers that don’t trust each other, won’t work together – and your project will suffer. Do all you can to help each team see what the other is doing. Bring the teams together and help them collaborate.

其次，测量。项目开始前捕捉数据，完成后展示给同伴，你的努力达成了什么。最后，建立互信，这是最重要的。让程序和美术互相信任，合作创造伟大的游戏。否则会很痛苦。做你最大的努力了解其他人在做什么，把项目团结起来帮助他们合作。

Strategic is the high-level vision of a tool. At this level, you should be looking at the big picture of how the tool fits into your overall pipeline, and how it affects the user workflow. This is also the most effective point at which you can save your company money and increase the productivity of your team. As our industry moves into another cycle of next generation hardware, I believe pipelines will become larger and more complex, so we need to build things that are scalable and most importantly, save your company money. I don’t know how common it is for Technical Artists to think about the tools they write in this way: your company is paying you to write tools to make the content pipeline an efficient machine, and so you must look at the best way to spend that money.

策略是高级别的事业，你应当看到大局，工具如何整合进管线，如何影响工作流。这是节省公司金钱和提高生产率最好的方式。当行业进入新一代硬件，管线变得更复杂和打，你需要让他灵活，省钱。我不知道TA是不是会通常这样认为，公司付你钱让你写工具，来优化管线，你必须用最好的方式省钱。

Tactical is the low-level view of a tool. This is where the architectural design, implementation and code reviews of tools happen.

I’d like to start the presentation by talking about the Strategic level of tool development, and the first part of that process for us is what I call Tool Briefs.

战术是低级别的工具，是架构设计，实施和代码review发生的。我想展示工具开发的策略级别，第一阶段我会讲工具概述。

Tool briefs are short documents, typically one page or less that describe the need, criteria and scope of the proposed tool. They are a strategic document, and don’t delve into the details and logistics of how the tool will be implemented. At Volition, tool briefs are written and approved prior to any technical spec being drafted.

工具概述是一个简短的文档，可能比一页纸好少，描述了需求，标准和范畴。这是策略性的，不关注细节和逻辑和实现。在我们工作室，工具概述在实施前书写并要通过，

The primary purpose of the tool brief is to make sure that everyone is on the same page about what will be delivered. They give your Manager the opportunity to assess the cost of implementing the tool, and they also provide an easy point to make course corrections early in the design process. Moreover, it gives everyone involved an opportunity to ask questions, and provides your Director a window into how you are thinking.

At Volition, our tool briefs are made up of three simple questions. These questions are intentionally designed to be kept short and focused to make the person writing the tool brief really think and question what they are about to build and write it in such a way that it communicates the tool to a wide audience.

主要目的是确保每人能从同一张纸了解到要传达什么。给经理机会来评估工具的实施，也提供设计初期确保路线正确。让每人有机会提出问题，告诉主管你如何想。在这里，我们的工具概述由三个简单的问题组成，问题足够简单并让开发者关注到在开发什么，并让更多人理解。

The Description (What is it?) This one is pretty straightforward. Here, you describe the needs, criteria and scope of the tool. The Function (How might the end-user use the tool?) Sometimes it’s easy to overlook how the tool might affect the end-users productivity. It’s important to keep this in mind and how the tool fits into the big picture of the overall process. It’s very easy to add new tools to a pipeline, but it’s very difficult to keep it running smoothly for your team. The Justification (Why does it need to exist?) This is the part of the brief that provides the rationale for why we should be creating the tool. The following is a quote that I feel fits the bill of a Tool Brief perfectly:

描述，这很直白，描述需求，标准和范畴。功能（如何使用？）有时会忽略工具如何影响使用者的生产率。也很难让团队中流畅使用。正当性（为何要存在？）为什么要创建，

Mapping out the workflow as a flow chart is a good way to get a high level perspective on the end users process. If your pipeline is creating bottlenecks for your users, then mapping it out should reveal where the problem areas are, then you can create a plan of action to address the issue. A good approach to how to map out the pipeline is to associate how long they spend on each part of the process.

画出工作流是获取更高事业的好方式。如果你的管线有瓶颈，就画出哪里有问题，写计划来解决。好的方式是画工作流时附上每个模块要多久。

Another way to familiarize yourself with the end-user is to sit down with them and watch how they are working. It’s very important to build those working relationships with the people we are supporting. They need to feel confident that the tools we are developing are there to make their lives better. Besides, if the person you are watching doesn’t get creeped out over this, it can be an eye-opening experience for a lot of Tech Artists. Sometimes, you’ll see artists using your tools in ways you didn’t expect and would have probably only surfaced by watching them work.

另一个熟悉用户的方式是坐在他们身边观察他们如何工作。这对于创建工作关系很重要。你需要信心，创造的工具确实让他们生活的更好。除此外，如果你在观察的人没有做好，是个开眼的机会。你会发现美术用你料想不到的方式，只有观察时才会出现。

Something I like to do is hold bi-weekly dependency meetings with each art discipline on the team. The meetings are fact-finding missions to discover what the artists are working on and what they have coming up. At Volition, we use Hansoft to manage the project’s tasks and backlog, but trying to determine dependencies in that software is nearly impossible, so I avoid it altogether and meet for 30 minutes to talk.

有时要与各职能组双周会议，了解美术在做什么，要做什么。在Volition，我们用hansfot管理项目的任务和log

The meetings are also great opportunity for the artists to bring up any other issues they are having and have become my most valuable meetings. I would encourage you guys to implement these into your process if you don’t already.

开会是了解美术的问题的很好的机会，也是我最重要的会议。我建议你们实施它。

Running behind schedule doesn’t always mean that something is getting overengineered. In most cases, we just underestimate how long something will take, usually because we discover things over the course of development. But it is a warning sign and if the person is running behind schedule, it’s probably a good time to step in and take a look at what’s going on.

落后进度不一定意味着有东西被过度设计了，大部分时候我们低估了花了多久，因为我们开发中发现了新事情。但如果有人落后进度是个警告，也许是时候花时间看看发生了什么。

Making the code too generic is another one of those tricky and subjective aspects of software development. One way to tell if something is being too generic is to look at the set of requirements. If you are expanding a focused set of requirements into something that can be a “jack of all trades”, you are probably overengineering something. For example, say you are tasked to build a simple tool that is supposed to track how shaders are used on content. Well, you decide that you want to turn it into a generic system that can track how any piece of data is being used on content. It would become incredibly complex and stop being good at showing how shaders are used on your content.

让代码通用是最麻烦和主观的部分。一种发现事情太宽泛的方法是看看要求。如果你发现吧关注点拓宽到几乎所有，你可能过度设计了。比如如果你要做一个简单工具，追踪用了哪些shader，你可能决定把它变成一个通用系统，多少任何数据被使用了，最后可能很复杂，也不能展示shader用了多少。

Another indicator of when something is being overengineered is when the code has become difficult to follow, which usually means it has also become difficult to maintain. A warning sign for this is when someone who is using your code is frequently asking questions about how it works. When this happens, the best method I’ve found to surface overengineering is to go to a white board and have the TA(s) write out what they are trying to do.

另一个过度设计的痕迹是代码很难跟上，很难维护。常见的警告是有人经常问你代码的问题。最好的方法是让过度设计浮出水面，写白板写出想干什么。

Probably the best way of detecting overengineering is when someone is designing too far in to the future.

也许最好的探测过度设计的方法是有人设计的过远过于考虑未来。

But at the end of the day, good design practice equals code that is easy to follow and maintain. Bad design practice ends in code that is too difficult to understand and maintain, and ends up costing you time and money.

好的设计时间等于代码好维护和理解。坏的设计导致很难理解和维护，增加时间和金钱成本。

Phase 1 – Basic design and implementation.

At this phase, the basic system is functional. Verification takes place based on the goal/task lists and associated expectations. The system is not polished, but sufficiently fleshed out to allow iteration work to start.

第一阶段 基本设计和实施，功能性的。主要是验证目标列表和工具的期待。系统没有精心打磨，但足够迭代开始。

Phase 2 – First pass of iteration.

In this phase, the system or tool is sufficiently fleshed out that a decision can be made as to whether it fulfills its promise or exhibits fundamental issues. Validation is focusing on whether the feature is “on track”. It’s also the point where the determination is made as to whether this is a tool or system that could potentially be cut.

第一次迭代，功能足够了，可以看看是否满足了期待和基本特性。验证方法是特性有没有在正确的轨道上，这也是工具或系统是否会被砍掉的关键点。

Phase 3 – Second pass of iteration.

This is the first polish phase and the tool or system should be fully implemented. Features at this point are locked down and only minor additions are acceptable (subject to approval). An evaluation is made to assess whether or not the tool is successful and whether it should be kept or cut. You can only enter the final phase if the tool or system is being kept.

第二次迭代，第一次精心打磨，完整实现。这是新功能不再有了，只有小添加。评估在于工具是否成功，应当留下还是砍掉。只有留下才能进入下个阶段

Phase 4 – Final polish pass.

Here, the features of the system or tool are locked down and it’s essentially production ready.

完成打磨，需求锁定，制作完成。

•Allow the team and QA to easily record bugs directly from the game.

•Provide art an easy way to provide direction.

•Allow the team and QA to easily navigate to bugs in the game.

允许QA轻易地追踪游戏

允许美术容易获取方向

允许QA在游戏中导航到bug

In order to make the end-user more productive, keep the number of clicks in your interface to a minimum. Using keyboard shortcuts are also good, but just be careful that they aren’t the only way to do something. I’ve actually used editors and tools in the past where this was the case and certain functionality of how to do something became lore of the tool, absent in any documentation.

为了让玩家更有效率，让点击次数更少，快捷键更好。

Intelligent grouping and keeping alignment of controls in mind and consistent will also make your interface appear clean and simple.

聪明的编组，对齐和统一的控件，让你的界面干净简洁。

In Viewmaster, to make sure communication was kept simple and in clear paths, I created a Management layer. The Management layer is how subsystems interact with each other. It becomes important at the Class or Object level of the code. Instead of having to pass every subsystem to each other, I only need to pass the primary manager class.

viewmaster中，为了让交流简单，创建了manager层，和其它交互，在代码里很重要，而不是给子系统传很多变量。只要传一个manager就行。

作者最后推荐了 Code Complete 2rd version