摸鱼之扉

此处即是深埋于互联网角落的幻想乡，日升月沉，星河流转，草木枯荣，四时不息

楔子

四个时辰后，便是三十四岁了。作为一名码龄二十余年的程序员，多年来一直在温饱线上挣扎，鲜有写作。蓦然回首，前半生毫无痕迹，满是遗憾。

摸鱼之门

PO自小学拥有第一台学习机开始，逐渐经历了SFC、MD、PS1、PS2、PS3、PS4…诸多次时代家用机、街机平台换代，热衷于各类复古游戏。尽管在学生时代也曾与同学玩过一些PC网游，却始终无法沉溺其中。时至今日，如同爵蜡的手游更加难以让我提起兴趣，何况常年996早已将原本不多的游戏时间压榨到极致。近十年时间，除了香草社的十三机兵防卫圈，都已记不起还有曾通关过哪款游戏了，哪怕是那些中古主机游戏。

如果说沉湎于过去的游戏只是怀旧，刷遍Steam也鲜有游戏能够让我快乐，那么，就只有自己动手了。 在无法逃离的996和生活琐碎的夹击之下，能够利用的大概也只有卑微的摸鱼与通勤的碎片时间了，利用好摸鱼时间，构筑出一块能够让我快乐的渺小世界，余愿足矣。

这个利用摸鱼时间打造摸鱼世界的摸鱼项目，自然会被命名为——摸鱼之门。

摸鱼企划

从今往后，PO会在简书与个人博客上看心情偶尔更新一些随笔，除了无病呻吟之外，更多的应该是从零开始记录《摸鱼之门》这块尚不存在的虚拟世界构筑过程。

1. 游戏类型

因为摸鱼时间大多是在A站的某个⑨课涂鸦群划水，难免会有想和群友一起摸鱼玩两把小游戏的想法，因此游戏必定是支持网络的，但现实是，要凑齐一起开黑的朋友，实数难得，因此能够单机独自玩耍必不可少。游戏模式大概会参照PO比较喜欢的中古游戏玩法，例如 FC 红白机时代的半熟英雄，但在战斗上会想增加一些微操，使之更像是卡普空吞食天地II街机版的爽快手感，大致就是这样一款可联机、可单机玩耍的4399小游戏级别摸鱼作品了。

1.1 游戏视角

游戏将会以玩家的个人角色为主要时间，可自由探索寻访NPC角色作为队友，整个队伍最大7人，战斗时仅操纵1人，但可任意切换，其他6名角色将按玩家自定义的战斗策略交由AI控制，与AI共同作战。后期也会逐步实现并优化玩家联机。

1.2 战斗模式

战斗模式采用横版卷轴多人战斗系统，硬要说的话类似三国群英传，但又不是那种无脑推兵，最终制作出来的效果应该更像是卡普空的吞食天地2街机版的效果，个人比较喜欢爽快的2D横版卷轴动作游戏，因此这将会是主要的战斗模式。

2. 游戏平台

时值2021年8月30日，比特币的价值再创新高，单枚价格在5W美金左右反复横跳，相信未来在很长一段时间内，都无法用上新一些的显卡了，因此游戏将采用3D技术2D视角来搭建整个世界观，以能让办公室的核显也能愉快运行为基准目标，考虑到通勤的碎片时间，移动端的支持必不可少，初步支持计划如下：

3. 技术路线

既然决定要做跨平台了，那么就将整个技术栈都确定下来吧。

3.1 图形引擎

目前跨平台游戏的主要技术有两种，一种是使用JavaScript、TypeScript等脚本语言以HTML5 Canvas / WebGL 技术为主由浏览器渲染的跨平台游戏，另一种则是使用 C/C++ 或是 C#、Java 等面向对象语言基于 OpenGL、DirectX 等传统图形技术主开发的本地游戏。显然，PO打算使用后者，即便这是个4399小游戏。

虽说打算使用C++来开发“摸鱼之门”，但也不能真的去基于OpenGL、DirectX开发游戏，因为跨平台移植所带来的工作量是在是太大了，利用业余时间来开发，显然是不明智的。本地渲染的跨平台图形库有很多，例如基于SDL2的OpenBOR，也有 Cocos2dx、Unity3d 、Godot 这类简单易用的跨平台游戏引擎，PO也曾粗浅的逐一把玩过。只不过这一次，PO决定选择更为小众、也更加单纯的图形库 Firemokey。

严格来讲，Firemonkey 甚至不能算作是一款游戏引擎，它只是基于 OpenGL、DirectX、Quartz 技术做了一些封装，节省了一部分图形程序的移植工作量，可以让程序员方便的在不同平台显示图片而已。但是做游戏么，不一定非得有引擎，何况是“摸鱼之门”这种脚踩西瓜皮，想到哪里滑到哪里、需要高度定制的4399小游戏。换言之，接下来的时光里，PO 需要利用图形技术造一个游戏引擎。

3.2 网络协议

近期，网络上出现了大量台湾骇客针对独立游戏制作组的恶意勒索攻击，作为个人开发者，尽管无法抵挡海量的 DDoS 攻击，但从协议上，可以稍作考虑，比如摒弃国内独立游戏开发者最爱的 HTTP、WebSocket 协议，直接采用底层 UDP 协议来开发这个项目、基于二进制协议进行通信，尽管开发难度直线上升，但会带来更加优良的游戏体验。

3.3 核心架构

PO就职于某物联网企业担任研发部门主程，全栈开发十年有余，比较擅长开发高并发的多用户系统。尽管开发网游的经验为零，但是想来也不会太难。既然是小型网络游戏，数据库的选型也比较容易，持久化数据采用传统的SQL数据库，实时数据采用自己移植的改版NoSQL数据库做为高速缓存，提高多人游戏的交互响应速度。服务端采用自研的分布式软件总线技术构建，其底层基于是Socket协议实现的RPC技术，能改轻松的构建分布式系统，将来游戏的服务端可以直接热更新，无需重启服务器。关于该技术之前曾在B站录制过一段演示视频。

自制软总线： 分布式微服务框架演示

只有三分钟的热血，最终究能够支持自己走多远？我也想知道

2021年8月30日 20:48