一个简单鸿蒙游戏的完整代码拆解

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、我们要实现什么游戏目标简单战斗点击游戏二、最终结构三、第一层状态层为什么必须有 Store正确写法这一层解决什么问题四、第二层系统层示例战斗系统这一层的意义五、第三层UI 层页面代码关键理解六、第四层入口这里做了什么七、完整运行流程八、这个结构解决了什么问题1、不会再“写乱”2、可以扩展3、支持多端九、常见错误对比错误写法正确写法十、你现在应该建立的“脑模型”总结引言当项目从 Demo 变成“稍微像个游戏”的时候文件开始变多 逻辑开始混乱 状态开始失控今天我们主要讲把一个“完整但简单”的鸿蒙小游戏彻底拆开讲清楚目标是让你真正理解一个 ArkUI 游戏项目到底应该怎么组织一、我们要实现什么游戏目标简单战斗点击游戏规则点击攻击 → 敌人掉血 敌人自动攻击 → 玩家掉血 血量为 0 → 游戏结束核心元素玩家 HP 敌人 HP 攻击行为 游戏状态进行中 / 结束二、最终结构我们先看“正确结构”再逐层拆/game ├── store/ │ └── GameStore.ts ├── system/ │ └── BattleSystem.ts ├── ui/ │ └── GamePage.ets └── main.ets核心思想状态store 逻辑system UIui 入口main这四层缺一不可。三、第一层状态层为什么必须有 Store如果你把所有状态写在 UI 里State hp State enemyHp结果就是页面 状态中心 逻辑中心直接爆炸。正确写法// store/GameStore.tsexportclassGameStore{playerHp:number100enemyHp:number100isGameOver:booleanfalseattackEnemy(){if(this.isGameOver)returnthis.enemyHp-10if(this.enemyHp0){this.enemyHp0this.isGameOvertrue}}takeDamage(){if(this.isGameOver)returnthis.playerHp-5if(this.playerHp0){this.playerHp0this.isGameOvertrue}}reset(){this.playerHp100this.enemyHp100this.isGameOverfalse}}exportconststorenewGameStore()这一层解决什么问题状态集中 逻辑内聚 可复用 可跨设备未来一句话总结Store 游戏的“唯一真实世界”四、第二层系统层很多人会问Store 已经有逻辑了为什么还要 System因为Store → 状态 基本操作 System → 游戏规则 / 调度 / 循环示例战斗系统// system/BattleSystem.tsimport{GameStore}from../store/GameStoreexportclassBattleSystem{start(store:GameStore){setInterval((){this.update(store)},1000)}update(store:GameStore){if(store.isGameOver)returnstore.takeDamage()}}这一层的意义把“游戏运行机制”抽出来 避免 UI / Store 变复杂你可以继续扩展AI 系统 掉落系统 关卡系统五、第三层UI 层终于到 ArkUI 的核心了。但注意一个原则UI 不写复杂逻辑只做“状态展示 触发行为”页面代码// ui/GamePage.etsimport{store}from../store/GameStoreEntryComponentstruct GamePage{build(){Column(){Text(玩家 HP:${store.playerHp}).fontSize(20)Text(敌人 HP:${store.enemyHp}).fontSize(20)if(store.isGameOver){Text(游戏结束).fontSize(30)}Button(攻击).onClick((){store.attackEnemy()})Button(重开).onClick((){store.reset()})}}}关键理解这里没有手动刷新 UI render() draw()因为ArkUI 自动根据状态更新 UI你只做一件事改状态六、第四层入口// main.etsimport{BattleSystem}from./system/BattleSystemimport{store}from./store/GameStoreconstbattleSystemnewBattleSystem()battleSystem.start(store)这里做了什么启动游戏循环 连接 Store 和 System七、完整运行流程把整个链路串起来点击按钮 ↓ store.attackEnemy() ↓ 状态变化enemyHp ↓ ArkUI 自动刷新 UI同时BattleSystem 定时执行 ↓ store.takeDamage() ↓ 状态变化playerHp ↓ UI 自动更新八、这个结构解决了什么问题1、不会再“写乱”因为UI ≠ 状态 ≠ 系统2、可以扩展你可以轻松加关卡系统 装备系统 技能系统3、支持多端因为状态在 Store UI 可多份天然支持手机 TV 同步九、常见错误对比错误写法StatehpStateenemyHpsetInterval(...)onClick(...)问题页面膨胀 逻辑混乱 无法扩展正确写法Store → 状态 System → 规则 UI → 展示十、你现在应该建立的“脑模型”写鸿蒙游戏时你脑子里应该是1、有一个“世界”Store 2、有一套“规则”System 3、有多个“观察者”UI而不是我在写一个页面总结一个简单鸿蒙游戏的完整结构本质是状态中心Store 规则系统System UI 渲染ArkUI你真正写的不是一个页面而是一个“可被 UI 渲染的状态系统”结合前几篇的所有结论状态驱动 多端协同 无设备边界最终统一成一句话鸿蒙游戏开发本质是在构建一个“跨设备的状态系统 UI 映射层”。