一、设计概述

本策划案基于上图框架进行内容细化。宗旨为在尽可能减少指令总数和交互次数的前提下，实现系统的设计功能，并向用户提供建立在原有好感度系统与FL经济系统之上的养成玩法。

二、组件

宿舍系统由房间、家具、宠物三类不同的组件组成。组件在本文档中用于形容一类按照固定或类似结构设置的结构，至少包含以下属性：

索引编号	类型	解锁状态&进度	展示状态
其他根据组件类型而各异的属性（如从属关系）

定义组件的展示状态包含展示与非展示两类。用户在进行正常交互而非全体查询时，只能与处于展示状态的组件交互，非展示状态的组件不可交互。用户在进行全体查询时，用户能够得知某种类组件全体的展示状态，当前处于展示状态的组件将被列出在最上方，可供更改展示状态的已解锁且非展示组件排列在其下，如：

房间A（已解锁）	房间B（已解锁）	房间C（解锁进度80%）	房间D（解锁进度80%）
房间E（解锁进度60%）	房间F（解锁进度20%）	房间G	房间H

根据是否可以调整展示的状态与否，又分为不可更换组件和可更换组件。可更换组件能够通过指令调整当前的展示状态，同时至多有1个相同组件展出，不可更换组件在解锁后就始终保持不变。

定义组件的解锁状态包含解锁与未解锁两类，满足条件时未解锁状态可以转化为解锁状态。非解锁互动时，用户只能与解锁组件交互；解锁互动时，用户只能与非解锁组件交互。

组件的状态遵循解锁决定展示的规则：未解锁的组件无法被玩家交互，因此无法被设置为展示状态。

因此，虽然理论上存在4种排列组合结果，但“未解锁已展示”显然不是符合系统要求和现实逻辑的状态。实际上存在的组件状态仅有“已解锁已展示”、“已解锁未展示”、“未解锁未展示”三种。其中“已解锁已展示”、“已解锁未展示”可以进行相互转化。“未解锁未展示”状态则需判断不同的情形，仅能向前两个解锁状态进行转化。已解锁状态下，展示和未展示的转化是暂时性的，而未解锁向已解锁的转化是永久性的。

实际操作中，不排除会遇到某一组件类型均处于“已解锁未展示”的BUG；或因为数据交互的原因，存在组件处于“已展示”状态但系统认定仍未展出的情况，因此在检测时优先考虑该组件未是否存在其他已解锁组件。

如果系统性能有富余空间，同时考虑是否已解锁和是否已展出是更优的解决方案，但会加倍性能负担。

对于房间组件来说，没有必要设计此系统。

因为房间作为一个组件独占某一组件位，不会出现家具或宠物组件存在的在同一位置有不同组件唯一展出的问题。

1.不可更换组件—房间

房间为用户提供了承载家具和宠物组件展示的空间，并作为解锁后两者的前提存在。每个房间均独立存在，当完成解锁后始终保持展示，不可被更改。

一个房间对应若干数量的家具位。当且仅当房间处于展示状态时，用户获取家具位的访问权限。

2.可更换组件—家具&家具位

家具为用户提供了可能的养成增益、特殊功能与纯粹剧情欣赏效果。家具仅有在家具位展出时才生效。

每个家具位对应若干家具，并与其他家具位的家具所独立。定义某一家具位可用时，该家具位对应的家具可解锁，且已解锁的该位家具可以被展出。也就是说，用户将获取在该位置操作家具的权限。

家具位实际上不应存在在系统内部，是仅为便于理解策划案而使用的说辞。

使用bool sCondition = 1作为展示，sCondition = 0作为未展示在程序上会更加直观。

不过，无论何种表示方式，某一家具位最多同时存在一件展出的家具。

3.可更换组件—宠物

宠物为提供了可能的养成增益和纯粹剧情欣赏效果，需要在对应的房间/家具已处于解锁状态时才可解锁。

宠物房提供了1个宠物位。当某一宠物已被抽取时，可以展出该宠物。理论上，在正常养成过程中，并不存在该宠物已被抽取但对应养成家具或宠物房未被解锁的情况，但不排除特殊宠物作为人物或活动奖励被赠送的可能性，由此产生的bug需要程序实现时加以注意。

由此，可以将整个组件系统的关系表示如下：

三、增益

组件所提供的增益，根据效果的不同分为百分比增益，数值增益和特殊指令。仅有处于展示状态组件的增益会正常生效。

须注意的是增益并不一定全为正加成，某一组件提供某方面加成的同时，亦可能会存在一定的减益。这种减益由增益赋值负数进行实现。

涉及增益时应当注意，对于单组件提供的单属性实际增益不应大于3%，对多属性实际增益的和也不应超过4%。如果一定要设计一个超过规定增益的组件，应当采取减益以在其他属性上提供扣除。同时建议整套宿舍系统提供的单属性增益不应大于10%。

在上述计算中，数值增益可以以50亲和度，10000好感度或整千增减的情况作为参考，等效为百分比增益计算。

数值应当在设计过程中就计算完毕，为防止误差过大，尤其是泛化误差过大，有必要建立参照表。当值无法取整时，建议保守起见，采取向下取整。

组件\道具	1%	2%	3%	4%	5%	6%	7%	8%	9%	10%
1%	98.01%	97.02%	96.03%	95.04%	94.05%	93.06%	92.07%	91.08%	90.09%	89.10%
2%	97.02%	96.04%	95.06%	94.08%	93.10%	92.12%	91.14%	90.16%	89.18%	88.20%
3%	96.03%	95.06%	94.09%	93.12%	92.15%	91.18%	90.21%	89.24%	88.27%	87.30%
4%	95.04%	94.08%	93.12%	92.16%	91.20%	90.24%	89.28%	88.32%	87.36%	86.40%
5%	94.05%	93.10%	92.15%	91.20%	90.25%	89.30%	88.35%	87.40%	86.45%	85.50%
6%	93.06%	92.12%	91.18%	90.24%	89.30%	88.36%	87.42%	86.48%	85.54%	84.60%
7%	92.07%	91.14%	90.21%	89.28%	88.35%	87.42%	86.49%	85.56%	84.63%	83.70%
8%	91.08%	90.16%	89.24%	88.32%	87.40%	86.48%	85.56%	84.64%	83.72%	82.80%
9%	90.09%	89.18%	88.27%	87.36%	86.45%	85.54%	84.63%	83.72%	82.81%	81.90%
10%	89.10%	88.20%	87.30%	86.40%	85.50%	84.60%	83.70%	82.80%	81.90%	81.00%
11%	88.11%	87.22%	86.33%	85.44%	84.55%	83.66%	82.77%	81.88%	80.99%	80.10%
12%	87.12%	86.24%	85.36%	84.48%	83.60%	82.72%	81.84%	80.96%	80.08%	79.20%
13%	86.13%	85.26%	84.39%	83.52%	82.65%	81.78%	80.91%	80.04%	79.17%	78.30%
14%	85.14%	84.28%	83.42%	82.56%	81.70%	80.84%	79.98%	79.12%	78.26%	77.40%
15%	84.15%	83.30%	82.45%	81.60%	80.75%	79.90%	79.05%	78.20%	77.35%	76.50%

如上表中数据所示，划线部分均达到试做分析中12%的警戒线。由于道具和组件的百分比增益为乘算，为防止经济系统的物价崩坏，设计道具提供的增益时应当保守起见。

1.百分比增益

百分比增益主要包含每次交互时获取好感的百分比加成与每次打工时间的百分比缩减。将其反向则视作一种减益，即按百分比扣除每次交互时获取的好感和按百分比提升每次打工的时间。

组件提供的百分比增益通过加算的方式累计，并与道具提供的百分比增益以乘算的方式累计，如当用户持有“未言的期待”，并展示减少打工时间分别为1%、2%、2%的家具时，其增益计算如下：

好感加成有待更多数据的分析，而打工时间的缩减，依据目前分析的结果，实际的增益总值不建议大于11%。

2.数值增益

数值增益主要包含每次交互时获取好感和亲和的具体数值加成。将其反向则视作一种减益，即每次交互时削减具体数值的获取好感和亲和。这一削减后的值在极端情况下也不应小于0，即每次成功交互的获取好感不应为负数。

数值增益和减益在不同的边际抵抗影响下难以平衡，建议对其的赋值应当保守起见。

3.特殊指令

特殊指令指部分家具组件提供的，关于其他系统的便利指令，亦可以接入其他组件的现有指令。

关于新构建的便利指令，例如对于已解锁剧情章节（包括DLC购买剧情章节）的查询指令，或查询用户拥有的全部道具数量并给出返回等。

一般来说，一个房间内至多包含一件拥有特殊指令的家具组件，最好不要让用户产生“本系统的目的是向用户兜售指令”的想法。

四、养成

养成部分主要包含各色对FL的盈利设计。由宿舍系统的设计初衷，我们不希望用户（除个别FL榜上有名者外）能短时间结束养成的体验。介于大多数用户的FL累计值处于3~4级，当某个房间的养成总费用大于4000FL时，大多数用户便会采取暂时观望或按件逐个购买的方式消费，特别是当他们还需要花费FL在其他系统（如DLC）上时。这将大大延长“一个房间”作为养成单元的生命周期。

1.养成单元

养成单元是某次更新的最小单位。从用户对某次更新的体验完整性考虑出发，没有必要在做完某一家具或某一宠物后就更新上线。每次更新应包含一或多个养成单元。

一般来说，一个房间与其配套的家具、功能可以视作一个养成单元，针对某一房间所有家具设计的“套件装饰”家具包也可以视作一个养成单元，但仅针对某一家具位的拓展增补包则因其体量过小（主要是覆盖面过小以至于用户购买的欲望可能不强）而不会被视作一个养成单元。

能被视作养成单元的可以有：

• 一个房间与其配套的家具、功能；
• 针对某一房间所有家具设计的“套件装饰”家具包；
• 包含50权重至1权重每个权重量级宠物的宠物包。

2.生命周期

生命周期是针对养成单元而论的数值，代表了某一养成单位更新上线后能够在用户群体中维持新鲜度的时长。生命周期的计算公式一般可以表示为：用该养成单元的价格除以期望收入后再乘以某一常数。该常数即为生命周期常数，与其他玩法的体量和用户选择如何分配其FL收入有关有关，且生命周期常数依赖于玩家群体的调研。在本策划案编写时由于系统尚未上线，缺乏调研数据，故暂时定为1.6。

若用γ表示生命周期常数，则生命周期的计算公式可以参照如下：

总生命周期为某次更新中各养成单元生命周期之和，决定了项目组更新的理想频率。

3.家具

家具是拥有最多盈利设计的组件类型，可以简单分为家具包、增益、解锁三个类型。

但这并不意味着家具的定价仅受此三者影响，基础价格同样重要，且在一定的范围内可以随机裁定。更高价的家具能让用户自然的产生高级感，并由此产生购买欲望，即使它们可能并不提供更大额的增益。

3.1.家具包

家具包类似DLC包，将多个家具组件打包出售并赋予一定折扣吸引用户购买，节假日或特殊日时亦可以采取限时折扣的方式。

封装家具包时，可以将同一家具位的不同家具打包，亦可以将同一房间不同家具位的家具打包。前者作为一种拓展增补包的形式出现，后者则包含一定的文案连贯性，即“套件装饰”。

家具包的定价以其包含家具组件的总价之和为基础，赋予5%10%左右的折扣，根据限时折扣的促销力度，可再度加算10%30%的折扣。

3.2.增益

增益作为家具定价的直接相关要素存在，高额的增益必然意味着更高的价格。每0.1%的增益意味着在价格上额外提升10~30FL。

3.3.解锁

家具家具位不一定需要跟随房间的解锁而解锁，亦可以需要用户单独购买。对于一些较为特殊的家具，可以采取与房间解锁方式相同的方式，每次支付解锁FL推进一定进度，在若干次推进之后解锁。

解锁后赠送并立刻为用户展出基础家具。

4.房间

4.1.解锁

房间并不需要像真实世界的房间考虑到布局和通路的问题，它们应当作为一个可以被随机访问的列表存在。如此能够作为经济埋点的只有针对每个房间的解锁功能。

初始时为用户解锁若干房间，用户仅能正常与这些房间交互，其余的房间在访问时则显示过于杂乱/堆满杂物等情况（具体如何参见外围系统—文案部分）。在解锁时，用户需要支付一定FL来推进解锁进度。

每个房间有其规定的解锁次数int uTimes，但在赋值不同用户的解锁次数int uUTimes时，随机赋值uUTimes∈{uTimes-1, uTimes, uTimes+1}。这一随机分配的权重可以调配，从而让不同用户在解锁相同房间时存在一定的随机性。

将B视作100%，而未推进解锁进度视作0%，每次推进时向用户展示推进后的进度百分比。若达到100%则不予展示，改为向用户声明解锁成功，并使该房间变为展示状态。

5.宠物

考虑到玩法的复杂度，本节的第二、三部分作为一种可选功能存在。

5.1.抽卡

用户解锁宠物房且至少解锁1个宠物家具后开放本玩法，在此前使用相关指令应提示用户未满足相关条件。如不使用第二和三部分的功能，在解锁宠物房时应当为用户解锁全部宠物家具位，并为用户赠送并展示基础家具。

每次抽卡需要间隔一定冷却时间，推荐将冷却时间设计为大于等于1天。抽卡时，需要支付一定FL，并依据宠物不同的权重组成概率池，从中随机抽取出1只宠物。抽出的宠物被解锁，但如果抽出的宠物已经解锁，则改为未抽出任何东西。根据宠物的稀有度，应设计50、25、10、5、1的不同权重梯度。若存在各一只时，其理想概率大体遵循下表。

权重	概率
50	=54.945%
25	=27.4725%
10	=10.989%
5	=5.4945%
1	=1.0989%
91	≈100%

由于取整后总概率并不一定恰好取得100%，实际算法的实现并不遵照理想概率中提供的百分比。

当用户抽卡时，应计算卡池中所有类型宠物的权重之和int petWeight ，以服务器时间或其他能提供随机性（不一定强求真随机）的参数为随机数种子，为抽卡结果int petGet赋值为[1, petWeight]间一随机整数。

将宠物按权重大小降序排序，大小相同者则按名称降序排序，名称相同者则手动编号降序排序。抽卡结果β所对应的排序后宠物即为所抽出的结果。

5.2.解锁

宠物家具可以被解锁。如若启用此玩法，则在解锁房间时为用户一并解锁若干宠物家具。

不同的宠物家具对应不同类型的宠物。未被解锁的宠物家具，其对应的宠物不可被抽取。一旦解锁，所有对应宠物便可加入至概率池中。

提供除了初始抽卡指令外的另一高级抽卡指令。使用高级抽卡指令时需要支付更多FL，并将权重不足25的宠物权重+10后再抽取。

5.3.等级

宠物家具亦可以包含等级机制，可以通过前述的展出功能实现。用户花费FL完成升级后，为其切换展示至更高级的宠物家具，用户不可手动更改展示状态。

用户不应能跳阶升级，升级至下一级家具需要本级家具作为前置需求，如不满足则声明未满足前置条件。高级的宠物家具解锁权重更低的稀有宠物类型。

五、外围系统

外围系统主要包含文案和指令两部分。

1.指令

特殊家具位对应的指令，在设计具体家具时再进行考虑。

用户应至少能使用满足如下功能的指令：

• 查询目前系统开放的所有房间列表，已解锁者将被置于前列并标示出【已解锁】，解锁中的房间将列出百分数，如进度为0%则不列出；
• 查询用户声明的某一房间中所有家具位，已有展出者将被置于前列，其余返回为【空】（若有家具需要多次解锁，同房间列表指令的百分数展示方式）；（可以与上条合并，如不声明房间则视作查询房间，声明则视作查询家具）
• 花费FL解锁某一组件；
• 花费FL抽取宠物；
• 查询用户声明的某一房间某一家具位已解锁的家具列表，如需更换展出则输入对应家具名，如不需更换则输入退出；
• 查询用户声明的某一房间某一家具位可购买的家具列表，如该家具位未解锁则返回前置条件不足，如需购买则满足前置条件的同时输入购买家具名；
• 查询用户解锁的宠物类型，如未解锁该玩法则返回前置条件不足，如需更换展出则输入对应宠物名，如不需更换则输入退出；
• 查询某一组件的具体功效与描述；

大体流程展示如下：

2.文案

文案描述可以遵循下属表格要求撰写：

家具/宠物	根据其价格与稀有度撰写组件描述
房间	撰写房间描述
返回报错	进行符合情景的修饰
抽取结果	进行符合情景的修饰
家具购买	进行符合情景的修饰

六、附录

1.术语对照表

本表不等效于数据字典。

术语	又名	注释
框架
组件		可包含参数的单元。可以作为最小单元存在，但不一定均为最小单元。组件可以将其他组件作为自己的参数。
状态		定义某一组件某时刻某状态的参数，一般为布尔类型变量。
FL	fl，Flucting Light	标准货币。
家具位	展出位	对应同一家具位的不同家具，视作同一类家具，仅可在该家具位展出。家具位归属于房间组件。
状态
展示	展出	所有满足相同展示条件的组件中，仅有1组件可供展出。
解锁		定义某一组件是否可用。
打工
原始打工时间	t/workTime_OT/workTime_F	原始打工时间为不受任何加成影响的初始时间，处理后变为实际打工时间。
实际打工时间
组件解锁
规定解锁次数	uTimesuUTimes	规定解锁次数为某一组件解锁所需的固定值，通过计算变为用户的解锁次数，注意与下条区分。
用户的解锁次数
解锁进度	uProgress	用户实际完成的解锁次数累计。
宠物
宠物权重		每种宠物按照其稀有度被赋予的唯一值，与其在抽取结果中出现的概率有关。
权重梯度		按照50、25、10、5、1的赋值为宠物区分稀有度的梯度。
宠物权重之和	petWeight	已解锁宠物权重的和。
宠物抽取结果	petGet	一次抽取后得到的值，属于[1, petWeight]并为整数。
概率池		所有可用宠物按权重大小降序排序，大小相同者则按名称降序排序，名称相同者则手动编号降序排序后得到的抽卡池。

2.数据字典

仅作为参考存在的字典，仅包含策划觉得可能有用的部分。

数据结构
ID	Name	组成
componentRoom	房间组件	indexRoom, nameRoom, componentFurn, uCondition, costFL //此处的u为Unlock解锁
componentFurn	家具组件	indexFurn, attributeFurn, uCondition
componentPet	宠物组件	indexPet, attributePet, uCondition
attributeFurn	家具属性	nameFurn, buff, uCondition, costFL
attributePet	宠物属性	namePet, buff, weight
uCondition	解锁状态	uTimes, uUTimes, uProgress
buff	加成	buffA, buffB, buffC
数据项
ID	Name	含义
nameRoom	名称	房间的名称
nameFurn		家具的名称
namePet		宠物的名称
indexRoom	索引	房间的序号
indexFurn		家具的序号
indexPet		宠物的序号
uTimes	规定解锁次数	某一组件解锁所需的固定值
uUTimes	用户的解锁次数	某一用户对某一组件唯一确定的解锁所需次数
uProgress	解锁进度	用户实际完成的解锁次数累计
buffA	增益/减益	组件提供的好感增益/减益
buffB		组件提供的亲和度增益/减益
buffC		组件提供的打工时间增益/减益
costFL	价格	货币消耗
weight	权重	宠物的权重
int petGet	宠物抽取结果	一次抽取后得到的值，属于[1, petWeight]并为整数。
bool sCondition	展示状态	某一组件是否展出
数据存储
ID	Name
user	前端用户
database	后端数据库&服务器
userTable	用户表
处理与加工
ID	Name	处理
dataManagement	数据管理中间件	包含下述4则管理处理
userManagement	用户管理	返回输入userInfo中满足actionRequest_V所需的部分
actionManagement	操作管理	将actionInformation中满足用户组使用的信息抽取出来，返回actionInformation_E//旨在提供一个管理员可用的接口
actionSystem	操作处理	将actionRequest_V传递给服务器并获取actionResult，将actionResult传递
resultSystem	结果处理	将actionResult与userInfo合并为用户可读性更强的actionResult_P，并返回之
petWeight	宠物权重之和	求已解锁宠物权重的和，返回petGet
drawPet	抽卡	将所有可用宠物按权重大小降序排序，大小相同者则按名称降序排序，名称相同者则手动编号降序排序后得到抽卡池 返回petGet
pValidation	权限验证	验证用户是否有权执行请求的操作=permissionJudge//此处的p为permission
fValidation	格式检查	对操作请求进行格式检查=formattingJudge+formattingTo//此处的f为formatting
formattingJudge	格式判断	判断输入的actionRequest为何种指令如果没能找到指令或格式错误，返回formattingError通过则向formattingTo传递actionRequest
formattingTo	格式指向	判断输入的actionRequest为何种指令如果出现错误，返回formattingError否则传递actionRequest和iName
permissionJudge	权限检查	判断输入的actionRequest是否能执行iName指令如果出现错误，返回permissionError否则传递actionRequest_V和actionInformation_E
数据流
ID	Name	注释
actionRequest	操作请求
actionRequest_V	验证后的操作请求	此处的v为verified
actionInformation	操作信息
actionInformation_E	可执行的操作信息	此处的e为enabled
actionResult	操作结果
actionResult_P	处理后的操作结果	此处的p为processed
databaseInfo	后端数据库信息
formattingError	格式错误
iName	指令名	由formattingTo获取的，actionRequest对应的指令名
permissionError	权限不足
userInfo	用户信息