feat: 新增涂鸦PK四课教案(第8-11课)及大纲更新
- 新增 AICODE06-08~11 完整逐字稿教案(每课600+行) - 涂鸦PK主题:画图工具→基础对战→动画音效→班级锦标赛 - 核心工程思维:需求驱动→测试验证→增量迭代→数据驱动 - 更新 AICODE-06 课程大纲,追加第8-11课内容 - 新增 demo-pk/ 目录(画图工具/对战/动画三个demo) Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
599
3-lessons/AICODE-06/AICODE06-11 涂鸦PK(四)— 班级锦标赛.md
Normal file
599
3-lessons/AICODE-06/AICODE06-11 涂鸦PK(四)— 班级锦标赛.md
Normal file
@@ -0,0 +1,599 @@
|
||||
---
|
||||
课时: 11
|
||||
主题: 涂鸦PK(四)— 班级锦标赛
|
||||
核心能力: [表达力, 共创力]
|
||||
核心工具: [Trae IDE, Kimi]
|
||||
时长: 90分钟
|
||||
透明化层级: 结果层
|
||||
适用路线: AICODE-06
|
||||
---
|
||||
|
||||
### 1. 课程目标
|
||||
|
||||
**知识目标:**
|
||||
- 理解「数据驱动设计」的核心思想:角色数据与游戏代码分离,加新角色只需加文件,代码不用改
|
||||
- 理解角色选择界面是「数据读取 + UI 展示」的组合,而非把所有角色写死在代码里
|
||||
- 理解路演的核心是「设计决策」而非「功能列表」:说清楚「为什么这样做」比「做了什么」更有价值
|
||||
|
||||
**能力目标:**
|
||||
- 能用增量需求文档描述 roles 系统,并经过窗口B审核、窗口C执行(共创力)
|
||||
- 能在班级锦标赛中用语言分析胜负原因,做出有依据的复盘(表达力)
|
||||
- 能按「展示角色→设计意图→精彩瞬间→设计复盘」结构完成3分钟路演(表达力)
|
||||
|
||||
**情感目标:**
|
||||
- 感受到「自己的角色和全班的角色一起对战」的真实社交激励
|
||||
- 建立「输了是迭代的起点」而非「输了说明设计失败」的成长心态
|
||||
- 对「数据和代码分离」产生直觉性认同——这是真实工程师的设计方式
|
||||
|
||||
---
|
||||
|
||||
### 2. 核心概念与误概念预设
|
||||
|
||||
**核心概念认知层级:**
|
||||
|
||||
| 概念 | 学生类比 | 认知层级 |
|
||||
|------|---------|---------|
|
||||
| 数据驱动设计 | 游戏皮肤系统——你换皮肤不需要重新下载整个游戏,皮肤是「数据」,游戏逻辑是「代码」,两者分离 | 理解层 |
|
||||
| 硬编码 | 把菜单直接印在餐厅墙上——想加一道菜要重新刷墙 | 识别层 |
|
||||
| roles 系统 | 班级花名册——班里来了新同学,只需要在花名册上加一行,不需要改班级的所有规则 | 理解层 |
|
||||
| 增量需求 | 在已有房子里加一个房间——不是推倒重建,而是在现有结构上扩展 | 应用层 |
|
||||
| 路演设计决策 | 苹果发布会不说「这个手机有摄像头」,而是说「为什么这个摄像头改变了拍照方式」 | 应用层 |
|
||||
|
||||
**典型误概念表:**
|
||||
|
||||
| 编号 | 误概念 | 正确认知 | 激发策略 |
|
||||
|------|--------|---------|---------|
|
||||
| M1 | 加新角色需要改代码 | 数据驱动设计:加一个 json 文件 = 加一个角色,代码不用改 | 演示:不改一行代码,只在 roles/ 文件夹里加一个新 json,新角色就出现在选择界面 |
|
||||
| M2 | 路演就是说「我做了什么功能」 | 路演要说「我为什么这样设计」——设计决策比功能列表更有价值 | 类比苹果发布会:发布会不说「手机有摄像头」,而是说「为什么这颗摄像头改变了拍照方式」 |
|
||||
| M3 | 属性随便分的角色不可能赢认真分的 | 「奇怪」的属性分配有时会产生意外的克制效果;游戏平衡比绝对强度更重要 | 展示一个「全部堆 HP」的坦克型角色用消耗战赢了「全部堆 ATK」的爆发型角色 |
|
||||
| M4 | 输了说明自己设计失败了 | 输了是迭代的起点;「如果重来属性怎么分」才是最有价值的问题 | 强调:世界上最厉害的游戏设计师也在持续迭代,没有「一次设计就完美」的 |
|
||||
|
||||
---
|
||||
|
||||
### 3. 教学准备
|
||||
|
||||
**工具与环境:**
|
||||
- 每台电脑已安装 Trae IDE,第10课的战斗游戏项目可以正常运行
|
||||
- 每台电脑有学生自己的角色图片(.png)和角色数据(.json)
|
||||
- 投影可切换至任意学生屏幕,用于锦标赛投屏
|
||||
- 教师电脑预建好 `roles/` 文件夹结构(用于演示数据驱动)
|
||||
|
||||
**教师备课必做(课前):**
|
||||
> 1. 提前向每位学生收集角色文件(角色名.png + 角色名.json),放入教师电脑 `roles/` 文件夹
|
||||
> 2. 在教师电脑上跑一遍 roles 系统生成流程,确保角色选择界面正常读取所有角色
|
||||
> 3. 准备好「花名册投屏」:一个展示全班角色名字 + 特技的页面或截图
|
||||
> 4. 准备好锦标赛对阵表(单淘汰制,根据班级人数提前画好括号)
|
||||
> 5. 备用方案:如果 roles 系统生成失败,手动在代码里加角色选择下拉菜单(15分钟内可完成)
|
||||
|
||||
**教学资源:**
|
||||
- 教师准备:全班 roles/ 文件夹(含所有 png + json)
|
||||
- 教师准备:锦标赛对阵表(投屏用)
|
||||
- 教师准备:保底提示词(见第5节)
|
||||
- 学生资源:第10课的战斗游戏项目文件(index.html)
|
||||
|
||||
---
|
||||
|
||||
### 4. 教学流程
|
||||
|
||||
---
|
||||
|
||||
**第一幕:联系 (Connect) — 10分钟** 🔗
|
||||
|
||||
*本幕目标:用「角色花名册」制造全班兴奋感,引出数据驱动概念,建立「今天是全班大乱斗」的期待*
|
||||
|
||||
**【环节】角色花名册 + 今日导入 (10分钟)**
|
||||
|
||||
**师:** 课前我收集了大家的角色文件。我现在打开,给大家看看今天的「选手花名册」。
|
||||
|
||||
【投屏展示花名册——所有角色的名字、HP/ATK/DEF/SPD 属性、特技名称】
|
||||
|
||||
**师:** 你们来数一数,今天一共有多少个角色参赛?
|
||||
|
||||
**生:** (数人数)……XX 个!
|
||||
|
||||
**师:** XX 个角色,今天全部都要上场对战。谁是最强的?我们今天锦标赛见真章。
|
||||
|
||||
【停顿 3 秒,让兴奋感发酵】
|
||||
|
||||
**师:** 但我现在遇到一个问题。大家的游戏现在只能用「硬编码」的两个角色。什么叫硬编码?就是角色数据直接写死在代码里,像这样——
|
||||
|
||||
【投屏展示代码片段】
|
||||
|
||||
```javascript
|
||||
// 角色数据写死在代码里
|
||||
const player = { name: '章鱼怪', hp: 80, atk: 15, def: 5, spd: 8 };
|
||||
```
|
||||
|
||||
**师:** 这种写法,想换一个角色,要去代码里改数字。想加一个新角色,要再写一段代码。如果班里有 8 个角色要互相打,要改多少次代码?
|
||||
【识别层:让学生感受到硬编码的局限性】
|
||||
|
||||
**生:** (预期:很多次……要改来改去)
|
||||
|
||||
**师:** 对,非常麻烦。今天我们要做一件事——用「数据驱动」的方式重新设计这个系统。做完之后,加新角色只需要加一个 json 文件,代码一行都不用改。我们先做好这个系统,然后——锦标赛开始。
|
||||
|
||||
【诊断点:学生是否感受到「数据驱动」和「硬编码」的差别,还是觉得无所谓】【识别层】
|
||||
|
||||
**【分支A】若学生问「数据驱动是什么意思」:**
|
||||
**师:** 你知道游戏皮肤吗?比如王者荣耀,你换一个皮肤,不需要重新下载整个游戏对吧?皮肤就是「数据」,游戏逻辑是「代码」,两个东西分开存放。我们今天就是要把角色数据从代码里分离出来,放进独立的 json 文件。
|
||||
|
||||
**【分支B】若学生觉得「改代码也没什么,反正能跑」:**
|
||||
**师:** 如果你做的游戏将来要卖给别人,需要经常更新角色,每次更新都要改代码,那维护成本是很高的。数据驱动就是为了让「扩展」变得简单——这是真实游戏公司的标准做法。
|
||||
|
||||
---
|
||||
|
||||
**第二幕:建构 (Construct) — 65分钟** 🛠️
|
||||
|
||||
*本幕目标:完成 roles 系统(数据驱动角色选择);举办班级锦标赛*
|
||||
|
||||
---
|
||||
|
||||
**【分段一:roles 系统——数据驱动设计实战】(20分钟)**
|
||||
|
||||
**预设误概念:**
|
||||
- 误概念 M1:加新角色需要改代码(核心要破除的误概念)
|
||||
- 学生可能认为「从文件夹读取 json」很难实现,需要很复杂的代码
|
||||
|
||||
**讲解与演示 (Teach & Demo): (5分钟)**
|
||||
|
||||
**师:** 现在我们用三个窗口来完成这个系统。还记得三窗口原则吗?
|
||||
|
||||
**生:** (预期:窗口A写需求,窗口B审核,窗口C执行)
|
||||
|
||||
**师:** 对。今天的需求是「增量需求」——不是从头做,而是在现有战斗游戏上加一个新模块。我先给大家看增量需求文档长什么样。
|
||||
|
||||
【投屏展示增量需求文档内容,逐条讲解】
|
||||
|
||||
**师:** 这份需求文档有四条核心要求。我来念一遍:
|
||||
第一,从 roles/ 文件夹读取所有 .json 文件,每个文件包含 name、hp、atk、def、spd、skill 字段。
|
||||
第二,显示角色选择界面:左边选玩家角色,右边选 AI 角色,每个角色显示名字和属性。
|
||||
第三,有「开始战斗」按钮,点击后进入战斗,加载选中角色对应的同名 .png 作为 Spritesheet。
|
||||
第四,不需要重写整个游戏——只增加角色选择这一层,原来的战斗逻辑不动。
|
||||
|
||||
**师:** 注意最后一条——「不重写整个游戏」。这就是增量需求的核心。我们不推倒重来,我们在现有基础上扩展。
|
||||
|
||||
现在我演示一下最重要的一步——数据驱动设计的关键代码思路。
|
||||
|
||||
【投屏展示两种写法对比】
|
||||
|
||||
```
|
||||
硬编码方式(现在):
|
||||
代码里直接写 { name: '角色A', hp: 80, atk: 15 ... }
|
||||
→ 想加角色:改代码
|
||||
|
||||
数据驱动方式(今天要做):
|
||||
读取 roles/角色A.json → 代码只负责读取,不存储数据
|
||||
→ 想加角色:在 roles/ 文件夹里加一个新 json 文件,代码不变
|
||||
```
|
||||
|
||||
**师:** 看到区别了吗?现在窗口A的需求文档大家已经看到了,我们直接去窗口B审核。
|
||||
|
||||
**学生实践 (Practice): (12分钟)**
|
||||
|
||||
【教师打开窗口B(新的 Kimi 对话),投屏展示审核提示词】
|
||||
|
||||
**师:** 窗口B的提示词是——
|
||||
|
||||
```
|
||||
你是一个严格的需求审核工程师。我有一份增量需求文档,请找出其中可能的漏洞和没说清楚的地方。每个问题单独列出来,只问问题,不给解决方案。
|
||||
|
||||
需求文档:
|
||||
[粘贴增量需求内容]
|
||||
```
|
||||
|
||||
**师:** 大家现在把窗口B打开,把这个提示词加上你自己的增量需求,提交审核。我来演示一遍,你们同步做。
|
||||
|
||||
> 教师同步演示窗口B审核过程,投屏展示 AI 找出的问题(如:roles/ 文件夹里没有 png 文件只有 json 怎么处理?同一个角色能选两次吗?)
|
||||
|
||||
**师:** AI 找到了这几个问题。大家对照一下,你的窗口B找到了什么问题?
|
||||
|
||||
**生:** (预期:找到类似问题,或发现自己的需求文档有遗漏)
|
||||
|
||||
**师:** 好,把 AI 问的问题答案补充进需求文档。然后开窗口C执行。窗口C的提示词见屏幕。
|
||||
|
||||
【投屏展示保底提示词,学生复制使用】
|
||||
|
||||
> 教师巡视:谁的屏幕 3 分钟没变化就主动过去。重点关注窗口C是否用了「只输出新增/修改的代码」指令,避免 AI 重写整个游戏。
|
||||
|
||||
**进度同步 (Checkpoint): (3分钟)**
|
||||
|
||||
**师:** 谁的角色选择界面已经出来了?截图或者展示屏幕。
|
||||
|
||||
【让 1-2 位学生展示屏幕】
|
||||
|
||||
**师:** 你试试——现在不改一行代码,把一个新的 json 文件放进 roles/ 文件夹,刷新页面,新角色出现了吗?
|
||||
【诊断点:验证学生是否真正实现了数据驱动,而不只是在选择界面里把角色名字硬编码进去】【应用层】
|
||||
|
||||
**【分支A】若角色自动出现了:**
|
||||
**师:** 这就是数据驱动。你的代码现在可以无限扩展角色,不需要碰代码本身。这是真实游戏公司的标准做法。
|
||||
|
||||
**【分支B】若角色没有自动出现(角色名写死在选择界面里):**
|
||||
**师:** 看一下你的选择界面代码,角色名是直接写在 HTML 里还是从文件里读的?如果是写在 HTML 里,说明还是硬编码,需要让 AI 改成读取 json 文件的方式。提示词这样说:「我的角色选择界面现在是把角色名硬编码在 HTML 里的,请改成从 roles/*.json 文件里读取,动态生成选择列表。」
|
||||
|
||||
**【分支C】若 AI 把整个游戏重写了:**
|
||||
**师:** 这是常见的情况——AI 有时候会把整个代码重写一遍。发现这个情况后,告诉 AI:「请不要重写整个游戏,只输出 roles 系统的新增部分,我自己复制进去。」然后把新增部分手动粘贴到原来的代码里。
|
||||
|
||||
---
|
||||
|
||||
**【分段二:班级锦标赛——全班大乱斗】(30分钟)**
|
||||
|
||||
**预设误概念:**
|
||||
- 误概念 M3:属性随便分的角色不可能赢认真分的
|
||||
- 误概念 M4:输了说明自己设计失败了
|
||||
|
||||
**讲解与演示 (Teach & Demo): (3分钟)**
|
||||
|
||||
**师:** roles 系统已经完成了。现在游戏可以选任意角色对战了。我们正式开始今天的班级锦标赛!
|
||||
|
||||
【投屏展示锦标赛对阵表】
|
||||
|
||||
**师:** 规则说明。单淘汰赛制。每场对战:一方选自己的角色,另一方选自己的角色,战斗5回合。5回合后谁 HP 多谁赢;如果有一方 HP 归零,提前结束。每场大约 2-3 分钟。赢的人晋级,输的人直接进入路演准备。
|
||||
|
||||
**师:** 在每场开始之前,我会给大家介绍两个角色的属性和打法,然后问你们——你们觉得谁会赢?
|
||||
|
||||
**师:** 有没有问题?
|
||||
|
||||
> 如果学生有问题,简短回答;如果没有,直接开始第一场
|
||||
|
||||
**学生实践 (Practice): (25分钟)**
|
||||
|
||||
【锦标赛主持逐字稿,每场 2-3 分钟】
|
||||
|
||||
**第一场开始前:**
|
||||
|
||||
**师:** 第一场对阵:[角色A] vs [角色B]。我来介绍一下这两位选手——
|
||||
|
||||
[角色A] 是 [学生名] 设计的,[角色名],属性是 HP[数字]、ATK[数字]、DEF[数字]、SPD[数字],特技是[特技名]。从属性看,这是一个[分析:高ATK爆发型 / 高HP坦克型 / 高SPD速攻型]的角色。
|
||||
|
||||
[角色B] 是 [学生名] 设计的,[角色名],属性是 HP[数字]、ATK[数字]、DEF[数字]、SPD[数字],特技是[特技名]。这是一个[分析]的角色。
|
||||
|
||||
你们觉得谁会赢?举手投票——投 [角色A] 的举手……投 [角色B] 的举手……
|
||||
|
||||
好,开始!
|
||||
|
||||
【由第一个出战的学生上台操作,或者由教师代操,全班围观投屏】
|
||||
|
||||
**战斗进行中(教师解说):**
|
||||
|
||||
**师:** 第 1 回合,[角色A] 先手——攻击了 [数字] 点伤害。[角色B] 现在剩 HP [数字]。
|
||||
|
||||
**师:** [角色B] 反击……特技触发了![特技效果]。现在形势[分析]。
|
||||
|
||||
**师:** 大家注意这一回合——[角色A] 的 DEF 是 [数字],所以对方每次攻击被减了 [数字] 点。这就是 DEF 的价值。
|
||||
|
||||
**战斗结束后:**
|
||||
|
||||
**师:** [赢方角色] 赢了![学生名] 晋级。
|
||||
|
||||
**师:** 分析一下——[赢方角色] 赢的原因是什么?是属性设计好,还是特技时机对,还是单纯运气?
|
||||
|
||||
**生:** (预期:因为 HP 多扛住了 / 因为特技打了两次 / 因为 ATK 高秒杀了)
|
||||
|
||||
**师:** 对。[具体分析赢的原因]。[输方角色] 输了——如果重来,你觉得属性怎么分会更好?
|
||||
|
||||
**生(输方学生):** (预期:我应该把 DEF 加高一点 / 我应该多加 SPD 先手)
|
||||
|
||||
**师:** 这个分析很好。记住这个想法,等会儿路演的时候说出来。
|
||||
|
||||
【继续下一场,同样流程】
|
||||
|
||||
**半决赛/决赛前:**
|
||||
|
||||
**师:** 现在进入[半决赛/决赛]![角色A] 和 [角色B],这两位已经赢过了[X]场。来介绍一下他们的战绩——
|
||||
|
||||
**师:** [角色A] 在上一场用[什么策略]赢了[谁]。[角色B] 在上一场用[什么方式]赢了[谁]。这场对阵,你们觉得——
|
||||
|
||||
**决赛结束后:**
|
||||
|
||||
**师:** 恭喜[冠军角色]![学生名] 拿到今天锦标赛冠军!
|
||||
|
||||
**师:** 但我要说一件事——今天冠军不是「最聪明的人」,而是「今天这个对阵顺序下最幸运的人」。如果换一个对阵顺序,冠军可能完全不同。游戏平衡性比绝对强度更重要——这是游戏设计师最核心的命题。
|
||||
|
||||
**进度同步 (Checkpoint): (2分钟)**
|
||||
|
||||
**师:** 锦标赛结束了。在进入路演之前,我问大家一个问题:你们觉得,今天的冠军角色「设计得最好」吗?
|
||||
|
||||
【诊断点:学生是否理解「赢得比赛」和「设计得好」是两件事,随机因素(对阵顺序)影响结果】【理解层】
|
||||
|
||||
**【分支A】若学生说「冠军设计最好」:**
|
||||
**师:** 如果把今天的对阵顺序换一下,让冠军第一场就对上另一个强角色,他还会赢吗?不一定。所以赢比赛不等于设计最好——游戏平衡设计是一门科学,不是谁 ATK 最高谁就赢。
|
||||
|
||||
**【分支B】若学生说「运气成分很大」:**
|
||||
**师:** 对,你说到一个重点。同样属性的两个角色打十场,赢的次数可能各五场。所以好的游戏设计要让不同风格的角色都有赢的可能,而不是让一种打法通吃所有。这叫「策略多样性」。
|
||||
|
||||
---
|
||||
|
||||
**第三幕:反思 (Contemplate) — 15分钟** 🤔
|
||||
|
||||
*本幕目标:每人完成3分钟路演,训练「说设计决策」而非「说功能列表」*
|
||||
|
||||
**【环节】班级路演 (15分钟)**
|
||||
|
||||
**师:** 现在进入路演环节。每个人 3 分钟,包括展示和提问。路演有四段固定内容:
|
||||
|
||||
【投屏展示路演结构】
|
||||
|
||||
```
|
||||
第1段(30秒):展示角色
|
||||
说:「我的角色叫 XX,是一个 XX 型,属性分配是……」
|
||||
|
||||
第2段(30秒):设计意图
|
||||
说:「我选这个打法是因为……我觉得用 XX 特技可以克制……」
|
||||
|
||||
第3段(60秒):精彩瞬间
|
||||
说:「最让我印象深刻的是和 XX 的对战,那一场……」
|
||||
|
||||
第4段(60秒):设计复盘
|
||||
说:「如果重来,我会把 XX 调低一点,把 XX 调高……因为我发现……」
|
||||
```
|
||||
|
||||
**师:** 注意——路演不是说「我的角色有什么功能」。路演是说「我为什么这样设计」。这两件事差很多。我来举个例子:
|
||||
|
||||
错误示范:「我的角色叫章鱼怪,它有 HP 80、ATK 15、DEF 5、SPD 8,特技是连击。」
|
||||
正确示范:「我叫它章鱼怪,我把 HP 设高是因为我想让它能扛住对方的连续攻击,用消耗战的方式赢。特技选连击是因为连击在对方 HP 低的时候效果最好,可以一次清掉。」
|
||||
|
||||
看到区别了吗?第一个说了什么,第二个说了为什么。
|
||||
|
||||
**师:** 好,谁先来?
|
||||
|
||||
【6-8人小班建议全员路演;学生逐一路演,教师计时,到 3 分钟给提示】
|
||||
|
||||
**路演示例(教师可以第一个先做一遍示范,30秒内):**
|
||||
|
||||
**师:** 我先给大家示范一遍格式。如果我设计了一个角色,我会这样路演——
|
||||
|
||||
「我的角色叫石甲龟,是一个防御型角色。HP 设了 100,DEF 设了 20,ATK 只有 5——我知道这样攻击力很弱,但我的想法是:用超高的防御力把对方的输出全部挡掉,靠持久战赢。特技我选了「反弹」——把对方一部分伤害反还给它。最让我印象深刻的是和高 ATK 角色对战,那一场打了整整 5 回合,对方 ATK 30 打在我身上每次只剩 10 点,我靠反弹慢慢把它磨死了。如果重来,我会把 SPD 调高一点,因为我发现先手权在某些情况下比防御更重要——有几场因为后手被秒杀了。」
|
||||
|
||||
看到了吗?每一个数字背后都有理由,每一个设计决策都可以说出来。好,现在轮到大家了。谁第一个?
|
||||
|
||||
【学生逐一路演,教师计时,到 3 分钟给提示】
|
||||
|
||||
**每位学生路演后,教师引导互评:**
|
||||
|
||||
**师:** [学生名] 路演完了。谁来给一个「一个优点 + 一个改进建议」?
|
||||
|
||||
**生:** (预期:优点是……建议是……)
|
||||
|
||||
**师:** 好。[学生名],你对这个建议怎么看?如果你的下一个版本按照这个建议改,你觉得会怎样?
|
||||
|
||||
**生:** (预期:可能会更好 / 但是我担心……/ 我觉得还有另一个问题是……)
|
||||
|
||||
**师:** 好,这就是设计思维——不是「改了一定变好」,而是「改了会带来什么新的权衡」。
|
||||
|
||||
**学生路演引导词(当学生卡壳时使用):**
|
||||
|
||||
若学生在「设计意图」卡壳:
|
||||
**师:** 你当时为什么把 HP 设成这个数字?是随机的还是有理由的?
|
||||
|
||||
若学生在「精彩瞬间」卡壳:
|
||||
**师:** 锦标赛里你最紧张的是哪一场?或者最意外的是哪一场?就说那一场。
|
||||
|
||||
若学生在「设计复盘」卡壳:
|
||||
**师:** 你输的那场,对方哪个属性让你最难受?如果把你的属性分配改一下,能不能针对性地克制它?
|
||||
|
||||
若学生整体准备不足:
|
||||
**师:** 好,我给你 30 秒想一下。有一个问题你一定能回答:你和谁打的那一场,最让你印象深刻?说那一场就行。
|
||||
|
||||
**路演结束后的整体反思问题:**
|
||||
|
||||
**师:** 好,大家都路演完了。我有一个问题——你们今天路演,最难说的是哪个部分?是「展示角色」还是「设计意图」还是「设计复盘」?
|
||||
【诊断点:学生是否认为「说为什么」比「说是什么」更难,反映其对设计思维的认知层级】【理解层】
|
||||
|
||||
**【分支A】若学生说「最难的是设计复盘」:**
|
||||
**师:** 对,复盘最难。因为复盘要求你承认「我的设计有问题」,然后还要找到具体是什么问题,还要想出怎么改。这个能力叫「反事实推理」——世界上所有的工程师和设计师都在练这个能力。你们今天已经开始练了。
|
||||
|
||||
**【分支B】若学生说「最难的是设计意图,因为我当时随便分的」:**
|
||||
**师:** 没关系,随便分也有设计意图——「我不知道怎么分,所以平均分」本身就是一个决策。下一次你设计角色的时候,在分属性之前先写一句话:「我要做一个什么风格的角色,要克制什么打法」,有了这句话,属性分配就有了方向。
|
||||
|
||||
---
|
||||
|
||||
**第四幕:延续 (Continue) — 5分钟** 🚀
|
||||
|
||||
**【环节】四课主线总结 (3分钟)**
|
||||
|
||||
**师:** 最后一个问题——锦标赛结束后,你们觉得游戏平不平衡?有没有某种打法「必赢」?
|
||||
|
||||
**生:** (预期:有一点不平衡 / 感觉高 ATK 的更容易赢 / 感觉差不多)
|
||||
|
||||
**师:** 游戏平衡是永远做不到「完美」的——哪怕是王者荣耀这种级别的游戏,每个版本也要出「平衡性调整」。你们今天做的游戏也一样,会有某些打法偏强。这是正常的。重要的是你们发现了这个问题,发现了就可以迭代。
|
||||
|
||||
好,进入总结。
|
||||
|
||||
**师:** 今天是涂鸦 PK 系列的最后一课。我们来回顾一下这四课做了什么——
|
||||
|
||||
【投屏展示四课主线总结】
|
||||
|
||||
```
|
||||
第8课:需求文档 → 画图工具
|
||||
你用工程流程做了一个工具
|
||||
|
||||
第9课:需求文档 → 战斗系统 + 测试验证
|
||||
你用数据验证了你设计的规则
|
||||
|
||||
第10课:增量需求 → 动画 + 音效
|
||||
你用「感觉描述」扩展了系统
|
||||
|
||||
第11课:数据驱动 → 角色系统 + 锦标赛
|
||||
你让系统可以无限扩展
|
||||
```
|
||||
|
||||
**师:** 但这四课里,你们学到的不是游戏。
|
||||
|
||||
你们学到的是——如何把一个想法,变成可以被验证、可以被扩展、可以被迭代的系统。
|
||||
|
||||
需求文档让你在动手之前想清楚。
|
||||
测试验证让你知道自己做的对不对。
|
||||
增量需求让你在已有基础上扩展,而不是推倒重来。
|
||||
数据驱动让你的系统可以无限成长,不被代码本身限制。
|
||||
|
||||
**师:** 这四件事,就是工程师做事的方式。你们今天用这个方式,做出了一个可以全班对战的游戏。
|
||||
|
||||
**【环节】下节预告 + 5分钟挑战 (2分钟)**
|
||||
|
||||
**师:** 下节课,我们开始新的项目。你们在前面学到的这些能力——需求文档、增量迭代、数据驱动——会在接下来的项目里继续用到。
|
||||
|
||||
**师:** 本周 5 分钟 AI 挑战——给你的角色设计一个「2.0 版本」:改变属性分配,写下这次你要克制哪种打法,以及你的设计理由。不需要改代码,只需要改 json 文件里的属性数值,然后写一段话说清楚「我为什么这样改」。下节课分享。
|
||||
|
||||
---
|
||||
|
||||
### 5. AI助教使用指南
|
||||
|
||||
**窗口A——增量需求文档模板(教师投屏用):**
|
||||
|
||||
```
|
||||
增量需求文档 v1.0
|
||||
项目:涂鸦PK战斗游戏
|
||||
新增功能:roles 角色选择系统
|
||||
|
||||
1. 从 roles/ 文件夹读取所有 *.json 文件
|
||||
- 每个 json 包含字段:name, hp, atk, def, spd, skill
|
||||
- 如果文件夹为空或读取失败,显示提示信息「暂无角色,请检查 roles/ 文件夹」
|
||||
|
||||
2. 战斗开始前显示角色选择界面
|
||||
- 左侧:玩家角色列表(从 json 文件读取,动态生成)
|
||||
- 右侧:AI 对手角色列表(同上)
|
||||
- 每个角色显示名字 + HP/ATK/DEF/SPD 数值
|
||||
- 两侧可选同一个角色(允许镜像对战)
|
||||
|
||||
3. 选择确认
|
||||
- 点击「开始战斗」按钮进入战斗
|
||||
- 战斗时加载对应的同名 .png 文件作为角色图片
|
||||
- 如果 .png 不存在,使用默认占位图
|
||||
|
||||
4. 不修改原战斗逻辑
|
||||
- 只新增角色选择这一层
|
||||
- 原来的战斗循环、伤害计算、特技逻辑保持不动
|
||||
```
|
||||
|
||||
**窗口C——保底执行提示词(学生直接使用):**
|
||||
|
||||
```
|
||||
我已有一个 Phaser.js 战斗游戏,两个角色数据现在是硬编码的。
|
||||
现在我要加角色选择系统:
|
||||
|
||||
1. 从 roles/ 文件夹读取所有 *.json 文件
|
||||
(每个文件包含 name/hp/atk/def/spd/skill 字段)
|
||||
2. 显示角色选择界面:左边选玩家角色(列表),右边选 AI 角色(列表)
|
||||
3. 每个角色显示名字和属性数值
|
||||
4. 选好后点「开始战斗」进入游戏,加载对应的同名 .png 作为角色图片
|
||||
5. 如果 .png 不存在,显示默认占位图
|
||||
|
||||
只输出新增/修改的代码部分,不要重写整个游戏。
|
||||
在代码里加注释说明每段新增代码的作用。
|
||||
```
|
||||
|
||||
**路演辅助提示词(给路演准备不足的学生):**
|
||||
|
||||
```
|
||||
我的游戏角色数据是:
|
||||
名字:XX
|
||||
HP=[数字], ATK=[数字], DEF=[数字], SPD=[数字]
|
||||
特技:[特技描述]
|
||||
|
||||
在班级锦标赛中,我赢了[X]场,输了[X]场。
|
||||
|
||||
帮我用 3 个问题引导我做「设计复盘」——只问问题,不给答案。
|
||||
```
|
||||
|
||||
**进阶提示词(给完成基础任务、想进一步扩展的学生):**
|
||||
|
||||
```
|
||||
我的角色选择系统已经完成了。现在我想加一个「角色详情」功能:
|
||||
点击角色卡片时,弹出一个详情面板,显示:
|
||||
1. 角色大图(放大版的 .png)
|
||||
2. 属性条形图(HP/ATK/DEF/SPD 各用一条进度条表示,满分100)
|
||||
3. 特技说明(从 json 里读取 skill 字段,格式化显示)
|
||||
4. 「选择此角色」按钮
|
||||
|
||||
只输出新增代码,不改变现有的选择界面逻辑。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. 教师指南
|
||||
|
||||
**本课技术备注:**
|
||||
|
||||
**关于浏览器无法直接读取本地文件夹的问题:**
|
||||
|
||||
浏览器出于安全原因,无法用 `fetch('roles/角色.json')` 直接读取本地文件夹(会报 CORS 错误)。解决方案:
|
||||
- 方案A(推荐):用 Trae IDE 的本地服务器功能启动项目(Trae 内置 Live Server,自动解决 CORS 问题)
|
||||
- 方案B:让 AI 生成一个简单的 Node.js 本地服务器(`node server.js`),在本地 8080 端口提供文件服务
|
||||
- 方案C(备用):改为手动列出所有角色文件名,用 `Promise.all` 批量 fetch(避免了「自动扫描文件夹」的需求,但需要每次加新角色时在列表里加一个文件名)
|
||||
|
||||
**备课时务必先在 Trae 里跑通,确认本地服务器正常。**
|
||||
|
||||
**关于 Phaser.js 动态加载 Spritesheet:**
|
||||
|
||||
Phaser 的 `this.load.spritesheet()` 需要在 `preload()` 阶段调用,不能在游戏运行时动态加载。如果 AI 生成的代码在 `create()` 里加载图片,会报错。解决方案:提示词加上「角色图片需要在 preload 阶段加载,请用 scene.restart() 重新启动场景来实现动态切换角色」。
|
||||
|
||||
**锦标赛组织 FAQ:**
|
||||
|
||||
| 问题 | 应对 |
|
||||
|------|------|
|
||||
| roles 系统没做好,无法进行锦标赛 | 退回到手动改代码换角色,每场由教师提前改好对应角色的数据,坚持锦标赛进行 |
|
||||
| 某位学生的角色文件损坏/无法加载 | 临时用教师提前准备的备用角色文件替换 |
|
||||
| 6人以下小班(如只有4人)| 改为双败赛制(输两场才淘汰),增加对战场次 |
|
||||
| 学生对结果强烈不满(认为Bug导致输了)| 认可情绪,说「你可以在5分钟挑战里设计2.0版本,下次来复仇」 |
|
||||
| 路演时学生只说功能不说设计意图 | 用引导词打断:「等等,你刚才说了做了什么。现在告诉我,你为什么这样做?」 |
|
||||
|
||||
**路演控时技巧:**
|
||||
- 用手机计时,3分钟倒计时给学生看
|
||||
- 到2分30秒时轻声提醒:「还有30秒」
|
||||
- 如果学生还没到「设计复盘」环节,可以跳过「精彩瞬间」直接问:「如果重来你会怎么改?」
|
||||
- 互评限时 30 秒:「一个优点,一个建议,简短说」
|
||||
- 路演顺序建议:冠军最后一个路演,制造节奏感;输了第一场的同学第一个路演,减少等待焦虑
|
||||
|
||||
**关于「数据驱动设计」的深度追问(给理解快的学生):**
|
||||
|
||||
如果有学生问「为什么要把数据和代码分开,直接写在代码里不是更方便吗?」,这是一个很好的问题,可以这样回答:
|
||||
|
||||
「当你只有 2 个角色的时候,写死在代码里确实更方便。但当你有 100 个角色的时候呢?当别人也要给你的游戏加角色的时候呢——你要让他改你的代码吗?数据和代码分离,是为了让扩展和维护变得容易。这个原则不只在游戏里,几乎所有的软件系统都在用——数据库、配置文件、皮肤系统,都是同一个思路。」
|
||||
|
||||
**锦标赛后的班级文化建立:**
|
||||
|
||||
锦标赛不是为了分出高下,是为了制造「真实战斗测试」的场景。建议在锦标赛结束后强调:
|
||||
- 不设「最强角色」称号,只设「冠军」(今日锦标赛冠军,不代表绝对最强)
|
||||
- 鼓励「最有创意设计」:给属性分配最特别、最有设计理由的角色点名表扬
|
||||
- 鼓励「最佳复盘」:在路演中,给复盘最到位、最有具体改进方案的同学点名表扬
|
||||
|
||||
**课堂风险预案:**
|
||||
- 如果 Trae 本地服务器启动失败:切换到 Kimi 直接生成 HTML,不依赖本地服务器
|
||||
- 如果锦标赛时间不够(roles 系统做得慢):缩减锦标赛场次,只打半决赛 + 决赛(两场)
|
||||
- 如果进度差异过大(有学生roles系统5分钟做完,有学生20分钟还没做好):先完成的学生做进阶任务(角色详情弹窗),帮进度慢的学生看报错
|
||||
|
||||
---
|
||||
|
||||
### 7. 5分钟日常AI挑战
|
||||
|
||||
**本周挑战:** 给你的角色设计「2.0 版本」
|
||||
|
||||
**挑战说明:**
|
||||
打开你角色的 json 文件,修改属性数值,设计一个新版本。要求写一段话(3-5句)说清楚三件事:
|
||||
1. 你改了哪些属性,改成了什么数字
|
||||
2. 这次你想克制哪种打法(比如:克制高 ATK 爆发型 / 克制高 SPD 速攻型)
|
||||
3. 你觉得这样改会带来什么新的弱点
|
||||
|
||||
不需要跑代码验证,只需要写出「设计意图」。
|
||||
|
||||
**下节课分享:** 下周课上选 2-3 位同学分享「我的 2.0 设计方案」,其他同学判断:这个改动真的能克制目标打法吗?
|
||||
|
||||
---
|
||||
|
||||
### 8. 拓展任务
|
||||
|
||||
**拓展一(推荐):角色详情卡**
|
||||
|
||||
在角色选择界面里,给每个角色加一个「详情」功能:点击角色名字时,弹出一个小面板,用条形图显示 HP/ATK/DEF/SPD 的比例关系(满分100的进度条),让玩家在选角色前能直观对比属性强弱。
|
||||
|
||||
提示:条形图可以用 HTML 的 `<progress>` 标签,或者用 CSS 的 `width` 百分比实现。
|
||||
|
||||
**拓展二(挑战):战斗回放摘要**
|
||||
|
||||
每场战斗结束后,自动生成一段「战斗日志」:记录关键回合(如特技触发、HP 归零)的文字摘要。格式参考:
|
||||
|
||||
```
|
||||
第3回合:章鱼怪特技「连击」触发,对火焰鸟造成双倍伤害 28 点
|
||||
第5回合:火焰鸟 HP 归零,章鱼怪以 HP 34 获胜
|
||||
```
|
||||
|
||||
这个功能需要在战斗循环里加「事件记录」逻辑,是真正的功能扩展挑战。
|
||||
Reference in New Issue
Block a user