108 lines
12 KiB
Markdown
108 lines
12 KiB
Markdown
# 设计与开发文档填写草稿（03设计与开发文档）
|
||
|
||
作品名称：李诫传——重修《营造法式》
|
||
|
||
作品编号：【待补充】
|
||
|
||
作者信息：【待补充】
|
||
|
||
版本号：V1.0.0
|
||
|
||
日期：2026年4月【待补充】日
|
||
|
||
## 绪论
|
||
|
||
“李诫传——重修《营造法式》”是一款以中国古代建筑制度史为主题的剧情交互游戏。作品以北宋将作监的历史语境为背景，以“画图令史”的成长视角串联叙事，通过章节化剧情推进、场景演出、对话交互和榫卯拼装玩法，将“材份制”“图样标准化”“制度化营造”等核心历史概念转化为可参与、可感知、可理解的互动体验。本文档围绕需求分析、概要设计、详细设计、测试与交付说明，对项目当前版本的设计思路与实现结果进行概述，重点体现作品的主要完成内容与可评审要点。
|
||
|
||
## 第一章 需求分析
|
||
|
||
### 1.1 开发背景与问题提出
|
||
|
||
在传统历史类数字内容中，用户往往只能被动接收背景知识，难以通过操作行为理解制度如何产生、如何落地以及如何影响社会实践。围绕《营造法式》这一主题，团队在前期调研中明确了一个核心问题：如果只做史料陈述，用户很难建立对“标准化营造”价值的直观认知；如果只做玩法而脱离历史语境，又会削弱作品的文化表达深度。因此，项目将“叙事表达”与“机制表达”并行设计，让玩家在剧情矛盾中理解问题，在交互任务中验证解决路径，从而把历史知识从“读到”转化为“做到”和“感到”。
|
||
|
||
### 1.2 目标用户与使用场景
|
||
|
||
本作品面向对历史文化、古代建筑、剧情互动游戏感兴趣的高校学生与普通玩家，也可用于课程展示、比赛答辩和文化传播场景。典型使用情境包括课堂演示中的短时体验、评审过程中的完整流程展示，以及玩家在课后进行章节化体验和 AI 问答延展学习。作品在设计上兼顾了首次体验的可理解性与完整通关后的主题留存，尽量让用户在有限时长内抓住主线思想，在重复体验中进一步理解细节。
|
||
|
||
### 1.3 核心需求与功能定位
|
||
|
||
项目的核心需求不是单纯完成“可运行的剧情游戏”，而是构建一个以历史问题驱动的交互闭环。该闭环由“历史冲突引入—制度认知建立—交互验证—章节推进—主题回收”组成，要求剧情、演出和玩法在逻辑上相互支撑。基于这一目标，作品在功能定位上形成了四条主线：一是以章节对话为主的叙事推进系统；二是以规则校验为核心的榫卯拼装交互系统；三是以背景与音乐联动为表达载体的演出系统；四是以 AIChat 为补充的问答式延展学习系统。四条主线共同服务于“重修《营造法式》”这一主题表达，而不是彼此割裂的功能堆叠。
|
||
|
||
## 第二章 概要设计
|
||
|
||
### 2.1 系统总体架构设计
|
||
|
||
作品基于 Unity 2022.3.62f3c1 开发，整体采用“流程驱动 + 组件协作 + 数据表配置”的架构思路。运行时由 Procedure 流程控制主状态切换，核心逻辑由 GameEntry 下的自定义组件承载，包括对话、拼装、故事导演、AI 对话与资源缓存等模块。剧情内容与界面配置主要通过数据表驱动，触发关系通过 StoryDirector 指令资产组织，使叙事推进、玩法切换、背景音乐和章节结束能够形成稳定的事件链路。该架构兼顾了开发阶段的可迭代性和提交阶段的稳定性，能够在不改动大量底层代码的前提下对剧情内容进行持续调整。
|
||
|
||
### 2.2 功能模块划分
|
||
|
||
从玩家视角看，系统由主菜单与设置、章节对话、拼装玩法、场景演出、AI 对话和音频系统构成完整体验。从实现视角看，项目将功能划分为流程控制层、剧情数据层、UI 展示层与交互执行层。流程控制层负责菜单进入与主线启动；剧情数据层通过 Dialog 与 DialogLine 等表驱动内容；UI 展示层负责底部对话、遮罩对话、章节标题、拼装界面与 AI 对话界面的呈现；交互执行层负责拖拽放置规则判定、事件反馈与章节推进。这样的划分使得每一层边界明确，便于在比赛前进行针对性修订和问题定位。
|
||
|
||
### 2.3 核心业务流程设计
|
||
|
||
玩家从主菜单进入主线后，系统先以章节标题和对话引导建立历史情境，再通过 StoryDirector 在关键节点触发背景切换、音乐切换、拼装任务或章节收束事件。拼装关卡完成后，系统将结果回写到故事流程并进入后续叙事。当前版本按照四章主线组织内容，章节主题依次围绕“无规矩则屋不立”“凡构屋之制皆以材为祖”“图文并重”“建筑是凝固的历史”展开，形成由问题提出、制度建立、图样落地到历史回响的叙事闭环。AIChat 入口在流程中常驻，用户可在不打断主线的前提下进行补充问答。
|
||
|
||
## 第三章 详细设计
|
||
|
||
### 3.1 剧情与交互设计
|
||
|
||
剧情设计采用“冲突驱动学习”的结构：先通过偷工减料、尺寸失准、工序失序等事件制造问题，再通过李诫与工匠群体的对话推动制度解释，最后以玩家可操作的拼装任务完成认知验证。拼装玩法并非独立小游戏，而是剧情论证的一部分，其规则重点在于类型匹配、顺序约束和完成反馈。玩家在交互中感受到“按法度拼装”与“凭经验凑合”的差异，进而将抽象制度理解为可执行的技术标准。这种设计避免了剧情和玩法两张皮的问题，也提升了主题表达的说服力。
|
||
|
||
### 3.2 数据与内容组织设计
|
||
|
||
项目的剧情文本主要通过 Dialog 与 DialogLine 数据表组织，章节、对话和行内容之间保持可追踪映射关系。场景与背景音乐分别通过 Scene 与 BGM 配置表管理，界面资源由 UIForm 配置表统一索引。故事触发逻辑通过 StoryDirector 指令资产落地，指令类型覆盖开始对话、启动拼装、切换背景、切换 BGM 和章节结束等关键节点。该组织方式使内容策划与程序逻辑可以相对解耦，既降低了后期调整成本，也提升了流程联调效率。
|
||
|
||
### 3.3 AIChat 模块设计
|
||
|
||
AIChat 模块采用可配置接入方式，运行时从 `StreamingAssets/apikey_config.json` 读取 `apiBaseUrl`、`apiKey` 与 `model` 参数，并通过心跳请求检测接口可用性。当前版本采用 DeepSeek 模型，默认配置为 `deepseek-v4-flash`。正式对话请求采用流式返回，界面端按增量文本逐步渲染，从而获得更自然的响应体验。模块同时提供错误兜底机制，在密钥失效、网络异常或请求超时时显示可识别错误信息，避免主流程被阻断。为增强历史语境适配，当前界面支持现代白话与文言风格指令切换，使 AI 回答语体能够与作品氛围保持一致。
|
||
|
||
### 3.4 界面与体验设计
|
||
|
||
界面设计遵循“信息清晰、语境统一、交互直达”的原则。主菜单承担入口分流，设置页提供音量与画面参数控制；主线中根据叙事状态切换不同对话形态，并通过章节标题强化阶段感。拼装界面在视觉上突出部件与槽位关系，在反馈上区分成功、顺序错误和位置错误，帮助玩家快速建立规则理解。AI 对话界面采用历史记录滚动与输入区分离布局，确保连续问答时的可读性。整体体验上，系统优先保证流程流畅与信息可理解，再在此基础上补充沉浸表达。
|
||
|
||
## 第四章 测试报告
|
||
|
||
### 4.1 测试目标与测试环境
|
||
|
||
本阶段测试目标是验证作品在比赛交付场景下的可运行性、流程完整性与关键功能稳定性。测试环境以 Windows 桌面端为主，开发与联调环境使用 Unity 2022.3.62f3c1。测试重点覆盖主菜单进入、章节推进、对话切换、拼装交互、故事触发、背景音乐切换、设置项保存以及 AIChat 连通性等核心路径，优先确保评审演示链路不出现阻断性问题。
|
||
|
||
### 4.2 主要测试结论
|
||
|
||
当前版本已完成主线全流程联调，四章剧情可顺序推进，关键触发节点能够按预期执行。拼装玩法在主要场景下可完成拖拽放置、规则校验与完成反馈，章节结束后可正确进入下一阶段。设置模块可保存并应用主要参数，音频切换与界面表现基本稳定。AIChat 在配置可用且网络正常时能够完成流式问答，在异常条件下可给出错误提示并保持主流程可继续。综合测试结果表明，作品已达到“可提交、可演示、可评审”的交付标准。
|
||
|
||
### 4.3 已知问题与处理策略
|
||
|
||
目前剩余风险主要集中在外部网络依赖与个别表现层细节。AIChat（DeepSeek）可用性受接口连通和额度状态影响，因此提交版本将采用可用测试密钥并准备异常情况下的说明口径，以避免评审误判。表现层方面，部分文案节奏、镜头衔接和细节反馈仍有优化空间，但不影响主线逻辑与核心体验。整体策略是保持功能冻结，优先保障稳定性与可复现性，在剩余时间内进行有限度的打磨而不引入高风险改动。
|
||
|
||
## 第五章 安装及使用
|
||
|
||
### 5.1 运行与安装环境
|
||
|
||
本作品最终提交形态为 Windows 平台打包压缩包，评审端无需安装 Unity 或额外开发环境。运行所需条件为常规桌面系统环境与可执行程序支持，AIChat（DeepSeek）体验阶段需要网络可访问对应接口。除 AI 功能外，主线剧情与拼装玩法不依赖外部服务，可在本地独立运行。
|
||
|
||
### 5.2 安装与启动方式
|
||
|
||
评审使用时将压缩包解压到本地任意目录，进入解压后的主文件夹并双击 `exe` 文件即可启动作品。启动后进入主菜单，选择“开始”即可按章节体验完整主线。若需要体验 AI 对话，可在运行过程中通过 AIChat 入口进入问答界面。提交包内将包含可用测试配置，供评审现场体验该功能。
|
||
|
||
### 5.3 典型使用流程
|
||
|
||
典型体验路径为“进入主菜单—开始主线—阅读并推进章节对话—在指定节点完成拼装交互—继续章节演出—在任意阶段可选进入 AI 问答—完成整条叙事收束”。如果评审时间有限，可优先体验第一章与第二章关键节点，以快速理解“制度问题提出—材份制验证”的核心表达；若时间允许，完整体验四章可更清晰地感受到从制度建立到历史回响的完整主题闭环。
|
||
|
||
## 第六章 项目总结
|
||
|
||
### 6.1 项目实施过程总结
|
||
|
||
本项目在实施过程中坚持“先打通主流程，再提升表达质量”的开发策略。前期以流程可跑通为目标，完成章节骨架、事件触发与玩法闭环；中期集中处理剧情文本、交互反馈和界面联动；后期围绕评审场景进行稳定性加固与交付材料整理。实践证明，以流程稳定性作为阶段验收标准，有助于在时间受限的比赛开发中持续保持进度并降低返工成本。
|
||
|
||
### 6.2 关键问题与解决思路
|
||
|
||
项目最核心的挑战是如何把历史制度表达转化为可玩机制，而不让作品落入“重讲述、轻交互”或“重玩法、轻主题”的两难。团队的解决思路是让每一次交互都服务于前置剧情提出的问题，让每一次剧情推进都对应一个可验证的行为结果，从而实现叙事与机制的相互印证。另一个挑战在于 AI 模块的工程稳定性，项目通过配置化接入、流式渲染和异常兜底，确保 AI 功能可加分但不成为主流程风险点。
|
||
|
||
### 6.3 后续优化方向
|
||
|
||
后续版本将在不改变主线结构的前提下继续完善表现层品质，重点包括局部演出节奏、交互反馈细节和文案润色一致性。同时，AIChat 可进一步扩展为与章节进度联动的上下文问答模式，使角色化回应与历史知识解释更加贴合当前剧情节点。在传播层面，项目也可考虑增加面向课堂与展陈场景的短流程演示模式，以提升作品在教学与科普场景中的复用价值。
|
||
|
||
## 参考说明
|
||
|
||
本文档为“03设计与开发文档”填写草稿，重点提供可直接转写到正式 Word 版的段落文本。最终提交前，请按实际情况补齐作品编号、作者名单、截图编号、测试日期与参考文献信息，并确保与官网信息概要表、答辩材料和演示视频中的表述保持一致。
|