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。