北京
動作角色扮演游戲的技能構筑，表面看是內容設計問題，直到組合開始爆炸式增長。
開發者分享了一個用Zig語言編寫的ARPG游戲引擎案例。技能、輔助寶石、物品、運行時規則，所有這些都需要組合生效。起初每條規則看起來都很單純：這個輔助加傷害，那個讓投射物穿透，某件裝備讓法術傷害作用于近戰，某個狀態臨時增加屬性，某個詞綴給怪物加速，某件暗金改變規則。
然后組合出現了。
橫掃技能配合擴大范圍的輔助。橫掃配合縮小范圍但增傷的輔助。橫掃附加流血效果。橫掃配合雙子側擊。一個投射物技能同時帶有穿透、連鎖和分裂。一件裝備讓法術屬性作用于近戰攻擊。一個狀態臨時修改了已被裝備和輔助寶石動過的同一項屬性。
最直觀的解法是一堆特例代碼：如果技能是橫掃且輔助是闊刃，就擴大半徑；如果技能是橫掃且輔助是聚鋒，就縮小但增傷；如果技能是橫掃且輔助是雙子橫掃且規則是守護弧，就默默躲進樹林。演示版本可以這么干。一旦技能、輔助、物品、狀態和遭遇規則多起來，這套就崩了。
更可行的框架是：把Buildcraft當成小型編譯器流水線。
策劃創作的內容是源碼輸入。輔助、物品、狀態、詞綴、職業規則都發射事實（facts）。這些事實被折疊進派生緩存。戰斗系統消費緩存。
在這個設計里，技能結算時不該問"這是帶了闊刃的橫掃嗎？放在第3個輔助槽？"到技能結算時，這個問題已經變成底層運行時數據：增加傷害基點500，范圍半徑加成子單位1000，范圍橫掃輪廓默認，狀態負載數量0，更多乘數列表[...]。
策劃數據應該保持枯燥。輔助定義不是可執行的游戲代碼，而是詞匯表很窄的數據。輔助可以發射屬性修正和行為變更，就這個盒子。它不直接操作投射物存儲、調用戰斗系統、或給世界里的隨機字段打補丁。
一條輔助定義讀起來像內容，不是行為代碼：技能域內增加物理傷害；發射一個行為；行為是范圍半徑增量；只作用于帶近戰和范圍標簽的技能。輔助可能插在橫掃旁邊，但發射的行為仍用內部適用性標簽說話。它說"近戰+范圍"，不是說"調用橫掃實現并改它的半徑"。
未來技能可以和現有輔助規則配合，不用手動把每個技能連到每個輔助。這也保持了一個重要區分：玩家可見的標簽和運行時適用性標簽不必相同。
輔助編譯成行。技能槽變動時，舊的編譯輸出必須先銷毀，再發射新輸出。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
