ERROR401——团队展示

目录

• 一、团队名片
  • 1.1 队名
  • 1.2 队员风采
• 二、NABCD 分析
  • 2.1 N —— Need（需求）
  • 2.2 A —— Approach（做法）
  • 2.3 B —— Benefit（好处）
  • 2.4 C —— Competition（竞争/替代方案）
  • 2.5 D —— Delivery（交付与推广）
• 三、拟作的团队项目选题
  • 3.1 一句话选题（中英文均可）
  • 3.2 选题 PDF 文档链接
• 四、团队的愿景
• 五、团队绩效考核方案
  • 5.1 考核目的与原则
  • 5.2 考核对象与周期
  • 5.3 考核维度与权重
  • 5.4 计算公式
  • 5.5 计分与评级标准
  • 5.6 加减分项与红线
  • 5.7 结果应用
  • 5.8 争议处理与申诉

一、团队名片

1.1 队名

队名： ERROR401

队名释义（为什么叫这个名字）：

「ERROR401」是 HTTP 里最有名的错误码：未授权——服务器拒绝了你的请求。它好记、好笑，也很像我们八个熬夜写代码的人凑在一起的样子，一次「未经授权的访问」。但真正让我们选定它的是它和《校园突袭》的关系：在我们的设计里，AI 不允许直接读取玩家位置，只能靠自己的眼睛判断——要在视距之内、视野角之内，而且中间没有被墙挡住，才算「看见」，看见之后还得等一段反应时间才开枪；换句话说，这张地图上没有人拥有「上帝权限」，看不到就是看不到——这正是 401 的含义。我们想做一款没有权限外挂、只靠枪法和配合说话的对枪游戏，也想做一支不走捷径、只靠一次次提交把东西做出来的队伍。

1.2 队员风采

成员 1

• 学号 ：102400129
• 成员姓名：烟雨梦江南
• CSDN 地址 ： https://blog.csdn.net/2402_90005310?type=lately
• 成员性格 ：慢热、习惯观察思考、对新事物好奇
• 擅长的技术 ：C/C++、Dart、flutter、Mysql、Git
• 兴趣爱好 ：音乐、游戏、羽毛球
• 希望的软工角色 ：后端开发
• Slogan ：慢慢成为自己

成员 2

• 学号 ：102400116
• 成员姓名：汉堡
• CSDN 地址 ： https://blog.csdn.net/hanbaowang666
• 成员性格 ：随和佛系，但做事有条不紊、按计划推进，情绪稳定
• 擅长的技术 ：Vue3、Vite、Element Plus、ECharts；Python、Flask、SQLite；jieba、scikit-learn 数据处理
• 兴趣爱好 ：听音乐、健身、吉他、睡觉
• 希望的软工角色 ：全栈开发（主要后端）
• Slogan ：慢慢来，比较快。

成员 3

• 学号：102400111
• 成员姓名：yywdzz
• CSDN地址：https://blog.csdn.net/yywdzz?type=bbs
• 性格：比较认真负责，遇到问题喜欢自己研究和尝试，做事情比较有耐心
• 擅长的技术：HTML、CSS、JavaScript、Vue、Git，了解 Node.js、Express、SQLite 等前后端技术
• 兴趣爱好：编程、玩游戏、听音乐，也喜欢尝试一些有趣的软件和小游戏
• 希望的软工角色：前端开发
• slogan：码上前行，加油

成员 4

• 学号：102400110
• 成员姓名：阿宝
• CSDN 地址：https://blog.csdn.net/2401_85045493?type=bbs
• 成员性格：做事沉稳细心，善于沟通，团队协作时乐于配合队友调整方案
• 擅长的技术：Java、MySQL、SpringBoot、Git；了解Vue基础，会简单的数据库设计与接口开发
• 兴趣爱好：打游戏，健身，听音乐
• 希望的软工角色：后端开发
• Slogan：积微成著，代码见真章。

成员 5

• 学号：102400127
• 成员姓名：prince
• CSDN 地址：https://blog.csdn.net/prince_1031
• 成员性格：乐观开朗 情绪比较稳定 善于沟通
• 擅长的技术：Java、MySQL、SpringBoot、Git；了解Vue、HTML、CSS基础；编写功能测试用例
• 兴趣爱好：打游戏 篮球 看电影
• 希望的软工角色：前端 测试
• Slogan：细节决定成败 态度决定一切

成员 6

• 学号 ：102400132
• 成员姓名 ：界限
• CSDN 地址 ：https://blog.csdn.net/2403_89224786?type=bbs
• 成员性格 ：较为活跃，喜欢有条理的做事情
• 擅长的技术 ：C/C++,SQL,HTML,Markdown,Git等
• 兴趣爱好 ：打游戏，聊天，打乒乓球
• 希望的软工角色 ：后端开发
• Slogan：精研软件工程，构筑数字根基

成员 7

• 学号: 102400112
• 成员姓名: みつき
• 成员csdn地址: https://blog.csdn.net/2401_88734098?type=bbs
• 成员性格:  嚴謹細緻
• 擅长的技术: C++ 開發能力
• 兴趣爱好: 探索後端新技術
• 希望的软工角色: 後端
• slogan: 邏輯即真理

成员 8

• 学号：102400130
• 成员姓名：乌鸭
• CSDN地址：https://blog.csdn.net/Big_Dark_Duck?spm=1000.2115.3001.5343
• 成员性格：做事踏实细心，遇到问题愿意沉下心排查调试，乐于和队友讨论方案，偶尔喜欢钻研底层原理，遇到难题不轻易放弃。
• 擅长的技术：Web前端基础、HTML/CSS/JS，Vue3基础；Git版本控制；简单硬件基础；C/C++编程
• 兴趣爱好：跑步，睡觉，研究硬件焊接、电路调试，游戏，阅读计算机相关技术文档。
• 希望的软工角色：前端开发
• Slogan：脚踏实地，把每一行代码写扎实。

二、NABCD 分析

2.1 N —— Need（需求）

目标用户： 宿舍、班级里 4—8 人的小团体，想在课间、午休、晚自习后打一局战术射击的同学；以及想在低配置笔记本上体验"对枪"乐趣、又不想被主流竞技游戏门槛拦住的玩家。

使用场景： 午休时间，几个人各自打开电脑，就算凑不齐人数也能和 AI 打上一场；一局打完不到十分钟，输了立刻再来一场。

核心痛点：

1. 凑不齐人：主流战术射击游戏需要 5 人组队才能好好打，少一个人体验就断了，而宿舍里往往凑不齐固定的五个人；
2. 单局太长：一局动辄三四十分钟，要先热身、再排队、再打满半场，课间和午休根本吃不下；
3. 规则太重：炸弹、经济、道具、技能层层叠加，新玩家上手成本高，还没体验到对枪就先被劝退；
4. 配置与体积门槛：安装包几十 GB，低配笔记本跑不动，宿舍网络下载一次也很痛苦。

2.2 A —— Approach（做法）

一句话方案： 用 Unity + C# 开发第一人称团队战术对枪游戏《校园突袭》，把规则砍到最简——没有炸弹、没有经济，红蓝两队完全对等，消灭对方全员的队伍赢下这一局。考虑到团队此前没有任何 Unity 经验，第一阶段只做最小可运行版本：一名真人玩家在一张白盒小地图上对抗 3 个 AI 敌人，能移动、能开枪，AI 会追人会还击，一方全灭即分出胜负；跑通之后再把 AI 逐个替换成真人玩家，平滑过渡到 4v4 联机。

功能范围（分两段做）：

技术路线与架构：

关键难点与应对：

1. 团队此前没有 Unity 经验 → 第一阶段只做最小可运行版本，按 4 周推进，每周都有可演示的验收物（能走动 → 能打固定靶 → AI 会追人会还击 → 完整打完一局）；第一周先全员跟官方教程做一遍热身；
2. AI 做不出来或调不好 → 状态先压到 4 个，视距、视野角、反应延迟、开火间隔等参数全部外置为可配置项，并严格遵守"AI 不直接读取玩家位置"的硬性约束；若进展不顺，退化为"会朝玩家移动 + 定时开枪"的极简版本；
3. 多人网络开发过难 → 先完成单机版本再开发多人，AI 设计刻意与多人模式兼容，可逐个替换为真人玩家；
4. 美术工作量过大 → 采用默认材质与白盒场景，把产能集中到玩法与手感上；
5. 8 人代码难以合并 → 统一目录结构、命名规范与模块接口，场景文件由专人主负责，走分支 + PR 流程，主干由成员 8 把关。

2.3 B —— Benefit（好处）

对用户的价值：

1. 随时能开局：有 AI 补位，凑不齐人也能打一场完整的战术对枪；
2. 碎片时间友好：单回合一两分钟，整场比赛 5—10 分钟，课间和午休就能打完；
3. 门槛低：没有经济与道具系统，比拼的只有枪法、走位、掩体、视野、声音信息与团队配合；
4. 完全公平：红蓝两队能力、武器、出生区条件完全相同，不存在攻守不对称带来的"选边优势"；
5. 体验更真实：AI 只能靠自己的视觉获取信息（视距之内、视野角之内、中间没有墙遮挡），而且看到之后还要等一段反应时间才开枪，不是"隔墙就能锁头"的自动瞄准机器人。

对团队与课程的价值： 用四周走通"环境搭建 → 玩家控制 → 射击 → AI → 流程与交付"的最小闭环，先把能跑的东西做出来，再按"单机完善 → 多人联机 → 4v4 完整版"逐步扩展；同时实践 Git 协作、模块化设计与文档沉淀，产出的 AI 感知与决策框架、白盒关卡结构均可复用到后续模式（如爆破模式）与其他课程设计中。

可衡量的指标（最小可运行版本验收口径）：

2.4 C —— Competition（竞争/替代方案）

我们的差异化优势（一句话）： 不跟大厂比内容量，我们比"进场门槛"——不用凑人、不用等匹配，十分钟内打完一场 4v4 战术对枪。

2.5 D —— Delivery（交付与推广）

交付形式： Windows PC 可执行版本（最小可运行版本）+ GitHub 开源仓库（源码、Git 规范、设计文档与答辩材料）；本学期先交付稳定可玩的单机版本，多人联机（2v2/3v3、4v4）作为后续阶段继续推进。

开发与交付节奏（对应《校园突袭_MVP精简设计方案》第 15 节）：

风险与备选方案（对应《校园突袭_MVP精简设计方案》第 16 节）： 团队没有 Unity 经验是当前最大的风险，因此第一阶段把范围压到"一张白盒小地图 + 一把枪 + 3 个简单 AI"，每周都有可演示的验收物，任何新想法先进"以后再做"清单；若 AI 进展不顺，退化为"会朝玩家移动 + 定时开枪"的极简版本，优先保证不卡地图、不穿墙；若流程整合或打包吃紧，则以"能走动 + 能打 AI + 能分出胜负"作为保底交付；联机、房间、匹配、数据库、爆破模式、角色技能等一律后置，坚决不做范围膨胀。

三、拟作的团队项目选题

3.1 一句话选题（中英文均可）

中文： 做一款以校园建筑为战场的短局制第一人称团队战术射击游戏《校园突袭》，红蓝两队完全对等，先赢 3 局者拿下比赛。

English： Campus Strike — a short-round first-person tactical shooter set in a symmetric campus map, where two equal teams fight to wipe each other out and the first to win 3 rounds takes the match.

3.2 选题 PDF 文档链接

• 选题文档 PDF： 选题文档链接

四、团队的愿景

选择《校园突袭》，初衷很朴素：八个人都没有 Unity 实战经验，想借软件工程实践走一遍从需求分析、原型设计到编码实现的完整流程，在协作中磨合分工与沟通。现阶段目标很明确：做出能用于课程答辩演示的单机原型——基础射击、简单对战、基础地图场景可用，AI 敌人会巡逻、追击并还击，整局流程稳定跑通。

我们不急着堆功能：先把单机本地版本做扎实，再逐步加入多种武器、部位伤害、AI 队友与回合制等玩法，最后做到 4v4 联机。希望借这个项目补上 Unity 短板，积累实战与协作经验，打磨出可持续拓展的原型。

希望通过这个项目积累Unity、C#、网络编程、AI和软件工程实践经验，将课程项目逐步沉淀为能够展示在简历和作品集中的完整项目，为未来就业、竞赛或考研继续深造打下实践基础。

五、团队绩效考核方案

5.1 考核目的与原则

• 目的： 让每个人的贡献都有据可查，让多干活的人被看见，避免贡献均摊和「搭便车」；同时给进度落后的成员明确的改进信号，而不是等到期末才追责。
• 原则： 过程留痕（一切打分都要有证据）、多来源交叉验证（自评 + 互评 + 组长评）、公开可申诉、考核结果与任务分配和课程成绩挂钩。

5.2 考核对象与周期

5.3 考核维度与权重

讨论过程： 以上维度由全队在第一次例会上共同确定。讨论中曾出现两种意见：一派主张按「工作量」占大头，另一派认为「交付是否按时」更能反映贡献。最终折中为——任务完成度 30%、工作质量 25%、投入与工作量 20%，其余 25% 留给协作与主动性，理由是游戏项目模块之间耦合度高（例如 AI 依赖地图导航、比赛流程依赖击杀判定），谁都不该只盯着自己那一块。权重合计 100%。各维度统一按 5 档折算：优秀为满分 ×90%—100%，良好 ×75%—89%，合格 ×60%—74%，待改进 ×40%—59%，不合格为 ×40% 以下。

5.4 计算公式

个人总分 = 自评得分 × 20% + 组内互评平均分 × 40% + 组长 评分 × 40%

组内互评平均分 = （所有队友评分之和 − 最高分 − 最低分）÷ （人数 − 2）

最终系数 = 个人总分 ÷ 全队平均分

计算示例： 某成员负责 AI 状态机模块，本迭代自评 88 分，7 名队友互评去掉最高 95 分与最低 70 分后平均 86 分，组长评 90 分，则个人总分 = 88×20% + 86×40% + 90×40% = 87.6 分。若全队平均 82 分，其系数为 1.07，可在下个迭代优先选择自己想做的模块。

防互相刷分：互评时去掉最高分和最低分；互评匿名提交；分数与「事实描述」一起写（如「本周期完成 3 个任务，其中 1 个延期 2 天」），避免只给结论。

5.5 计分与评级标准

5.6 加减分项与红线

加分项（每项 +2 分，单迭代上限 +6 分）：

1. 主动承担无人认领的模块并按时交付；
2. 发现并修复影响游戏能否跑通的严重缺陷（如 AI 卡在地图里、比分判定错误、回合无法结束），或提出被采纳的架构改进；
3. 主动补位他人任务，且交接文档清晰。

扣分项：

1. 未请假缺席例会：−2 分/次；
2. 任务延期且未提前告知：−2 分/天，单迭代累计上限 −10 分；
3. 提交未经人工审查的代码（含 AI 生成代码）直接合并，导致主干构建失败或功能回退：−3 分/次；
4. 违反 Git 协作规范（在主干直接开发、分支命名混乱、提交信息无意义）造成他人工作冲突：−2 分/次。

红线（直接判定为不合格并上报）：

1. 提交他人代码 / 抄袭冒充本人工作；
2. 编造进度、伪造提交记录；
3. 超过 2 周完全不参与且失联。

5.7 结果应用

1. 每个迭代结束后公布贡献系数排名，用于下一个迭代的任务分配优先级（系数高者可优先选择自己感兴趣的模块）；
2. 期末总评 = 各迭代个人总分的加权平均（按迭代时长加权），由组长汇总、全队核对后提交，作为个人课程成绩组内系数的主要依据；
3. 答辩主讲、现场演示、演示视频出镜等展示机会，优先给各迭代贡献系数排名靠前的同学；
4. 全队平均分纳入团队整体成绩的讨论依据。

5.8 争议处理与申诉

1. 队员对评分有异议，须在结果公布后 48 小时内向组长提出，逾期不再受理；
2. 由组长 + 一名非当事成员组成复核小组，依据提交记录、Pull Request 记录与会议纪要复盘；
3. 复核结果 3 天内反馈；若对复核结果仍有异议，可整理材料直接向任课老师 / 助教反映。