游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

如何为一款异步多人游戏创造AI

发布时间:2015-06-05 11:06:27 Tags:,,,,

作者:Andras Bondor

《城堡风暴》是什么

《城堡风暴》是由Zen Studios所开发的一款集合了2D实体破坏性和塔防元素的游戏。它是在2013年5月面向Xbox发行,之后又出现在Steam,PlayStation,PlayStation Vita,PlayStation 4,任天堂Wii U和Xbox One上。一年后,也就是在2014年起面向手机平台的免费版本也问世了。

其核心游戏玩法提供给玩家实现目标的多种不同方法。

玩家可以派遣军队到战场上继续战斗。在游戏的4个国家中,每个国家都拥有9种不同的单位。有些单位只是在行走并粉碎任何事物,而有些单位则会发射飞箭或炮弹,有些单位则会治愈周边的军队。

使用古代武器朝军队或城堡发射炮弹则是控制战斗的另一种方式。这里存在许多不同的投射物,大多数投射物都具有特殊的能力,如分裂成其它不同的投射物,在冲击时爆炸,改变方向,解冻或治愈它们所撞击的单位。

创造攻击或防卫魔法咒语,如摧毁敌人或治愈军队,召唤其它不可生成的单位或使用防护物保护战地等等也是一种有效的选择。复制关键单位或转变敌人军队方向也能够派上用场。

玩家可以召唤一个英雄并以骇客砍杀风格进入战场去控制敌人的军队。这种方法有时候也能够扭转战斗局势。

城堡是根据军队的空间而建造的,这能够决定玩家将派遣怎样的单位到战场上。这同样也包含了不同的支持空间,即能够增加军队数量,提升食物的产量,并提到玩家对于敌人投射物的防卫性。

引进多人游戏

我们已经在手机上玩过经典的非对称异步游戏,即玩家将设立自己的防御系统并离开基地,之后其他玩家将攻击他并实时协调自己的军队。这些游戏需要AI,但是AI在游戏中的作用只是寻找道路与瞄准目标而已。

然而当我们面对的是拥有全新游戏模式的《城堡风暴:自由攻城》时,我们需要问自己一些问题,市场上也还未出现能够参考的对象。《城堡风暴》与其它异步游戏的最大区别在于,这款游戏的游戏玩法全是对称的。基于主机和Steam的游戏拥有一些不同的多人游戏模式,但是其标准的对抗都是围绕着两个主要目标展开:获得敌人的旗帜或摧毁他的城堡。我们并不想改变游戏玩法的核心元素,所以将标准角色带到游戏中是不可能的,在这里防御者将高举防护物,而攻击者只会派遣军队。

CastleStorm-PVP(from gamasutra)

CastleStorm-PVP(from gamasutra)

准备工作

我们的第一步是为对手创造一个真正的AI。因为游戏基础是基于生成系统,偶尔射击,投掷咒语以及召唤英雄的能力而创造的,所以这是我们最初需要设定的基本内容。为了多人游戏而创造的适应性AI系统是严格受数据驱动的,这意味着我们没有可遵循的预定程序,所有的一切都是源自配置文件。

如何运作

作为一个基于事件的系统,它可以被分解成两个主要组件。一方面,在玩游戏的同时会出现一些不同类型的事件(就像生成一个单位,发射1枚炮弹,投掷一个咒语,摧毁一个单位等等)。如果出现一个事件,系统将寻找一个行动,并定义AI在这种情况下将作出怎样的反应。

首先,它将经历一组过滤器以判断这一事件是否是它应该作出回应的对象。过滤器能够协调每一个事件以匹配我们所寻找的内容(就像一个单位/咒语/炮弹是否属于玩家或敌人;这是否是旗帜的载体;是否拥有比一些比例更多/更少的生命值;是否更接近敌人的门;是否是一种特殊类型;周边是否拥有一些其它单位)。

如果找到匹配项,系统将着眼于行动以明确该做什么。每个行动包含一种以上的反应,就像发射一枚炮弹,投掷一个咒语,派遣一组军队等。AI将检查每种反应是否(炮弹是否冷却,或者是否存在足够的食物能促成单位生产)能够保持预设顺序,如果它找到一个的话便可以将其添加到队列中。

cs_ai_event_handler(from gamasutra)

cs_ai_event_handler(from gamasutra)

AI将启动四个不同的层面:发射炮弹的古代武器模式,投掷咒语的魔法模式,派遣单位的军队模式,以及召唤英雄的英雄模式。

每个层面都有自己的队列反应,并且在执行后都是伴随着预期的炮弹/魔法/军队,目标和延迟。不管何时当延迟达到0时,反应将被执行并从队列中撤除。如果队列中不存在反应,那就说明未采取任何行动。

但是作为一款异步多人游戏,玩家应该拥有定制自己的防卫AI的选择。创建城堡并设置理想装备是一件事,而如果所有的防卫者都使用一个预配置AI,这很快就会影响游戏的乐趣。这也是为何我们会想出这个理念:AI应该能够掌握并适应玩家的游戏风格,并在离线的时候使用抵御攻击者的模式。基于这种方式,如果玩家基于同样的装备和城堡攻击两个敌人,游戏便能够以不同方式呈现出来,就像两个玩家是基于不同方式游戏。

适应系统

为了做到这点,系统会监控玩家所进行的每个行动,并贯穿最新事件以寻找最匹配的内容。如果没有任何收获,它便会从当前的战场快照中生成一个。在战斗最后将会生成一个人类可读懂的配置文件(类似于我们手动创造的),它将包含系统基于玩家回合所生成的每一个事件和行动。下一次当我们攻击这一玩家时,这个全新生成的文件将用于AI中。我们必须清楚系统并不能重写数据,它只能够延伸之前创造的数据集。如果出现全新事件以及与之相关的行动,它便会着眼于之前的数据以检查是否存在重复,以避免冗余。如果事件已经被记录下来了,系统便会添加行动作为对于事件的另外一种反应。如此玩家便能够随着时间的变化而改变自己的游戏风格,系统也能够监控到玩家最常派遣怎样的军队,最喜欢使用什么内容,从而在保持同一装备的情况下切换到全新战术中。举个例子来说吧,如果玩家更喜欢在前十次战斗中使用石人与牧师的组合,然后切换到石人与弹弓的组合,那么在几次战斗后AI将开始倾向于后者。

还有一些其它元素也被记录了下来,如精确度和反应时间。当我们更接近公开测试时,我们意识到同样的配置文件也能够基于第1个关卡和第20个关卡创造出同样的游戏玩法,因此这并不能在较高的关卡中提供足够的挑战性。于是我们决定基于玩家的关卡调整这些数值的极限,即意味着当更高关卡的玩家变得更准确且更快速,AI也将基于同样的水平运行。最终结果还是让人很满意的,因为关于较低关卡的AI的配置文件将在同样的水平上创造出适当的挑战,并在战斗变得更加激烈的时候升级到更高的装备,但同时保持不变的难度。

经过证明适应系统具有很强的学习力。在经过4至5次战斗后它便能够创造一个比默认AI更有效的定制AI。着眼于我们尝试着做到的,该目标与创造一个不断学习的神经网络一样,尽管它消除了对于无数次迭代的需求并在达到一定重量的时候会冻结系统。我们需要不断改变系统从而能在较少的样本中实现最佳结果、

当我们在运行测试时,它证明了这样的AI数据文件将超过200千字节。对于单一用户来说这并不是多大的空间,但是为了避免重荷载,并且玩家在每次开始战斗时都需要加载这一数据,所以我们清楚需要尽可能多地削减这一规格。第一步便是将人类可读懂的文本文件转变成二进制内容,这能够削减一半的规格。之后我们将添加自定义压缩到流中,这能够将任何数据文件缩减到10千字节中(游戏邦注:通常是在4千字节到6字节)。

CastleStorm-PVP(from gamasutra)

CastleStorm-PVP(from gamasutra)

结论

随着新游戏模式已经出现在Android和iOS平台上,我们很期待它之后的发展,并且玩家也会感受到它的整体价值。创造这种全新模式并尝试不同的理念真的是种很棒的经历。创造适应系统是很难的,要做到平衡并不是一件容易的事。然而当所有的一切有效地匹配在一起时,我们便能够一直看到各种不同的变化。

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

Postmortem: Crafting AI for a symmetric asynchronous multiplayer game mode of CastleStorm

by Andras Bondor

What is CastleStorm

CastleStorm is a mixture of 2D physics destruction and tower defense brawler, developed by Zen Studios. It has been released for Xbox 360 in May 2013, followed by the releases for Steam, PlayStation 3, PlayStation Vita, PlayStation 4, Nintendo Wii U, and Xbox One. Its free to play version for mobile was launched a year later, in May 2014.

The core gameplay offers several different ways for the players to achieve their goals.

They can send out troops which will fight on the battlefield. There are nine different units for each of the four nations available in the game. Some of them just walk and smash everything, others fire arrows or cannonballs, some can heal or buff the troops around them.

Firing from the ballista aiming the troops or the castles is another way to take control of the battle. There is a wide variety of available projectiles, most of them with special abilities, like splitting to multiple other projectiles, exploding on impact, converting, transforming, freezing or healing the unit they slam into.

Casting offensive or defensive magical spells, such as damaging enemy or healing friendly troops, summoning other non-spawnable units or protecting the battlefield with the projectile shield is an option as well. Cloning key units or turning the enemy troops around on the field may really come in handy, too.

The players can also summon a hero and jump into the battlefield themselves in hack ‘n’ slash style to dominate the enemy troops. This can turn the tide of a battle sometimes.

The castles are constructed from troop rooms, which determines what units the players will have on the field. It also consists of different support rooms that can grow the number of troops the players can spawn, or speed up food production, increase defenses against enemy projectiles etc.

Introduction to multiplayer

We’ve all played classic asymmetric asynchronous games on our mobiles, where a player sets up his defenses and leaves the base, another player then attacks him and coordinates their troops in real-time. These games require little to no AI, as simple as path finding and basic targeting, but that’s all.

However, when we’ve come to the point that CastleStorm – Free to Siege should receive an update with a completely new game mode, we’ve had several questions for ourselves, and there were no other titles on the market to look at for reference. The biggest difference between CastleStorm and the other async games is the fact, that CastleStorm’s gameplay is all symmetric. The game on consoles and Steam has several different multiplayer game modes, but the standard versus is based around two major objectives: capturing the enemy’s flag or destroying his castle. We didn’t want to change the core elements of the gameplay, so bringing the standard roles to the game was impossible, where the defender would put up defences, and the attacker would simply send out troops…

Preparations

Our first step was to create an actual AI for the opponent. As the base game is built on scripted spawn system, occasionally firing ballista, and the magic casting and hero summoning ability only allowed for the player, they were fundamentals we had to set first. The adaptive AI system created for the multiplayer is strictly data-driven, meaning that it has no pre-programmed behavior to follow, everything comes from – in our case – config files.

How it works

Being an event-based system, it can be split into two major components. On one hand, several different types of events are generated while playing the game (like a unit is spawned, a projectile is fired, a magic is cast, a unit is damaged etc.). If an event occurs, the system looks for an action, which will define what reaction should the AI take in such a case.

First, it runs through a large set of filters to see if this event is one it should respond to. The filters are meant to be able to fine-tune every event to match exactly what we are looking for (like whether a unit/spell/projectile belongs to the player or the opponent; is it a flag carrier; has more/less hp than some ratio; is closer to the opponent’s gate; is a specific type; has a number of other units around etc.).

If a match is found, the system looks up the action to see what to do. Each action can contain one or more reactions, like firing a projectile, casting a magic, sending out a set of troops, or using the duck ability. The AI checks every reaction if they are available (is the projectile not on cooldown, or is there enough food for the unit to spawn) keeping the preset order, and if it finds one, it is added to its queue.

The AI operates on four different layers: – Ballista mode for firing projectiles – Magic mode for casting spells – Troop mode for sending out units – Hero mode, for playing the hero

Each layer has its own queue of responses, each with the desired projectile/magic/troop, the target and the delay after it should be executed. Whenever the delay reaches zero, the response is executed and removed from the queue. If there are no responses in the queue, no action is taken.

But being an asynchronous multiplayer game, the player should have the option to customize his own defending AI. Building the castle and setting the desired equipment is one thing, but if all defenders would use one preconfigured AI, it would ruin the fun after a very short time. That’s why we’ve came up with an idea: the AI should be able to learn and adapt the playstyle of the player, and use the patterns against his attackers while being offline. This way, if a player attacks two opponents with the same equipment and castle, the game will be played out differently, as the two players probably don’t play exactly the same way.

The adaptive system

To achieve this, the system monitors every action the player takes, and runs through the latest events to find the most suitable. If none is found, it generates one from the current snapshot of the battlefield. At the end of the battle, a human readable config file is generated (similar to what we’ve created by hand), containing every event and action the system has generated based on the players session. The next time we attack this player, this newly generated file will be used for the AI. It is important that the system doesn’t overwrite data, it extends the previously created datasets. If a new event occurs and an action is associated to it, it will look up the previous ones to check if there is no duplication, to avoid redundancy. If the event has already been recorded, the system simply adds the action as another reaction to that event. It is also possible for a player to change his game style over time, as the system also monitors what troops he sends out the most, and will prefer the ones with the highest usage, so switching to new tactics while keeping the same equipment will be followed by the AI as well. For example, if the player prefers to use golem-priest combos for the first ten battles, then switches to golem-catapult later on, after a few battles the AI will start to prefer the latter too.

Several other factors are also recorded, like accuracy and reaction times. When we were getting closer to the open beta, we realised that the same config would produce the same gameplay on lvl1 and lvl20, and thus would not provide enough challenge at higher levels. We’ve decided to tune the limits of these values based on the players level, meaning that on higher levels if the player is accurate and fast, the AI will be able to catch up and operate on the same degree, but on lower levels it is a bit handicapped. The end results were quite satisfying, as the same config given to a low level AI would produce a good challenge on the same level, and after upgrading to higher equipments the battle became much more intense, but kept the same difficulty.

This adaptive system proved to be a quick learner. After only 4-5 battles it can already produce a customized AI which will be much more efficient compared to the default that everyone starts with. Looking at what we’ve been trying to achieve, the goal was similar to getting an ever-learning neural network, while eliminating the need for millions of iterations, and having to freeze the system once the correct weights are found. We needed a continuously changing system that can achieve good results from as few samples as possible.

When we ran our tests it turned out that such an AI data file can be more than 200 Kbytes in size. This is not much space for a single user, but preparing for heavy loads and keeping in mind that the players will download this data every time they start a battle, we knew that we should cut the size as much as possible. The first step was to convert the human readable text file to binary, which cut the size to half. After this was done, we’ve added our custom compression to the stream, being able to reduce the size of any data file below 10 Kbytes (usually between 4 and 6 Kbytes).

Closing thoughts

As the new game mode has just been launched on both the Android and iOS platforms, we are excited to see where it will go and how the players will find its overall value. It was a great experience creating this new mode and experimenting with different ideas. Crafting adaptive systems is always difficult, as balancing is not so trivial. However, when everything fits together, it’s nice to see something different every time.(source:gamasutra)

 


上一篇:

下一篇: