玩家数据重置的几种策略

玩家数据重置是游戏逻辑里永恒的话题。历经岁月的洗礼，到目前为止，我发现（注意！是发现，不是发明！）了3种实现方法。现在，项目里玩家数据重置的时间是每天0点。

方法1：

记录上次重置时间last_reset_time，若last_reset_time<今天0点（为昨天或者之前的时间），则重置，据，且将其设为当前时间now。

方法2：

记录数据过期时间expiry_time，若当前时间now>=expiry_time，则重置数据，且重新计算expiry_time，将其设为明天0点。相比与方法1，它的优点是每天只需要计算一次某天0点的Unix时间戳。

 

方法1和2有以下几种调用方式。

a.所有玩法共用一个时间，每次获取任意一个玩法的数据时，都要执行重置判断。若要重置，要依次重置所有玩法的数据，并返回重置后的数据。

b.每个玩法维护自己的时间。每次获取某玩法的数据时，只执行该玩法的重置判断逻辑，并返回重置后的数据。这样就可以分辨出玩家当天首次进入各玩法的时刻了。问题是，这也是重复造轮子，多占了内存和磁盘空间。

c.起一个1秒间隔的定时器，每秒执行一次重置判断。若要重置，则依次重置所有玩法数据。

d.玩家每次登录的时候调用一次重置判断。再加上全局定时器，每个午夜时分都通知全服在线玩家执行重置。

 

方法3：

记录玩家的上次在线时间last_online_time。当玩家不在线的时候，这就相当于上次下线时间。起一个2秒间隔的定时器，每2秒一次地将其更新为当前时间now。若更新前的last_online_time与now不属于同一天，则依次重置所有玩法数据。

 

除了各玩法重置互不影响的方式b，其他都需要依次重置一系列地玩法数据。问题是，倘若某个玩法重置出错，而又没有try...catch的话，紧接着它之后的玩法都无法重置了。啊！一人失败，影响兄弟。Every coin has two sides. 假如代码不会出错，这一切的一切，都只是无聊的幻想而已啦！

实际上，方法1也可以理解为这样的判断：last_reset_time与当天0点是否属于同一天。

自由组合可以衍生出无穷的变化哦！

暂时大概表达思路咯！

 

附上一些有用的代码：

-module(useful_time_function).

%% API
-export([now/0, midnight/1, next_midnight/1, is_same_date/2]).

%% 当前时间（Unix时间戳）
now() ->
erlang:system_time(second).

%% 获取给定时间当天的0点。
midnight(Timestamp) ->
{Date, _} = calendar:system_time_to_local_time(Timestamp, second),
Base = calendar:datetime_to_gregorian_seconds({{1970, 1, 1}, {0, 0, 0}}),
[LocalDate] = calendar:local_time_to_universal_time_dst({Date, {0, 0, 0}}),
calendar:datetime_to_gregorian_seconds(LocalDate) - Base.

%% 获取给定时间第二天的0点。
next_midnight(Timestamp) ->
midnight(Timestamp) + 24 * 60 * 60.

%% 判断两个时间戳是否在同一天。
is_same_date(Timestamp1, Timestamp2) ->
{Date1, _} = calendar:system_time_to_local_time(Timestamp1, second),
{Date2, _} = calendar:system_time_to_local_time(Timestamp2, second),
Date1 =:= Date2.