每半年更新一次，该来的还是会来的。虽然但是，总是有人催我写这玩意（不食哥们，距离下一个第二学期还有大半年啊）。

欢迎来到 GitHub 学期

注意
以下所有的内容均仅代表 24/25 学年的情况。此后的课程实际情况可能有所不同。
由于时间仓促，此文可能没有覆盖到大家感兴趣的全部信息。请务必在回复中指出，以便及时更新。
对本文的编辑更新不会另行通知。

先来看这学期课程：

专业课：

DI32001 - Agile Software Engineering 敏捷软件工程（第 1-6 周）
DI32002 - Games Programming 游戏编程（第 7-16 周）
DI32003 - Theory of Computation 计算理论（第 7-16 周）

公共课：

习概
（体测，形策）

专业课教师情况

DI32001 - Agile Software Engineering: Karen Petrie
DI32002 - Games Programming: Chris Jefferson
DI32003 - Theory of Computation: Chris Jefferson（教学开始 - 泵引理部分）, Perley Xu（图灵机部分 - 教学结束）

DI32001 - Agile Software Engineering

内容概述

这是一门教你如何“工作”的课。这个课只有短短 6 周（在第 1-6 周），但将可能是你们 DIICSU 感觉到的最为充实的一门课。

第 1-2 周（除第 2 周最后一节课外）是正常上课，讲解各种敏捷价值观、标准团队协作流程、各种术语的含义等。同时要在这段时间内完成组队（正常情况下 8 人，但是会有组缺 1-2 人）。

在第 2 周的最后一节课，“客户”将会出现，并会带来甲方的需求文档。在这节课上，客户将会详细讲解自己的具体需求，并针对大家的问题进行答疑。

注意：在接下来的部分，大家可能对一些概念或名词感到陌生。在下文有一个专门的“概念解释”部分，以供参考。

在第 2 周结束后的那个周末，小组需要做的事情有：

创立 GitHub 仓库，拉入所有小组成员以及 Karen
制定接下来四周的“工作日程”
制定项目的 Product Backlog
确定接下来四周中的第一周 (Sprint 1) 的 Product Owner 和 Scrum Master

接下来的四周（第 3-6 周），小组将作为敏捷团队完成四次 Sprint。周一至周五每天将进行 Daily Scrum。此外，每周一进行 Sprint Retrospective，Sprint Planning，每周五进行 Sprint Review。

每次 Sprint，Product Owner 和 Scrum Master 职位都将轮换。每人必须，且仅应在一次 Sprint 中担任一个职位（小于 8 人的组除外）。

Karen 将旁听并记录每次 Daily Scrum 和 Sprint Review，并在每次 Sprint 结束后的那个周末给出文档反馈。Sprint 2 和 Sprint 4（即第 4, 6 周）的所有会议均将被评分。

每个 Sprint 的评分标准如下：

Sprint Retrospective and Follow Up Actions - 20%
Sprint Backlog - 20%
Software Artefact Development - 10%
GitHub Usage - 10%
Agile Method Usage - 30%
Sprint Review - 10%

特别地，Sprint 4 的 Sprint Review 将更为正式，类似其它课程的 Pre，且将被视频记录。当天还会有客户测试环节，客户将会亲自上手体验产品，同样被视频记录。这将用作 Sprint 4 评分中的 "Software Artefact Development" 部分的参考。（Sprint 2 中这一部分的评分参考直接基于 Sprint Review。）

此外，在 Sprint 2 结束时，客户将会变更一定需求，发布新的需求文档。团队需基于此作出行动，例如更新 Product Backlog。

本课程允许完全使用 AI（Full AI）。

作业与考试情况

本课程无任何实际意义上的作业。当然，Sprint 2 和 Sprint 4 可被视为“作业”。它们各自占据课程总成绩的 40%。

考试方面，本课程有两次在线小测，可在第 6 周的周末（即结课）前任意时间完成。它们各自占课程总成绩的 10%。无期末考试。

注意事项

孩子们，这课可不兴缺席，尤其是第 3-6 周。缺席将导致小组不能满员开会，如在第 4, 6 周缺席还会直接影响你的小组分数。

建议提前熟悉 GitHub 相关的操作，如创建 PR，代码审核等（如有能力请熟悉 CI/CD）。Sprint 2, 4 均有 GitHub 使用规范的评分。

请切记，除非团队小于 8 人，每人仅能在一次 Sprint 担任一个职位。务必安排小组内最有能力的 4 个人在 Sprint 2, 4 担任工作。

（以下注意事项仅适用于：如 Karen/外方教师上课）

请重视在每次 Sprint 结束后得到的反馈，如果你想追求还算好看的分数的话。

请勿在非工作时间在 Teams, GitHub 或任何 Karen 可能接触到的平台上活跃，尤其是在 Sprint 2, 4 期间。否则被抓了你们组就是 666 掉大分。

概念解释

注意：以下概念解释纯属主观，更基于本人的个人理解以及 24/25 学年本课程中的实际情况。对部分概念的解释可能与标准敏捷价值观或软件开发行业共识有所差异。

Sprint

一次敏捷开发流程，通常为一周。在每次 Sprint 的第一天，需要进行 Sprint Retrospective 和 Sprint Planning。在每次 Sprint 的最后一天，需要进行 Sprint Review。Sprint 流程中的每天（包括第一天和最后一天），需要进行 Daily Scrum。

工作日程

团队可根据课表以及大家的个人需求商量制定。每周总时长应为 35 小时（包含该课程的课堂时间）。根据敏捷宣言，不得有任何工作时间安排在周末。工作时间外不得进行任何工作，这甚至包括回复 Teams 上的消息。反正您就是得装死，至少从老师的视角看。

Product Backlog

团队基于客户需求，堆积所有 User Story 的仓库。在每次 Sprint Planning 会议上，Product Owner 将负责制定当次 Sprint 需要将哪些 Product Backlog 中尚未完成的 User Story 移入 Sprint Backlog。

Sprint Backlog

用于在一次 Sprint 流程中管理所有被选取的 User Story。在第一次 Daily Scrum 中，Scrum Master 基于它来进行工作分派。在后续每次 Daily Scrum 中，它都应被更新。在本课程中，采用的模式是 Kanban。

Kanban

Kanban 模式将当次 Sprint 中的所有 User Story 分为三类：待办、进行中以及已完成。Sprint 一开始时，所有的 User Story 应均位于待办区域中。如果发生了在 Sprint Review 前部分 User Story 仍未进入已完成区域的情况，这些 User Story 应被移回 Product Backlog，敏捷团队应当在此后的 Sprint 中吸取教训，Product Owner 在此后的 Sprint Planning 中也应微调预期 Story Point 值。

User Story

可理解为项目的一个功能点，但是是用“用户故事”的形式来叙述的。比如，对于一个外卖软件，两个可能的 User Story 的例子是：

作为点餐顾客，我能按照人均价格排序附近的所有商家，以便我能满足自己的预算。
作为骑手，我能在地图上看到点餐顾客的位置，以便我将餐品送达。

User Story 应当尽可能原子化，不应过于含糊或是多个可被细分的功能的合并。例如，“作为点餐顾客，我能在手机上点餐，以便我能足不出户地解决就餐问题。”便是一个糟糕的故事。

每个 User Story 均有一个 Checklist。一个 User Story 的 Checklist 在每次 Sprint 中的 Sprint Planning 中被制定。

每个 User Story 均有一些用于区分、筛选的指标，用于评估其预期工作量、重要性及紧急性。两个例子是 Story Point 和 MoSCoW。

Checklist

它制定了一个 User Story 的细分任务点。比如，对于一个描述“用户可以做什么功能”的 User Story，前端人员要干什么？后端？数据库？数据本身？最后如何测试？

Story Point

用于评估 User Story 的预期工作量的单位。它应是斐波那契数列中的值，例如 3, 5, 8。在 Sprint Planning 中，Product Owner 选取当次 Sprint 的所有 User Story 的一个重要方法便是设置一个预期 Story Point 数值，并选取 Story Point 总和约为该数值的一些 User Story。

MoSCoW

一个非常经典的用于评估 User Story 的重要程度的指标，它分为四个级别：

Must Have
Should Have
Could Have
Won't Have

对于上文 User Story 定义中提到的外卖软件中的两个 User Story 例子，前者可能是 Should Have 或 Could Have（因为这是一个不影响基本使用的功能，没这个功能也能点餐），而后者应该是 Must Have（因为这个功能非常重要，无法缺失）。

条件允许时，Must Have 的 User Story 总是应当在 Sprint Planning 中被优先移入 Sprint Backlog。

Product Owner

一个小组中的特殊职位。职责主要是负责确定产品的功能，确定优先级，并确保产品符合客户的需求。具体地说，他/她需要：

在 Sprint Planning 中制定本周需要将哪些 Product Backlog 中尚未完成的 User Story 移入 Sprint Backlog
在每次 Daily Scrum 上了解其它组员对于产品功能的疑问，并及时与客户交流确认
主持 Sprint Review

Scrum Master

一个小组中的特殊职位。职责是负责敏捷实施流程，并向其它组员评估和分派工作量。具体地说，他/她需要：

主持 Sprint Retrospective
主持每次 Daily Scrum
在每次 Sprint 的第一次 Daily Scrum 上，对 Sprint Backlog 中所有的 User Story 进行工作分派
在此后的每次 Daily Scrum 上跟进开发人员的最新进度，并确保所有完成的 User Story 符合 Definition of Done

开发人员

敏捷团队除 Product Owner 和 Scrum Master 以外的所有人员。

Sprint Retrospective

一个会议类型，在每次 Sprint 前或开头举行。由 Scrum Master 主持。敏捷团队回顾上次 Sprint 的表现，并总结一些可以提高团队表现的行动。

Sprint Planning

一个会议类型，在每次 Sprint 开头举行。由 Product Owner 主持。如果感觉必要，敏捷团队可以首先对 Product Backlog 进行略微调整，如新增 User Story 或修改某个 User Story 的指标。敏捷团队随后从 Product Backlog 中选取本周需要完成的一些 User Story，放入 Sprint Backlog。然后为每个本周需要完成的 User Story 制定 Checklist。

Daily Scrum

一个会议类型，每天举行。由 Scrum Master 主持。

在每次 Sprint 的第一次 Daily Scrum 中，对 Sprint Backlog 中所有的 User Story 进行工作分派。

在其余每次 Daily Scrum 上，所有团队成员互相汇报自己的任务进展，并互相提供帮助与指导。Sprint Backlog 也是在此时被更新，可能会有如下情况：

一些 User Story 从待办区转入进行中区
一些 User Story 的 Checklist 中一些新的任务点被完成

如果有一些进行中的 User Story 的 Checklist 被全部完成，Scrum Master 需要确保它们符合 Definition of Done。然后，它们被放入已完成区。

Sprint Review

一个会议类型，在每次 Sprint 的末尾举行。由 Product Owner 主持。客户将会到来，团队向客户展示产品开发的最新状态，并接受客户的反馈。客户的反馈有助于在下次 Sprint 中团队针对性调整计划。

Definition of Done

指一个 User Story 如要被认为“已经被完成”，需要符合的条件。这由团队成员共同确定。例如，代码已经经过审核流程，或通过自动化测试。

DI32002 - Games Programming

内容概述

这门课就是教你写个游戏出来。（与上面那个课相比是不是过于简洁了）

此门课在第 7 周开始。

本课程允许完全使用 AI（Full AI）。

作业与考试情况

本课程有两个作业，均为个人作业。

它们是连贯的，均是围绕设计一款计算机游戏展开。游戏的题材不限制，但需具有图形界面，并满足以下至少一个要求：

运用物理引擎
联网（单人/多人均可，亦不局限于互联网，蓝牙/局域网等技术也算“联网”）
使用 AI（指传统意义上的游戏 AI，如人机玩家、寻路、程序化生成等。注意这不包括大语言模型！）
具有关卡创建器（指玩家能够在某种程度上自由编辑关卡/地图等）

游戏可以基于任意操作系统开发。

Assignment 1 - 游戏设计

截止日期：5 月中旬

提交以下四个内容（不包括 AI 声明）：

一个能够体现游戏地图的草图，需要体现地图的高度感（如在 2D 游戏中，地图是俯视还是侧视 / 在 3D 游戏中，是第一人称还是第三人称，以及摄影机的大致位置）以及尺度感（即玩家的屏幕上能看到什么内容，是全部地图还是仅仅角色附近的地图区域）。无需考虑美观性。

一个流程图，阐释玩家游玩一个典型的地图/关卡时的所有操作/行为及后果。

一个类图，体现所有你计划使用的类，以及它们将如何交互。不必严格遵循任何 UML 设计规范，因为大部分基于脚本的游戏开发（如 Unity, Godot 等平台）并不遵循面向对象思想。

一个文档，讲解你计划满足上文提到的四个要求中的哪些，以及预期使用的最重要的算法或其它技术。需要体现对多种方案的研究和批判性思考。

本作业占据课程总成绩的 20%。

Assignment 2 - 最终游戏

截止日期：6 月中旬

提交以下三个内容（不包括 AI 声明与使用的第三方资源声明）：

一个版本管理系统的仓库 URL，作为游戏代码提交（如 GitHub, Gitlab, Gitee, Unity 版本控制等）。应具有足够的推送历史以证明原创性。

一个视频（不得超过 5 分钟），记录游戏被游玩。允许剪辑拼接、配文及解说。应当记录真实的游戏游玩过程，而不应类似预告片风格。

一个报告（正文部分不得超过 5 页，A4 尺寸，字号需至少为 11），讲解：

与 Assignment 1 的设计相比，所有发生的变动（无论是游戏玩法还是代码架构上）以及原因；
所有用于满足上文提到的四个要求的算法、代码以及它们在项目中的具体位置；
与你所开发的游戏相关的安全/道德考量；
本游戏的测试过程（如他人的游玩测试/本人在开发过程中进行的测试）、测试结果以及改进策略；
如果你有机会重新启动这个项目，您会做些什么不一样的事情。

本作业占据课程总成绩的 60%。

辩论

在本课程开课后不久，你需要组成 5 人小组，并与另一个小组一起共同从给出的 6 个选题中选择 1 个，作为双方的辩论话题。

辩论每周举行一次。辩论话题主要覆盖一些游戏开发中的道德考量。（例如，”电子游戏该不该具有谋杀元素？“或”电子游戏该不该完全是买断制？”）

辩论的形式是：双方开题陈述 - 互相反驳时间 - 自由辩论时间（辩手/观众均可提问）- 结题陈述。

在每场辩论开始前/结束后，观众都将参与投票。通过辩论改变了更多人的观点的一方将会获胜。例如，辩论开始前，80% 的观众赞同正方观点，20% 的观众赞同反方观点，而结束后数据变为了 70% 比 30%，则反方获胜。胜利与否不会影响分数。

不强制每人均需要发言（例如，可以有人专门负责对对方辩手的论据进行事实核查）。

参与辩论，占据课程总成绩的 5%。

游戏测试

第 15, 16 周的最后一节课为游戏测试课，同学之间将会互相测试所开发的游戏原型，并给出反馈，以便改进游戏。这个反馈是 Assignment 2 的报告中“测试过程”部分内容重要的来源。

参与每次游戏测试课，占据课程总成绩的 1.5%。

讨论与小测

本课程一共有 6 次讨论与 6 次小测，覆盖游戏策划、开发、测试、道德考量等话题。讨论的形式为在 My Dundee 内的讨论区内发布帖子并回复他人的帖子。每次小测仅分通过/不通过。

完成每次讨论，占据课程总成绩的 1%；通过每次小测，占据课程总成绩的 1%。

注意事项

Chris 曾经反复强调的一句话是：切记这是“游戏编程”课而不是“游戏开发”课。重要的是代码而非游戏本身。没有必要花费过多精力追求更完美的图形/音效资源，因为这不会影响评分。

对于所开发的游戏必须具备的四个要求，并非是满足得越多越好。评分时看重的是原创的代码量。比如，如果你计划满足“运用物理引擎”这个要求，当然可以通过仅仅使用 Unity 来满足。虽然这在技术层面上满足了，但是像你这种分数出来就老实了，因为没有自己的工作量。“正确”的满足方法是独自开发一些物理引擎逻辑，比如重力/碰撞检测等算法；又比如，如果你计划满足“使用 AI”这个要求，仅仅写一个 BFS/DFS 同样也满足要求，但同样会被视为没有工作量。

评分时看重原创的代码量还意味着，如果你计划使用高级游戏开发平台，所有平台“替”你完成的功能都不会被考虑。比如在 Unity 中，可以完全不写一行脚本代码，仅仅依靠在 Inspector 窗口中编辑器中的自带组件便能实现一个相当完善的游戏。但你这么搞的话只能中午去做。

同时，这个课对学术不端查的真的 tm 的很严。请确保你使用的所有第三方图形/音效资源的提供者均给出了明确的商用许可，并已被您正确引用。

还有，所有的 references 不要依赖 AI 来帮你搞，我们届就有五个人中招了，让 AI 整了个打不开的假 URL。然后就没有然后了（好在他们都在 AI 声明里列出了这个生成记录，所以没被抓学术不端，只是直接挂掉了报告部分的分数），所以像这种该严谨的地方一定要自己搞。

DI32003 - Theory of Computation

内容概述

这门课中学习的内容主要如下：

有限自动机（DFA, NFA, NFA-ϵ）
正则语言，泵引理
图灵机，以及一些经典问题
复杂度
P 类，NP 类，NP-Complete 类，P = NP 问题

此门课同样在第 7 周开始。

作业与考试情况

本课程无作业。除课程第一周外，每周第一节课通常为 tutorial 课，提供习题来巩固此前所学。

有两次课堂测试，第一次在上完泵引理后，考全部已学的知识。第二次在上完图灵机的全部内容后，只考图灵机的知识。每次课堂测试占据课程总成绩的 10%。

期末考试考课程的全部知识，占据课程总成绩的 80%。需要 24/25 学年的期末考试题目请问我要。

注意事项

请认真完成每次 tutorial。我知道你们在想什么，我们已经帮您问过了，根据一些神秘的规定，老师不能提供参考答案，所以不要指望它。有问题一定及时去问。

每次考试（课程小测、期末考试）前会提供一个 Sample Test。注意它们仅题目数量和覆盖的知识点与真的考试差不多一样，其它方面（比如每道题的题型是概念题，计算题，具体情形的证明题还是抽象证明题）与真实考试基本上只能称互为独立事件。所以说句老实话，不要依赖这破玩意。

可能是本人错觉，真实的考试其实比每次考前的 Sample Test 难度略低。

还有，请注意合理分配花在这门课上的时间和花在开发游戏编程课的作业上的时间。Chris 曾经说过，他认为因为很多人为了担心这门课（计算理论）挂掉，在每次考试前花费了大量时间复习，反而低估了游戏编程课的两个作业。他还透露过，他这么想的原因是因为 22 级中游戏编程课 Assignment 1 挂掉的人数大约是计算理论 Class Test 1 的五倍。

----- 分割线 ----- Split Line ----- 分割线 ----- Split Line ----- 分割线 ----- Split Line -----

P.S. 这次就不写公共课的攻略了。体测和形策可参考大三上我写的攻略。至于另外那门思政课我不敢写（你承认这文章是你写的了？）。

以上
Made by WaterCoFire
v: LovelyJason0601
有问题欢迎留言捏