从Store到Agent：鸿蒙游戏逻辑与渲染分层架构设计
大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
文章目录
引言
很多开发者刚开始做鸿蒙游戏时，项目结构通常是这样的：
Page
↓
State
↓
UI
例如：
@State hp: number = 100
Button("攻击")
.onClick(() => {
this.hp -= 10
})
Demo 阶段完全没问题，甚至：
小游戏
休闲游戏
活动页游戏
都能顺利开发，但随着项目规模增长：
背包系统
战斗系统
技能系统
AI系统
任务系统
不断增加，代码开始变成：
UI修改状态
状态触发逻辑
逻辑修改UI
最终形成：
页面 = 系统
系统 = 页面
高度耦合，此时会出现几个典型问题：
功能越来越难加
Bug越来越难查
多人协作越来越困难
性能越来越差
所以大型游戏项目最终都会走向：
Store
↓
System
↓
Engine
↓
Agent
形成完整 Runtime，今天我们从实际开发角度聊聊：
为什么鸿蒙游戏一定会从 Store 演化到 Agent 架构。
一、第一阶段：UI驱动架构
很多项目初期：
@State gold: number = 1000
Button("购买")
.onClick(() => {
this.gold -= 100
})
问题在哪？因为：
UI负责展示
UI负责业务
UI负责状态
全部混在一起。当页面变多：
ShopPage
BattlePage
MissionPage
同一个状态：
金币
可能被多个页面修改。最终：
无法追踪数据来源
这是最早期的架构问题。
二、Store：统一状态中心
解决方案就是：
Store
统一管理状态，例如：
export class PlayerStore {
gold: number = 1000
level: number = 1
}
页面只负责：
Text(`${store.gold}`)
修改统一进入：
store.addGold(100)
此时数据流变成：
UI
↓
Store
↓
UI
优势：
状态统一
数据可追踪
方便调试
但新的问题又出现了。
三、为什么Store还不够？
很多团队做到 Store 后，会继续这样写：
store.player.hp -= 20
if(store.player.hp <= 0){
gameOver()
}
逻辑依然散落各处，例如：
BattlePage
MissionPage
SkillPage
都在修改状态，这时候：
Store管理数据
但没人管理规则
于是出现：
同一个伤害
多个地方计算
最终导致：
规则不一致
四、System：业务规则中心
这也是现代游戏架构的核心思想。
不要：
页面写规则
而要：
System写规则
例如：
class BattleSystem {
attack(
attacker: Unit,
target: Unit
) {
const damage =
attacker.attack -
target.defense
target.hp -= damage
}
}
此时：
Store
负责状态
System
负责规则
职责开始明确，数据流：
UI
↓
System
↓
Store
↓
UI
五、Engine：统一调度系统
当系统越来越多：
BattleSystem
SkillSystem
MissionSystem
AISystem
新的问题出现，谁决定执行顺序？例如：
攻击
↓
扣血
↓
死亡判定
↓
任务更新
如果顺序错误：
Bug立即出现
因此需要：
Game Engine
统一调度，例如：
class GameEngine {
update() {
battleSystem.update()
missionSystem.update()
aiSystem.update()
}
}
形成：
Engine
↓
System
↓
Store
架构。
六、逻辑层与渲染层彻底分离
这里是很多鸿蒙项目最大的架构升级。
错误写法：
battleSystem.attack()
Text(
`${player.hp}`
)
逻辑直接依赖 UI，问题：
无法复用
无法测试
无法迁移
正确做法：
Logic Runtime
Render Runtime
分离，逻辑层：
battleSystem.attack()
只修改：
store.player.hp
渲染层：
Text(`${store.player.hp}`)
只负责展示，此时：
逻辑不知道UI
UI不知道逻辑
完全解耦。
七、Agent出现以后发生了什么？
传统游戏：
玩家产生行为
驱动世界，例如：
点击攻击
↓
执行攻击
但 Agent 游戏不同，行为来源开始增加：
玩家
NPC
Agent
自动系统
例如：
NPC决定巡逻
NPC决定对话
NPC决定攻击
这些行为不再来自：
Button点击
而来自：
Agent Decision
八、AISystem架构设计
Agent不能直接修改Store，这是很多项目最容易踩的坑。
错误：
agent.run()
store.hp -= 20
正确：
const action =
agent.decide()
engine.dispatch(action)
统一进入：
Action Queue
例如：
{
type: "ATTACK",
target: 1001
}
然后：
Engine
↓
BattleSystem
↓
Store
执行，这样：
玩家行为
Agent行为
脚本行为
全部统一。
九、Action驱动架构
到了 Agent 阶段，项目通常会引入：
Action
机制，例如：
interface Action {
type: string
payload: any
}
所有状态变化：
必须由Action触发
例如：
dispatch({
type: "PLAYER_ATTACK"
})
而不是：
store.hp -= 10
直接修改，优势：
行为可追踪
支持回放
支持录像
支持同步
这也是大型游戏常用方案。
十、鸿蒙游戏Agent Runtime
最终形成如下结构：
Agent
│
Agent Runtime
│
Action
│
Engine
│
┌─────────────┼─────────────┐
▼ ▼ ▼
BattleSystem SkillSystem MissionSystem
│
Store
│
ArkUI Render
这里：
Agent
负责：
行为生成
System
负责：
规则执行
Store
负责：
状态管理
ArkUI
负责：
界面渲染
形成完整闭环。
十一、实战项目推荐目录结构
src
├── engine
│ ├── GameEngine.ts
│ ├── ActionQueue.ts
│
├── store
│ ├── PlayerStore.ts
│ ├── BattleStore.ts
│
├── systems
│ ├── BattleSystem.ts
│ ├── SkillSystem.ts
│ ├── MissionSystem.ts
│
├── agent
│ ├── AgentRuntime.ts
│ ├── NPCPlanner.ts
│
├── ui
│ ├── BattlePage.ets
│ ├── MainPage.ets
这样：
业务逻辑
运行时
状态管理
界面渲染
完全独立。
总结
很多鸿蒙游戏项目后期出现的问题。
本质不是：
ArkUI不够强
而是：
架构没有分层
从技术演进角度看：
UI驱动
↓
Store
↓
System
↓
Engine
↓
Action
↓
Agent Runtime
这是现代游戏架构的自然演进路径。
未来随着：
AI NPC
World Model
Agent Game
不断普及，真正驱动游戏世界运行的已经不再是：
页面
而是：
Store + System + Agent Runtime
这也意味着鸿蒙游戏开发正在从：
“页面开发时代”
逐渐进入：
“Runtime 架构时代”。
讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。
更多推荐
7
0- 0
已为社区贡献129条内容
所有评论(0)