在追求藤崎诗织过程中，为了提高某个属性，玩家需要多多参加某些社团，提高自己的体力，毅力，运动等等属性，但社团里会有其他女孩子存在，这样就会很容易降低藤崎诗织对主角的好感。

放学事件也是如此，有其他女孩子想邀请主角一起放学回家，如果答应下来的话，确实可以提升这个女孩子的好感度，但会增加其他所有人的伤心度，这个时候就需要玩家取舍了，衡量利弊后由玩家自己决定。

正是因为诸如此类的不确定因素太多，让游戏设计进展缓慢。

上月景正来到研发部，发现组员们都很头疼，争论不休。

“广崎，发生了什么事？”上月景正心中产生了不妙的感觉。

项目负责人广崎桥拿着一个小黑板，解释道：“我们一部分人认为，所有的角色都应该作为全局变量，与时间轴平行，另一部分人认为，只有男女主角才需要这么做。”

上月景正皱眉：“说的浅显易懂一点。”

广崎桥画出两条平行线，介绍道：“所有角色设置成全局变量，也就是以上帝视角来看待整个游戏，一条时间轴，另一条捆绑着所有的人物。在程序设计时，我们只需要控制时间轴上的触发点，比如安排3月1日主角和藤崎诗织一起放学，那么我们只需要做两件事，一个是藤崎诗织好感+1，其余12人好感-1，只需要调用13个函数即可。”

然后在另外一张纸上画出一根时间轴，用两个小圆圈代表着男女主角，串在时间轴上，接着画出12个小三角，介绍道：“另一种，只有主角设置成全局变量。比如说3月1日放学，按照故事剧本，3月2日会有某个女配角过来约主角，我们需要首先根据全局变量中主角与藤崎诗织的好感度，来决定该由谁来出现，排除了前10个配角后发现应该由第11个出面，于是安排她出现，玩家决定后，改变主角的全部属性和数值，时间轴继续滚动。”

用三角移动，画出12条线指示在3月2日这一天，上月景正一下子就听明白了，这是两种程序设计思想。

第一种，每个配角都是独立的个体，都有自己的属性，一直当成变量，存放在内存中。

这样设计优点是读写速度快，容易写代码，缺点是游戏运行时间稍长后，数据大量冗余，内存和cu被占领，游戏会运行的很慢。

第二种，每个配角只是一段简单的固定数据，需要她出现的时候才会出现，但是主角是一个包罗万象的属性，主角身上记录了所有的人际关系数据。

这样设计优点是每次女配角出现时，调用模型函数即可，等她消失，没有她的戏份后，释放掉她的空间，修改主角的属性，缺点是主角太复杂，在每个触发点判断语句相当多，程序员要写到崩溃。

“其他同类型的游戏，他们用的技术一般是哪一种？”上月景正问道。

广崎桥放下纸笔，皱眉道：“我们只能从一些成人游戏中找到结论，但很可惜，绝大部分的成人游戏都是c端的作品，他们用第二种多一些，毕竟c的cu和内存并非全部用于游戏运行，更多的时候还在操作系统以及各类控制指令上，他们必须尽可能降低运算量。”