来源：
https://blog.csdn.net/a526059967/article/details/89457864
写这篇文章的目的是为了记录一下自己根据老板需求设计的农场游戏【毕竟也是一点点积累起来的 =-= 】：（简单的种树领水果类游戏，本人初次接触并且从头开始到迭代多次的第一款算是自己实现的游戏）
简单的说，就是每天做任务获得水滴等道具，给果树浇水。果树成长周期达到并且收获后达到足够的数量即可兑换指定的水果一箱。
**大概分为几个模块：**经过了几次的迭代。现在写的是比较完整的并且已经在使用中的模块,其中，我个人觉得比较重要的都加上了*号，持续更新。。。一次没法都加完
*道具管理
主要属性：
*奖励
主要属性：
奖励规则：
奖励条件：
签到奖励
*任务奖励
枚举属性：
*任务属性：
重要点：任务的查看和完成。
*果树/鸭子
主要属性
通知
留言
百科（答题、阅读）
库表设计
效果图
*道具管理
将最基础的可获得的物品设计为道具并且可以录入（用于各种奖励的物品选择）。其中，道具有自己的id和type。type可以用于分类（大类），可用于后面奖励的type随机等。id则用于确定道具其他属性和使用的效果
主要属性：
额外属性： 属性格式：id，code，value
（这个用于将一些特殊属性拆分出来，其实成长值也能，但是太麻烦了， =- =） 旨在根据code将特殊属性拆分（code这里用枚举，在使用和校验中会比较方便），并赋予其特殊处理值value。这样属性的扩展比较友好一点，比较不容易出现冗余字段。基础道具我都是做缓存存储，如有额外属性，并将其直接填入对应的道具属性中。
拆分出额外属性的好处： 1.减少字段冗余。2.可重复利用属性。**缺点：**设计和处理较扩展字段麻烦。
简单的说一下项目中道具的用途：1.增加成长值。2.翻倍浇水成长值（时间段内）3.增加结果
4.根据特殊type确认作用，如兑换其他道具等。
*奖励
这个也算是抽象的比较好的一个模块吧。主要分作：奖励规则，奖励条件（根据某些条件选取奖励），游戏中大部分奖励都是基于奖励规则来，然后条件拆分出多种模块（因为大部分条件都不同，所以设计了不同的逻辑表来实现）
主要属性：
其中道具类型有两个特殊的。高级种子和鸭子。这两个不属于基础道具用于如种树需要先有对应的种子。
奖励规则：
基本上，游戏中大部分的奖励，都是从此规则中来获取对应的奖励。奖励规则目的是为了确定奖励的物品，设计的时候，每条规则对应一种单物品。必要的字段：
物品id/种类type（用于在type内随机）
数量/数量范围
特殊标识：这个是用作标识特殊属性，如种子、鸭子、水果订单等。非基础道具需要特殊逻辑的。否则都是统一操作
奖励条件：
奖励条件大部分都是根据需求来，如设计时间段内，可获取礼包里面奖品有一定概率获取（对应奖励规则）；种树得奖励；点赞兑换奖励；答题奖励；任务领取奖励等。。。也可以绑定多个奖励规则，并且单独设置获取概率。此处可以用上我的概率工具类
概率抽奖工具类（支持概率大于100抽奖）
签到奖励
设计支持设置自定周期内每天有不同的奖励
id，天数，峰值（用于达到峰值从最低循环），奖励id
签到表：id，user，last_sign_day，continue
其中可以根据最后签到日期和持续天数来判断此次签到
*任务奖励
任务这块也是大块的逻辑，因为其中的需要获取的动作大都不同，太分散。所以我只能对其中的校验做抽象，还没有想到一个比较好的方法：目前的方法，使用code+java枚举区分任务类型，其中，枚举中code对应的业务逻辑是固定的，但是条件/奖励都是不固定的。
从完成任务角度分，可以分成两种：前端判断/系统判断；前端判断即看xx60秒等；这样设计需要多一层校验，避免了使用code直接完成任务。以任务属性+枚举基础属性来实现任务的完成。
枚举属性：
根据需求，又将任务设置多种属性，通过对应的枚举。枚举属性相当于默认且固定的属性，不能更改却又涉及逻辑的属性。
历史累计：否，则算是当日任务
系统判断：是否是后台判断，后台判断不可用接口完成任务
是否需要数量：如果true，则需要校验触发该事件的次数，历史累计默认true
*任务属性：
数量条件： 需要xx次完成任务，当枚举数量true
时间段： 在xxx到xxx时间段内，可以完成任务
限制次数： 表示每日可以完成任务几次
冷却： 如果每日可完成多次，则间隔xx分钟
奖励： 选取奖励规则
重复完成： 这个可以加，但是目前没有需求。可以限制这个任务完成（限制次数）后，隔天无法再完成
因为任务大都有不同的完成条件，所以我分成两种code，一种是下单code（可重复使用），非下单code每种code都表示了不同的业务条件。
重要点：任务的查看和完成。
这边任务除了奖励基本都是做缓存，包括操作次数记录（使用code+用户）下单的可以再加id做key。
查看： 查看任务时，校验code对应的枚举是否有数量，如果有，从缓存中获取数量。
完成： 完成时，将要数量的做了抽象处理，其他的都直接增加完成记录
1.查任务
2.查操作次数，每步满足了才往下走。当完成了。
2.1增加完成记录（完成记录可领取，领取后才有奖励。每个code+id完成任务同时只能存在一个，也就是说，同一个任务必须领取了，才能继续完成）
2.2推送，用于通知前端刷新任务数据等
3.增加次数
*果树/鸭子
果树在我们项目中算是最主要的业务：简单描述，就是有多个阶段，在收果时如果足够了就可以兑换指定商品；鸭子类似
果树又有土地区分，所以设计了土地–果树。土地有限制在其上种多少数；
主要属性
兑换数量：果树需要多少果实才可兑换
最大偷取：果树结果后，在主人还未收取前可以偷取。单次最多可偷数量
果实剩余：果实被人偷取后，至少剩下多少
收果延迟：成熟需要有收果延迟，才能实现偷取
所属土地：标识所在土地
兑换水果：指定兑换时换取的水果
过季范围：水果过季后，可代替兑换的价格范围
阶段： 为了录入方便和计算方便，结果期采用循环，摘果后清空成长值，继续结果期，直到兑换。
需成长值：需要xx成长值进入下阶段/结果
是否结果期：如果是，则成长值满后，延迟后结果
结果数量：
通知
发布一些系统通知
留言
为了避免处理一些敏感字符，直接采用模板留言方式，类似蚂蚁森林留言。
百科（答题、阅读）
答题： 百科答题中，设置答题数目，随机从题库中筛选同数量题目，题目有单选或者多选，答错后显示对应的解析。答题可以设置阶段，答题结束后获得阶段最高的奖励。
阅读 设置一些知识百科普及知识，增加对应的水果链接直接链接到商城
库表设计
g_prop 基础数据表
id 道具id
name 道具名称
type 道具类型：0水滴 1果篮 2爱心值 3化肥 4点赞数 5剪刀 6鸭食 7鸭蛋 8虫 9草 50高级种子 51鸭子 100果树成长值 101果实 200鸭子成长值
base 成长值
use_type 使用类型：0果树1鸭子
has_arrtibute 是否有额外属性
description 描述信息
g_prop_attribute 基础数据附加属性表
id
attribute 属性code
value 属性值
prop_id 对应的道具id
g_prop_user 用户道具表
id
user 用户id
prop_id 道具id
prop_type 道具类型
num 数量
g_reward_rule 奖励规则表
id
name 奖励名称
is_range 是否有范围true（max，min）false（num）
max 最大值
min 最小值
use_type 类型随机
prop_id 道具id
prop_type 道具类型
goods_id 水果id
spec_id 规格id
g_task 奖励规则表
id
name 任务名称
icon 图标
info 任务描述
sort 排序
code 任务代码（重要）
del_flag 是否禁用
limit_time 次数限制
reward_id 奖励规则id
time_interval 多次完成的时间间隔
use_time 是否使用时间段
start_time 开始显示时间
end_time 结束显示时间
num 数量条件，当code特殊时需要
other_json 特殊code需要，其他json字符串如不需要用于关联，排序等复杂型数据。如时间段登陆奖励json [{“start”:“10:00:00”,“end”:“12:00:00”}]
g_task_finished 用户完成任务表，(用于校验任务限制次数和防止多次领取)
id
user 用户id
been_receive 是否被领取
task_id 任务id
task_code 任务代码
create_date 创建时间
g_login_reward 登陆奖励
id
day 持续登陆天数
reward_id 奖励规则id
is_last 结尾循环
题库随机：mysql使用RAND()函数做随机数排序，再使用limit取题数
g_answer 百科答题
id
type 单选、多选
info 答题解析
exercise_problems 问题描述
g_answer_option 百科答题选项
id
answer_id 题目id
text 选项文字
is_right 正确答案
g_answer_option 百科答题阶段奖励
id
num 数量
reward 奖励规则id
g_knowledge 百科知识
id
title 标题
text 内容
link 关联的链接
goods_id 关联的水果id
g_friend 好友列表
id
main_user 自己的id
friend_user 朋友id
create_date 创建时间
g_praise 点赞记录表
id
user 点赞用户
effect_user 被赞用户
create_date 创建时间
g_praise_exchange 点赞兑换表
id
num 需要数量
reward_id 奖励规则id
惊喜礼包：每日从规则中选取启用的模板，检查未创建日规则的模板创建对应的每日奖励规则，可查看每日用户领取奖励记录等。
g_sys_reward 惊喜礼包规则模板
id
loop_type 循环类型:0自定时间段1日循环
start_time 开始时间
end_time 结束时间
enable 启用/禁用
create_date 创建时间
g_sys_reward 惊喜礼包每日奖励规则
id
sys_reward_id 模板id
loop_type 循环类型，同上
start_time 开始时间
end_time 结束时间
create_date 创建时间
g_sys_reward_goods 惊喜礼包奖励内容
id
day_id 奖励模板id/每日奖励规则id
reward_id 奖励规则id
probability 抽中概率
num 数量
reward_num 中奖总数
left_num 中奖剩余数量
create_date 创建时间
g_land 土地类型表
id
name 名称
tree_num 土地可种果树数量
g_tree 果树表
id
name 名称
icon 用户头像上使用的小图标
seed_icon 种子图标
goods_icon 果实图标
fruit_num 兑换水果需要的果子总数
exchange_spec 指定兑换规格id
exchange_fruit 指定兑换水果id
price_min 过季水果区间最低价
price_max 过季水果区间最高价
delivery_info 配送信息
tree_info 果树信息
hide_seed 种子是否可见
land_id 土地id
type 种子类型（0普通种子1高级种子）
receive_delay 收果延迟，当果子结果后，需要等待延迟时间后才能摘取
steal_max 单次可偷最大数量0~max
min_left 被偷时最少剩下的数量
can_use 是否可用，当激活时检查数据完整性
g_tree_language 树语表
id
msg 消息
is_stage 阶段显示
stage 阶段号
g_tree_stage 果树阶段表
id
tree_id 果树id
stage 阶段编号
name 名称
energy 满成长值所需能量
can_harvest 是否是结果期
get 结果数量
own 自己可摘个数
stage_image 名称
g_tree_user 用户果树表
id
tree_id 果树id
user 用户id
growth_value 当前成长值
receive_order_id 兑换订单id
is_receive 是否已经领取了，当未铲除，还是可见
is_eradicate 是否已经铲除
need_take 是否可以收果
can_receive 是否可以兑换
receive_time 兑换时间
obtain_fruit_num 可摘果树/可偷数
friend_can_obtain 好友可帮摘果数
fit_num 施肥增产数量
fruit_time 结果时间 可摘果/偷果时间=结果时间+延迟
create_date 创建时间
g_tree_prop 果园道具表
id
tree_user_id 用户果树id
push_user 放置用户
tree_user 果园用户id
type 道具类型（0虫1草）
create_date 名称
g_leave_msg_template 留言模板
id
msg 模板文字
icon 表情
g_leave_msg_user 用户留言表
id
main_user 留言用户
tree_user_id 用户果树id
template_id 模板id
create_date 创建时间
g_planting_reward 种树奖励
id
type 奖励类型0注册奖励1土地奖励2指定果树奖励3普通奖励
land_id 土地奖励对应的土地id
tree_id 指定果树奖励对应的果树id
reward_ids 奖励规则id 奖品，逗号隔开
function_type 0果树1鸭子
g_system_info 系统消息表
id
title 标题
detail 详情
icon 图标
start_time 开始显示的时间
end_time 结束显示的时间
效果图
个人觉得其实功能大部分都是跟着需求来，在实现的基础上再尽量进一步的抽象一下。更易于迭代设计才是比较好的，防止需求延申时又需要维护旧数据。
————————————————
版权声明：本文为CSDN博主「迷失d_e章鱼」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a526059967/article/details/89457864