请教一下成就系统的设计思路

hercules135 2016-02-23 01:46:20
比如
连续登陆 5天 达成之后就换成
连续登陆15天 ....以此类推

不知道如何做比较好.

自己想了一下,可以获取用户登录的天数,然后按范围显示成就,但是这有个问题,就是每次都要重新判定,

又想了一个方法是成就记录也持久化入数据库,但是每次更改都要去修改

之前没有什么这类经验,但是看到很多游戏/app都有这方面的设计了,所以来请教各位前辈有没有更完整的设计方案?
...全文
634 11 打赏 收藏 举报
写回复
用AI写文章
11 条回复
切换为时间正序
请发表友善的回复…
发表回复
hercules135 2016-02-24
  • 打赏
  • 举报
回复
引用 4 楼 xdashewan 的回复:
成就记录也持久化入数据库,但是每次更改都要去修改,为何不能修改?“每次”又是什么场景。每当用户获得一个新的成就去更新一下数据库可以说是很正常的行为,如果你觉得更新太过频繁,那么只能说明你们成就设计的门槛过于低了,设想一下经常能完成的事有何成就感,刷牙一个年你觉得有成就感吗,相反一年里每天跑5公里减肥风雨无阻,那就有成就感。过于频繁的更新并不是数据库的问题,而是业务本身没有考虑周全或者真需要如此
您说的很有道理. 同时也谢谢楼上的回复,日后结贴
wanghui0380 2016-02-23
  • 打赏
  • 举报
回复
很多事情,其实就跟你平时做的事情一样,这些无关技术。 比如我上班前先去看板获取今天又多少bug需要修复(进入游戏查一下我订阅的任务列表,上面有啥任务我就做啥任务),然后我干完了,也写上一句“某bug已经修复完毕”(上面的任务说要求我登录的时候通知一下,那么我登录玩了就通知一下他呗,如果他又联系方式我就直接联系他,如果他没有我就放公共看板上,他想后续处理就自己订阅这消息去)
wanghui0380 2016-02-23
  • 打赏
  • 举报
回复
我不管,我只是发了一个消息。如果有人订阅他就拿去,没人订阅这消息就被丢弃了 同样这里我只是往消息总线上写了一条“XXX 登录” 或者从消息总线上查询了一下“今天我该完成几条任务”
by_封爱 版主 2016-02-23
  • 打赏
  • 举报
回复
成就跟那个连续登陆没什么关系. 如果只是成就 你只有一个 用户编码 成就编码 成就名字 获取时间 是否获得 添加用户的时候 从一个"模板"把这些给copy过去 ,然后更新下"小试牛刀"成就 时间=getdate()之类的, 至于你所谓的"连续登陆"这是属于其他"动作"实际上跟"成就"只是出发关系. 比如 你登陆的时候 一定有一个登陆日志 每次登陆的时候 判断连续登陆的次数 如果满足你的"流程" 就更新下表. 杀怪的时候 判断杀了多少次 如果够300了. 更新下表.
  • 打赏
  • 举报
回复
比如说一个用户现在登录了,那么负责登录的服务系统会首先往时间窗口系统发一条消息,然后才将数据保存到数据库。 打个比方吧。假设低级的数据是一片海,那么你就需要单独创建一个非常简单、高效的系统,来实时捞起这片海里边的一些珍珠。你不能在你需要捕捞珍珠时,把整个海都抽干了,才去采集珍珠。
xuzuning 2016-02-23
  • 打赏
  • 举报
回复
数据库不会因为增加一次 update 而崩溃,只是你杞人忧天而已 你完全可以把信息存储于客户端,所谓成就与他人无关
  • 打赏
  • 举报
回复
如果死抠底层,那么可能觉得“没有什么”。有些人(特别是一些在国营单位的机构里搞开发的人)喜欢玩弄几十行的sql语句、视图之类的东西。那些东西非常适合官僚机构。 如果换一个思维方式,就知道普通人不这样去决策。普通人描述决策的逻辑非常简单,只要其通过采集系统得到的外部信号涉及4、5个事件ID、6、7个时间节点,立刻就反应出来行为模式了。根本不用去查询什么数据库、研究什么“统计指标公式”之类的。 普通人能接受比较干脆的、短的玩法,而不喜欢数据库。
xdashewan 2016-02-23
  • 打赏
  • 举报
回复
成就记录也持久化入数据库,但是每次更改都要去修改,为何不能修改?“每次”又是什么场景。每当用户获得一个新的成就去更新一下数据库可以说是很正常的行为,如果你觉得更新太过频繁,那么只能说明你们成就设计的门槛过于低了,设想一下经常能完成的事有何成就感,刷牙一个年你觉得有成就感吗,相反一年里每天跑5公里减肥风雨无阻,那就有成就感。过于频繁的更新并不是数据库的问题,而是业务本身没有考虑周全或者真需要如此
  • 打赏
  • 举报
回复
简单说吧: 事件流是一个非常普遍的业务结构,应该单独设计。你可以设计这样一个(例如)实体结构
public class 时间窗口{
    public string ID;
    public DateTime[ ] 发生时间;   // 倒序的,只记录最近发生事件的时间
    public int 最大记录次数 = 20;
    public int 最多记录天数 = 70;
}
其结构基本上就是如此。 通常使用 NoSql 来存储这类系统,更新这类系统。并且至少达到每秒更新(保存)10万个时间窗口数据对象的水平。 当然你可能会在“发生时间”属性上做一些数据结构优化,例如预先分配2倍于“最大记录次数”的空间,并且用两个指针数字来表示数组空间中有效数字的起点位置和终止位置。这样就避免每一次填入新的事件时间时去重建数组。 基于时间窗口有很多业务算法需求。例如“当一只股票突破了5日均线,5分钟内又突破了10日均线,站在10周均线之上(比较站在10周均线之上和站在10周均线之下两个事件发生的时间大小),那么就赶紧买入。 我只是随便瞎举一个业务例子而已,不要当真。但是这种系统是真实的。当你监视100只股票,如果你是从海量数据里边查询(视图)去作为决策参考,那么你的决策效率就低了1000倍,甚至即使是电脑根本承受不住的。因此应该是直接从时间窗口系统中进行决策判断,而不是从原始数据去决策。
  • 打赏
  • 举报
回复
如果你是搞一个比较复杂的智能服务系统,例如交易或者游戏,那么甚至可能把时间窗口系统单独用一个纯内存数据库来支撑,而不用传统的关系数据库。
hercules135 2016-02-23
  • 打赏
  • 举报
回复
自己顶一下,大家都没做过成就吗?

111,128

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Creator Browser
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧