现代游戏设计师存在的共识是，要尽早及时常给游戏设计内容建模。但此时你通常尚无法将任何艺术元素放入模型中：美工也许也才刚刚着手制作内容。有些设计师也许会觉得这是件好事：游戏设计需要在只有彩色格子或简单图标的情况下也富有趣味，这样只要抽象核心玩法富有趣味，你就只需添加图像和音效。我过去非常赞同此观点，但在开发《Awesomenauts》的过程中，我发现基于此抽象原型也或许会导致开发者偏离设计调整方向，这未必有助于优化游戏设计。

真正让我意识到这点的是《Awesomenauts》的跳跃机制。当时这款新游戏还未融入任何艺术元素，于是我们通过《武器与战士》的角色创建游戏的首个玩法原型。但这些角色没有任何跳跃动画效果，因为《武器与战士》的角色没有跳跃元素。

尚未融入艺术元素的Awesomenauts原始模型

我们的设计师想要提高角色的运动效果，所以他们提议，角色在跳跃时应完全离开地面，跳跃后呈现着陆状态，而不是立即继续向前行走。我们此时尚没有任何艺术元素，所以我只是让角色在跳跃前及着陆后稍微停顿一会儿。所以当你点击跳跃时，角色就会停顿0.5秒，再向上跳跃，着陆后又暂停0.5秒，然后才继续行走。

就纯粹的游戏机制来说，这就是全部内容。当前模型和最终成品的差别在于在最终成品中，0.5秒的暂停会以特定动画效果呈现。所以就抽象游戏模型而言，这就是包含所有机制的完整模型。

但其体验效果依然非常糟糕：让人觉得游戏的控制装置反应迟缓和滞后，完全没有提高角色在游戏世界中的重要性和表现效果。所以在经过简短的内部测试后，我们决定去除停顿设置。

此时我发现这些停顿设置之所以呈现糟糕感觉不是由于机制本身出错，而是内容因为缺乏动画效果。若没有动画效果，跳跃前的0.5秒停顿就只是控制装置的拖延，点击跳跃键，然后有一小会儿什么都没有发生。但若融入动画效果，就会立即呈现相应内容：角色弯曲膝盖，离开地面。点击按键和向上移动的推迟有没有动画效果都一样，但有动画的反馈效果更好，因为角色会立即就你的按键操作做出反应，虽然它没有立即向上移动。

在我看来，这是个有趣的发现：我们很难基于抽象模型查看机制是否能够顺利运作。有时你需要通过适当的图像和动画效果获悉玩法是否合适。

在这种情况下，在跳跃前后改变角色形态已是很大进步，因为至少此时图像的反馈非常即时。

未融入中间动画的Awesomenauts，旨在让游戏呈现更迅速、直接的感觉

所以原型不适合进行内容测试。但没有额外动画效果是否是个好的选择？我依然觉得这是很好的选择：《Awesomenauts》是款基于技能的快速操作游戏，便捷和直接的控制装置非常重要，所以我们希望觉得能够立即进行跳跃。所以尽管原型不适合进行测试，我依然觉得这是正确的选择。

当然这因具体游戏而异：例如在《刺客信条》这样的游戏中，精致动画效果就非常适合，让人觉得角色真正攀爬墙壁，真的具有一定重量感。所以动画间隔的停顿是利是弊完全取决于游戏内容。

Prince of Persia非常注重角色运动，因此在跳跃中间添加动画非常重要

所以原型是否融入动画给玩法总体感觉带来的影响很大。这同样体现在其他内容中。下面是几个具体例子，其中模型是否融入音效和图像给呈现效果带来很大影响：

——游戏融入音效更富趣味。玩家从游戏体验中感受到的紧张和激动情绪主要来自声音。但有时，声音设计师很晚才加入开发进程中，因此在前期的制作中，你无法感受到真正的音效。在《武器与战士》中，我们以简单方式解决此问题：我们复制《魔兽争霸III》中的音效，暂时利用其中的音乐。只要完成Sonic Picnic真正音效的制作，我们就会去除所有的《魔兽争霸III》音效。但到那时，我们就会对真实游戏产生更好的感觉，因为游戏真正融入音效。

——谈到寻找合适风格的游戏配乐，常见快速建模方式是在游戏之外播放音乐，然后开始体验内容，查看是否适合。这显然是个好主意，但这也会给音乐和游戏的连贯性带来负面影响。其中问题是采用此方式，你无法将音乐的播放时间同游戏内容联系起来，因为你需要在游戏之外播放音乐。若音乐的播放时间同关卡同步，运作效果会更好，因为此时音乐不再置身游戏之外。我从很多游戏作品中总结出这点：只有正确把握音乐的开始和停止时机，音乐才能够有效配合主题。我们很容易就能够在原型中添加此定时设置，这可以起到显著的作用。

——一个典型例子是射击游戏中的枪支。射击枪支最重要的一点是呈现正确感觉，具有强大冲击力。枪支80%的冲击感来自图像和音效，只有20%来自枪支的真实玩法和破坏性，所以若没有声音和视觉画面，我们无法真正给枪支创建模型。但创建这些内容涉及很大的工作量，所以我猜想你通常会在没有这些元素的情况下着手内容（游戏邦注：因此你无法判断某枪支概念是否合适）。

——《武器与战士》的Aztec Sun Giant和Viking Frost Hammer就抽象游戏设计来看是颇为类似的士兵——缓慢的个体，他们需要应对破坏区域，然后迅速将敌人驱逐出战争之外。体验没有图像元素的游戏时，玩家也许会觉得，它们过于相似，只在价格和热门程度上存在差异。所以我们也许需要融入更多变化？不见得如此：融入图像元素后，两个个体也许就会呈现独特特性，顺利于游戏中运作。同样，也许这两个元素并不适合采用没有图像元素的原型。

左边是 Viking Frost Hammer，右边是Aztec Sun Gian

整个话题中最重要的一点是，建模方式会极大影响最终结果。原型玩法（游戏邦注：无论有没有声音或图像元素）会呈现不同的机制运作效果结论，把握这点非常重要。当然我们非常支持趁早及时常进行创建原型，虽然你还没有任何图像元素，但我觉得趁早添加声音和图像元素帮助很大，即便是暂时借用其他游戏的艺术元素。

本文主要谈论图像和声音元素，我觉得建模方式也会影响内容的最终成果。在进行纸上建模及其他游戏中的编辑器建模是记住：建模方式会给作品的最终成果产生一定影响。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

How a lack of art influences prototyping results

It is common knowledge among modern game designers that you have to prototype your game designs early and often. Yet when you do that, you usually don’t have any art to put in your prototypes yet: the art team has probably also only just started development. Some game designers might say this is actually a good thing: your game design should be fun even when played with just coloured squares or simple icons, so you should start there and only add art and sound once the abstract core gameplay is fun. I used to agree with that in most cases, but during development of Awesomenauts, I learned that working from such abstract prototypes can also steer your design in certain directions, which is not always an improvement.

What really made me realise this is the jumping mechanics in Awesomenauts. Since we didn’t have any art for this new game yet at that point, we made the very first gameplay prototypes for Awesomenauts using characters from Swords & Soldiers. However, these characters don’t have any jumping animations, since Swords & Soldiers doesn’t feature any jumping.

Now at some point our game designers wanted to add some weight to the movements of the characters, so they proposed that the characters would need to really push off the ground when jumping, and really land after a jump instead of immediately continuing to walk. Since we didn’t have any art for this yet, I implemented this by simply adding a short pause before jumping and after landing. So when you press jump, the character takes 0.5 seconds before going up, and after landing he pauses 0.5 seconds before continuing to walk.

In terms of pure game mechanics, this is the entire thing. The only difference between this and what would be in the final game, is that these 0.5 seconds pauses would have specific animations for pushing off and landing. So in terms of abstract game prototyping, this was a complete prototype with all the mechanics in it.

Yet is played horribly: it simply felt like the game’s controls were slow and lagging behind, not like the character had more weight and presence in the world. So we threw out the pauses after a couple of short internal playtests.

At this point I realised that the reason these pauses felt bad was not that the mechanic in itself was wrong. The reason it felt bad was that there were no animations. If there is no animations, then the 0.5 seconds pause before jumping is simply a delay on your controls. You press the jump button and nothing happens for a little while. Yet when there are animations, something does happen immediately: the character bends through his knees and pushes off the ground. The delay between pressing the button and moving up is the same with and without animation, yet the feedback is way better when there is animation, because the character immediately reacts to your button press, even though he doesn’t immediately start moving up.

To me this was an interesting realisation: it is not always possible to use abstract prototyping to see whether a mechanic works! Sometimes you need proper art and animations to know whether the gameplay is any good.

Note that in this case, squashing the character before and after a jump would already have been a big improvement, because this way at least the graphical feedback would have been immediate.

So the prototype was not a good enough test. But was not having these extra animations a good choice? I still think it was: Awesomenauts is a very fast skill-based game and quick and direct controls are incredibly important, so we would have wanted immediate jumping anyway. So despite the incomplete test, I definitely think we made the right choice.

Of course, this is totally different for each game: for a game like Assassin’s Creed, the subtle animations really make the game, and make it feel like the character is really climbing those walls and has real weight. So it really depends on the game whether the delay that is added by in-between animations is a good thing or not.

So whether you have animations in your prototype or not greatly influences the core feel of your gameplay. The same applies to many other assets. Here are a couple of examples of situations where prototyping with or without sound and graphics can make a big difference on what the conclusions of the prorotype are:

-Games are way more fun with sound. Half the intensity and thrill you feel while playing a game comes from the audio. However, often sound designers are contracted rather late in development, so you usually don’t have the real sound effects during the first half of development. For Swords & Soldiers, we fixed this in an easy way: we simply copied the sound effects from Warcraft III and used those temporarily. As soon as the real sound effects by Sonic Picnic were created, we threw out all the Warcraft III sound effects. But until that time, we had a much better feel for the actual game, because we actually had any sound at all.

-When looking for the right style of music for a game, a common quick prototyping method is to simply put on the music outside the game and then start playing to see whether it feels right. This is of course a good idea, but it also influences the attachment between the music and the game negatively. The problem is that the timing of the music is not linked to the game when you do this, because you have to start the track outside the game. It works much better if the music is started at the exact same time as a level, because now the music is not part of everything outside the game any more. I noticed this with several games now: music never really feels right until the timing of starting and stopping the music is right. Adding this timing to a prototype is usually really simple and helps a lot.

-A really obvious example is guns in a shooter. The most important thing for a gun in a shooter is that it feels right and has serious impact. Since 80% of the feeling of impact for a gun comes from the graphics and the sound, and only 20% from the actual gameplay and damage of the gun, it is impossible to really prototype guns if you don’t add any audio and visuals. However, creating those well is a lot of work, so I guess you have to start without, but until you have sound, I don’t think you can really tell whether a certain concept for a gun is an awesome idea or not.

-The Aztec Sun Giant and the Viking Frost Hammer in Swords & Soldiers are rather similar soldiers in terms of abstract game design: slow, specialist units that deal area of effect damage and shortly put the enemy out of battle (through respectively knockback and stun). When playing the game without graphics, one might conclude that they are too similar, except for their large difference in price and health. So maybe more variation is needed? No, not really: when the art is added, these two units feel really unique and different, making them work really well in the game. Again, prototyping without art might not have been a good idea for these two units.

The most important realisation from this whole topic is that the prototyping method greatly determines the outcome. Prototyping gameplay with or without graphics and audio gives different conclusions about which mechanics work, and it is important to realise that this is the case. Of course, I am absolutely in favour of prototyping early and often, even if you don’t have any art yet, but I do think trying to add some sound and graphics as early as possible greatly helps, even if they have been ripped from other games for the time being.

There is a more general lesson here as well. This post was just about graphics and audio, but I think the prototyping method always influences the outcome. Paper prototyping, prototyping in editors from other games: always keep in mind that the prototyping method used has some kind of influence on the outcome!（Source：joostdevblog）