产品策划 · 游戏玩法 · 关卡系统 · 技术架构 · 后台管理 · 部署方案

8

建议将产品定位为一款 徐州地方美食文化 + 休闲三消 + 城市探索 + 关卡运营 的移动游戏。采用服务端配置关卡、客户端本地执行消除逻辑、服务端校验结算的架构，既能保证流畅操作，又方便后台持续更新内容。

一、产品定位

二、游戏玩法

三消棋盘交互原型

点击相邻两块美食进行交换，三个及以上相同美食连成横排或竖排即可消除。

第 1 关 · 彭城初味目标：获得 3000 分

试玩原型

得分

0

剩余步数

18

目标

3000

🍲🥟🍗🥞🍜🍖🍗🥞🍜🍲🥟🍗🥟🥟🥞🥟🍖🍜🥞🍜🍗🍖🍲🥟🍖🍲🥟🍜🥞🍗🍜🍗🍖🥟🍗🍲

交换相邻美食，尝试消除！重新开始

这是可操作的简化玩法演示，正式版本将增加动画、重力掉落特效、道具、特殊棋子和完整关卡规则。

消除规则

基础规则建议采用 6×6 入门棋盘、8×8 标准棋盘、9×9 高难棋盘。每关设置步数、目标、障碍物、奖励及三星评价。

三、徐州美食元素

🍲

地锅鸡基础棋子

🥞

烙馍基础棋子

🥣

羊肉汤基础棋子

🍖

把子肉基础棋子

🍜

饣它汤基础棋子

🥟

煎包基础棋子

正式版应使用原创美食图标替换 Emoji，保持每种棋子的色彩、轮廓和识别度明显不同。

四、闯关与地图设计

i.ifeng.com

建议首发设计 100 关，划分为 5 个章节，每章 20 关。

每章最后一关设计为特色挑战关，通关后解锁徐州美食图鉴、城市故事或限定头像框。

关卡配置示例

服务端返回 JSON，后台通过可视化编辑器生成并发布。

{
  "id": 21,
  "version": 3,
  "name": "云龙湖的早餐",
  "chapter": 2,
  "difficulty": "normal",
  "board": {
    "rows": 8,
    "cols": 8,
    "tileTypes": [1, 2, 3, 4, 5],
    "cells": [],
    "obstacles": [
      {"row": 2, "col": 3, "type": "ice", "hp": 2}
    ]
  },
  "limits": {
    "moves": 25
  },
  "objectives": [
    {"type": "collect", "tileId": 3, "count": 20},
    {"type": "clear_obstacle", "obstacle": "ice", "count": 8}
  ],
  "stars": [2000, 4000, 6000],
  "rewards": {
    "coins": 100,
    "firstClearCoins": 50
  },
  "rulesVersion": "1.0",
  "seedPolicy": "server"
}

后台需支持草稿、版本管理、预览、测试、发布、回滚。已发布版本应保持不可变，避免玩家进行中的关卡因配置变化而无法结算。

五、道具系统

🔨

小锤子 · 200 金币

指定清除一个普通棋子，部分障碍需要多次使用。

🔄

乾坤翻转 · 300 金币

随机重排可移动棋子，确保至少存在一个有效操作。

💣

地锅爆弹 · 500 金币

清除指定位置周围 3×3 区域。

⏳

再来五步 · 800 金币

步数耗尽时增加 5 步。

道具分为开局前道具、局内道具、失败续关道具三种类型。所有使用和扣费均需有服务端流水，防止重复扣除。

六、商店与经济系统

初期建议只使用游戏内可获得的金币，等核心玩法和留存验证后，再考虑真实货币购买。若未来接入付费，需要分别对接 Apple App Store 和 Google Play 的应用内购买及服务端订单验证。

七、技术架构

客户端 · FlutterAndroid / iOS · Flame 游戏引擎 · Riverpod · Dio

HTTPS · REST API

NginxTLS 终止 · API 反向代理 · 负载均衡 · 静态资源

Rust API 01Axum · Tokio

Rust API 02Axum · Tokio

MySQL 8持久化数据

Redis 7缓存 · 排行 · 限流

运营后台 · Vite + Vue 3 + Element Plus通过 Nginx 提供静态页面，调用独立权限的管理 API

技术选型

八、后端模块设计

建议采用 模块化单体 + 多实例部署，不必在首发阶段拆成大量微服务。

backend/
├── Cargo.toml
├── crates/
│   ├── api/              # HTTP 接口
│   ├── auth/             # 登录认证
│   ├── users/            # 用户系统
│   ├── levels/           # 关卡配置
│   ├── gameplay/         # 游戏会话和结算
│   ├── inventory/        # 道具背包
│   ├── economy/          # 金币、交易流水
│   ├── shop/             # 商店
│   ├── leaderboard/      # 排行榜
│   ├── tasks/            # 每日任务
│   ├── admin/            # 管理后台
│   └── common/           # 通用组件
├── migrations/
├── config/
└── tests/

核心 API

所有改变金币、道具、进度的接口都应要求认证、进行参数校验并支持幂等处理。

九、关卡结算与防作弊

三消玩法适合本地即时交互，但不能直接信任客户端提交的得分。

推荐流程：

1. Flutter 请求关卡配置，获得 levelId 和版本号。
2. 开始游戏时，Rust 创建 gameSessionId，下发随机种子及规则版本。
3. Flutter 本地生成棋盘并运行消除动画。
4. 客户端记录每次交换、道具使用和操作顺序。
5. 结算时上传操作记录和会话 ID。
6. Rust 使用同一套确定性规则重新执行操作，验证得分、步数和目标。
7. 验证通过后，在数据库事务中更新进度、金币和奖励。
8. 更新 Redis 排行榜，并返回结算结果。

关键是让随机数算法、棋盘生成、掉落规则和特殊棋子逻辑全部确定化。Rust 可以实现权威游戏规则引擎，并用跨语言测试用例确保 Flutter 行为一致。

十、后台管理系统

关卡编辑器 · 管理后台原型

可交互示意

运营控制台

演示数据

关卡编辑数据概览用户管理关卡名称步数限制画笔工具

冰块

选择画笔后点击棋盘格子进行编辑。

清空棋盘导出关卡 JSON

正式后台模块应包含：

• 关卡管理： 关卡 CRUD、Excel/JSON 导入、地图编辑、障碍物绘制、模拟试玩、批量发布、版本回滚。
• 用户管理： 用户搜索、进度、背包、金币流水、封禁和申诉记录。
• 商品管理： 道具价格、礼包、库存策略、限购、活动商品。
• 排行榜管理： 总榜、周榜、好友榜、异常成绩审核。
• 运营配置： 签到、每日任务、活动、公告、邮件奖励。
• 数据分析： DAU、留存、关卡失败率、道具使用率、金币产出与消耗。
• 权限管理： 超级管理员、运营、关卡设计师、客服、数据分析员。

关卡导入需进行 JSON Schema 校验、坐标边界检查、目标可完成性检查和关卡模拟测试。后台操作要保留审计日志。

十一、数据库设计

建议使用 MySQL 作为最终数据来源，Redis 存放排行榜、热点配置及临时数据。

核心约束包括：金币余额不能为负、订单有唯一幂等键、玩家每关只有一条最佳进度记录、关卡版本不可变、会话只能结算一次。

Redis Key 设计

game:level:21:v3           关卡配置缓存
game:rank:weekly:2026w44   周排行榜 ZSET
game:rank:alltime          总排行榜 ZSET
game:session:{id}          临时会话状态
game:rate:{userId}         接口限流
game:daily:{userId}        每日任务缓存

Redis 排行榜建议使用 Sorted Set，MySQL 定期保存必要的排名快照。涉及金币和背包的数据不能只写入 Redis。

十二、Docker 部署方案

建议开发环境和生产环境分开配置。

deployment/
├── docker-compose.yml
├── docker-compose.prod.yml
├── .env.example
├── nginx/
│   ├── nginx.conf
│   └── conf.d/
│       ├── api.conf
│       └── admin.conf
├── mysql/
│   └── init/
├── redis/
│   └── redis.conf
└── scripts/
    ├── backup.sh
    └── deploy.sh

生产部署拓扑

用户请求 · HTTPS

Nginx 负载均衡

Rust API 1

Rust API 2

Admin Web

MySQL

Redis

初期可使用单机 Docker Compose；业务增长后再拆分数据库、缓存与应用实例。

Nginx 使用 least_conn 或轮询策略分发请求，并配置健康检查、超时、连接限制和 HTTPS。Rust API 设计为无状态服务，用户会话通过令牌和共享存储处理，不依赖固定实例。

生产环境还需考虑 MySQL 自动备份、Redis 持久化、日志采集、指标监控、容器重启策略、密钥管理、镜像漏洞扫描和部署回滚。单台服务器上的两个 API 容器能分担流量，但不能解决服务器本身的单点故障。

十三、Flutter 客户端工程

flutter_app/
├── lib/
│   ├── app/
│   ├── core/
│   │   ├── network/
│   │   ├── storage/
│   │   ├── theme/
│   │   └── routing/
│   ├── features/
│   │   ├── auth/
│   │   ├── home/
│   │   ├── level_map/
│   │   ├── game/
│   │   │   ├── engine/
│   │   │   ├── components/
│   │   │   ├── animations/
│   │   │   └── screens/
│   │   ├── shop/
│   │   ├── ranking/
│   │   ├── inventory/
│   │   └── profile/
│   └── main.dart
├── assets/
│   ├── foods/
│   ├── backgrounds/
│   ├── effects/
│   ├── audio/
│   └── levels/
├── android/
└── ios/

游戏棋盘建议交给 Flame 渲染，登录、商店、排行榜、设置等界面使用 Flutter Widget。这样既能实现高性能消除动画，也便于开发常规业务页面。

十四、开发阶段与交付计划

01

基础架构与账号系统

第 1–2 周

Rust API、MySQL、Redis、Flutter 项目、后台基础框架、Docker 环境

02

核心三消与关卡编辑

第 3–5 周

棋盘、交换、消除、掉落、连击、关卡 JSON、可视化编辑器

03

游戏业务系统

第 6–8 周

关卡进度、道具、金币、商店、签到、任务、排行榜

04

内容制作与运营能力

第 9–10 周

100 关制作、徐州美食素材、音效、后台权限、数据统计

05

测试与上架

第 11–12 周

防作弊、性能测试、容器部署、Android/iOS 构建、商店审核准备

12 周是有经验的小团队、素材与需求相对稳定时的初步估算，实际周期会受游戏动画质量、规则复杂度、测试覆盖率和应用商店审核影响。

十五、建议的首个可交付版本（MVP）

首个版本建议优先完成 20 个可玩关卡、5 种美食棋子、3 种道具、游客登录、账号绑定、金币商店、排行榜、关卡后台编辑、完整游戏结算和 Docker 部署。待核心循环稳定后，再扩展至 100 关及更多运营系统。

最重要的架构决策是：

关卡数据由后台管理，游戏规则由版本化引擎执行，金币和通关奖励由 Rust 服务端权威结算。

这样后续增加关卡、美食、障碍物和活动时，大部分内容可以通过后台发布，不必每次都重新提交 Android 和 iOS 安装包。

如果下一步进入实际开发，我建议先建立一个包含 flutter_app、backend、admin、deployment 的 Monorepo，并优先实现一条完整链路：后台创建关卡 → Rust 发布接口 → Flutter 加载并游玩 → 服务端验证结算 → MySQL 保存进度 → Redis 更新排行。这条链路跑通后，整个项目的核心技术风险就基本得到验证。

我最推荐的名字是：《彭城消消乐》。

既有徐州地域特色，又能直接体现三消玩法，朗朗上口，适合 Android 和 iOS 游戏品牌。

另外推荐 10 个名字：

最值得考虑的 3 个

彭城

消消乐

🍲

1. 彭城消消乐

首选

玩法清晰，容易搜索和理解，适合全年龄段。

彭城

食光

🥟

2. 彭城食光

更有品牌感，适合精致国潮画风、城市探索和美食图鉴。

徐州

有好味

🥞

3. 徐州有好味

亲切可爱，美食属性最突出，适合休闲小游戏。

我的建议：

• 游戏正式名称：《彭城食光》
• 游戏宣传副标题：徐州美食消消乐
• 宣传语：消出徐州味，闯遍彭城关！

这个组合既有品牌辨识度，也能让玩家快速理解玩法。正式上线前还需要查询游戏名称、商标及应用商店重名情况。

推荐英文名：Pengcheng Food Crush

与中文名《彭城食光》搭配，既体现徐州文化，又突出美食三消玩法。

最推荐的品牌组合

彭城食光

Pengcheng Food Crush

A Delicious Match-3 Adventure

消出徐州味，闯遍彭城关！

如果希望未来面向海外市场，我更推荐 Flavor Quest，简短、容易记忆，也方便将游戏从徐州美食扩展到中国各地美食。

如果主要面向国内玩家，则优先选择 Pengcheng Food Crush。

已经生成 《彭城食光》v0.1.0 首版开发工程，包含游戏逻辑、Rust 接口、Vue 管理后台、Flutter 客户端源码，以及 Docker 部署配置。

当前交付状态：离线试玩版已经运行并测试；全栈源码已写入，但尚未完成 Rust、Flutter 编译和真实数据库联调。本次不包含 APK 或 IPA 安装包。

一、下载工程与试玩

pengcheng-foodtime-v0.1.0.zip
包含 71 个文件：源码、20 个示例关卡、数据库迁移、部署配置、测试和使用文档。

下载后用浏览器打开即可体验，无需安装依赖。这个试玩版使用本地金币和进度，不连接真实账号，也不会同步线上排行榜。

README.zh-CN.md · demo-desktop.png

游戏内已经使用你确定的品牌文案：

彭城食光
徐州美食消消乐
消出徐州味，闯遍彭城关！

二、本次已经写入的功能

美食棋子目前采用形状＋名称＋颜色占位，便于区分；还不是最终的原创美食插画。

服务端结算不是直接接收客户端分数

源码中的结算流程是：

请求开始游戏
    ↓
服务端锁定关卡版本、随机种子和携带道具
    ↓
客户端运行游戏，记录有效操作
    ↓
提交交换、道具使用等操作序列
    ↓
Rust 重放操作，计算实际得分和目标完成情况
    ↓
数据库事务更新奖励、背包、进度
    ↓
刷新排行榜缓存

同一局重复提交相同结算会返回原结果，不重复发奖；已结算后修改操作记录会被拒绝。这些后端逻辑已写入源码，仍需在实际运行环境执行联调测试。

三、工程结构

pengcheng-foodtime/
├── backend/          Rust API、权威规则引擎、数据库迁移
├── admin/            Vite + Vue 3 + Element Plus 后台
├── mobile/           Flutter + Flame 客户端
├── demo/             可独立运行的浏览器试玩
├── levels/           20 个示例关卡
├── contracts/        关卡 Schema、跨语言回放测试数据
├── deploy/           Nginx、镜像和 HTTPS 配置
├── scripts/          初始化、备份、接口联调脚本
├── tests/            JavaScript 规则与浏览器测试
├── docs/             接口、架构、测试状态和发布清单
└── compose.yaml      Docker Compose 编排

后台发布采用不可变版本：修改关卡会生成新版本，发布后用于新对局；玩家正在进行的对局仍使用开始时的版本。

四、在本机启动验证

后端与管理后台

解压后，在安装了 Docker Compose 和 Python 3 的机器上执行：

cd pengcheng-foodtime

# 生成数据库、Redis、JWT 和管理员随机凭据
python3 scripts/init_env.py

# 构建并启动服务
docker compose up -d --build

# 检查容器状态
docker compose ps

默认入口：

管理后台：http://127.0.0.1:8080/
离线试玩：http://127.0.0.1:8080/demo/
后端接口：http://127.0.0.1:8080/api/v1

管理员账号和随机密码在生成的 .env 文件中。首次启动会执行数据库迁移并导入示例关卡；不要把 .env 提交到代码仓库。

Flutter 客户端

安装 Flutter SDK 后，从工程根目录执行：

# 生成 Android / iOS 平台工程，替换为自己的组织标识
python3 scripts/init_mobile.py --org com.yourcompany

cd mobile
flutter pub get
flutter analyze
flutter test

# Android 模拟器连接本机服务
flutter run \
  --dart-define=API_BASE_URL=http://10.0.2.2:8080/api/v1

Android/iOS 平台目录需要由上述脚本生成。正式构建还需要配置包名、HTTPS 服务地址和签名；iOS 构建与发布需要 macOS、Xcode，以及相应的 Apple 签名与开发者配置。Flutter Docs

五、实际验证结果与尚未完成的部分

浏览器检查使用了模拟的本地存储，因此不能据此宣称真实持久化测试已经通过。完整记录在包内的 docs/TEST_STATUS.md。

本版暂未实现四连／五连特殊棋子及组合效果、活动任务、广告、真实支付、周榜和好友榜。20 个关卡是用于验证机制的示例，尚需人工试玩和难度平衡；上线前还需要完成全栈编译、并发与断网测试、最终美术、签名打包及发布验收。