《fish》捕鱼印钞机，他连底牌都开源

游戏厅里最沉的那台机器，永远是捕鱼机。金鲨银鲨转一圈，八个座位的人盯着同一条鲨鱼开炮，金币哗啦啦往下掉的音效能盖过整条街。这个品类后来搬进手机，换了个名字叫“千炮捕鱼”，依旧是休闲游戏圈公认的流水怪兽。但个人开发者对它向来只敢远观：这不是一个小游戏，这是一套带联机的经济系统——房间、座位、金币、炮台倍率、爆率、抽水，每一环都写着“劝退”。

直到你翻开 dwg255/fish 这个仓库。一个中国开发者，用三个 Go 进程，把捕鱼达人的整套骨架原原本本摊在了 GitHub 上：账号服、大厅服、战斗服三服分离，WebSocket 联机，Redis 记账，MySQL 存档，服务间 Thrift 通信。183 个 star 不算显眼，但论“一个仓库能学到的东西密度”，它可能是你今年能挖到的最划算的一座矿。

仓库档案

这游戏是什么

一句话：八个人围一张桌，各管各的炮台，打死的鱼按倍率爆金币。

它就是你在游戏厅见过的那台机器的网页版。服务端 define.go 里的数值表，就是这台机器的完整说明书：35 种鱼，倍率从 2 倍的小鱼一路排到 200 倍的金鲨级大鱼；4 种特殊鱼——四种“一网打尽”（打死它全场鱼一起爆，注释里还留着商业版 45~150 倍浮动区间的痕迹）、“全屏炸弹”100 倍、三种“同类炸弹”110 倍（打死一只，同屏同类全死）；炮台分 22 种，普通炮三档，VIP1 到 VIP6 每级三档倍率，外加一门激光炮；8 个环形座位，8 种鱼阵场景每 5 分钟轮换一次。

flowchart LR
    A[进房入座<br>携带金币] --> B[买炮弹<br>选炮台倍率]
    B --> C[瞄准·发射]
    C --> D{服务端判定}
    D -->|打死| E[鱼按倍率爆金币<br>小鱼2倍 大鱼200倍]
    D -->|打空| F[炮弹沉海<br>金币 -1]
    E --> G[赚了<br>想打更大的鱼]
    F --> H[亏了<br>沉没成本想回本]
    G --> C
    H --> C
    E --> I[金币雨全场可见<br>同桌看在眼里]
    I --> J[上 VIP 炮台<br>倍率 x3 x5]
    F --> K[金币见底]
    K --> L[充值或看广告<br>换金币再来]
    L --> B

注意这个循环里没有“胜利条件”。捕鱼没有一局终了的概念，它只有资金曲线的起伏——这正是它和几乎所有其他品类的本质区别，也是它被叫作“电子海洛因”和“印钞机”的原因。

为什么上头

即时反馈，一秒闭环。 开炮→子弹飞行→命中→爆炸→金币入账，全程一秒出头。相比之下俄罗斯方块的反馈周期是消行，RPG 是升级——捕鱼把反馈压到了人眼能分辨的最短刻度，多巴胺回路根本没有冷却时间。

变率奖励，两种糖轮着喂。 2~5 倍的小鱼密度高，隔着几秒就给你一次“打中了”的小确幸，维持手上的操作感；50~200 倍的大鱼几分钟才巡游一次，专门制造“全场屏息”的高光时刻。更狠的是“一网打尽”和“同类炸弹”这类连锁鱼——它们把一次命中放大成一场演出。老虎机靠转轮，捕鱼靠鱼阵，本质是同一套变率强化调度。

沉没成本，写进了弹道。 每发炮弹都是消耗品，打空就是真金白银地减少。“我都打了三十发了，这条鲨鱼肯定快死了”——捕鱼玩家嘴里的这句话，和赌桌上的完全同构。金币见底时最痛，而充值按钮恰好就在手边。

同屏攀比，免费的活广告。 八人一桌，你打爆金鲨的全屏金币雨，七个人都看得见。这一桌人里最近刚亏过钱的那位，就是下一发重炮最可能的射手。街机时代这叫“跟风下分”，放到线上就是天然的社交裂变——不需要任何分享按钮，金币雨本身就是传播素材。

数学上你永远差一点。 define.go 里躺着两个不起眼的常量：抽水比例千分之五（TaxRatio = 5），携带金币上下限（1~100 个底分）。前者保证系统每一笔成交都微利，后者防止大户一波掏空。再叠加爆率控制，玩家体感是“有输有赢、手气会来”，账面却是稳定向下的斜线。这套算盘在街机机柜里拨了三十年，如今原样躺在两百行 Go 常量里。

五分钟一次的新鲜感闹钟。 鱼阵场景每 300 秒轮换，8 种阵型轮着来。散兵游勇、龙卷风列队、鱼群过境——阵型一换，屏幕上的目标密度和打法就变，玩家刚产生倦意就被打断。这个“5 分钟”不是随便填的，恰好是一次“再玩一会儿”的心理时长。

技术拆解

这个仓库对个人开发者真正的价值，不是捕鱼本身，而是它用最小代价演示了“商业棋牌服务器”的标准刀法。

三服分离，棋牌公司的标准架构。 account 负责注册登录（配置里直接预留了 QQ 第三方登录）、hall 管大厅和房间列表、game 管战斗结算，三个独立进程，各配一个 .bat 一键启动，还有个 z-start_all_server.bat 三服齐开。大多数人写联机小游戏是一个 main.go 走天下，一旦要加充值、加房间、加机器人就搅成一锅粥。这个仓库告诉你业界为什么拆：账号数据要和战斗逻辑隔离，大厅要能独立扩容，战斗服崩了不能连累玩家资产。

通信栈一目了然。 客户端到服务端走 gorilla/websocket；服务进程之间走 Apache Thrift RPC；状态进 Redis（go-redis 和 redigo 两个客户端混用），账户落 MySQL（sqlx + go-sql-driver），HTTP 侧用 beego。这套组合是 2019 年国内 Go 游戏服务端的典型配置，拿来当模板毫无违和感。nginx 那段配置也写在 README 里：静态客户端直接托管，/qq 路径反代到 9000 端口——五分钟就能在自己服务器上复刻整套部署。

战斗服小得惊人。 全部核心逻辑就五个文件、不到 50KB：define.go（数值表）、fish_utils.go（鱼路工具）、room.go（房间状态机）、request.go（协议处理）、client.go（连接管理）。没有框架魔法，没有中间件迷宫，一个下午能通读。所谓“大型联机游戏服务端”，在这个品类里原来就这么点东西——因为捕鱼的状态同步极轻：鱼走预设路径，炮弹走直线，服务端只需要广播“谁开了炮、谁打死了谁”。

鱼的走位是回放的，不是算出来的。 服务端用 LoadTraceFile 从 JSON 轨迹文件加载每条鱼的路径表，鱼按预录轨迹游动。这是街机捕鱼传下来的老手艺：美术在编辑器里摆好鱼阵和路线，运行时原样回放。好处是致命的——所有客户端看到的是同一条鱼在同一秒的位置，命中判定天然一致，服务端甚至不用跑物理。

判定权在服务端。 金币就是钱，所以开炮扣费、命中判定、倍率结算、抽水，全部在服务端完成，客户端只负责表现。这套“客户端是皮、服务端是账本”的原则，是这个仓库最值得抄的一课。

能直接搬走的件：三服分离骨架、房间/座位模型、金币账户与抽水结算、WebSocket 广播层、Thrift 服务间通信、轨迹回放方案。每一个都是独立可复用的组件，跟你做不做捕鱼没关系。

变现观察

捕鱼品类的变现路径早就被市场验过千百遍，这个仓库的数值表就是路径图：

红线必须讲清楚：金币单向流动（只买不兑）是娱乐游戏；一旦能兑回现金，性质就变成赌博，国内是刑事红线，出海也要过 Google Play 和 App Store 的真钱审核。这套代码教你的是经济系统的构造，不是它的灰色用法。

这个仓库自己的变现痕迹很有意思：代码里没有一分钱支付逻辑，但仓库根目录躺着一张 100KB 的微信二维码 wx.jpg。作者的生意显然不在游戏内，而在游戏外——卖部署、卖定制、卖技术支持。这其实是开源棋牌圈的普遍生态：代码免费，饭票在群里。对个人开发者来说，这个信号比代码本身更值钱：围绕一套成熟骨架做服务，往往比做游戏本身赚得稳。

换皮铺量是这个品类跑通最久的打法：同一套服务端，海洋皮、太空皮、僵尸皮轮着换，在小游戏平台买量跑广告。门槛不在开发，在美术产能和买量账算得平。

给我的灵感

一、单机切片，一周上架。 把三服砍成单机：去掉联机房间，同桌换成 AI 玩家，命中判定搬到本地。客户端是现成的，重点工作只剩换皮和接激励视频。上微信小游戏或抖音小游戏，“金币复活”“看广告抽激光炮”两个点位就够跑广告变现。MVP 一到两周，是这个仓库最短的变现路径。

二、换皮出海，两三周。 保住循环、换掉皮肤：把鱼换成太空陨石带（大陨石=金鲨）、地牢魔物（BOSS=一网打尽）、甚至弹珠机台。倍率表、抽水、VIP 炮台整套平移，网页版挂广告，或做成 itch.io/Steam 的小体量付费产品。赌桌心理是跨题材的，这套数值骨架搬到任何“打靶得奖”题材里都成立。

三、抽骨架，卖水。 把 account/hall/game 三服结构、Thrift 通信、金币账户模型抽成与玩法无关的棋牌通用底座，接棋牌外包、卖部署服务。路径已有先例——仓库作者的二维码就是招牌。这条路的收入天花板不如爆款游戏，但确定性高得多，适合把它当副业 rather than 一次豪赌。