MINIGROVE × 椰岛 GAME JAM · 60 分钟

MiniGrove 和 AI 时代
做游戏的一些分享

AI 时代,什么决定作品的高度?
从人的判断出发,一起做一场战棋小战斗。

00 / 先认识一下

00—02 MIN · 2′

谁是MiniGrove的作者

本来想业余做个游戏……点击放大 ↗

01 / 为什么需要新的做法

02—04 MIN · 2′

执行越来越容易,
什么变得更重要

我相信,AI 会让越来越多执行工作变得容易。
做游戏需要的技能与关注点,也会随之改变。

正在改变的条件

执行时间和技能
开始被 AI 压缩

从原型、素材到具体修改,
AI 正在压缩执行耗时,也降低对专业执行技能的依赖。

更需要人的判断

决定做什么

探索什么方向,怎样评审结果,
什么时候继续,什么时候停下。

我想探索一种新的开发方式:从游戏该是什么样子、这次要做什么决定出发。

02 / 什么影响作品的高度

04—07 MIN · 3′

品味、工程思维、决策框架

我认为,这三种能力结合在一起,
会越来越多地影响一款作品能走多远。

01 / TASTE

品味

什么体验是好的,什么细节值得坚持。
对玩法、节奏、视觉和声音,形成自己的判断。

什么值得留下
02 / ENGINEERING

工程思维

把想法做成完整、可靠、能够交付的产品。
考虑边界、整合、验证,以及最后一步。

怎样把作品完成
03 / DECISIONS

决策框架

先验证什么,怎样评审,投入到什么程度。
决定继续、调整,还是停下。

下一步,为什么做这件事

作品走向商业成功还需要面对发行、玩家触达、商业模式与时机。

03 / MiniGrove 的实践

07—10 MIN · 3′

把对作品的理解,
做成可以一起评审的版本

MiniGrove 想让每个人的想法,都有机会成为一个小实验。
让团队面对同一个可玩的结果,再决定下一步。

  1. 01

    提出想法

    这次想验证什么

  2. 02

    做小实验

    做多大就足够

  3. 03

    试玩评审

    让大家亲手体验

  4. 04

    决定取舍

    继续 · 调整 · 停止

  5. 05

    整合回主线

    重新检查整体体验

品味得以表达
从文档走向实现。觉得哪里不对,就直接上手改,把自己的判断做成可玩的版本。
决策有据可依
一起上手,围着游戏评审决策。MiniGrove 帮你记住试过什么、什么有效、什么行不通,让尝试成为作品、个人与团队的宝贵资产。
工程走向交付
把后续工作接着做完。MiniGrove 帮你推进实现、整合、验证与交付。顾问团从产品、PM、工程、美术等视角补齐你的短板,帮助你走向交付。
讲者提示 · 从理念接到方法

从文档走向实现:哪里觉得不对,先在一个范围清楚的小实验里动手改。大家实际玩过,围着游戏讨论和评审,负责人确认取舍。把尝试、评审和结论留下:什么试过、为什么有效或行不通,都是这个游戏以及个人、团队的长期资产。MiniGrove 接着推进实现、整合、验证和交付,顾问团补充产品、PM、工程、美术等视角,帮助发现盲点、补齐短板,推动作品走向交付;建议只读,具体制作和验收继续在项目里推进。

04 / 一种协作方式的实验

10—12 MIN · 2′

执行被 AI 重新定义,
职业的帽子也要重新定义

过去,我们常按执行分工定义岗位:
谁写代码、谁做美术、谁设计规则、谁验证质量。

当 AI 改变这些执行工作,每个人参与作品的方式也会改变。带着经验与品味,提出方案、发起小实验、参与试玩评审。

品味、工程思维与决策框架,
可以来自一个人,也可以分布在整个团队。

大家贡献方案,最终取舍有明确负责人
讲者提示 · 为什么重新定义职业的帽子

职业的帽子原本很大程度上来自执行分工:我是程序、美术、策划或 QA,我负责完成哪部分工作。当执行被 AI 重新定义,帽子也需要重新定义。带着原来的专业积累,更多地参与对作品的判断,让经验与品味融进共同的结果。三种能力可由个人或团队具备;一个人时,顾问团帮助补充视角。

愿景

让你和团队对游戏的理解,
决定能做到的高度

用一场战棋小战斗,试试看 ↓

05 / LIVE DEMO

12—45 MIN · 33′

先把一个小想法,
变成能玩的东西

用一场战棋小战斗,
把三种能力放进同一个项目。

本次示例

做一个经典战棋游戏。
先验证站位与行动顺序是否有意思。
首版只做一场能结束、能重开的战斗。

「我的战棋」· 水闸余火 · 项目内实机截图点击放大 ↗
讲者提示 · 演示准备与切换

现场从零开始时,点「打开 MiniGrove」进入主页新建项目;也可打开「我的战棋」对照准备好的结果。本次以经典战棋串起制作。新建项目、BYOK 与构建位置仍配有接水果教学截图,Bajia 用作美术与标注示例;这些是操作参考,不是战棋项目的生成过程。Windows 与 Web 交付前先核对项目引擎和构建支持。预备空项目、制作中和可交付三个进度点。等待生成或构建时,切到已经准备好的结果,并现场说明。下面的截图来自本地教学界面,部分任务与构建状态为预设,不代表真实 AI 或构建已执行。

LIVE 01 / 搭好起点

12—18 MIN · 6′

创建项目,
选好引擎和 AI

先确定想做什么、让谁来玩,
再选择这次需要的工具。

  1. 新建项目,描述一个小目标

    起一个名字,写清这次要验证的玩法、首版范围与目标平台。

  2. 选择引擎

    结合团队熟悉程度与目标平台;这次用 Godot,把最终 Windows 交付也考虑进去。

  3. 选择 AI 的使用方式

    打开「连接与密钥」,看一遍 BYOK、ChatGPT 与 Claude 的入口。

新建项目 · 教学界面点击放大 ↗
BYOK

使用自己的 API Key

配置自己的 Key,验证模型后使用。

CHATGPT

连接自己的 ChatGPT

按连接流程完成授权,再回到项目。

CLAUDE

Claude 订阅 · 支持的单人项目

以项目显示的可用选项为准;邀请队友前需断开 Claude 订阅。

备用截图:BYOK 配置 +
空白配置表单 · 未填写任何密钥 · 点击放大

决策 × 工程 先验证站位与行动顺序;首版完成一场能分胜负、能重开的战斗。

LIVE 02 / 一起开工

18—24 MIN · 6′

每个人的想法,
都能成为一个小实验

  1. 邀请队友加入

    进入同一个工作空间,约定这次验证的问题,以及谁负责最终取舍。

  2. 写下第一个可验证的任务

    「先做一场小战斗,验证站位与行动顺序。只做移动、攻击、待机、胜负与重开,先用简单素材。」

  3. 切换看板、聊天与树图

    看板跟进实验进度;聊天保留问题与讨论;树图看清任务和实验如何展开。

  4. 开一个分支对话问问题

    带着当前版本讨论另一种行动节奏。明确范围后,再另开任务做小样;讨论本身不会改游戏。

界面位置示例 · 接水果教学工程教学预设 · 点击放大 ↗
看板验证到哪一步聊天问题与判断依据树图实验怎样展开

决策框架 每条实验写清问题、范围与评审方式;大家贡献方案,负责人确认取舍。

LIVE 03 / 做出内容

24—33 MIN · 9′

从「我想要」,
走到游戏里看一眼

把个人品味做成可体验的方案,
放进同一场战斗,再决定是否留下。

  1. 给美术一个清楚的方向

    说明风格、尺寸、用途和参考。先做一个角色,判断它在棋盘上是否清楚、是否符合作品气质。

  2. 制作动画,再检查动作

    把攻击或行走放进战斗,看节奏、可读性与循环;选更适合体验的结果。也可以用 Seedance 做动画,成本更高,按项目风格、动作需求和预算选择。

  3. 让后续任务自动接上

    把选定素材交给动画或接入任务,带上文件、已确认的选择与验收目标。

Bajiao · 真实角色帧序列静态代表帧 · 点击放大 ↗
美术任务角色素材文件 + 使用说明
动画任务动作序列文件 + 播放参数
接入任务游戏内效果能试玩 + 能检查

人来定方向,任务之间接力执行。

讲者提示 · 展示协同的边界

用已经准备好的素材结果串起一次实际交接。当前连续自动交接有 3 跳边界,之后会回到成员操作;不要把它描述为无限自动运行。现场把「这次交接了什么」展开给大家看。

品味 × 工程 素材进入游戏后,角色是否更清楚,动作是否读得懂,整体体验是否更好?

LIVE 04 / 边玩边改

33—39 MIN · 6′

一起试玩,
决定留下什么

面对同一个可玩的结果,
决定继续、调整,还是停下。

  1. 打开预览,实际玩一轮

    围绕原来的问题实际玩一轮。再打开已有的顾问建议,补充产品、工程、玩家体验与美术视角。

  2. 用标注说清楚修改

    用画笔、箭头、文字与取色指出问题,说明它怎样影响体验,以及改到什么程度算通过。

  3. 演示实时编辑与版本变化

    对比前后并重玩,决定保留、继续改或停止。把选定结果整合回主线,再检查整体体验。

Bajia · 实际标注工具本地示例,未发送 · 点击放大 ↗
“战棋行动菜单再容易点一些,减少误操作;保留移动范围和伤害规则。”把感受写成可验收的要求;图中 Bajia 建筑按钮是另一项目的标注操作参考。
讲者提示 · 展示一次真实取舍

先回到这次实验要回答的问题,再对照试玩结果。顾问团展示已有建议,是否采纳由人判断;建议只读,不会自动改游戏。不要把有修改当作有进步:可以保留,也可以继续调整或停下。选定结果进入主线后,再试玩整合后的版本。

评审与取舍 这个改动让哪件事更好?根据试玩结果,决定保留、继续调整,或结束这个实验。

LIVE 05 / 交给玩家

39—45 MIN · 6′

把选定的结果,
完成到可以交给玩家

选定结果整合回主线,重测整体体验,
再从同一份候选构建交付。

01 / WINDOWS

交出一个可下载的包

  1. 进入「发布」,查看平台与候选。
  2. 配置 Windows 构建与构建电脑。
  3. 从确认的版本创建候选,下载 ZIP。
  4. 在 Windows 上亲自运行、检查。
教学构建状态 · 还需要亲自试玩 · 点击放大 ↗
02 / MINIGROVE.GAMES

把确认的版本公开发布

  1. 准备这个版本的 Web 构建。
  2. 检查游戏信息与发布预览。
  3. 确认要公开的版本,一键发布。
  4. 把链接交给队友和玩家。
教学发布表单 · 截图未确认发布 · 点击放大 ↗
讲者提示 · 引擎与平台需要提前核对

这条 Windows 演示路线使用标准 Godot / GDScript / Compatibility renderer,或受支持的 Web 项目。Unity 当前没有 Windows 构建配方,Bajia 只作为成品示例。构建成功还需要实际试玩;Web 预览也需要明确确认,才会成为公开版本。现场构建若需等待,切到准备好的同流程候选。

工程落地 从小样走到完整产品:确认版本、检查构建、亲自试玩,再把同一份结果交给玩家。

06 / 这次 JAM 的支持

45—50 MIN · 5′

卡住了,
直接 @MiniGrove

问题随时问,需求尽管提。
我会在这次 Jam 里,和大家一起把问题解决。

在项目里求助输入 @,选择「MiniGrove 客服」,写下遇到的问题。

让问题更容易复现你在做什么、卡在哪里、希望怎样;能附截图就更好了。

真实求助入口 · 本地示例,未发送点击放大 ↗
求助时的项目访问授权

发送前检查是否附带 7 天的项目访问授权;可以取消勾选,也可以之后撤销。需要协助定位时,再按你的选择提供访问权限。

ALPHA

我们还在试用阶段

功能、UX 和打磨度都还在完善。哪里不顺手,直接告诉我。

WISHLIST

把需求带进下一版

可以在项目里反馈,也可以看看 Roadmap 上在做什么,继续许愿。

看看 Roadmap ↗

07 / 现在轮到你

50—60 MIN · 10′

你想做什么游戏?
还有什么,让你犹豫?

功能怎么用、团队怎么协作,
或者只是一个还没想清楚的点子,都可以聊。

带着一个问题开始让下一版游戏,帮我们回答

01 / 14 · 开场

截图

窄屏可左右滑动查看细节