作者：Clarence Simpson

若你是个玩法编程员，那你就是设计和编程工作之间的沟通桥梁。那么你就需要应对设计师奇幻梦想和目标平台、游戏引擎及人力资源等残酷技术现实的一线之差。你在游戏开发中扮演重要角色，你应该这样看待自己的工作。

要在此桥梁角色中发挥作用意味着你要能够同双方保持良好沟通，做出迎合双方需求和预期的折中决策。

designer vs programmer(from stripgenerator.com)

多数玩法程序员都主要接受编程艺术方面的训练。所以他们能够很自然地同其他程序员互动，发现编程方面的需求。但也许你在互动和把握设计知识方面有所欠缺。幸运的是，你所要做的就是，遵循这些适合各种引擎的规则，确保自己同设计师保持良好关系，或者至少不会不愉快。

1. 确保内容都处于须知范围内

玩法程序员制作的复杂机制细节内容对于非程序人员而言也许会太过棘手。可能情况下，自己保留这些细节内容，不要拿这些干扰设计师。事实上，这意味着你要注意隐藏设计师无需知晓的信息或逻辑运算。一个最基本的方法就是，合理设置所有方法和变量的可访问性。不要为了节省几行代码而公开这些内容，进而导致设计师陷入困惑境地。

你还应该考虑各种设计设置的适用范围。很多游戏引擎都有针对游戏对象的预制件或模板。这种结构让你能够将设置范围定义成全局性，基于预制件或基于实例。你应该谨慎看待这一范围决策，这样设计师就只会修改需要他们修改的内容。

例如，在多数游戏中，当你遇到之前遇过的角色或对象时，你会希望它的表现方式和之前看到的一样。在这些类型的游戏中，针对实例进行设置就是禁忌。你定不希望设计师以玩家预料之外的方式放置对象。从理想角度看，当设计师将一个对象放置于关卡中时，呈现在他们面前的应该是系列能够进行调整的配置选项（游戏邦注：不能多也不能少）。

“就是那里的设置，是吧？是的，你可以进行调整，但不要这么做。”如果你说过这样的话，那么你就错了。

2. 不要涉及编码内容

你要尽可能让设计师在无需改变或查看代码内容的情况下调整游戏。幸运的是，至少你是从Unity或Unreal之类包含稳固GUI的游戏引擎着手。这些引擎让设计师能够在无需进行编程的情况下修改游戏内容。

unreal from geek.com

设计师总是着眼于构思和灵感。“也许离子炮应该呈现区域破坏效果……”“如果冒火光的僵尸发现其他僵尸也陷入火海会怎么样？”“也许Frank Ferret应该跳得更高……”游戏开发建立在设计师的构思和灵感上。确保他们能够在不寻求你的援助的情况下追踪这些构思。

只要他们的构思需要编程，设计师就只能等你帮助，或被迫做出设计师或程序员都觉得不妥的代码调整。这最终会导致创造性受挫。但若你一开始就向设计师提供能够让他们在无需你帮助的情况下更新和扩展构思的工具，那么你就算是帮了个大忙。

3. 确保看起来赏心悦目

设计师多半都是视觉动物。他们很多，尤其是关卡设计师，都有些许艺术背景或受到过相关训练。当你在创建供他们使用的机制时，发挥这些优势，保持内容的直观性。下面是若干例子：

若你创建的是供设计师在游戏中放置哨岗的机制，那么确保不要只是向他们呈现“半径”或“射界”之类的数字变量，还要绘制这些变量的视觉表征。在屏幕上画个圈圈，这样他们就知道50米有多远。画个椎体，这样他们就知道30度的圆弧有多大。

若你创建的是解锁门的开关遍布各处的机制，那么在开关和目标门之间绘制一条横线。若你设计的是包含众多门的游戏，那么这点非常重要。设计师通常会直接复制/粘贴，忘记更新各对象的引用。

若你创建的是敌人AI机制，其中包含5种敌人类型，但只有一个有艺术模型，那么你有义务充分利用此情景。临时给设计师添加些许视觉元素，这样他们就不需要猜测具体敌人。添加图标、文本标签，或者是简单的颜色变化，以从外观上区分各个敌人。

记住，虽然你不是艺术家，但通过简单圆圈、球体、直线及其他基本实体，你依然可以向设计师呈现杰出视觉反馈。

4. 将乏味的设计工作自动化

在你的职业生涯中，你会发现有很多功能是设计师完成其本职工作所不需要的，但它们的存在是件好事。通常这些工作能够由美工和设计师通过机械式的手动操作完成，但程序员可以将其设置成自动操作。不要因为它们无法直接带来更优质的终端用户玩法体验而过快否定它们。

例如，假设你面临AI游走出关卡边界的问题。设计师和美工完全无需你的帮助，就能够通过手动在游戏关卡边界中放置有形墙面解决这一问题。而则你可以从编程角度判断各关卡的边界。然后，你可以利用此信息，或放置有形墙面，或将其运用至AI逻辑中，确保AI不会离开这些边界。你的编程解决方案也许需要耗费数小时完成，但它其实会帮你省下需要耗时几天或几个礼拜的设计或美术工作。这是非常值得投入的时间。

所以总之，这四条规则会让你的设计师心情愉快。记住：若你有效简化设计师的工作，避免让他们感到困惑、乏味或有压力，那么你就做对了。你最终将收获更优质的游戏作品。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Designer-Friendly Programming 101

by Clarence Simpson

If you are a gameplay programmer, you are the conduit between design and programming. You are the person walking the thin line between the fantasy dreams of every designer and the harsh technical realities of what your target platform, game engine, and human resources can provide. You play a critical role in the development of any game and should treat it as such.

Being effective in bridge roles like this means being able to communicate well with both sides as well as making good compromise choices that attend to the needs and desires of both sides. Those choices are the focus of this post.

Most gameplay programmers are traditionally trained in the art of programming. So, it’s typically very natural for them to interact well with other programmers and to be aware of the needs of the programming side of things. As such, I’m not going to spend any time telling you how to be a good programmer. Anyone still reading this is already a rock star programmer anyway, right?

But maybe you don’t do so well with interacting with and being aware of the design side of things. Luckily, all you need to do is follow these simple engine-agnostic rules to make sure that your designers love you… or, at least, don’t hate you.

1. Keep things on a need-to-know basis

The details of complex systems created by gameplay programmers can be overwhelming to non-programmers. Whenever possible, keep those details to yourself and don’t trouble your designers with them. In practice, this means being careful to hide any information or logic that your designer does not need to know. One of the most basic ways to do this is by properly setting the accessibility of all your methods and variables. Don’t make members public just because it will save you a few lines of code at the expense of potential designer confusion.

You must also consider the scope that the various design settings may take on. Many game engines have a concept of prefabs or templates used for their game objects. This kind of architecture allows you to define the scope of your settings as global, per-prefab, or per-instance. You should take great care in making this scoping decision such that only things that should be changed by the designer can actually be changed.

For example, in most games, whenever you encounter a character or object that you have encountered before, you expect it to behave just like the last one you encountered. In these types of games, per-instance settings are a no-no. You don’t want to give a designer the opportunity to place an object that doesn’t behave as expected by the player. Ideally, when a designer places an object in a level, they should be presented with a set of configuration options that make sense for them to change. No more. No less.

“Oh that setting right there? Yeah, you can change it, but don’t.” If this sentence has ever left your lips then you’re doing it wrong.

2. Provide power without programming

As much as possible you should empower your designers to tweak the game without needing to change or even look at a single line of code. Hopefully, you’re at least starting out by choosing to use a game engine with a robust GUI like Unity or Unreal. These kinds of engines give great power to the designers to make changes without coding.

Designers are struck with ideas and inspiration all the time. “Maybe the plasma cannon should do area of effect damage…” “What if the flaming zombies caught other zombies on fire?” “Maybe Frank the Ferret should jump higher…” Game development thrives on the ideas and inspirations of designers. Give them every opportunity to chase those ideas without having to ask for outside help from you.

As soon as their ideas require programming, the designers will either have to wait on you or be forced into making code changes that neither designers nor programmers feel comfortable with. This can ultimately lead to stifled creativity. But if you give designers tools from the beginning that allow them to iterate and expand on their ideas without your help, you have done them a great service.

3. Make it easy on the eyes

Designers are often very visual creatures. Many of them, especially level designers, have some kind of background or training in art. As you build systems for them to use, play to those strengths and make everything as visual as possible. Here are a few examples:

If you are building a system for designers to place guard towers in your game, then make sure to not just give them numeric variables like “radius” and “firingArc,” but also to draw visible representations of those variables. Draw a circle on the screen so that they can see how far 50m really is. Draw a cone so they know how big a 30 degree arc is.

If you are building a system where you have switches scattered around that unlock doors, consider drawing a line from the switch to the door that it operates. This is especially important if you are designing a game with lots of doors and designers will be prone to copy/paste and forget to update each object’s references.

If you are building an enemy AI system and there are 5 different enemy types but only one has been modeled by art, it is your job to make the best of that situation. Temporarily add something visual for the designers so that they don’t have to guess which enemy is which. Add an icon, a text label, or even just a simple coloring change to visually differentiate between the enemies.

Remember, though you are not an artist, there is still plenty you can do with simple circles, spheres, lines, and other primitives to provide excellent visual feedback to your designers.

4. Automate the tedious design work

During your career you will find plenty of features that your designers don’t NEED to do their job, but they would be nice to have. Often these will be tasks that can be tediously done by hand by artists and designers, but could possibly be automated by a programmer. Don’t be too quick to shoot those ideas down just because they don’t tangibly and directly result in a better end-user gameplay experience. In each of those cases you should always do some quick mental cost-benefit analyses in terms of how much team time may be saved by implementing those features.

For example, imagine you have a problem with AIs wandering out of the bounds of your level. The designers and artists could probably fix that without your help by manually placing invisible walls around the bounds of each level in the game. On the other hand, you might be able to programmatically determine the bounds of each level. Then, you could use that info to either place invisible walls or use it in the AI logic to make sure the AIs never leave those bounds. Your programmatic solution may take hours to do, but it may also save days or weeks worth of design or art work. That may make it a very worthwhile usage of your time.

So, there you have it. Four rules that will make your designers’ happy. In general, just remember: if you make your designers’ jobs easier, less confusing, less tedious, and less stressful, then you’re doing it right. You will also inevitably end up with a better game. And we all want to make better games, right?（Source：gamasutra）