runhey
协作系统
考虑这样的场景，组队打完一段时间的御魂后突破卷满了，这需要停止御魂副本将突破卷清空然后继续刷御魂。一般的脚本无法自动处理这类多人协同副本（御魂、觉醒、日轮、永生之海、探索），OAS 希望可以通过设定将其自动化执行，这将详细描述协作系统的设计思路:
既然是针对多人副本而系统，那么第一点首先考虑人数的问题，在前面的记录中，考虑用户之间在系统内随机组队是被否决的，其中最重要的一个原因是这无法保证所组队的队员的阵容匹配和御魂水平，其他倒是小问题，第二个比较合理的是由多个人自发组成的小圈，这可以称为小组，小组的协作系统会自动的协调调度多人副本任务，这样规模的人员数量有这样的优势：1.执行稳定，小组内一致协商好 2. 不会被一锅端，每次执行副本只是两个人，如果都是长期固定的会被鬼使黑 3. 任务调度更加灵活。 第三个是点对点的，即两个人所组成，这本身就是第二个的子集。
另一个比较重要的是组网的问题，个体之间的通信才能保证即时响应副本任务，自然而然想到的是搭一个供所有人可以接入的服务器，讨论一番后发现最无法回避的是这会导致被抓去喝茶，其次是规模上去后服务器的费用问题。合理的方案是小组之间自行组网，这可能会有一些门槛但是不难，借助一些组网工具如zerotier、wireguard（傻瓜式）来搭建局域网。剩下的如在一台电脑上这些格局太小。
那么剩下是对这个系统的功能需要，准备的说是思考路径：
- 自适应：对于每个个体都会自适应各种情况，当然这里太广泛了，具体来说小组成员一直离线、小组成员突然掉线、系统处于某些原因无法正确调度 等等。这应该单独讨论
- 多角色：个体的角色不是固定的，在有的任务中可以是队员，也可以是队长。但是对于具体的某个任务这将是固定的，否则将会引入极大的复杂度。
- 时差：这貌似并不难
- 引入新的调度器(个体): 对于协作系统的设计直观的描述应当是：对于每个个体，在保证执行其他的任务的条件下，调度执行多人任务。如何量化？ ~~摊手~
如何实现这一系统，是否需要建模，是否引入优化理论，基于主从的协同还是基于博弈的协同？ 我也迷乎
感觉把问题复杂化了，其实只要在现在的调度系统的基础上加上「中断」的概念就可以了。
组队无非两种情况：当队长、当队员 对于队员比较简单，收到组队邀请，判断多人任务的优先级是否比现在的更高，高的话就中断现在的任务 队长会更复杂一点，可能需要一个脚本间的通信机制，让队员来告诉队长「我现在有空」，队长再视情况来判断是否要中断当前任务。
