作者：一位熱心網(wǎng)友

跟怪物和角色AI打交道也有段日子了，受之前底層架構(gòu)限制。沒辦法自由的做一些修改和擴(kuò)展，現(xiàn)在結(jié)合這些經(jīng)驗(yàn)總結(jié)一下，在從零構(gòu)建的時候需要考慮的點(diǎn)和問題。

一、AI應(yīng)該做成什么樣？

我認(rèn)為，我們不斷地追求更聰明的AI，主要為了在滿足玩家期望的同時，盡可能的節(jié)省我們的工作量。一個能夠滿足玩家期望的AI應(yīng)該具備以下2個點(diǎn)：提供符合常識的反饋，和不符合常識的反饋。符合常識的反饋，使其增強(qiáng)代入感，而異于常識的反饋，則是玩家想要體驗(yàn)的東西。

1、讓玩家看到他覺得正確的

正確的，即是符合常識的，是符合玩家認(rèn)知內(nèi)應(yīng)當(dāng)發(fā)生的一些因果。人被砍會受傷，人被殺就會死，疲勞了動作會遲緩，看見敵人就要警惕，敵人靠近就要攻擊，打的過我要追，打不過我就跑。這些都是符合我們現(xiàn)實(shí)生活的常識性行為。

那么讓玩家在干涉環(huán)境時，看到他覺得對的反饋，就是AI的其中一個重要功能。越普適的地方，玩家接觸越多的反饋，就越要如此。對于怪物AI的部分，怪物的觸發(fā)與睡眠，巡邏和追擊，在進(jìn)入戰(zhàn)斗時不同條件下的行為模式，以及這些行為模式之間的切換，都盡可能要符合我們的常識，除非……

2、超出玩家的期待

“

我看見了一個敵人，悄**地走了過去。瞄準(zhǔn)，開了一槍，**沒打中，趕緊藏箱子里！**他好像看見我了？……哦還好還好還好沒看……他干嘛呢，無線電？……停一下停一下怎么就請求支援了，還來了一個排的人，都沖我來的嗎？救命?。?/p>

這種超出期待的，所謂異于常識的反饋，是出于一個大的常識框架下的。敵人發(fā)現(xiàn)了我，所以對我進(jìn)行攻擊。但通常的游戲，敵人發(fā)現(xiàn)我后的行為，不是立刻攻擊，就是立刻停止，所以呼叫援兵是異于玩家常識的。在大框架下，其選擇的行為方式越超出玩家想象，就越能給玩家留下深刻的印象。這種新鮮的感覺使得他愿意去嘗試，體驗(yàn)更多的玩法，以換取更多刺激的體驗(yàn)。

無論符合玩家常識，或是超出玩家期待，本質(zhì)上都是設(shè)計師對玩家行為和心理的預(yù)測與應(yīng)對。在這一點(diǎn)上，了解人的情感是很重要的。而AI系統(tǒng)的重要性在于，它使得設(shè)計師可以根據(jù)玩家行為變化，動態(tài)地給出不同的應(yīng)對措施，同時這個設(shè)計是可重復(fù)利用的。

3、讓策劃省事

對的，最終目的還是讓策劃省事，你們知道我曾經(jīng)做boss挑戰(zhàn)的時候干過什么嗎？一個動作游戲做了個小范圍內(nèi)的時間軸boss，硬生生靠猜玩家行為做出來了。然后這套只是完全隨機(jī)打幾個組合連續(xù)技的boss花了我接近一周的時間去構(gòu)思和調(diào)試，一旦玩家摸清套路，之前看上去各種預(yù)讀的技能就變成了毫無卵用的雜耍，而趕完版本重新用AI來做，這套東西一個下午就配出來了，還順帶做了優(yōu)化。AI相比之下，是應(yīng)用面最廣、量產(chǎn)成本最低的一個實(shí)現(xiàn)方式。

所以說AI相關(guān)系統(tǒng)的需求包含了：盡可能多的能夠?qū)Σ煌瑮l件的情況作出判斷和回應(yīng)，并且能夠盡量節(jié)省策劃的配置量和思考量。

二、怎么設(shè)計AI系統(tǒng)？

對于不同項(xiàng)目來說需要考慮的因素有很多，最終導(dǎo)向的AI相關(guān)的功能也千差萬別，我就是想要一個非常擬真的生態(tài)系統(tǒng)，和我只想要一個一旦發(fā)現(xiàn)就幾乎會追你一輩子的怪物AI實(shí)現(xiàn)方式是完全不同的。都是精細(xì)的AI判斷，開放世界的AI和動作游戲的AI生效的部分也完全不一樣，系統(tǒng)的重點(diǎn)在于2個部分：怎么將我們想要自動化的行為抽象和切分，還有用什么形式來編輯和儲存這些AI。

1、對大的行為模式切割

對于怪物來說，比較常見的一些AI行為模式如下：

• 閑置：不執(zhí)行任何有意義反饋的狀態(tài)，像小范圍的遛彎、隨便蹦蹦跳跳之類的行為其實(shí)是可以包含在內(nèi)的。
• 戰(zhàn)斗：準(zhǔn)備從技能池中選取合適的技能釋放的狀態(tài)。
• 移動：未觸發(fā)戰(zhàn)斗時，從一個位置移動到另一位置的模式，比如巡邏和脫戰(zhàn)返回。
• 追擊：當(dāng)觸發(fā)了戰(zhàn)斗后，從一個位置移動到另一位置的模式。
• 互動：與玩家進(jìn)行非戰(zhàn)斗交互的部分，比較個性化，就先合并到一起來說。

這些行為模式其實(shí)覆蓋了一個怪物可能與玩家交互的絕大部分行為，在這個基礎(chǔ)上再進(jìn)行細(xì)分，去做各個行為模塊的邏輯，我認(rèn)為是比較好的。

一個AI行為應(yīng)當(dāng)包含的是：在某個檢測對象滿足某種觸發(fā)條件下，某個行為對象執(zhí)行了某個特殊行為組合，也就可以分解成如下的幾個部分。

2、觸發(fā)條件和檢測對象

觸發(fā)條件：攻擊類、受擊類、擊殺類、死亡、tick/周期檢測。

觸發(fā)條件需要支持計數(shù)，因?yàn)橛兴查g性行為，所以對條件要有一個計數(shù)有效時間。作為if（*）內(nèi)的條件語句，自然也要有且或非。

檢測對象：檢測對象與我的關(guān)系、檢測對象的相關(guān)條件（血量、距離、特殊標(biāo)記、屬性等）。

我將常態(tài)化的條件部分切分進(jìn)了檢測對象中，這樣將檢測對象的屬性封裝成了一個整體，方便調(diào)用。

3、行為與行為對象

行為：尋路、釋放技能、固有屬性修改、特殊標(biāo)記與取消等。

行為集：這算是我上個項(xiàng)目的遺恨了，多個行為的序列與并發(fā)，或者干脆將他們按照狀態(tài)機(jī)的方式封裝成一個行為模式，這樣可以定義一套很完整的行為。

行為對象：行為對象有時未必只針對自己，比如說一個怪物頭頭發(fā)出指令，讓其他怪物跟他一起巡邏，這相當(dāng)于一個技能修改了幾個怪物的行為模式，所以行為里需要對行為對象進(jìn)行指定。但本著AI掛誰身上誰辦事兒的原則，執(zhí)行行為的個體一定是自己，不需要額外進(jìn)行區(qū)分。

4、一些特殊部分

這部分我暫時不清楚要怎么劃分，因?yàn)閷?shí)際上AI在游戲中的應(yīng)用有兩部分控制需求相對集中：交互狀態(tài)的改變，和具體技能釋放的選擇。其中后者主要應(yīng)用在一些特定戰(zhàn)斗下，較多的技能分配上。有些團(tuán)隊(duì)會選擇直接通過關(guān)卡邏輯來調(diào)整，有些是完全隨機(jī)選擇，有些是固定時間軸，更多是以上幾種的混合控制。

這類AI有時候甚至?xí)畏殖鲆粋€功能來實(shí)現(xiàn)，比如單獨(dú)控制怪物的lua腳本。而我今天說的更偏向于利用一個完整的功能將這些囊括進(jìn)去。根據(jù)團(tuán)隊(duì)開發(fā)習(xí)慣和項(xiàng)目側(cè)重不同，實(shí)現(xiàn)時很多方式的評估結(jié)果是不一樣的。

三、工具相關(guān)的問題

關(guān)于AI方面，我之前經(jīng)歷過兩個不同的項(xiàng)目。一個是走狀態(tài)機(jī)，使用表格做特殊行為的檢測和執(zhí)行。一個是UE4，選擇了原生的AIController來控制。我曾經(jīng)一度非常吹捧ue4的行為樹與其編輯器，但是后來也慢慢有一些想法在改變。

1、學(xué)習(xí)成本

我本身對于程序是有一定了解的，也說不上很好吧，自己在unity寫過狀態(tài)機(jī)，平時能看看項(xiàng)目代碼，瞅瞅策劃失傳的無主字段干什么用。學(xué)行為樹的時候看了看大致思路：“哦，一個大型的if-else嵌套集合”，基本上就知道怎么做了，細(xì)節(jié)的部分程序規(guī)范一下，跟藍(lán)圖一樣設(shè)計。這方面表格看起來反而有些吃力，打開一張表密密麻麻的都是數(shù)，一個一個看批注煩都煩死了。

長時間下來，我發(fā)現(xiàn)有時候需要程序指點(diǎn)的零碎地方，比預(yù)想的要多。隨著經(jīng)歷更多的事情，我意識到自己終歸和程序存在著本質(zhì)差別，那么并沒有自學(xué)過程序，本身沒有程序功底的人呢？即便程序也是會隨著經(jīng)驗(yàn)的不斷加深而重構(gòu)代碼，一個龐大而復(fù)雜的AI自然也是。更多時候，策劃并不需要那么多數(shù)據(jù)隨時可以訪問，我們應(yīng)該主動封閉一部分不必要的數(shù)據(jù)，來減少策劃的設(shè)計負(fù)擔(dān)。那么數(shù)據(jù)具體暴露到什么度，是需要程序和策劃之間，根據(jù)雙方的能力和默契程度不斷協(xié)調(diào)的，這部分更多是需要靠經(jīng)驗(yàn)決定的。

從我的認(rèn)知角度講，直接按照一個完整事件來封裝一條AI，是最直觀和容易認(rèn)知的。想到一條寫一條，之后再決定檢測次序和優(yōu)先級，組合成一個大的AI鏈。實(shí)際上串聯(lián)排好后會發(fā)現(xiàn)，這種結(jié)構(gòu)和行為樹還蠻像的。另外，整體功能參數(shù)越復(fù)雜，思考難度就越大，功能參數(shù)越簡潔，要實(shí)現(xiàn)同一個復(fù)雜功能可能需要的步驟就越多，這兩種情況最終都是會提高學(xué)習(xí)成本的，需要根據(jù)需求平衡和規(guī)避。

2、量產(chǎn)與個性化

開頭我要以狀態(tài)機(jī)的形式定義一些行為模式，一方面是因?yàn)檫@種切分形式符合人的樸素思維，另一方面是因?yàn)閷ζ渲幸徊糠中袨槟Ｊ嚼^續(xù)切分，對于設(shè)計師來說本身就是無意義的。為什么程序會存在方法這個概念？為什么會有封裝、繼承和多態(tài)？——因?yàn)槭∈?清晰=方便復(fù)用，我為什么要每次都重新在行為樹里執(zhí)行一遍判斷是否有敵人，有敵人是否在攻擊范圍內(nèi)，在的話選擇技能對其釋放，而不讓他直接走“攻擊模式”這個行為呢？

這部分其實(shí)是和上面聯(lián)動的，就算使用行為樹，這些基礎(chǔ)的部分也會被封裝成一個行為集合，這也是我為什么在前面對行為集怨念的原因，不過這部分有很多東西會需要評估如何進(jìn)行封裝，我目前還是持中性態(tài)度，以程序的意見為最先考量。

3、出現(xiàn)bug時

上一個項(xiàng)目另外一個怨念的部分就是不能打斷點(diǎn)，可憋死我了?。ㄎ也皇俏覜]有

客戶端高級程序員熊寶寶給我講：“就算把客戶端代碼給你，邏輯不是你寫的，我不告訴你哪個類，你要斷去哪斷？我們自己看以前代碼都需要理解和查bug的時間，你能保證斷得出來，其他策劃能嗎？”

是這樣的，而且我也不能，斷點(diǎn)程序這玩意兒確實(shí)如他所說，并不是策劃應(yīng)當(dāng)觸碰的領(lǐng)域。就算程序互相之間也很難查bug，更何況策劃，但我并不是想要斷點(diǎn)的功能，而是想知道策劃配置能夠正確行進(jìn)至哪一部分，方便定位問題。

最起碼對于自己朝夕相處擺弄的功能，絕大部分人知曉一個最簡單的工作原理，在這個基礎(chǔ)上迅速定位問題，很多配置錯誤其實(shí)不需要再經(jīng)過程序也能快速查找出來，能夠有效提高雙方的開發(fā)效率。這方面編輯器，尤其是內(nèi)嵌在引擎可以同時保證調(diào)整和監(jiān)控的編輯器，是有得天獨(dú)厚優(yōu)勢的。

4、后續(xù)擴(kuò)展與持續(xù)維護(hù)

擴(kuò)展包含兩個維度：程序方面的擴(kuò)展和策劃表/編輯器結(jié)構(gòu)的擴(kuò)展。這兩部分分別會引發(fā)不同的維護(hù)問題，最終都會反饋到策劃這邊：前者會使得功能擴(kuò)展本身難以推進(jìn)，后者則會讓配置量越來越大，容錯性和bug排除難度等，都會越來越惡化。

另一方面，由于我在這里吃過大虧，所以這件事一定要記住：一旦產(chǎn)品上線，所有已有功能的修改，哪怕是純配置都要經(jīng)過程序，保證在其知曉的情況下進(jìn)行修改。

因?yàn)橐坏┥暇€，玩家在某個功能獲得了數(shù)據(jù)（很多情況下是付費(fèi)了的）并進(jìn)入了數(shù)據(jù)庫儲存，你的配置改動也許會使得鏈接的數(shù)據(jù)源頭改變，那么很有可能會產(chǎn)生臟數(shù)據(jù)。這個臟數(shù)據(jù)可以理解為無主數(shù)據(jù)，但無論如何玩家是不可能接受【清庫】這種處理方式的，直接對服務(wù)器中的臟數(shù)據(jù)進(jìn)行遍歷處理又會極大的增加服務(wù)器負(fù)荷，最后很可能需要服務(wù)器特別為這些臟數(shù)據(jù)添加處理代碼。這樣有可能最終會形成策劃數(shù)據(jù)和程序代碼的一些廢棄數(shù)據(jù)，影響整潔度，進(jìn)一步阻礙下一次的功能擴(kuò)展。

關(guān)于如何保證一個系統(tǒng)的可擴(kuò)展性，我的傾向和經(jīng)驗(yàn)是：在設(shè)計之初想的可以非常大，然后和盤托出講給程序，之后共同閹割無關(guān)功能，到目前需求的部分。這種工作方式需要雙方互相的一定程度的信任，但程序知道你未來打的什么算盤，架構(gòu)上一開始就會留好那個方向的余地。當(dāng)然如果自己沒想好或者計劃趕不上變化的時候，總會有做出難以擴(kuò)展的系統(tǒng)的情況，那個時候我的建議也只有盡早跟上級溝通確認(rèn)不能實(shí)現(xiàn)的效果是否是剛需，一旦有這種情況，也只能請程序老哥重新幫忙修改一下了不是？畢竟危樓之上壘得再高，還是危樓。

5、合并分支

這塊我自己不同項(xiàng)目的經(jīng)驗(yàn)也不多，只能先拋出問題：編輯器在上述幾個問題中大部分是優(yōu)于表格的，但唯獨(dú)這塊有著很大劣勢。在合并分支版本時，單獨(dú)的某些部分的值很難被合并，ue4的map、blueprint，unity的scene和prefab都是如此，他們很難達(dá)到像xml一樣快速合并的靈活性，只能作為一個整體。尤其是blueprint這類本身就是可視化編程的模塊，合并某個版本甚至?xí)枰銌为?dú)為其擺放一部分藍(lán)圖和創(chuàng)造新的變量。這會增加很多無謂的分支bug。編輯器輸出xml化是一個解決方案，但多數(shù)策劃看不懂這件事還是很容易出現(xiàn)，難道只能以大功能模塊為切分去做更新了嗎？