作者：Joost “Oogst” van Dongen

在Ronimo Games工作室，我们总是尝试制作出富有创造性的游戏，而我认为我们在此所面临的最大的挑战是很难更好地安排游戏设计师的工作。游戏设计师总是致力于游戏机制以及控制方案等工作，但是他们却不知道自己设计的纸上方案是否真的可行。而这时候就需要程序设计员的帮助，根据设计师的设计编写出真正可行游戏的内容；所以除非设计师本身也是程序设计员，要不他便很难完全依靠自己的力量完成游戏。

而美术人员现在已经不用烦恼这个问题了，因为图像工具能够帮助他们无需程序员的协作便创造出大部分图像内容（大概除了优化和执行都能够做到了吧）。而对于游戏设计来说，这应该算是一个众所皆知问题了。虽然有许多方法能够帮助游戏设计师解决这个问题，但是却没有一个是切实可行的。我大致列举出几个：编撰脚本语言，基于事件的系统，使用像Gamemaker和Virtools等工具，而最多人采取的方法是：从现有的游戏中复制所有内容，甚至未添加任何创新元素。

对于我们来说，所有的游戏都是从程序员与游戏设计师的紧密合作开始的。现在，不论程序设计员何时创造了何种内容，我们都会尽可能地保持这些内容的灵活性，并创建相关设置以控制它们。我们将所有可以想到的内容，包括速度，规模，生命，冷却等安插在这些设置中，从而让游戏设计师能够编辑这些内容。

但是在《剑与勇士》中，设计师的工作权限也非常有限。所有现实的行为都是明确地按照每个单位进行编程，所以设计师唯一能够做的便是调整它们。如果他们想要创造一个新的单位或者将现有的单位与性能结合在一起，他们便需要请求程序设计员帮助执行这一过程。

在《剑与勇士》中，每个角色的技巧都是属于硬编码。设计师只能够调整一些确切的数字（游戏邦注：如破坏率，速度，冷却等），但是如果离开了程序员，他们便不能创造出新的角色。

Swords & Soldiers(from joostdevblog)

在《Awesomenauts》中，我们尽可能让所有内容都更加灵活。我们明确了游戏中的角色包含了哪些技巧以及玩家按压哪些按钮能够使用这些技巧。我们已经编写了大约20种技巧（游戏邦注：包括射击，打击，跳跃，冲撞以及防御等），而设计师可以通过单独设置创造出每个技巧的新版本。设计师同样也可以在每个按钮中附加一些技巧从而创造出新的结合体，所以如此便可能同时出现发射子弹和开始防御的组合技巧。

Skill system(from joostdevblog)

以上就是游戏中Sheriff Lonestar所拥有的技能。

每个技能都涉及了一组设置并用于定义相对应技巧的性质。所以游戏中共有许多不同的射击技巧，而每一个技巧又有不同的设置。按照这种方法，将会延伸出手榴弹或者其它子弹，激光或者地雷等。

shootgrenade(from joostdevblog)

以上是手榴弹射击的设置。一些合理的设置：每隔4.6秒可以投射出手榴弹，这是由子弹衍生出来的。而子弹也有许多不同的设置。根据这些不同的设置，射击也能够创造出激光等威力。

这就是真正的灵活性，并且我认为这么做比《剑与勇士》中所使用的角色硬编码有效多了。而促成出这种灵活性的秘诀便是创造各种不同的设置。通过《Awesomenauts》的开发，我们不断地添加新的设置以促使现有技能更为灵活，并因此能够创造出更多内容。

虽然说起来头头是道，但是真正实践起来却总是难以像想象中那么完美。这种方法同样也有弊端，总的归结为一点就是：技巧能够通过任何方式结合在一起，但是却因此让所有角色的编码变得更加复杂。就像是如果你有20种技能，那么设计师便可以同时创造出400个2种技能的结合体。如果每个角色都拥有10种技巧，那么设计师所面临的工作量便更难估量了……

所以执行这种系统并合理地创造出所有结合体将会花费我们大量的时间。这一任务复杂性的一个重要方面体现在动画上。同时触发一些技能时要使用何种动画？我们曾经遇到过许多次因为技能错误，导致动画效果不好或使用不当的情况。这是游戏最后必须具备的一大关键要素，但是却需要我们投入更多的努力。不幸的是，这也仍然是一种容易遭受破坏的代码（例如在编码时很容易出现漏洞）。

关于这个系统的另外一个缺陷是，如果你希望它真正具有灵活性，你就必须为每个技能创造更多不同的设置。但是需要的设置越多，设计师所面临的任务就越复杂。所以在游戏开发过程中，我们的设计师总是会寻找一些本已经存在的功能。

当然了，这种系统的优点便是，具有如此多设置，让我们能够利用这些组合创造出更多独特的内容。特别是我们的游戏设计师使用射击和防御技巧创造出许多我们在编程时从未想象过的内容。

所以总的看来，在比较《Awesomenauts》的灵活性以及《剑与勇士》的非灵活系统时，我并不认为灵活系统拥有更大的优势。甚至，我想说《Awesomenauts》的灵活系统需要我们花费比之前的游戏多三倍的创作时间。

但是不管怎样，就像在《Awesomenauts》中，我们需要花费更多的时间进行游戏迭代，并需找更多有趣且不同的单位，所以更多的灵活性也是不可缺少的。我认为我们在《Awesomenauts》中做出了正确的选择。虽然这一选择需要我们投入更多的开发时间，但是我们却能因此更好地提升游戏质量。

游戏邦注：原文发表于2011年12月24日，所涉事件和数据均以当时为准。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The skill design system in Awesomenauts

Joost “Oogst” van Dongen

At Ronimo Games we always try to make innovative games, and in my opinion one of the biggest challenges when doing so is how to enable the game designers to do their work. Game designers work with things like game mechanics and control schemes, but you cannot know whether what you designed on paper is a good idea, until you played it and experimented with. It requires programming to create something playable, so unless a game designer is also a programmer, he cannot really do much on his own.

For artists, this problem has pretty much been solved: graphics tools are so powerful that artists can create most things without need of a programmer (except maybe for polish and performance). For game design however, this is essentially an open problem. There are many methods to empower game designers, but none are ideal. To name a few: scripting lanuages, event based systems, tools like Gamemaker and Virtools, and the most used of them all: just copying everything from existing games and not even trying to be innovative in any way (this also solves a lot of other issues, like the problem of being creative and taking pride in your work).

The approach we use to enabling game designers to create stuff is not ideal either, but it does work really well for us, so I’d like to write a couple of blog posts about the systems that allow our game designers to create game mechanics. Today is the first, and it is about our skill system.

To us it all starts with the coders and the game designers working together closely. Now whenever a programmer builds something, we set it up as flexible as possible, and make settings to control it. Things like speed, size, health, cooldowns and whatever else we can think of are put in settings and our game designers can edit those. Last year I wrote a post about our settings system in Swords & Soldiers that explains the basic idea further.

However, the way we approached this in Swords & Soldiers was also quite limited. All actual behaviour was programmed specifically per unit, so the only thing our designers could do, was tweak them. If they wanted to create a new unit, or even combine properties from existing units, they had to ask the programmer (me) to implement this for them.

In Awesomenauts we set out to make things more flexible. A character in Awesomenauts mainly consists of a list of skills, and which button needs to be pressed to use that skill. We have programmed around 20 skills (things like Shoot, Hit, Jump, Dash and Shield), and designers can create new versions of each skill with separate settings. Designers can also attach several skills to one button to create combinations, so maybe there is a combo skill that shoots a bullet and starts a shield at the same time.

In this trailer you can see how Sheriff Lonestar’s set of skills works out in the actual game:

Each of the skills refer to a group of settings that define the exact properties of that skill. So there can be many different Shoot skills, each with different settings. This way some become grenades, other bullets, lasers or mines, and some even spawn new creeps.

Now this is really flexible, and I guess it is quite obvious that building it like this works much better than hardcoding the entire character as we did in Swords & Soldiers. The trick to making this really flexible, though, is to make lots of settings. Throughout development of Awesomenauts, we have constantly been adding new settings to make the existing skills more flexible, so that more things could be made with them.

However, it may seem so, but working like this is not an Obvious Good Idea ™. It has some serious downsides as well, which all boil down to one thing: skills can be combined in any way and this makes all character code infinitely more complex. If you have 20 skills, then designers can already make 400 combinations of two skills happening at the same time. You can see where this goes once every character has 10 skills…

So implementing this system cost us an enormous amount of time to get all the combinations to behave correctly. A good example of the complexity here is animations. How to choose which animation to play when several skills are active at the same time? There are so many combinations that we kept bumping into situations where an animation did not look good or work correctly because some other skill interrupted it in the wrong way. This is very solid in the final game, but it took us a lot of work to get there. Unfortunately, it is still very fragile code (i.e. it is easy to introduce bugs when working with it).

Another downside of this system is that if you want it to be really flexible, then you need dozens of settings for each skill. The more settings there are, the more difficult it becomes for the game designer to keep track of what each does exactly. During development it happened quite often that our designers asked for a feature that was already there.

Of course, the upside of this is that with so many settings, there are many combinations that achieve totally unique things. Especially the Shoot and Shield skills have been applied by our game designers to do totally different things than what I expected when we programmed them.

So choosing between the flexibility in Awesomenauts and the very inflexible system in Swords & Soldiers, I actually don’t think the flexible system always wins. I would even say the system in Awesomenauts might be up to three times as much work.

However, if, like we did in Awesomenauts, you want to spend a lot of time iterating on the game design to find the most fun and varied units, then more flexibility is definitely necessary. So I think we made the right choice for Awesomenauts. It is a choice that cost us a lot of development time, but that also improved the game’s quality enormously. (source:Joost’s Dev Blog)