07 · 社交与元系统

〇为什么把这些系统归成一簇

核心循环(01)和养成(04)解决"在线密集反馈"和"中期收入爆发",但放置游戏真正的命门在后期:玩家把主线 60 城推到一定深度后,"换城重置"的新鲜感会衰减。社交与元系统就是专门钉在后期/长线时间尺度上的留存装置,有四个共性:

①俱乐部 Clubs(后期社交长线)

俱乐部要解决的问题是:给已经玩到后期的玩家一条"永远在涨"的社交进度条,并把它的奖励接回单人主循环。它不是排位竞技,而是一个异步协作的等级容器——一群人共同把俱乐部从 Lv0 爬到 Lv50,每升一级解锁一份奖励。

1.1 解锁门控

俱乐部配置字段:

设计取舍:6000 解锁 + 2001 露出 = 先让玩家看见、晚让玩家进。早期 5000 级别玩家会在 UI 里反复瞥见俱乐部入口却进不去,制造期待;真正开放时玩家已是付费/留存意愿都更高的"后期人群"。创建收 1000 钻是软门槛——筛掉随手建群、避免空俱乐部泛滥。

1.2 等级与 XP 曲线

俱乐部等级数据字段 Level / XpToNextLevel / TotalXp。共 50 级(索引 Lv0–49,Lv0 起始无奖励,Lv49 满级 xp_to_next=0)。

曲线是典型的"前快后线性"软上限:Lv0–10 单级 XP 从 150 陡增到 2500(逐级 ×~1.4),Lv20 后增速放缓近似线性(Lv30=6400 → Lv49=8200,每级仅 +100 左右)。

1.3 升级奖励:回流单人养成

俱乐部奖励数据字段 Level / RewardType / RewardValue(double);另有 GetAllProfitMultiplier(level) 读取全局利润倍率。每升一级发一份奖励,奖励类型(俱乐部奖励类型,完整枚举 0–8):

枚举 俱乐部奖励类型:
  0=Gems    1=PetFood   2=AllProfit
  3=SmallBox 4=BigBox    5=PetBox
  6=ClubBox  7=EpicEgg   8=LegendaryEgg
# 这些奖励全部回流单人系统:钻石进通用货币、宠物食物喂养成(04)、
# 各类宝箱掉装备、史诗/传奇蛋孵宠物。

最关键的回流是 AllProfit(全店收益倍率)——一个永久的全局利润乘数,直接接到主循环每单收入上:

AllProfit 共 15 档,从 Lv2 的 ×1.05 起,每隔几级递增,到 Lv47 达成 ×2.0:

1.4 服务器侧机制

以下俱乐部机制客户端无配置,由服务器驱动:

1.5 升级判定伪代码

# 俱乐部升级（异步协作：所有成员贡献 XP 累积到俱乐部）
玩家贡献(club, xp):                         # 贡献来源服务器侧（捐献/活跃）
   club.totalXp += xp
   while club.totalXp >= 俱乐部等级表[club.level].升级所需经验:   # 查等级表
      club.level += 1                                                # 升级
      reward = 俱乐部奖励表[club.level]                           # 取本级奖励
      发放到玩家(reward.type, reward.value)                           # 回流单人系统
      if reward.type == AllProfit:
         player.globalProfitMult = reward.value      # 永久全局利润乘子，接主循环收入
      if club.level >= 49: break                      # Lv49 满级封顶（xpToNext=0）

# 解锁门控（主线进度逐个开侧系统，见 02）
if restaurant.id >= 2001: 显示俱乐部入口            # _showRestaurantId 预告
if restaurant.id >= 6000 and 花费(1000钻): 解锁创建  # _unlockRestaurantId + _clubCreationCost

②成就 Achievements(全周期目标埋点)

成就要做的是用一张表覆盖全部系统的"行为目标"——让玩家无论在玩哪个系统(经营/装备/活动/宠物/公会),都有一个"再做 X 次就解锁下一档奖励"的隐性驱动。它是贯穿整个生命周期的目标埋点网,和俱乐部(钉后期)不同,成就从新手期就开始计数。

2.1 数据结构

成就拆在两张表里、按下标一一对应:

• 目标定义 成就配置(44 条):Name / Type(0–4 大分类) / 解锁门槛(餐厅 ID / 工位 ID / 厨师等级解锁条件,-1=不用) / Condition.ConditionType(目标 tag) / Condition.PrimaryTargetValues(10 档递增目标)。
• 奖励定义 成就奖励配置(44 条):字段 StarReward(每档授予的星星,固定 1/2/3/4) / GemRewards(List<int>)(10 档对应钻石)。

每个成就 = 10 个档位逐档解锁;每完成一档给 StarReward 颗星 + 该档钻石。奖励 = 星星 + 钻石。

2.2 覆盖维度:44 成就跨 5 大系统

Type 字段对应游戏内成就分页 Tab:

2.3 奖励数值分布 (rewardsDict)

星星 StarReward:每档授予 1–4 颗,全部 44 成就满级(每个 10 档)总星星 = 770 颗。分布:

钻石 gemRewards:单档 1–180,全表 440 格总和 12,135。钻石只用 5 套递增模板按价值分级复用:

钻石逐档单调递增且后期加速(各档全表列和 207→3015,越高档回报越大),是典型长尾激励:前档便宜易得维持高频反馈,后档昂贵稀有钓住硬核玩家。

2.4 解锁判定伪代码

# 成就逐档解锁（全周期后台计数）
玩家行为发生(actionTag, amount):                  # 任何系统的行为都打 tag
   for ach in achievements where ach.conditionType == actionTag:
      if not 满足门槛(ach): continue               # Restaurant/Station/ChefLevel 门槛
      ach.progress += amount
      while ach.progress >= ach.primaryTargetValues[ach.tier]:   # 10 档逐档判定
         发放(star = ach.starReward)                # 固定星星（1~4）
         发放(gem  = ach.gemRewards[ach.tier])       # 该档钻石（rewardsDict）
         ach.tier += 1
         if ach.tier >= 10: break                    # 满级 10 档封顶

# 特例：限时类目标"越小越难"，PrimaryTargetValues 递减
#   CityTime 30→5 分钟 / NightmareTime 300→10 / RaceRankTimes 名次 9→1
#   EarnCash 仅 9 档（数据本身如此，画图/解析需特判）

2.5 二级系统:成就 Pass

成就段位数据:把累计星星(共 770 可得)再转化成10 个段位的双轨奖励,每段含 FreeRewards(免费轨)+ PassRewards(付费 Pass 轨)。这是把成就星星变现的一层——全量段位与奖励如下表:

10 段星星门槛合计 710,略低于全成就总池 770,留有约 60 星余量;免费轨钻石合计 6,085、Pass 轨合计 30,425(约 5 倍),付费轨还独占宠物宝箱与传奇/终极级装备(Pet_ManekiNeko_Legendary、Pet_Gnome_Ultimate)。数据结构中另有永久倍率、免广告、装备槽等奖励字段,但本版数据全部为 0/空,未启用。

③家园 HomeMeta(独立锤子货币的收集轴)

家园 meta 的角色很特殊:它是一条和主线金币完全解耦的、纯收集向的侧进度。玩家在主线餐厅购买/升级时会掉落锤子 Hammer,锤子只能花在家园装修上——这给玩家提供一个"和数值爬坡无关、纯外观满足"的副目标。

3.1 机制与数据

家园装修项配置:5 个装修项 × 5 级,升级货币 Hammer(锤子)。

成本曲线项内逐级翻番、项间起步递增:每项 Lv5 大致是 Lv1 的 20 倍,5 项起步从 5 递增到 25。全满 = 2,890 锤子(5 项累计求和)。

3.2 关键取舍:纯装饰 sink,零回流

家园装修项配置只有 3 个字段:Key / DisplayName(LocalizedString) / Levels(int[]=锤子成本),无任何 reward/profit/boost/multiplier 字段;存档只存 Index+Level。锤子是单向流入:主线餐厅购买掉锤子 → 花在家园装修 → 仅改变外观,零数值反馈。

3.3 升级伪代码

# 主线购买掉锤子（单向流入）
玩家在主线餐厅购买/升级:                    # HomeMetaSetupHammerRestaurantBuyRewardSystem
   player.hammers += dropHammers            # 数额服务器/掉率侧

# 家园升级（纯锤子 sink，无奖励发放）
玩家升级装修项(item):
   cost = 家园装修成本表[item][item.level]   # 查成本表
   if player.hammers >= cost and item.level < 5:
      player.hammers -= cost
      item.level += 1
      更新家园外观(item)                     # 仅视觉，无 boost / 无产出 / 不回流主线

④排行榜 Leaderboard(竞争留存,多服务器侧)

排行榜提供社会比较驱动的留存:全球榜(GlobalLeaderBoard)让玩家看到自己的城市/餐厅进度排名,竞速活动(RestaurantRaceEvent,见 05)按名次发奖。它把"数值爬坡"转成"和别人比"的动机。

4.1 数据:核心在服务器

排行榜配置客户端只配了 2 个连接参数(无其它字段):

其余 16 个 leaderboard 相关类(GlobalLeaderBoardEntry、RestaurantRaceLeaderboardEntry、LeaderBoardRewardsPanelView 等)全部是纯 UI View:只有引用与布局,无任何榜单奖励数值。竞速榜的 _reward 字段也只是 UI 指针,不含数值。

⑤玩家·好友(UserProfiles / Invite / CharacterInvite / FollowPlayer / Auth)

这组系统支撑社交留存的最外层:玩家档案展示、邀请助手、关注其他玩家、账号鉴权。它们的共性是——绝大多数是服务器侧逻辑,客户端几乎无数值配置。本节逐一诚实裁定,避免编造。

5.1 逐项裁定

客户端配置交叉核对:

5.2 CharacterInvite:唯一的客户端数值

邀请配置("装扮自己的角色被别人邀请"玩法,单位秒):

奖励来源为引用装备宝箱配置(装备宝箱)——具体掉落表在装备系统(04),不在此处内联。

⑥本篇小结:社交/元系统的共性取舍

回到 00 总览 的根本取舍——这五个系统都是"后期/长线留存"的不同切面,且都遵循同一套设计原则:

5 · 社交是壳、单人是核 + 重逻辑放服务器:榜单/人数/捐献/邀请奖励/鉴权全在服务器侧——客户端只留 UI 与极简参数,换取实时性、防作弊、运营可远程调。多人实时交互很轻,符合放置品类定位。