避难所小游戏全功能结构图

2024-02-28 14:34:56   1  举报





AI智能生成

避难所小游戏是一种休闲益智类游戏，其核心玩法包括建造和管理避难所，以及探索和收集资源。以下是功能流程的总结： 1.资源收集：玩家需要派遣居民到外面的世界探索，收集各种资源，如食物、水、特殊材质等。 2. 避难所升级：玩家可以升级避难所，扩大规模，提高生产效率和居民的生活水平。 3. 居民管理：玩家需要招聘和培训居民，分配他们到不同的工作岗位，以满足避难所的日常需求。 4. 科学实验：玩家可以研究新技术，提高资源收集效率，解决避难所面临的问题。 5. 挑战任务：比如抵御外敌、处理灾害等，以保持避难所的稳定和发展。避难所小游戏以其丰富的玩法为玩家提供了一个休闲娱乐的好选择。

游戏开发

游戏设计

游戏系统

作者其他创作

大纲/内容

申请挖掘（10201）

目的：根据配表的挖掘时间，开始挖地，需要占用建筑队列数和小人上阵。并添加一个定时器。触发定时器->挖地时间结束时，给前端推送挖地的刷新（主要是改变状态字段的数据）和小人回城，建筑队列数据的协议

挖掘时间：round(配表时间 * (1 - (0.25 * 人数)))

和其他功能相关的地方：1.为了方便前端对小人的统一处理（因为去挖地的小人就不能出现在建筑内，必须出现在挖地的地方），所以外出小人需要做上阵的处理。2.挖地会占据建筑队列。

需要注意的地方（bug): 1.这里添加定时器的写法，是拿到现在挖掘种最少的时间数，拿这个时间做一个定时器，等到这一个定时器结束时，检测全部挖掘中的地块，判断是否结束申请挖掘，然后再根据前面的方法加下一个定时器。这里需要注意，定时器的时间是否加错。 2.上下阵小人以及占用建筑队列的数据处理，是否和挖地的数据不一致。建议策划测试的时候注意离线的时候完成挖掘，看数据是否正确

做挖掘任务（10102，10203）

属性验证任务

根据配表判断前端传入的玩家是否能满足属性验证需求，满足就将状态改成2状态

todo:以后如果策划想新增一些类型的验证，现在只有属性和战力验证。就需要在对应的表和代码中加相应内容。room_dig_area 的check_cond or check 方法

战斗任务

开始战斗，战斗没有特殊处理。战斗胜利就把状态改成2状态，失败就把状态改成3状态

需要注意的是，这里有一个前端的表现，需要记录当前地块是否是第一次战斗，给前端的返回的状态不一样

无任务

会在申请挖掘定时器结束时判断，如果无任务，会直接变成2状态

完成挖掘，领取奖励（10204）

领取奖励，成功就把地块解锁，保存到已完成地块字段种，修改房间格子状态为可使用状态。失败不改变

-define(UN_FINISH_DIG, 0).          %% 未完成挖掘
-define(NO_FINISH_EVENT, 1).        %% 完成挖掘未完成事件
-define(FINISH_EVENT, 2).           %% 完成事件
-define(NO_FINISH_EVENT_BATTLED, 3).           %% 完成挖掘未完成事件且战斗失败过

小人基础信息

基因检测范围：有一个功能可以检测基因段，这里就用来记录已经被检测出的基因段。这个功能已经写完了，写过测试数据，但是基因检验室还没有弄，到时候弄房间的时候，把这边的字段对应过去就好

小人饥饿 soldier_hungry

需求：当小人饥饿时，根据规则，随机让小人离家出走一段时间。可能会随机获得物品或者重伤。代码不多，看注释就可

名字（10111）：只需要注意下小人是存在冷冻库还是小人列表中

属性：attr:calc_soldier_attr/2

装备和宠物：这两列功能很类似，都是获得装备。需要注意的点，就跟之前出过的宫斗bug一样，不要一口气获得多个数量的某物品id。异能的装备和宠物多了一个筛选，根据item表里面的shape_id。去hero_shape_data里面筛选对应的性别，对应的body_type (这个是基因里面随机出的body_type，保存在基因那边),判断是否能穿。
穿脱装备：10104，10105
一键穿脱装备：10128，10129
穿脱宠物：10112，10113

小人buff : 对应字段state.用来记录小人身上的buff

重伤buff

战斗失败扣到没血会获得重伤buff。小人有个每分钟的定时器，里面有对buff结束时做处理

饥饿buff

能量棒不够会获得饥饿buff

贤者模式buff

怀孕之后，会有一定时间处于贤者模式中。有这个buff就不能继续生育

血量：血量会根据时间，慢慢回血。根据配表每分钟恢复x点。但是没有真正的做到恢复一点推送一点给前端。一般只有重登，或者战斗之后，会推送最新的实时血量

npc_id字段：用来判断小人是否是npc

体力(10108)：类似血量，也是会根据时间恢复体力。但是也可以用药恢复体力。

技能：看小人基因那列

年龄

分为三个年龄段，幼年期，中年期，老年期. 在新增小人时，为了让小人年龄有些许差别。在中老年期加了一个随机年龄段（+-配表区间值）。逻辑在soldier:age_range(). 还有一些根据年龄计算年龄段的方法，其他的可以复用。

年龄是分阶段发给前端，所以不需要实时推送年龄的更新。包括小人老死，也没有推送死亡处理。有个要注意的地方，看策划是不是到时候需要做死亡推送，虽然暂时没有这个需求

复活（10106）：小人老死之后，可以复活成老年期。有个情况需要处理，假设小人老死在工位上，那么复活的时候，需要把小人变成闲逛的状态。就涉及到，要先复活小人，然后才能让小人从房间离开。如果小人离开失败，就会连续保存两次。感觉这里处理的不太好。但是还没找到好的办法。

返老还童药（10108），这条协议可同时处理恢复体力：扣除物品，恢复配表的年龄。需要注意的是，每个小人都有个随即年龄段，扣除年龄数的时候，记得加减对应的区间（age_stage）

等级

小人去可以工作的地方，可以获得经验。经验可用来升级

小人生育：在宿舍模块中详解

小人基因：决定小人的外貌和技能.

功能：对小人的基因列的增删改查.删除和查询感觉不需要特别说明，修改外貌就是当进入基因研究室（修改基因的房间，还没有对接，但是已经写的差不多了，后面有说明），取代了某个基因段，重新生成小人技能和外貌。

新增（特别说明）：分为两种。一种是引导或者任务赠送的小人。这些小人，策划们会直接把小人的外貌字段都填好。直接写进去就可以了。另外一种就需要根据基因规则生成。对应代码144行（create_new_gene).

基因规则：随机技能：把全部的基因id转换成[{基因id，num}]形式的基因列表. 再根据配表，获得符合的技能库，根据优先级，再根据概率随机技能id，一个小人最多不能超过3个技能。随机外貌：随机出一个性别（rand），然后根据性别，随机出body_type和body_id，然后根据根据配表和前面得到的基因列表。得到其他外貌id的随机值。

小小人规则：根据小人的身体字段的值，配表对应小小人的身体id.小小人的衣服根据小小人的身体配表得到。小小人的头的类型根据rand_list 配表获得

可能出现问题的点：策划配错表，前面基因规则，需要根据基因列表随机配表得到body_type和body_id。一旦配错表，容易导致后面根据body_type随机的数据全都报错

房间模块

冷冻库

移入冷冻库（10107）：要删除房间记录的小人列表

移出冷冻库（10119）

批量删除小人（10118，10121预览）：删除的时候要注意装备的返还，还有小人怀孕那边，如果有一方删除，要解除怀孕关系，并推送更新给前端

宿舍：soldier_procreate

小人怀孕

小人拖入房间时，进行判断是否符合怀孕条件。需要注意的点：小人怀孕的定时器也不是配对一个就添加一个新的定时器。是等上一个定时器触发后，又添加了下一个新的定时器。还有，登陆的时候，重新计算小人怀孕时间。

小人生育

过了配对时间后，点击就可以让小小人出生。小小人的基因规则是：先男后女，从父母的基因列表中，每个随机出50个。对应到不同的位置上。然后再根据基因规则，得到小人技能和外貌。小小人的基础属性attr_ratio,在soldier:calc_rand_range/3方法中。根据对应的规则获得。

需要捋捋的地方：生育后，小人会有一个贤者模式时间，小人处于贤者模式中，就不能继续配对。所以需要注意把小人一直放在宿舍中，看他度过了贤者模式时间后，是不是会继续重新配对生育。（现在的处理是，在小人那边有个每分钟都会调用的方法，do_auto_reply，在这个方法里面检测小人是否结束了贤者模式，然后调用配对方法进行配对）。

基因研究室（todo 做的差不多了的功能）：应该后面会开发一些查询基因序列的房间，以及修改基因id改变技能和外貌的房间。方法写在gene_mgr，gene模块了.只写了一些基础的改变外貌的方法。后续可根据文档进行修改

伤药工厂：注意一下小人加经验的判断，策划测过暂时没问题

抽卡

抽卡 + 神装抽卡：之前爱情公寓的模块。
现在异能学院暂时没用到，但是可以拿来一起写（11455-11464）

感觉需要修改优化的地方：之前的抽卡结构是，每次增加一种卡池类型，就要新增n个字段。
感觉这种处理有点麻烦。不如改成右图这种结构。

-record(magic_costume, { %% 勾选的物品 type = 0 %% {pos, base_id} , choice_list = [] %% 本轮获得得物品[{}] , send_pre_list = [] % 刷新时间 , refresh_time = 0 % 保底次数 , dozen = 0 % 累计次数 , count = 0 %% 奖励id , normal_reward = [] %% 使用钻石抽奖次数 , limit_count = 0 }).

抽卡主要逻辑:配表里面有一个当前卡池类型的保底次数，和一个到达指定次数就跳转到对应的保底卡池的次数。根据数据存的保底次数判断是否触发保底。
现在的卡池里面可以配各种类型，包括道具，和小人。小人只需要设定基因列表，传入基因那边就可以得到对应小人。

引导

一般都是帮前端记录跑了哪些引导。但是也有一些触发式的条件。需要推送给前端、

一个地方是，事件触发，配在guide_data的guide_cond表。根据触发事件，给前端推送条件id。引导这边的触发，看guide:callback/3方法

另一个地方就是，引导组结束之后，即完成引导组，后端的一些处理。

引导获得小人，soldier:guide_gain_soldier/4 (任务那边，结束任务也是调用这个方法获得小人)

还有接触某个引导组获得扣除物品 or 开始扣电量等设定。配置在guide表的complete_special。这里是特殊处理的地方。以后可根据策划的需求修改

激活

从之前由前端记录变成了后端记录推送。并拦截。查看activate:cfg/0 方法。激活方式：触发事件

学员任务：limit_task

分为两种类型任务

一种是，要求小人自己完成身上的任务，这种是调用handle_evt里面的check_finish_limit_task/3, 后面的第三个参数填写需要对比的参数

第二种，类似新增小人那种触发事件，需要遍历全部小人事件，判断是否完成。调用handle_evt里面的check_all_finish_limit_task/2

todo:没有跟前端对接，但是协议没变，应该没什么问题。具体的事件自己测过一遍了。策划还没有测。还有个需求是在刷新任务时,(0点和12点),判断一下玩家是否有没有领取的任务，有的话，直接发邮件给玩家。因为现在还没有邮件功能，所以还没有写。

需要注意的地方：刷新任务的时候，任务的发布时间尤其是离线重登的时候）

杂项

个人信息界面

发展度等级

有个需要注意的地方，关于小人更新发展度等级。现在是根据10002协议。判断是否需要推送新增发展度的特效。这里的逻辑处理是。后端根据当前role的fight值，和重新计算的最新的fight值判断，发展度是否新增了，如果新增了，就给前端推送10002协议。10002协议里面有个上次最高的发展度值和当前的发展度的值，前端对比这两个值，来判断是否需要播特效。
特别说明是这个播特效的地方，之前老出bug。不过最近没了

暂定是计算房间的发展度 + 小人的战力。这个会经常修改，我已经修改不下五次了。room_util:get_room_develope/1