大家好，最近想试试 Kimi K3 能不能把一个“可以真正上线”的小游戏从需求推进到成品，所以选了我很喜欢的 Google Daily Games 里的 Color Tiles 作为目标。
这次不是照着截图写一个只能演示的 Demo ，而是尽量把完整玩法、关卡生成、操作手感和动画做出来，再做成一个打开浏览器就能玩的独立网页。
先放地址：
在线体验：
https://colortilesgame.net
简约版开源地址：
https://github.com/weizixiao/color-tiles
玩法很简单：滑动棋盘，让 4 个或以上同色方块相连并消除。看起来容易，但每一步都会消耗 moves ，消除后才能补回步数，后面的棋盘还会逐渐变大并加入障碍块。
下面简单分享一下开发过程。
一、先和 Kimi K3 把需求拆清楚
我没有让 K3 一上来就写代码，而是先通过实际试玩，把游戏目标、规则和交互整理成需求。
我们重点确认了几块内容：
- 棋盘大小、颜色数量和关卡推进方式
- 方块滑动、碰撞与停止规则
- 4 个以上同色连通块的检测和消除
- 每次移动扣除步数、消除后返还步数
- 键盘、触屏、撤销、重置和教程等操作
- 不同屏幕尺寸下的棋盘和控制区布局
这些内容先变成实现清单，再进入编码阶段。对小游戏来说，规则看似简单，但如果不提前定义清楚，很容易出现“画面像，实际玩起来不对”的情况。
二、K3 负责工程实现和持续迭代
确认规则后，K3 把游戏实现成了 Next.js / React + PixiJS 项目，包括关卡生成器、棋盘渲染、移动和消除动画、撤销、重置、教程、键盘方向键 / WASD 、触屏滑动、移动端布局和排行榜。
我的参与主要是定目标、实际试玩、指出体验不一致的地方，再让 K3 定位原因、修改实现、补测试并重新验证。
所以它并不是“一句话生成游戏”。更接近一个持续工作的开发 Agent：先拆任务，写实现，运行测试，再根据浏览器里的真实结果反复修正。
三、GPT Image 2 负责美术资产
代码之外，GPT Image 2 主要用来制作和迭代视觉素材，包括：
- 俯视角海岛棋盘背景
- 彩色方块 Sprite Atlas
- 方向键、撤销、重置等 UI 控件
- Logo 和分享图
这里 K3 更像总控：先根据游戏布局写出详细提示词，明确尺寸、视角、材质、配色和哪些区域必须保持不变，再调用 GPT Image 2 做文生图或带遮罩的图片编辑。
生成结果不能直接扔进项目。还需要挑选版本、裁切图集、校正坐标、压缩成 PNG / WebP ，并放进 Pixi 的渲染流程里继续验证。图片模型不擅长生成准确的 UI 文字，所以功能性文字仍然用 HTML / CSS ，生成图片主要负责背景、材质和图形资产。
四、最后用测试把代码和美术接起来
项目里加了 Playwright 浏览器测试，检查首关棋盘、Canvas 是否正常渲染、方向键、撤销、重置、教程弹窗，以及 390x844 等移动端视口下的布局。
随机关卡、图集坐标、动画效果和各类交互也会通过实际运行持续检查，避免改了视觉之后破坏玩法，或者桌面端正常、移动端却无法操作。
整个过程里，我觉得 K3 最有价值的地方不是写出某一段代码，而是能连续处理“拆需求 -> 实现 -> 测试 -> 修正”这条长链路； GPT Image 2 则很适合快速探索视觉方向，但要得到真正能用的游戏素材，提示词约束、遮罩编辑和后期工程处理都不能省。
欢迎大家试玩，也欢迎提 Issue / PR 。对玩法、移动端体验、性能或者 AI 开发流程有建议，都可以留言交流。
这次不是照着截图写一个只能演示的 Demo ，而是尽量把完整玩法、关卡生成、操作手感和动画做出来，再做成一个打开浏览器就能玩的独立网页。
先放地址：
在线体验：
https://colortilesgame.net
简约版开源地址：
https://github.com/weizixiao/color-tiles
玩法很简单：滑动棋盘，让 4 个或以上同色方块相连并消除。看起来容易，但每一步都会消耗 moves ，消除后才能补回步数，后面的棋盘还会逐渐变大并加入障碍块。
下面简单分享一下开发过程。
一、先和 Kimi K3 把需求拆清楚
我没有让 K3 一上来就写代码，而是先通过实际试玩，把游戏目标、规则和交互整理成需求。
我们重点确认了几块内容：
- 棋盘大小、颜色数量和关卡推进方式
- 方块滑动、碰撞与停止规则
- 4 个以上同色连通块的检测和消除
- 每次移动扣除步数、消除后返还步数
- 键盘、触屏、撤销、重置和教程等操作
- 不同屏幕尺寸下的棋盘和控制区布局
这些内容先变成实现清单，再进入编码阶段。对小游戏来说，规则看似简单，但如果不提前定义清楚，很容易出现“画面像，实际玩起来不对”的情况。
二、K3 负责工程实现和持续迭代
确认规则后，K3 把游戏实现成了 Next.js / React + PixiJS 项目，包括关卡生成器、棋盘渲染、移动和消除动画、撤销、重置、教程、键盘方向键 / WASD 、触屏滑动、移动端布局和排行榜。
我的参与主要是定目标、实际试玩、指出体验不一致的地方，再让 K3 定位原因、修改实现、补测试并重新验证。
所以它并不是“一句话生成游戏”。更接近一个持续工作的开发 Agent：先拆任务，写实现，运行测试，再根据浏览器里的真实结果反复修正。
三、GPT Image 2 负责美术资产
代码之外，GPT Image 2 主要用来制作和迭代视觉素材，包括：
- 俯视角海岛棋盘背景
- 彩色方块 Sprite Atlas
- 方向键、撤销、重置等 UI 控件
- Logo 和分享图
这里 K3 更像总控：先根据游戏布局写出详细提示词，明确尺寸、视角、材质、配色和哪些区域必须保持不变，再调用 GPT Image 2 做文生图或带遮罩的图片编辑。
生成结果不能直接扔进项目。还需要挑选版本、裁切图集、校正坐标、压缩成 PNG / WebP ，并放进 Pixi 的渲染流程里继续验证。图片模型不擅长生成准确的 UI 文字，所以功能性文字仍然用 HTML / CSS ，生成图片主要负责背景、材质和图形资产。
四、最后用测试把代码和美术接起来
项目里加了 Playwright 浏览器测试，检查首关棋盘、Canvas 是否正常渲染、方向键、撤销、重置、教程弹窗，以及 390x844 等移动端视口下的布局。
随机关卡、图集坐标、动画效果和各类交互也会通过实际运行持续检查，避免改了视觉之后破坏玩法，或者桌面端正常、移动端却无法操作。
整个过程里，我觉得 K3 最有价值的地方不是写出某一段代码，而是能连续处理“拆需求 -> 实现 -> 测试 -> 修正”这条长链路； GPT Image 2 则很适合快速探索视觉方向，但要得到真正能用的游戏素材，提示词约束、遮罩编辑和后期工程处理都不能省。
欢迎大家试玩，也欢迎提 Issue / PR 。对玩法、移动端体验、性能或者 AI 开发流程有建议，都可以留言交流。
Select Language