交出一个可下载的包
- 进入「发布」,查看平台与候选。
- 配置 Windows 构建与构建电脑。
- 从确认的版本创建候选,下载 ZIP。
- 在 Windows 上亲自运行、检查。
00 / 先认识一下
00—02 MIN · 2′01 / 为什么需要新的做法
02—04 MIN · 2′我相信,AI 会让越来越多执行工作变得容易。
做游戏需要的技能与关注点,也会随之改变。
从原型、素材到具体修改,
AI 正在压缩执行耗时,也降低对专业执行技能的依赖。
探索什么方向,怎样评审结果,
什么时候继续,什么时候停下。
我想探索一种新的开发方式:从游戏该是什么样子、这次要做什么决定出发。
02 / 什么影响作品的高度
04—07 MIN · 3′我认为,这三种能力结合在一起,
会越来越多地影响一款作品能走多远。
什么体验是好的,什么细节值得坚持。
对玩法、节奏、视觉和声音,形成自己的判断。
把想法做成完整、可靠、能够交付的产品。
考虑边界、整合、验证,以及最后一步。
先验证什么,怎样评审,投入到什么程度。
决定继续、调整,还是停下。
作品走向商业成功还需要面对发行、玩家触达、商业模式与时机。
03 / MiniGrove 的实践
07—10 MIN · 3′MiniGrove 想让每个人的想法,都有机会成为一个小实验。
让团队面对同一个可玩的结果,再决定下一步。
这次想验证什么
做多大就足够
让大家亲手体验
继续 · 调整 · 停止
重新检查整体体验
从文档走向实现:哪里觉得不对,先在一个范围清楚的小实验里动手改。大家实际玩过,围着游戏讨论和评审,负责人确认取舍。把尝试、评审和结论留下:什么试过、为什么有效或行不通,都是这个游戏以及个人、团队的长期资产。MiniGrove 接着推进实现、整合、验证和交付,顾问团补充产品、PM、工程、美术等视角,帮助发现盲点、补齐短板,推动作品走向交付;建议只读,具体制作和验收继续在项目里推进。
04 / 一种协作方式的实验
10—12 MIN · 2′过去,我们常按执行分工定义岗位:
谁写代码、谁做美术、谁设计规则、谁验证质量。
当 AI 改变这些执行工作,每个人参与作品的方式也会改变。带着经验与品味,提出方案、发起小实验、参与试玩评审。
品味、工程思维与决策框架,
可以来自一个人,也可以分布在整个团队。
职业的帽子原本很大程度上来自执行分工:我是程序、美术、策划或 QA,我负责完成哪部分工作。当执行被 AI 重新定义,帽子也需要重新定义。带着原来的专业积累,更多地参与对作品的判断,让经验与品味融进共同的结果。三种能力可由个人或团队具备;一个人时,顾问团帮助补充视角。
让你和团队对游戏的理解,
决定能做到的高度
05 / LIVE DEMO
12—45 MIN · 33′用一场战棋小战斗,
把三种能力放进同一个项目。
现场从零开始时,点「打开 MiniGrove」进入主页新建项目;也可打开「我的战棋」对照准备好的结果。本次以经典战棋串起制作。新建项目、BYOK 与构建位置仍配有接水果教学截图,Bajia 用作美术与标注示例;这些是操作参考,不是战棋项目的生成过程。Windows 与 Web 交付前先核对项目引擎和构建支持。预备空项目、制作中和可交付三个进度点。等待生成或构建时,切到已经准备好的结果,并现场说明。下面的截图来自本地教学界面,部分任务与构建状态为预设,不代表真实 AI 或构建已执行。
LIVE 01 / 搭好起点
12—18 MIN · 6′先确定想做什么、让谁来玩,
再选择这次需要的工具。
起一个名字,写清这次要验证的玩法、首版范围与目标平台。
结合团队熟悉程度与目标平台;这次用 Godot,把最终 Windows 交付也考虑进去。
打开「连接与密钥」,看一遍 BYOK、ChatGPT 与 Claude 的入口。
决策 × 工程 先验证站位与行动顺序;首版完成一场能分胜负、能重开的战斗。
LIVE 02 / 一起开工
18—24 MIN · 6′进入同一个工作空间,约定这次验证的问题,以及谁负责最终取舍。
「先做一场小战斗,验证站位与行动顺序。只做移动、攻击、待机、胜负与重开,先用简单素材。」
看板跟进实验进度;聊天保留问题与讨论;树图看清任务和实验如何展开。
带着当前版本讨论另一种行动节奏。明确范围后,再另开任务做小样;讨论本身不会改游戏。
决策框架 每条实验写清问题、范围与评审方式;大家贡献方案,负责人确认取舍。
LIVE 03 / 做出内容
24—33 MIN · 9′把个人品味做成可体验的方案,
放进同一场战斗,再决定是否留下。
说明风格、尺寸、用途和参考。先做一个角色,判断它在棋盘上是否清楚、是否符合作品气质。
把攻击或行走放进战斗,看节奏、可读性与循环;选更适合体验的结果。也可以用 Seedance 做动画,成本更高,按项目风格、动作需求和预算选择。
把选定素材交给动画或接入任务,带上文件、已确认的选择与验收目标。
人来定方向,任务之间接力执行。
用已经准备好的素材结果串起一次实际交接。当前连续自动交接有 3 跳边界,之后会回到成员操作;不要把它描述为无限自动运行。现场把「这次交接了什么」展开给大家看。
品味 × 工程 素材进入游戏后,角色是否更清楚,动作是否读得懂,整体体验是否更好?
LIVE 04 / 边玩边改
33—39 MIN · 6′面对同一个可玩的结果,
决定继续、调整,还是停下。
围绕原来的问题实际玩一轮。再打开已有的顾问建议,补充产品、工程、玩家体验与美术视角。
用画笔、箭头、文字与取色指出问题,说明它怎样影响体验,以及改到什么程度算通过。
对比前后并重玩,决定保留、继续改或停止。把选定结果整合回主线,再检查整体体验。
“战棋行动菜单再容易点一些,减少误操作;保留移动范围和伤害规则。”把感受写成可验收的要求;图中 Bajia 建筑按钮是另一项目的标注操作参考。
先回到这次实验要回答的问题,再对照试玩结果。顾问团展示已有建议,是否采纳由人判断;建议只读,不会自动改游戏。不要把有修改当作有进步:可以保留,也可以继续调整或停下。选定结果进入主线后,再试玩整合后的版本。
评审与取舍 这个改动让哪件事更好?根据试玩结果,决定保留、继续调整,或结束这个实验。
LIVE 05 / 交给玩家
39—45 MIN · 6′选定结果整合回主线,重测整体体验,
再从同一份候选构建交付。
这条 Windows 演示路线使用标准 Godot / GDScript / Compatibility renderer,或受支持的 Web 项目。Unity 当前没有 Windows 构建配方,Bajia 只作为成品示例。构建成功还需要实际试玩;Web 预览也需要明确确认,才会成为公开版本。现场构建若需等待,切到准备好的同流程候选。
工程落地 从小样走到完整产品:确认版本、检查构建、亲自试玩,再把同一份结果交给玩家。
06 / 这次 JAM 的支持
45—50 MIN · 5′问题随时问,需求尽管提。
我会在这次 Jam 里,和大家一起把问题解决。
在项目里求助输入 @,选择「MiniGrove 客服」,写下遇到的问题。
让问题更容易复现你在做什么、卡在哪里、希望怎样;能附截图就更好了。
发送前检查是否附带 7 天的项目访问授权;可以取消勾选,也可以之后撤销。需要协助定位时,再按你的选择提供访问权限。
功能、UX 和打磨度都还在完善。哪里不顺手,直接告诉我。
07 / 现在轮到你
50—60 MIN · 10′带着一个问题开始让下一版游戏,帮我们回答