大家好,最近想试试 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 开发流程有建议,都可以留言交流。