【GameLook专稿，未经授权不得转载！】

GameLook报道/Supercell是业内最为独特的手游公司，没有之一。从成绩来看，这家芬兰公司上线了5款游戏，而且都是十亿美元级独角兽，甚至还有CoC这样成功超过10年的产品。另一方面，Supercell旗下游戏还有一个非常鲜明的特点，那就是几乎所有游戏从本质上来说都是单人体验（单机或者一对一竞技）。

不过，2021年测试的《Everdale》改变了这一现状，这款游戏虽然目前仍未加入竞技玩法，但从一开始就要求多玩家合作。在GDC 2022大会演讲中，Supercell高级程序员Tristan Williams讲述了该公司为新游戏打造技术的过程与心得。

以下是GameLook听译的完整内容：

Tristan Williams：

从CoC到Everdale

我们今天要分享的是“从CoC到Everdale，从单人玩法到社交玩法”，我是Tristan Williams，在Supercell担任高级程序员，我是2014年加入的公司，在此之前，曾在Remedy、Splash Damage和Ratbag等多家游戏工作室就职。

今天的主要话题是开场介绍，游戏设计我们会浅尝辄止，大部分都是从技术层面来说的，最后分享一些心得。

你们可能有人听说过CoC，但比较神奇的是，这款游戏发布于2012年，并且自此之后就一直保持在iOS畅销榜Top 50以内，至今已经10年了。《Everdale》是我们最近测试的新游戏之一，发布于去年。

CoC是一款城建游戏，你建造各种资源，比如圣水和金矿，打造自己的防御设施和军队，然后通过塔防玩法攻击其他玩家的基地以获得资源，随后用这些资源训练更多军队并获得天梯分数。

在这款游戏里，你同时在屏幕上只能看到一个玩家的大本营，其核心玩法完全是单人的。

游戏里的部落实际上是可选玩法，你不会被强制要求加入部落，当然，部落成员还可以通过部落战更快速得到更多资源，不过它更多的是作为单机玩法之外的另一个资源收入渠道，你的进度依然完全是自己的。

《Everdale》的灵感来自于一些经典游戏，比如《工人物语2（The Settlers 2）》是我青少年时候最喜欢的一款城市建造游戏，还有《模拟人生4》以及《辐射避难所》，它们对这款游戏的角色和互动设计都有所影响。

另一个灵感来源是《文明6》，更多的不是对玩法的影响，而是游戏的规模，我们希望将《Everdale》做成一个比以往Supercell产品都更大的游戏。

在这款游戏里，玩家可以安排不同的角色建造各种建筑，还可以分配角色伐木、采石等多项工作，每个建筑都可以分配不同的角色，收集资源扩张小镇，并不断解锁新建筑和新角色，所有的工作和资源都是相互影响的，但首先要伐木才能建造更多的建筑。

以上并不是全部，这里是科技树，如果玩过《文明》系列可能会对此比较熟悉，你可以解锁新建筑、新等级。从游戏的一开始，玩家们就是在山谷里共同生活的，你可以在小镇看到其他玩家的村落，彼此之间不用转换，整个小镇地图是无缝连接的，所有人共同打造一个更大的世界。

你可以安排村民到羊毛纺织厂工作，得到羊毛之后我们可以找裁缝做袜子，这些建筑并不属于某一个玩家，而是属于整个小镇。Great Library里的科技需要所有人努力解锁，这些进度属于整个山谷的人。

这是交易系统，所有的订单都来自于很远的地方，通过这些订单，你可以获得资源以及山谷升级点，游戏玩法是非常放松的。

总的来说，山谷与你的城镇玩法深度关联，山谷技能解锁可以帮助城镇玩法推进，你还可以赢得金币建造更多的建筑。从一开始，山谷和城镇就是相互影响的，这是游戏的核心玩法，我们有共享的进度以及玩家之间的深度合作。

在谈更多内容之前，我们先说说《Everdale》的团队，这样更容易理解游戏中的一些决策。与很多的Supercell游戏一样，《Everdale》的团队非常小，实际上，我们从2016年就开始了这个项目，但团队人数大多数时候不到6个人，直到测试发布之前，才将团队扩充至10-20人之间。团队规模最大的时候，我们有4名客户端程序和2名服务器程序，这就是《Everdale》的背景。

做Everdale的梦想

接下来我想说说“梦想”。

所有的创意，不管是一款游戏、一幅画还是一本书，都是从某种形式的梦想开始的，哪怕你不是以这种方式思考，比如在你脑海中想要实现的想法，也是一种梦想，这些梦想都有不同的形式和大小。

我是如何区分梦想大小的？比如一个小的梦想可以是个非常酷的玩法机制，就像是在《卡通农场》里，你收割庄稼的时候不是点击屏幕，而是划屏的方式实现镰刀一样的收割动作。一个小的梦想也可以是个独特的玩法想法、一种艺术风格（比如Limbo），或者一些有趣的技术。

这些小的梦想就像是一粒种子，种在地下，随后慢慢发芽、成长，通常情况下，对于这些梦想，你都有比较清晰的参照物以便进行创造。但这里真正的挑战是做出差异化，你该如何做出独特的东西？

大的梦想，可以是你“崇高的目标”，它通常是用户体验或者情感驱动的，当玩家体验游戏的时候会有什么感觉？他们会不会在游戏里觉得自己是外星人、大厨或者管理城市的市长？它是从高度幻想开始的，与小梦想不同的是，大梦想是从最高处开始，然后向下生长，你考虑的是，我要打造什么树枝才能支撑这样的大树？最终你可能会找到种子，然后从下再次向上增长。

另外，你还可以同时拥有大梦想和小梦想。

大的梦想是令人生畏的，因为你可能还不了解其玩法机制，可能你只是有一个想法，“我想做一个感觉自己是神明的游戏”，但你该如何打造这样一款游戏？这样的梦想缺少参照物，有时候你可能在打造一个新品类，需要的技术可能并不存在。

说回《Everdale》，一开始的时候，我们希望触及大众用户，不想要加入战斗。这个想法来自于观察妻子玩CoC和《帝国时代》，如果你玩过CoC，就知道刚开始的时候会有几天的护盾，这个期间其他人没办法攻击你，因此也不会偷走你的资源。

所以在最开始几天的时候她很开心地建造基地，升级建筑，并设计了她很喜欢的阵型，然而几天之后，保护期结束，她的基地被人攻击了，丢失了很多资源，她觉得很失落，于是卸载了游戏。

《帝国时代》也是类似的经历，她派军队到处探索，填满了城镇，随后战争开始了，她受到了攻击，感受到了很大的压力，然后她退出了游戏，重新开始玩，到了战争开始之前的时候再次重新开始游戏，随后又一次卸载了游戏。

这让我看的眉头紧锁，我在想，或许市面上没有战斗的城建游戏很少，这是一个我们应该解决的挑战，或许并不是所有游戏都一定要战斗。我每天都玩很长时间的《Everdale》，也会投入时间玩《毁灭战士》，或许没有战斗的游戏可以作为一种休闲放松方式。我们的另一个梦想是，让它比之前任何一款Supercell游戏都更需要合作，都更有沉浸感。

我们再从梦想角度来看看这款游戏，小梦想方面，我们希望把它做成一款优秀的城建游戏，它的氛围应该是和平与放松的；大梦想角度来说，我们希望一开始就需要玩家之间的合作，我们要做的是真正有意义的合作，而不只是形式上的合作，我们希望打造一个无缝的世界和多个城镇。

因此，所有游戏都是以某种梦想形式开始的，你一开始可能意识不到，但脑海中或许会有某种感觉，努力确定这些梦想，因为它可以帮你在早期确定游戏的核心原则，在我们的案例中，它还可以推动技术决策。

我还想谈谈什么是合作玩法

这里用CoC举例，这是部落界面的截图，你可以看到部落成员，可以点击访问他们的基地，甚至还可以与他们聊天。

接下来就是部落战争，虽然依旧是单机战斗，但你们可以通过积累星星的方式帮部落获胜，你可以根据战斗表现获得星星和不同的资源数量，这些资源都是你的，所以本质上来说它依然是单人玩法。

对于升级版的合作，我们希望打造一个无缝的世界，可以实时看到其他人玩游戏，可以在世界当中有真正的玩法互动，而不只是菜单层面的互动。我们希望团队协作是真正有意义的，玩家之间有共同的目标，我们对这些目标非常的兴奋。

但是，对这个目标，我们同样有些担心，比如更大的游戏世界模拟和渲染起来会比较昂贵，因为《Everdale》的目标是手机硬件，而不是PC或者主机设备。我们觉得这样的游戏设计起来可能会很复杂，测试起来或许更复杂。

不过，我们依然毫不犹豫地开始了这个项目。

Everdale的技术迭代

技术层面，我们挖掘了CoC的潜力，它使用了内部引擎打造，每次只能在屏幕上展示一个城镇，而且合作仅停留在菜单层面，虽然现在不完全是2D，但过去它只能做2D。

另外，它是客户端/服务器架构，服务器授权并实时验证客户端，我们是通过大量的“代码”在客户端和服务器运行实现的，这些代码当中没有任何浮点值。它的逻辑状态是固定的，因此你不用定制化。

CoC的客户端和逻辑代码非常依赖单项物，比如游戏物体设计经理负责提供所有的物体，商店促销管理者决定所有的商店促销活动，这种方式很方便也很容易写代码，但问题在于，你一次只能运行一个城镇。

在多城镇设计中，我们把它拆分为“上下文”概念，它打包了城镇运行状态所需要的一切子系统，不管是物体、商店还是任何环节，都知道它们所处的运行状态是什么，虽然没什么大不了的，但是很好用。

这样做的优势在有，我们甚至可以在后台运行城镇拷贝版本，还可以用它做逻辑验证的debug，我们可以预测未来。总得来说，这些设计目标给了我们很不错的技术优势。

我们想要做一个无缝世界，意味着每个城镇都有一个“渲染世界”，也就是每个城镇都有自己对应的系统，比如，我的城镇和你的城镇都是从0开始，然后各自发展为不同的规模。山谷也是一个渲染世界，它包括山谷里的建筑和物体，与玩家城镇不同。山谷的视觉是由不同世界组成的，每个世界都用补偿的方式渲染。

我们希望把它做成一个城镇建造游戏，村民有不同的文化、服饰，而且可以运行大量不同的任务，我们还希望对村民进行定制化，比如每个人的服装。如果从2D角度来看，这需要大量的内容排列，一旦想要改变某一样东西，就需要重新渲染大量的东西。

因此我们决定采取3D风格，但问题是，我们还没有一个真正的3D引擎。我们可以做一些3D的东西，比如《荒野乱斗》里的角色是3D的，但环境是2D；《海岛奇兵》的一些环境是3D的，《皇室战争》的一些菜单也是3D。

所以，我们打造了一个非常简单的3D引擎，之所以说简单，是因为它的用途几乎与我们的2D用户非常接近，因为Supercell大部分的人都没有3D游戏背景，只有我和少数人具备3A主机游戏的研发经历。 做引擎非常重要的是，能够让人们快速上手做出新内容，这也是我们做简单3D引擎的原因。

另一个决策就是，我们的摄像头控制直接复制了CoC，你们可能注意不到，但一定可以感觉到的是，你看到的视野与手指碰到一致，而且，这个引擎在《荒野乱斗》的时候就开始做了，到了《Everdale》的时候我们一起对它进行提升，所以它一直在变得更好用，这样一个小小的梦想，最终带来了一个让整个公司都受益的大技术。

合作玩法的支撑技术

真正的主菜是合作玩法技术，我们想要的是一个无缝世界里的多人游戏，一开始的时候，玩家们的动作会发送给其他客户端，但你并不能对此做出互动，也无法一起完成某些事，在你自己的成长，验证过程很简单，你想要做的动作会发送给服务器，得到验证后即可执行，如果是无效的，服务器会发回正确的方式。

然而，如何处理共享状态呢？之前的游戏里，我们所有的共享状态、信息处理以及每个功能的纠错都是手动的，所以每次做新功能的时候，我们都需要客户端和服务器方面的程序员加入。但我们想要更复杂的功能，而之前的技术只能带来比较乏味的合作功能，而且会限制研发时间。

那么，我们该怎么做？我们的第一件事就是为山谷增加共享的逻辑状态，包括共享的 逻辑代码和上下文，我们还确定了“行为”目标，包括玩家动作与参数，以及所有的验证核查、验证失败状态的处理以及需要的回撤。

具体过程就是，如果客户端验证通过，就发送给服务器，每个城镇以及山谷都是独立的，如果验证失败，客户端会运行失败代码并回撤到之前的状态，如果验证成功，则发送给山谷状态服务器，如果山谷服务器验证失败，则发送回城镇服务器和客户端，运行回撤代码，验证通过，则分发给其他客户端。

你们可能已经看出，这种方式并不够好。不过，它的优点在于，你可以在一个地方更简单更整洁的看到所有的处理过程，而且可以共享大量的逻辑代码。这种方式下，一名游戏程序员就可以打造完整的交换过程，不需要服务器程序的帮助，因为服务器程序需要他们更擅长的事情。

劣势在于，程序要预测所有可能的失败条件，并且对所有情况下加入合理的回撤代码。而且，它依旧很冗长、需要大量的人力，很多方面都和之前的旧方法相似。所有的客户端和UI代码都需要写下来，以保证所有不同场景下的边缘情况都可以被处理，这需要大量的时间和努力。

为了改善这种状况，我们采取了resimulation-based approach，如果你写过多人游戏，可能对这种方式比较熟悉，客户端先于服务器运行，如果遇到了错误就回到之前的状态，然后重新预测重新运行，在玩家没有注意到之前就完成了这一切。

因此，服务器会同时运行山谷内所有的城镇，客户端比服务器运行稍早一些，如果发生改变，客户端就可以回到上一个良好的状态并重新模拟游戏。因此，服务器同时验证并应用城镇和山谷的所有动作。

这种情况下，我们不再需要做所有的错误解决方案或者回撤，只是在需要的情况下验证和执行特定行为。这种方式非常强大，服务器状态始终都有明确的定义，大多数情况下错误的方案都可以被统一解决。

尽管不是所有情况，尽管不适合快节奏的动作游戏，但这种方法很适合慢节奏游戏。

这种方法的不利在于，它在客户端和服务器存储了很多东西，对CPU和存储要求较高。有些情况下，客户端和UI仍需要谨慎处理，因为错误的预测可能导致状态变化很大。它避免了直接从逻辑代码转为客户端代码，比如有时候导致声音或者特效可能在重新模拟期间被触发很多次。

实际上，这对《Everdale》项目来说是一个很大的成功，因为我们可以更快速地研发复杂的合作游戏系统，与CoC技术相比，我们把某些东西的研发时间从数月缩短到数周，一个功能只需要一个程序就可以搞定。

最后，如果你做过手游，就会知道迭代时间是很关键的，尤其是团队非常小的情况下，很多时候我们只有3个程序，而其他们还要处理渲染技术，因此节约他们的时间，快速测试功能是很重要的。

如何保证游戏性能？

我们的问题是，每个山谷有10个城镇，每个城镇都有成百上千个物体，因此每个物体做debug需要的工作量很大，我们的逻辑也非常复杂，你无法一直推进，只能等待上一个结果之后才能进行下一个流程，所以性能成为了比较大的问题。

所以在渲染方面，我们选择将成长渲染为纹理代名，我们首先加载整个城镇而不是城镇里的所有物体，随着你放大城镇，再对代名进行更新，避免了一直要渲染所有城镇带来的性能问题。

如果你知道自己想要的是什么，就会发现还有很多工作要做，我们将城镇渲染成正常的大小，但放大之后会显得有些嘈杂，所以远距离看到的是icon版本的城镇。与此同时，我们做了大量的努力，让缩小和放大之间的视觉切换尽可能无缝化。

优化的逻辑是可以在服务器同时运行多个城镇，并且在客户端可以快速重新运行。我们的玩法是相对慢节奏的，所以我们发现可以将logic tick rate从25Hz降低到5Hz，与此同时，玩家还不会注意到任何差别。

反应时间是一个问题，从你的动作到真正看到反馈可能会有最高200毫秒的时延，所以客户端的反应方式是，如果同步没有发生，那就直接跳到下一个城镇，让他们感觉所有动作带来的反馈都是即时的，必要的时候客户端还会插入到逻辑状态中，这种方式是行之有效的。

我们还确保所有的不同长度逻辑的更新都是确定的，如果能够重新去做，我们或许会选择不同的方式，但考虑到当时的限制，这是我们最好的选择。我们允许所有物体、系统申请它们可以更新的次数，我们发现很多物体可以一次数秒跳过更新。我们让客户端一点一滴的推进，而服务器可以快速推进。

虽然这个数据有点保守，但我们降低了80-90%的服务器负载，这里我们说的是与CoC的城镇对比，所以即便是同时要运行10个城镇，我们也只需要使用一个CoC城镇的服务器负载，我们还在客户端做了屏幕外的城镇逻辑更新。

但遇到的问题是，我们如何保证确定性，所以我们可以运行后台验证，后台的城镇副本快速运行并与现在的版本对比，如果出错则可以存储其轨迹，我们可以加载到客户端深度运行，并找到解决方法。Debug服务器也可以在同步中断的情况下保存运行轨迹，我们可以找到对应的问题。

有了确定性和分离式逻辑执行方式之后，我们可以做回退测试，将玩法“回放”存储用来测试游戏bug，我们存储所有城镇并且在变化发生之前和之后进行模拟，确保带来同样的结果，所有形式的验证都可以在后台运行。

我们还打造了可以玩游戏的AI逻辑，一开始只是在客户端这样做，但后来我们发现可以在逻辑代码库运行，还可以将同步逻辑移植到逻辑代码库，然后将服务器连接到负载测试状态，再次运行。我们运行了数千个bots，收集了大量的平衡与稳定性数据，这种方式帮我们避免了很多罕见的bug，当然也非常复杂，因为是很多系统一起工作。

结果是，我们实现了梦想，至少它已经进入了测试阶段，即使是没有最终进入全球发布状态，这个项目的技术也可以在后续被全公司继续使用。

心得

这里主要的心得是：

拥有大的梦想，但要睁大眼睛。追逐宏大的梦想并不一定是容易的，但你的努力不会白费，游戏设计和技术之间是深度影响的，你在技术方面的投入可能会在以后有用处，希望今天的分享能够帮助你们追寻自己的梦想和目标，更希望未来看到更多非常酷的新游戏出现。

问答环节：

1、你在演讲中提到了交易系统的讨论，以及每次做一个功能，开发者参与到这些功能的设计过程中吗？

A：当然如此，尤其是在小团队当中，让所有人都参与到每个环节的对话，这可以节约大量的修改时间。

2、提到变焦（放大或者缩小）的问题，你说游戏允许多种方式的缩放，多大或者多小才是合适的？有时候在大屏幕上的表现很好，但如何让它适应各种尺寸的屏幕？

A：适配不同的机型，适应不同尺寸的手机屏幕，做到自然流畅的缩放，这需要大量的尝试，所以始终有可以提高的地方。我们做了很多测试，团队所有人都玩过很多次，以找到最合适的感觉。

3、在漫长的尝试当中，由于团队很小，你们如何平衡迭代与游戏API更新之间的关系，以便游戏不会被移出PlayStore？

A：这是个非常好的问题，我要说的是我们没有完美的标准，只是用一些常识，通常一批优秀的开发者共同努力可以做出比较好的决策，我们公司内部有一个说法，那就是“Supercell优先”，也就是说，我们做决策的时候更多考虑的是对公司有好处，而不只是为了满足我个人的天马行空的想法，这对我们是很有帮助的。

4、谈到确定性，你们如何保证同样的代码能够适配所有的CPU架构，带来同样的结果？

A：这个问题很好，实际上问题比这个还复杂，因为我们的服务器是用Java支持的，我们使用了固定点（fix point），没有浮点（float point），这样做会在M1处理器条件下有些边缘案例出现，我们需要手动去解决，但这些都是比较特殊的情况。

5、当你提到服务器架构的时候，曾提到多次反应，客户端也有多次重构（refactor），如何平衡快速创意和重构之间的关系？有时候重构是被直接跳过的，因为它不一定会进入最终的产品中，你们是如何做的？

A：对于这个问题，我个人有一些原则，如果复制黏贴代码超过三次，我就会开始考虑重构，这取决于考虑什么是对的，有时候我可能希望更早这么做，虽然需要投入更多的努力，但完全是值得的，所以这是根据个人经验来处理的。

6、这听起来可能会耗费比较长的时间，你如何处理它和其他计划的关系，比如你要跟制作人说，这个功能需要重构，所以还需要一两个月，那么是否意味着项目要因为这个功能往后推迟，还是说会采取一些折中方案？

A：有时候一些功能确实需要很长时间，但我们可以在它的基础上让以后的进度快很多。如果不是团队所有成员都要参与，只是我自己的工作，那我可以专门投入时间去解决它，等所有系统都完成之后，其他人也可以在你的基础上继续。最重要的是让你的制作人了解它的代价，当然更重要的是你要清楚需要付出的真正代价是什么，努力做出最好的决定。

7、你在提到项目梦想的时候说到，游戏不需要加入战斗以避免损失带来的挫败感，但《英雄联盟》这样的游戏更有竞技性，但你不会损失任何资源，所以团队有没有考虑加入这样的玩法保持游戏的竞技性？

A：实际上我们是考虑过的，但游戏当时仍处于很早期，包括现在，我们也讨论过，或许两种玩法可以共存，让休闲和竞技玩家可以同时享受这款游戏，或许未来我们会考虑这样的玩法。

8、从玩家的体验观察当中，你们学到了什么？

A：目前来看玩家们的反馈很好，不过有一点比较意外的是，我们本以为这款游戏会对全新的用户类型更具有吸引力，结果发现很多的CoC玩家也很喜欢。如果愿意，实际上也可以用很硬核的方式玩《Everdale》，但我并不提倡。

玩家构成方面，我们原以为女性用户会占绝对优势比例，但结果发现实际上那女比例比较均衡，这也是非常不错的结果。当然，游戏目前还处于早期阶段，我们还需要学习很多东西。

9、你在总结的时候提到，这款游戏有可能不会进入全球发布阶段，那么它的原因可能是什么？没有战斗还是说付费表现不好？

A：可能是我的措辞有问题，目前《Everdale》仍处于测试阶段，我们还在观察玩家的反应，收集更多的数据，有些玩家的行为甚至和我们预期的不一样，我们还在学习很多东西。我没办法保证它一定能够全球发布，但在Supercell，我们所有的项目决策都是团队做出来的，比如，我们是否还相信它能够成为一款让人们体验10年以上的游戏？

我说的意思并不是要强调它不会全球发布，一切还要看后续的玩家反馈和游戏表现。

10、CoC是一款竞技向的游戏，经济因素可能更容易让人付费，因此可以围绕这方面设计变现系统，对于《Everdale》有没有这样的变现考虑？

A：我们还处于学习阶段，有些时候你总能看到惊喜，人们不会按照你的设想去玩游戏，所以我们在不断地学习、适应，尝试更多东西。

11、我看到人们在社交行为方面有很多的沟通，比如在Discord、Facebook或者Reddit形成讨论组谈论游戏策略，你们是否考虑过打造自己的工具或者在游戏内做特定功能支持这些社交行为？

A：始终有大量的想法出现，我们会看到底会发生什么。有时候看CoC的头部玩家行为，你会觉得很疯狂，他们甚至画出了各种各样的防御布局，这些都是非常酷的事情。