AIGC时代，万物ID、万事事件、万人数据，这是怎样的游戏抽象设计？

一、前言 在AIGC时代，我们总想AI能帮我们开发游戏，但是让AI编写游戏代码还是很难达到预期，尤其是大数值体系的游戏。 本文用图示的方式介绍游戏的抽象设计，可能有些思路让你耳目一新。在代码和AI之间根据游戏特征做进一步规范化的业务抽象会不会提高AI的成品率？ 二、抽象 抽象有高低之分，越接近个性的抽象适应性越弱。 图1 两个抽象高度的框架 图2 抽象、分层、模块化 三、万物皆ID 当ID统一的时候，你会发现很多事情都很好做。 统筹配置文件的ID段（位），实例（生产）ID再使用64位的（如雪花算法），避免了每个配置表都有相同的ID： 图3 三、万事皆事件 事件是游戏活动的驱动源。动作执行、数据改变都会触发相应事件： 图4 三、万人皆数据 数据是游戏实体对象的个性化体现。 把普通怪、人形怪、地上物品、随从、玩家都抽象成最高集成的地图实体，那些低级实体只不过少某些配置而： 图5 把药品、道具、武器、服装、货币都抽象成物品对象，非武器类物品只不过没有对象仓库而已： 图6 综上，一个实体对象终极抽象模型： 图7 这时候再使用ECS架构来设计游戏就显得更加容易了。 四、“生产-消费”模型 游戏一大特征：消耗什么给予什么。即消耗数据副本(如：等级>100)、消耗数据实例(如：经验值-100)、消耗物品实例（如：金币-10），给予数据加成（如:攻击+10）、物品奖励（如：灵芝+10）、动作允许（如：跳转(广寒宫)）。 游戏的生产—消费模型： 图8 条件-动作表达式配置范例： 图9 基于图8的模型，依托图7的数据仓库和再设计一个函数库，条件表达式和动作动作表达式就能满足多数的业务场景需求了：“条件系统”+“成长线框架”+“若干模块配置表”就能满足了多数的成长线功能需求，而且能留给策划更大的想象空间。 五、业务抽象 凡是策划的需求都是游戏的个性化体现。配置表抽象能解决80%的策划需求（操作配置表工作效率高），脚本功能抽象可以补足20%的特殊需求。 图10 业务抽象细则： 图11 如果图11所示，脚本可以弥补配置表的不足，但脚本开发工时和准入门槛稍高。技能、活动、刷怪、掉落等业务功能同理。 六、模块化配置 每个类型的配置表都可以有子表，如：变量总表:var.csv，技能变量子表：var_skill.csv。其它类推，即可按目录来实现模块化配置（各模块分配好ID段即可）： 图12 七、表达式解析和执行 # 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编写脚本也是更加容易的事情。 九、结束语 十、相关链接