qq_36790074的博客

这个系统算是所有系统的基础系统，不管是奖励的发放、还是其它业务，都是通过背包来工作的，但是不建议所有系统跟背包进行强关联，否则系统后期会很难维护，就像我们前期为了省事，考虑可能出现的各种交易，将所有的系统DbId跟背包关联，导致后期背包中存在很多无用的数据，而且一个数据存储在两个地方，本身就是违背设计的，但是由于各种原因，我们还是做了，希望大家做的时候想清楚，当然如果遇到一个喜欢应付的合作对象，你会发现，不管你怎样说他总有理由 ^ ^理论上，我们希望，减数据的时候先减 同itemId中 数量最小的；

申请添加好友的人，动态的修改好友的数据,当然好友在线的话，可以给好友发一条消息，好友在线修改添加，如果离线，我们采取的方案是直接给这个好友添加数据（注意理论上这里会出现，玩家A修改玩家B的数据，玩家B此时刚好上线获取，发现拿的是老数据，导致数据错误），不过这个问题没有被提出来，是后面我自己分析出来了，后面跟做的人说，他感觉这个问题先这样，我相信大家都碰到过这种情况 ^ ^。这种设置可以只修改自己的数据，黑名单可以直接在表里体现，申请状态也可以直接在表里体现，可结合业务情况设计“好友申请”、“黑名单”功能。

另外，玩家上线后会获取很多数据，只是提示作用，获取完整的数据效率低，大部分情况没有实际意义，使用红点可以很好的解决这个问题，玩家上线时只推送一个数组，表示各个系统的红点状况，如果玩家需要深入查看，则获取详细的信息。一般来说项目前期，基本不会关注红点提示问题，后期提了需求后，做了一部分发现，每做一个模块都需要添加一个协议，不如设计一个系统统一管理这个问题；

奖励Reward系统设计

这个基本和系统邮件类似，就是奖励的获取建议，建议使用一个至少为byte的字段GotSign表示，如果后期存在 部分领取的情况，将这个字段分成几位，每一位代表奖励的领取情况即可。2.尽量不存储重复信息，比如同步的系统邮件，如果内容固定，个人邮件只需根据MailId即可获取邮件的内容，数据库不用再存储相关的内容字段，当然也要结合实际业务。1.直接获取全部的邮件内容，邮件数目多的时候会比较费，如果可以合理的控制邮件的过期时间，这个方案是可以的。所有人都可以接收的邮件，一般系统发放后，玩家登录时拉取。

这个主要是设置相关的业务触发类型，不同的业务设置不同的值，这里建议将类型至少设置为ushort, 太小后期会出问题 ^ ^这里建议将状态的枚举值设置的大一些，方便后期插入一些特殊的状态，要不然需要改许多已经写好的东西，踩过坑的都懂的为啥 ^ ^一般来说，当任务结束，也就是相应的条件完成，比如常见的主线、支线、每日、每周、委托、成就任务等。激活任务的条件id列表，满足则任务进入 Active 状态，否则 处于 Init 状态。完成或改变特定的条件，触发任务状态的改变，一般由各个系统触发；

实际上，会有很大的可能，玩家会加入匹配再退出，当然写完功能我们也会跑测试，假设我们加入匹配，但是突然取消匹配，但程序已经匹到玩家，这个时候我们就需要处理很多状态，最简单就是，搜索清理所有数据，但这个会把所有任务暂停下来，可想而知，代价是很大的，当上百万人同时取消；3.在每次开始 主流程时 可以记录一个状态，当中间有玩家退出时，改变这个 状态，只有在 主流程开始到结束，这个中间 所记录的状态 依然为每次开始时标记的状态，才清理过期数据，如下代码。1.进入下一个流程，匹配队友，或匹配对手。

由于业务需要，灵活的，交易等原因，目前我们将很多不属于背包的功能放入背包，起初感觉这样省了不少事情，很多东西的获取直接走背包就好，不用添加任何协议。