游戏签到系统

分为几个模块：

配置模块。从Excel表>导表工具>序列化文件>配置管理器。
玩家数据。存本地则玩家数据有签到记录、玩家数据管理器。
UI。签到面板、奖励格子、获得奖励界面、获得奖励格子。
业务控制器。从配置管理器、玩家数据管理器拿数据，准备UI参数，显示和初始化UI。
一个Excel配置文件，记录每天的奖励，需要能记录金币、各种道具、人物等各种物品。用导表工具导成json。还有相应的C#配置类。游戏要运营几年，不可能把每天的奖励配好。奖励必然是循环的，常见的有周循环和月循环。
一个玩家签到记录文件，记录玩家签到了哪些天；
UI：一个面板，需要自动布局组件。奖励格子。配套的视图类、参数类。
一个控制器，负责读取签到配置文件，得到每天奖励的图标。读取玩家签到文件，显示哪些天签过，哪些天错过，以及可以签的今天。
领取奖励后弹出一个全屏窗口，提示获得的奖励。最好预留显示多种奖励的能力，弄一个自动布局组件。

漏签规则和刷新周期

签到漏签的时候有两种规则

开放当天的签到，漏签的可以花资源补签。适用于每天奖励差不多的。如果想弄一个大奖则可以弄一个一周完整签到的奖励；
累积签到，漏签则签到进度落后，之后的奖励拿不到。适用于最后一天奖励很大的；

刷新周期规则：

一周或一个月结束后刷新；
距玩家第一次签到后过一周、一个月后刷新；
等玩家签完一周期再刷新；

规则1就是说如果玩家第一次玩不在一周第一天，那么他已经注定拿不完奖励。这样也行，就是要在奖励下标注周一-周日。然后发现这种逻辑是绑定漏签规则1的，你不能今天是周三然后开放周二的奖励。

规则2则需要判断玩家一个周期第一次签到，记录下玩家第一次签到的时间，当前日期-第一次>=7天时刷新。这样玩家如果忘记了第一次签到是哪天，也会对奖励刷新疑惑。虽然绝大多数玩家不会在意。

漏签规则2匹配刷新规则3，是另一种自洽逻辑。玩家一定能拿满奖励，只是会晚一点。

综上，漏签规则和刷新周期其实是绑定的：

当天签到+漏签，则应该在一周或一个月的第一天刷新，且奖励标明日期；
累积签到+进度落后，可以在拿满一周期奖励后刷新；
累积签到+进度落后，可以在一周、一个月开始时刷新，但要标明是本周、本月签到；

玩家签到记录

假设我们采用方案2。玩家漏签导致落后。

玩家的签到记录怎么记录？用列表还是字典？如果用字典，键是什么？记录全部签到记录还是最近一个周期？

最简易的方式，只记录上一次签到的配置ID。还有时间，用于判断是否该解锁新奖励。只有规则2能这么做，因为玩家最后一次签到之前的配置一定都签到了。虽然够用，但感觉不严谨。

然后如果用列表，直接看最后一条就是最近的签到。但是测试的时候漏写了判断时间，导致同一个签到ID出现了多个签到记录。总之要用列表就充分利用最后一条就是最近签到记录的特性，否则列表没有优势。

用字典，如果用日期为键：

cs 复制代码

dateTime.ToString("yyyy-MM-dd");

可以绝对避免一天的记录出现多次。

我们要获得当前应该签哪天的到，就是获得签到记录里ID最大的，+1.

玩家签到记录是记录所有的还是当前签到周期？加载到内存的应该是全部记录还是当前周期记录？

为了数据完整性，应该记录全部签到记录。但是随着游戏运营几年，签到记录数据量巨大，肯定不会全加载的内存。应该是服务器拿到本周期的记录发给客户端。

那么如果存本地应该怎么做？应该签完一个周期后单独存一个文件，以后打开游戏不再加载此文件。不过为了省事，可以签过的周期就不记录了。那么逻辑就是

签到记录只记录当前周期，假如一周为周期，则记录不超过7个。
登录游戏，检查当前和记录里最后一条是不是一周，不是就清空记录。

奖励状态逻辑

先循环得到玩家签到记录里最晚的，和当前时间比较是不是同一天。得到是否有奖励可领。

如果奖励凌晨4点刷新就把最后签到时间和当前时间都-4小时比较是否是同一天。

获取每个奖励的状态：读取玩家签到记录，把不属于本周的记录过滤掉。然后有记录的日期标记已领取，无标记的和玩家最后的签到记录比较是否是id+1。

奖励循环新周期

签到调试工具

需要做到

显示签到记录；
把最近的记录前推一天以解锁新奖励；
清空签到记录；

测试环节

签到一次，然后打开签到窗口，重新登录，打开签到窗口，确认不能再次签到；
修改时间，把使用的当前时间往后推，再次签到。如此重复，直到完成一个签到周期，签到状态归零，开始下一个周期。
把当前时间改成2天、3天后，验证漏签后无法拿满奖励的情况。

cs 复制代码

        public DateTime Now
        {
            get
            {
#if UNITY_EDITOR
                return DateTime.Now.AddDays(RootSO.Single.SigninTestOffset);
#else
                return DateTime.Now;
#endif
            }
        }

和其他进入大厅弹出面板的冲突：依次弹窗框架

发现注册新玩家后，进入大厅同时弹出了开场介绍面板和签到面板。这些面板应该一个结束后弹出下一个。

面板关闭时执行一个委托。而且只有进入大厅自动弹出的这一次执行。

然后好像要给大厅控制器弄一个List<UnityAction>，控制器在显示一个面板时把下一个委托塞给它的关闭回调。但是UnityAction又没有指定是加载面板，一定有关闭回调。

那么窗口基类弄一个委托onClose，List<窗口基类>，循环，把下一个弹窗的显示加入上一个的关闭回调。窗口现在是用MVC的，由它的控制器准备参数，显示窗口，输入参数。

那么只能把控制器也接口化IUIController，实现同一个ShowPanel方法。再弄一个set属性，传入委托。本来想把ShowPanel加个参数输入委托，发现这样只能在传入时立刻显示窗口，无法做成一个窗口关闭打开下一个窗口的链式。

那么把IUIController增加一个设置onClose的属性，把外面传入的委托寄存在控制器的成员。ShowPanel时传入。

然后发现越来越框架化：

面板、面板参数、控制器、配置管理器，全部有抽象类或接口。