【图解】AIGC时代的游戏抽象设计:万物皆ID、万事皆事件、万人皆数据
一、前言
在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编写脚本也是更加容易的事情。

浙公网安备 33010602011771号