开题报告｜BroFuTo：福大兄弟——把期末周做成一款能打赢的游戏

目录

一、队名

BroFuTo｜福大兄弟队

拆开来看，队名就是我们想做的事：

同时，也作为项目内容提示——和Brotato（土豆兄弟）是同类型游戏。

二、队员风采

队员 1｜bobo学长（队长）

• 学号：102400226
• 姓名：石华波
• CSDN：CSDN主页-石华波
• 性格：慢热但较真，习惯把问题拆成清单再动手；对"没人负责的功能"零容忍。
• 擅长的技术：GDScript、Godot 节点与场景组织、需求拆解、看板与里程碑管理。
• 兴趣爱好：塔防与肉鸽构筑类游戏、沙盒游戏、在食堂吃饭时顺手改需求。
• 希望的软工角色：PM + 主程序
• Slogan：需求先落地，头发后掉落。

队员 2｜铅笔侠

• 学号：102400310
• 姓名：陈炳珲
• CSDN：CSDN主页-陈炳珲
• 性格：上手快、爱试错，能在一天之内把想法做成可玩的最小版本。
• 擅长的技术：GDScript、状态机与对象池、2D 碰撞与手感调参。
• 兴趣爱好：动作游戏速通、羽毛球、拆解别人游戏的打击感。
• 希望的软工角色：前端（客户端玩法开发）
• Slogan：手感对不上，就再调一遍。

队员 3｜计算器

• 学号：052402138
• 姓名：朱宇濠
• CSDN：CSDN主页-朱宇濠
• 性格：安静、严谨，喜欢用表格说话；数值改了就必须写清为什么改。
• 擅长的技术：GDScript、数据结构与平衡性建模、CSV 数据驱动配置。
• 兴趣爱好：桌游数值设计、手冲咖啡、看游戏拆解视频。
• 希望的软工角色：后端（系统与数据）
• Slogan：每一个数字都要有理由。

队员 4｜像素晚八点

• 学号：102400308
• 姓名：游诗可
• CSDN：CSDN主页-游诗可
• 性格：审美固执但对反馈开放，愿意为一个待机动画重画七遍。
• 擅长的技术：Aseprite 像素绘制、角色三视图与动作拆帧、调色板控制。
• 兴趣爱好：独立游戏美术鉴赏、街拍、养多肉。
• 希望的软工角色：前端（美术/视觉）
• Slogan：16×16 里也要有表情。

队员 5｜教学楼打光师

• 学号：102400302
• 姓名：郭锦蓉
• CSDN：CSDN主页-郭锦蓉
• 性格：细节控、有条理，能为了一个 UI 对齐和人讨论半小时。
• 擅长的技术：像素场景绘制与 Tile 拼接、UI 排版与图标设计、低保真原型。
• 兴趣爱好：城市漫步、建筑速写、看美食纪录片。
• 希望的软工角色：前端（UI/UX）
• Slogan：玩家第一眼看到的地方，不能将就。

队员 6｜音效组组长

• 学号：102400329
• 姓名：吴江彬
• CSDN：CSDN主页-吴江彬
• 性格：外向、点子多，最喜欢问"这个能不能自动化"。
• 擅长的技术：Godot 音频总线与音效触发、Shader 与粒子、导出打包脚本。
• 兴趣爱好：混音、做播客、折腾机械键盘。
• 希望的软工角色：后端（工具链/技术美术）
• Slogan：玩家不一定听得见，但删掉一定不对劲。

队员 7｜找茬的

• 学号：102400333
• 姓名：詹铖煜
• CSDN：CSDN主页-詹铖煜
• 性格：有耐心、描述精确，能把"偶尔卡一下"复现成三个步骤加一段录屏。
• 擅长的技术：黑盒与边界测试、缺陷复现与优先级判定、Godot 自动化冒烟脚本。
• 兴趣爱好：解谜游戏、数独、剧本杀。
• 希望的软工角色：测试（QA）
• Slogan：我玩得不开心的地方，玩家也不会开心。

三、NABCD 表述

N（Need，需求）

给谁用：福州大学在校学生（首要用户），以及喜欢轻量肉鸽（Roguelite）的高校玩家。

他们有什么问题：

1. 期末周的解压需求没法被"大游戏"满足。学生在期末周能挤出的时间是碎片化的 5–10 分钟，而主流单机游戏动辄需要半小时以上的连续投入，打开成本太高。
2. 市面上的幸存者类游戏缺少中国高校语境。同类玩法的头部产品多为西幻、科幻或末世题材，玩家在其中找不到"这是我学校、这是我昨天刚经历的期末周"的身份认同感。
3. 已有的校园题材游戏偏叙事或模拟经营，节奏慢。它们大多承载回忆与情怀，却不适合"课间想爽一把"的场景。

为什么是我们：我们自己就是目标用户。团队成员全部处在"被期末周追着跑"的真实处境里，对痛点的理解不需要做用户调研——产品需求的第一手反馈就在工位上。

A（Approach，做法）

技术形态：Godot 4.7 + GDScript；2D 正上方固定视角、单屏竞技场，逻辑分辨率 1280×720。选择固定视角与单屏是为了把开发成本集中在"手感与内容"上，而不是摄像机与地图流式加载。

核心循环（参考《土豆兄弟》的波次生存结构）：

波次倒计时 → 玩家专注走位 + 武器自动攻击最近敌人
   → 击败敌人掉落"学分" → 波束结算
   → 商店购买升级（伤害/移速/生命/投射物/拾取范围/攻速）
   → 进入下一波 → 第 3 波"期末周"BOSS → 击败即通关

题材映射（所有元素都从校园生活中直接取材）：

技术路线

技术路线按“分层 → 换皮 → 打磨”三段推进：M2 把代码拆成七个人能并行开发的模块，M3 把画面换成原创美术并把数值搬进数据文件，M4 只做打磨与发布。下面按八个方面展开。

技术栈选型

核心系统实现方案

1. 玩法状态机。采用五态结构，由 main.gd 统一持有当前状态与转移，并把转移条件集中成一张表，避免判断逻辑散落在各处：

   当前状态	触发条件	下一状态
   MENU	按 Enter / 点击开始	PLAY（第 1 波）
   PLAY	波次倒计时归零且 wave < 3	SHOP
   PLAY	玩家生命 ≤ 0	DEAD
   PLAY	击败第 3 波 BOSS	WIN
   SHOP	按 Space / 点击继续	PLAY（下一波）
   DEAD / WIN	按 Enter / 点击重开	MENU → PLAY

2. 战斗与碰撞。M2 引入均匀空间网格（战场按 64×64 分格，实体注册到所属格），把“最近敌人查询”与“命中检测”限制在目标格及其 8 个邻格内，避免每发子弹都遍历完整的敌人列表；同时为子弹与伤害飘字引入对象池，消除波次中段的瞬时分配抖动。目标是在同屏 300 敌人时，把每帧查询量控制在数百次量级。

3. 武器系统。把武器拆成“数据 + 行为”两层：WeaponData 定义射速、伤害、弹数、扩散角、射程、穿透数、弹道类型；行为层用策略模式实现三类武器族——直线投射（铅笔、尺子）、环绕守卫（橡皮绕玩家旋转）、近战横扫（圆规挥击）。新增一把武器只需要加一个 .tres 和（最多）一个行为脚本，不必改动战斗主循环。

4. 敌人行为。敌人按"行为族 × 数值变体"组织，而不是一类敌人一个脚本：追击（闹钟，直线冲撞）、绕行（试卷，斜向贴近）、冲锋（间隔突进）、远程投掷（扔纸团）。行为族共用一个状态机（切入 / 追击 / 攻击 / 硬直），差异全部走数据。

5. 波次与难度曲线。把每一波描述成一行数据——时长、刷怪间隔的起始值与斜率、各行为的出现权重、是否刷 BOSS——让难度曲线从“改代码”变成“改表格”，调平衡不必触碰逻辑代码。

6. 经济与商店。把学分掉落 → 拾取半径吸附 → 波间商店结算拆成三个独立模块，各自可以单独调参。商店池按波次分层（前两波抽基础池，BOSS 前抽进阶池），刷新成本随次数递增，避免“无限刷新找最优解”。

7. 数值平衡方法。不凭感觉调参：为每一波定义"敌人总血量 / 玩家期望 DPS"作为平衡指标，理论上玩家清完该波的时间应略小于波次时长，多出来的部分才是容错空间。参数集中在数据文件里，一次只动一个变量，并记录改动理由。

美术与渲染管线

占位绘制与 sprite 双轨并存。所有可见实体走同一个创建接口——有对应 sprite 就用 sprite、没有就回落到代码绘制——因此美术资源可以逐层替换、随时回滚，不会出现“美术没画完所以这个版本不能玩”。M3 结束前完成全部替换。

像素美术规范（先定规范再开工，避免后期返工）：

场景构成：五张校园场景（教室、图书馆、操场、宿舍、食堂）用 TileMapLayer 拼装，配合可复用的装饰件（花坛、长椅、门窗、公告栏）组合出不同地点的差异，而不是画五张整图——这是七人小团队控制美术量的关键取舍。概念图（concept-art/）仅作为风格方向参考，不会直接当作整张游戏背景使用。

数据驱动的配置方案

目标是做到“一处定义、一处修改”：同一项数值只在一个地方写，不出现改一处、漏一处的情况。这项改造安排在 M3，优先级低于玩法成型。

工程质量、测试与构建

• 版本控制：M1 内初始化 Git 仓库，仓库包含 .gitignore，排除 .godot/ 导入缓存与导出产物；采用 main + feature/* 分支，功能完成后提 PR、至少一人 Review 再合并。配合文件级所有权——每个模块有明确负责人，从源头上减少同文件冲突。
• 每日构建可用性：build master 轮值（与绩效考核方案 6.7 呼应），每天确认主分支能跑；谁造成构建失败，由当周的 build master 当日修复并在站会说明原因，问题只记录、不指责。
• 自动化测试：分两层。纯逻辑单元测试覆盖数值计算、经济结算、波次调度、升级叠加等可以脱离画面验证的部分；无头冒烟测试用 --headless --quit-after 启动工程跑若干帧，确认主场景能加载、脚本无解析与运行错误，作为每次提交进入主分支的最低门槛。
• 代码规范：GDScript 的编译告警按错误处理，统一缩进与命名风格，提交前跑一次格式化与静态检查。
• 构建与发布：每个里程碑结束导出 Windows 可执行文件（PCK 内嵌，双击即玩、零安装）；M4 视时间尝试 Web 导出，作为"发个链接就能试玩"的传播手段。Windows 优先，Web 可选。

性能目标与验收方式

"自写碰撞 + 空间网格 + 对象池"这套组合的目的，是让逻辑帧预算在实体数量增长时保持平稳，而不是靠"把敌人数量砍下来"来达标。

主要技术风险与对策

B（Benefit，好处）

对玩家：

• 零学习成本：WASD/方向键移动，武器自动攻击，不需要记按键表就能上手。
• 时间友好：单局 5–10 分钟，课间、等电梯、排队打饭都能玩一局。
• 情感认同：校园梗和具体校名带来的"这就是我们学校"的共鸣，是同类玩法产品给不了的。
• 可重复：每局升级组合不同，构筑差异让重玩有动力。

对团队：

• 题材自带动因，美术与文案的沟通成本显著低于自创世界观。
• 玩法框架天然模块化（移动 / 战斗 / 敌人 / 商店 / UI / 音频），7 个人可以分模块并行推进。
• 增量可验证：每个里程碑都能交出一个"能玩的新版本"，不是只能等期末才看到成果。

对课程：完整覆盖需求 → 设计 → 开发 → 测试 → 发布的全流程，且轻量到能在两周内产出可玩增量，便于按时评估。

C（Competition，竞争）

直接对标：

• 《土豆兄弟 Brotato》——本作队名即是对它的致意；
• 《吸血鬼幸存者》；
• 《20 Minutes Till Dawn》。

差距要先讲清楚：头部产品在玩法深度、美术量、内容体量上远超我们，在同一个赛道上硬碰硬是不现实的。我们的目标不是做"更好的 Brotato"，而是做一个属于我们自己的、小而完整的校园版本。

我们的差异化：

1. 题材稀缺：校园生存 + 中文语境，同类玩法里几乎没有直接竞品。
2. 强身份认同：福州大学的具体元素（图书馆、宿舍楼、期末周）让学生玩家立刻有代入感，这是通用题材拿不到的情绪价值。
3. 极致轻量：低配笔记本可流畅运行，适合作为校园活动、社团迎新、开放日的"展台小游戏"——这是我们区别于商业产品的使用场景。
4. 反馈闭环最短：我们既是开发者也是目标用户，一条玩家反馈到一次数值调整的路径最短。

D（Delivery，交付）

现有进展（已可玩的 Demo）：

• 单局三波闭环：第 1、2 波各 25 秒，其间可进商店购买升级；第 3 波 35 秒并刷出"期末周"BOSS，击败即胜利，生命耗尽即失败。
• 玩家 WASD/方向键移动，武器自动攻击最近敌人；击败敌人掉落学分并可拾取。
• 商店支持鼠标购买、数字键 1–4 购买、R 刷新、Space 进入下一波；首页与结算页可按 Enter 开始/重开。
• 6 种升级：伤害、移动速度、生命上限、投射物数量、拾取范围、攻击速度。

四阶段计划（与约 2.5 个月工期对齐，双周一个里程碑）：

最终交付物清单：可运行构建（Windows，可选 Web 版）、源码与美术源文件、设计文档、测试报告、演示视频与本篇开题博客。

四、拟作的团队项目选题描述

一句话：

BroFuTo 是一款以福州大学校园生活为题材的 2D 俯视角竞技场生存游戏：玩家扮演背包学生，用文具武器抵挡试卷与闹钟，在"波次—商店—升级"的循环中撑到期末周，并击败最终的 BOSS。

选题文档（PDF）链接：BroFuTo-选题说明

五、团队的愿景

我们做 BroFuTo 的初衷，是让每个在福大熬过期中的学生都能在屏幕上看见自己：背着塞满资料的书包，握着一支写秃的铅笔，被试卷和闹钟追着跑。希望它不只是一份课程作业，而是一款真有人愿意反复打开的小游戏——从一间教室出发，长出图书馆、宿舍、操场和食堂，让玩家在五分钟一局里，用文具武器打出自己的期末生存打法。它能在课间的笔记本上跑，也能出现在迎新摊位的大屏上。更希望它是七个人共同的成长记录：第一行 GDScript、第一张像素画、第一份测试报告都留在这里，也许，我们毕业之后还愿意回来加一个新 BOSS。

六、团队绩效考核方案

本节由全队共同讨论形成。方案的设计参考了课程提供的两篇材料（见文末附录），核心思路是：不用容易钻空子的单一指标考核，而是先对齐投入、再用"任务 + 团队贡献"两个维度打分，最后把人评折算成系数，分掉一个事先约定的浮动分池。

6.1 我们认同的四条原则

1. 任何一种衡量方法都有致命的空子可以钻，但完全不量比不量更糟。 所以我们不追求绝对精确，只追求"规则公开、事先约定、结果可复核"。
2. 不用工作量做单一标尺。 代码行数、提交次数、在线时长都不进考核：重构删掉 2000 行是有价值的劳动，为凑数量写注释不是，比谁走得晚更不是。真正要衡量的是可验证的交付。
3. 事先坦诚说明投入，团队才有默契。 每个人的生活里都不只有这门课，各人的能力与投入本来就有区别。我们在每个里程碑开始前填《投入声明表》，把"我能投多少、我想要多少贡献分"摆在桌面上，而不是期末再翻旧账。
4. 重大决定由"猪"来定夺。 我们在团队内公开区分三种投入级别，并让承担关键路径的人拥有对应的话语权。

6.2 投入级别声明（猪 / 鸡 / 鹦鹉）

每个里程碑开始时，每人为自己声明本阶段的投入级别：

说明：级别只是对这一阶段实际投入的描述，不是道德评价。有人这个阶段是"鸡"，下个阶段可以是"猪"。**我们不允许的是"自称猪、实际当鹦鹉"**——一旦出现，先由 PM 单独沟通，仍不改善则在该里程碑的贡献分中如实体现，并在复盘会上说明理由。

6.3 考核维度与权重

每个里程碑结束后，为每位成员打一次分。四维基础分（满分 100）占 70%，队友互评排序分占 30%。

打分方式：

• 自评：本人给出四维分与产出清单（必填），并说明本阶段受阻情况。
• 互评：每位成员给其余 6 人排序（不是打绝对分，避免分数普遍虚高）。排序依据是"如果只能带一个人去下一个项目，你会带谁"——我们借用了救生艇练习的思路：排序比打分更接近直觉，也更容易达成共识。
• 汇总：互评排序换算为 0–100 的排序得分，与四维自评互评分的均值按 70:30 合并，得出 S_i。
• PM 复核：PM 只做两件事——剔除明显偏离共识的异常值，以及检查"声明的投入级别"与"实际产出"是否一致。PM 不单独加分。

6.4 贡献分怎么变成成绩：浮动系数

设团队课程成绩为 T，人数 N = 7。

个人最终成绩 = T × C_i，其中：

C_i = 0.6 + 2.8 × ( S_i / ΣS )      并把 C_i 限制在 [0.8, 1.2] 之间

这个公式的含义用一句话就能讲清：团队分的 60% 保底共享（Σ 0.6 × 7 = 4.2），剩下 40% 按贡献浮动分配（Σ 浮动 = 2.8）。因为 ΣC_i 恒等于 N = 7，团队平均分不会被这套规则稀释，改变的只是团队内部的分配；同时系数被限制在 [0.8, 1.2]，避免一次评分就把差距拉成"大锅饭的反面"。

算例（数字为演示，非实际成绩）：设 7 人合并后的贡献分 S_i 与 ΣS = 577。

可以看到：差距是真实存在的（85.4 与 91.5 之间差 6 分左右），但没有被放大到失真的程度；同时因为不设强制比例、不硬性指定"必须有最差的 10%"，我们避免了"表现都不错的团队必须挑一个人出来垫底"的困境。

6.5 考核节奏

为什么按里程碑分四次算：一次性的期末互评很容易被"最近发生的事"主导，也会让前期划水、后期补救的人拿到同样分数。分四次算，投入曲线才能被看见，也给了每个人纠偏的机会。

6.6 每个环节只有一个 R：RASCI 职责表

跨模块协作（尤其是"美术—程序"接口）最容易出现"大家都以为对方在做"。因此每个里程碑我们都为关键环节明确 RASCI 角色，每个环节有且只有一个 R（负责把事做成的人）：

6.7 防钻空子的条款

这部分是我们在讨论时争议最多、也最想写清楚的地方。每一种衡量方法都有空子，所以规则要提前堵住，而不是事后争论：

1. 不以代码行数 / 提交次数 / 在线时长计分。 重构删代码、写文档、调一晚上数值手感，都是真实劳动。
2. 不把"没犯错"当绩效。 探索性失败不扣分——有人研究了某项技术最后决定不采用，这是有价值的结论。但因个人原因导致构建失败或阻塞他人要如实记录（见第 3 条），归因到"协作与响应"维度，而不是笼统地"扣绩效"。
3. 构建失败（Build Break）机制。 我们采用 build master 轮值：谁导致主分支跑不起来，由当周的 build master 负责当日修复并在站会说明原因。这不直接扣分，只作为协作维度的观察记录——目的是让问题被快速解决，而不是制造互相指责。
4. 不接受"影评家"式贡献。 只开会点评、只提架构空谈、不产出任何可交付物的行为，在"团队增益"维度得 0 分。
5. 不搞平均主义。 所有人都评"优"、平分浮动分，结果一定是认真的人先离开。我们的浮动池就是为此设置的。
6. 不搞强制比例。 我们不要求团队里必须选出"最差的 10%"——如果七个人这一阶段确实都做得不错，那就都拿接近 1.0 的系数，这是好事，不是管理失败。
7. 异议与申诉。 贡献分公示 24 小时内可提出异议，由 PM 与一名非 PM 成员共同复核；有争议时，以"可验证的交付物"为准，而不是以谁的表述更有说服力为准。

6.8 这份方案哪里还需要完善

我们清楚它的问题，也写在这里接受老师和同学的建议：

• 互评排序会被"人缘"影响。 我们的缓解办法是把排序理由写下来，并且要求理由指向具体的交付物，而不是"感觉他比较努力"。
• PM 掌握了复核权，本身也需要被评估。 目前的做法是 PM 参与互评但不给自己打分，其权重由全队共同商定。这一点我们希望得到更成熟的建议。
• 美术与程序的"工作量"很难放在同一个标尺上比较（一张结算界面的价值和一个碰撞 Bug 的修复价值，谁更大？）。我们暂时用"是否解除他人阻塞"来部分回答这个问题，但它显然不完美。

附录 ：参考资料

本方案的绩效部分参考了以下两篇课程材料：

1. 邹欣（SoftwareTeacher），《现代软件工程 10 绩效管理》，博客园，2011-05-01。
   https://www.cnblogs.com/xinz/archive/2011/05/01/2033927.html
   —— 主要参考：各种工作量衡量方法的失效案例、浮动贡献分的设置、Valve 的队友评估四维、"贡献度 = 工作量 × 影响力 × 不可替代性"、二维评价体系（任务维度 × 团队贡献维度）与 20/70/10 的利弊。

2. 邹欣（SoftwareTeacher），《软件工程 之 动物世界》，博客园，2011-03-14。
   https://www.cnblogs.com/xinz/archive/2011/03/14/1983620.html
   —— 主要参考：猪 / 鸡 / 鹦鹉 三种投入级别的划分、"重大决定由猪来定夺"、影评家角色，以及 RASCI 职责模型。