一、前言
在AIGC時代，我們總想AI能幫我們開發遊戲，但是讓AI編寫遊戲代碼還是很難達到預期，尤其是大數值體系的遊戲。
本文用圖示的方式介紹遊戲的抽象設計，可能有些思路讓你耳目一新。在代碼和AI之間根據遊戲特徵做進一步規範化的業務抽象會不會提高AI的成品率？
二、抽象
抽象有高低之分，越接近個性的抽象適應性越弱。
三、萬物皆ID
當ID統一的時候，你會發現很多事情都很好做。
統籌配置文件的ID段（位），實例（生產）ID再使用64位的（如雪花算法），避免了每個配置表都有相同的ID：
三、萬事皆事件
事件是遊戲活動的驅動源。動作執行、數據改變都會觸發相應事件：
三、萬人皆數據
數據是遊戲實體對象的個性化體現。
把普通怪、人形怪、地上物品、隨從、玩家都抽象成最高集成的地圖實體，那些低級實體只不過少某些配置而：
把藥品、道具、武器、服裝、貨幣都抽象成物品對象，非武器類物品只不過沒有對象倉庫而已：
綜上，一個實體對象終極抽象模型：
這時候再使用ECS架構來設計遊戲就顯得更加容易了。
四、“生產-消費”模型
遊戲一大特徵：消耗什麼給予什麼。即消耗數據副本(如：等級>100)、消耗數據實例(如：經驗值-100)、消耗物品實例（如：金幣-10），給予數據加成（如:攻擊+10）、物品獎勵（如：靈芝+10）、動作允許（如：跳轉(廣寒宮)）。
遊戲的生產—消費模型：
條件-動作表達式配置範例：
基於圖8的模型，依託圖7的數據倉庫和再設計一個函數庫，條件表達式和動作動作表達式就能滿足多數的業務場景需求了：“條件系統”+“成長線框架”+“若干模塊配置表”就能滿足了多數的成長線功能需求，而且能留給策劃更大的想象空間。
五、業務抽象
凡是策劃的需求都是遊戲的個性化體現。配置表抽象能解決80%的策劃需求（操作配置表工作效率高），腳本功能抽象可以補足20%的特殊需求。
業務抽象細則：
如果圖11所示，腳本可以彌補配置表的不足，但腳本開發工時和准入門檻稍高。技能、活動、刷怪、掉落等業務功能同理。
六、模塊化配置
每個類型的配置表都可以有子表，如：變量總表:var.csv，技能變量子表：var_skill.csv。其它類推，即可按目錄來實現模塊化配置（各模塊分配好ID段即可）：
七、表達式解析和執行
# 1、初始化名字系統（id-name，這是id統一的好處之一）
names.add(cfg.loader("var.csv", "cfg_id", "cfg_name"))
names.add(cfg.loader("map.csv", "cfg_id", "cfg_name"))
names.add(cfg.loader("item.csv", "cfg_id", "cfg_name"))
names.add(cfg.loader("monster.csv", "cfg_id", "cfg_name"))
names.add(cfg.loader("skill.csv", "cfg_id", "cfg_name"))
# 2、加載、解析監聽表達式（自動模式）
pairs = cfg.loader("growth.csv", "cond_exp", "action_exp")
cond_sys.listen(names, pairs)
# 3、加載、解析監聽表達式（手動模式）
pairs = cond_sys.paser(names, cfg.loader("growth.csv", "cond_exp", "action_exp"))
#玩家請求
player_request(player, id)
{
pair = pairs[id]
# 檢查條件表達式
if cond_sys.check(player, pair.cond)
{
# 執行動作表達式
cond_sys.exec(pair.action)
}
}
...
# 表達式執行方式（有了統一的ID規範，可以提高表達式執行性能）：
# 表達式原型：
當前地圖=廣寒宮 and 殺怪=北帝
# 表達式解析後的形態
# 假定“當前地圖”的ID定義為9000000，“殺怪”的ID為9000001，
# 廣寒宮、殺怪ID參考圖3
if player.datas[9000000]=200001 and player.datas[9000001]=300001
{
}
八、AI、腳本師、策劃的工作模型
1、定義模塊變量
2、編輯模塊條件表達式
3、編輯模塊動作表達式
無論是AI還是人工（包含程序員），工作更加簡單和標準化，但又具有廣闊的想象空間來滿足策劃需求。甚至AI編寫腳本也是更加容易的事情。
