好奇 V 站的游戏服务端开发小伙伴多不多

[Joey2022]

本人是一名四年工作经验的游戏服务端开发，有时候会感慨游戏服务器的技术栈陈旧，每家公司基本上都有自己的一套或者几套传家宝似的底层框架，而与游戏服务器开发相关的论坛比起互联网端更是少之又少。 所以有时会渴望和同行业的前辈们交流。 希望有在此行业里打拼的小伙伴们冒个泡呀。让我知道我不是一个人哈哈

[Joey2022]

亦或者是游戏开发的客户端伙伴，甚至是对游戏开发感兴趣的朋友，也可以踊跃发言~

[Joey2022]

也希望佬们可以推荐一些有意思的游戏开发相关的 blog

[pointerman]

现在游戏行业是不是没经验简历看都不看一眼

[sunny352787]

没错，游戏这边确实爱用旧架构，稳定快速出活儿。架构好几年不变太正常了。啥时候你当主程决定技术栈的时候就可以用点新东西。

[kiracyan]

反正我感觉每个公司的都不一样

[kiracyan]

我司的游戏网关服务器少说有 20 年历史了

[zuosiruan]

我司的游戏后端的那套 c++也就 10+年吧

[myxingkong]

OP 有没有听过 “仙剑修”，我现在还在改二十年前的游戏客户端\服务端代码😂

[hwdq0012]

dx 群里看他们 cpp20 都库库上 协程 反射
我制造业还在 ubuntu16 + gcc5.4

[Lockroach]

目前国内游戏服务端的主流技术栈和国外的分别是什么？

[choiceice]

三年客户端，已经是 UE 的形状了 hhh

[p1gd0g]

6 年游戏全栈，这个圈子确实太封闭了，每个公司自己搞一套。

[jackOff]

之前去过三家，第一家的项目架构研究大半年得出结论，服务端代码就是 0 几年网游页游的 java 后端代码，原始版本的 spring 架构(魔改屎山)+mysql 存储过程(屎山)+mina 通信+memcached(数据库缓存+同一个机子不同实例对象的共同缓存)+redis(排行榜积分)+表结构代码生成框架(强制性拉平所有人代码风格)+hibernate+unity2d ，这套架构吃了十来年，非常稳定，就是网游这种东西改成手游画质也是一言难尽，属于非常公式化的氪金手游模板项目


第二家抽象了，spring 全家桶，看起来像是直接魔改商业版本的 web 项目改的，mybaits(xml)，mq 通信，redis,unity3d,其他的记不清了，这一家技术储备比较差，项目 bug 很多，我进来挑太多 bug 估计也得罪人了，但是因为 bug 太多导致公司很快就解散了。

第三家技术力最强，游戏非常稳定，也是这几家里最好玩的。是 3d 的 moba 类对战游戏，c++程序员写前后端,unity 和 java 后端都是一个人写的，唯一的问题是全部代码没有任何注释，没有文档，全局变量随处写，java 写的和 c 语言似的，结构体都整出来了，数据库里随处可见的 arr1,arr2,arr3 这种莫名其妙的东西，估计是个人 carry 全部项目后的自由风格，反正一直看不明白项目写的啥玩意，但是的确很佩服这个项目的负责人，虽然完全从这个项目里感受不到任何程序设计之美，技术很杂很乱,客户端是 ue4 技术，和我玩 steam 游戏的感觉一模一样，后端是 mysql,redis ，memcached,kafka 还是 rabbitmq?一直没看明白这代码风格写的啥玩意，反正项目和人能跑一个就行。

总之，第一家是比较成功稳定的传统手游厂商，第二家技术储备不足，第三家非常创新大胆，敢于突破一切技术常识，尤其是在 ue 客户端开发上做了很多研究设计。

游戏性和画质是第三家最棒，第一家次之，第二家感觉像是魔兽争霸的画质

[way2create]

以玩家的角度好奇开发游戏客户端非核心玩法部分的那些操作设置之类的界面操作为什么感觉都完全不考虑简便性跟用户体验，是没时间优化还是无所谓纯偷懒还是别的原因？

玩过不少国内的端游手游这方面都很 shi ，有时候上线领个东西设置个东西都点的累死，要是点卡游戏还说故意耗费时间，有些不是的也是，完全没有非游戏产品的体验好，甚至还很感觉个别是为了方便开发强行搬不符合操作习惯的别的功能界面过来

[ggzhyipeng]

@way2create 还是有一些拉在线率的原因在，还有可能是资源不够去搞其他业务了，或者干脆就是因为策划能力不足，游戏策划这行业门槛低，但是做得好的没几个

[kepenj]

1. 游戏行业整体来讲就是周期短，需求量大。
2. 沾上这两点就不可能有大而美的框架/程序设计，全部都是拿来就用，能跑就行。慢慢的就会形成了一个公司一套系统，甚至一个项目一套系统的现状了。
3. 我之前公司的卡牌游戏全都是买的同行的，技术栈都是 10year+ ，除了卡牌项目组，其他项目组的游戏压根用不了买的那套。
4. 敢从 0 开始撸的团队/公司，要么不差钱，要么项目死公司基本也就黄了。

[zuosiruan]

@ggzhyipeng 同感，策划属于上限和下限拉的极大的职业的，另外混子非常多。

[anynull777]

使用 php + swoole 的游戏后端见过吗

[sunny352787]

大部分都是吐槽哈哈哈哈哈，那我说点有用的吧

目前的项目是卡牌，功能偏单机，只有部分功能会有玩家交互。根据这种游戏的特点，客户端 Unity 服务端 Go ，Http API+json 进行主要功能逻辑的通讯，外加一条 websocket 做服务器主动推送消息（跑马灯之类的），聊天接第三方 SDK 。数据库 MongoDB ，Redis 做缓存。服务间通讯用 GRPC 。服务器使用 docker 镜像，线上 k8s 无状态集群。

这个架构的好处是能充分利用云服提供的各项服务：无状态服务保证你负载均衡路由到任何一个节点都可以正常运行，并且干掉了传统游戏服务器的网关；使用 Mongo 可以不用过多考虑 MySQL 之类关系数据库的建表问题，随时加功能随时扩展字段； http+json 的组合让客户端自己写服务器逻辑，不用考虑 protobuf 的协议转换；我在 gin 当中封装了数据库操作使得这帮客户端不用操心 find 、insert 等，只处理 if else 就够了，对玩家数据的修改会统一做脏数据检测存盘，这样开发效率极高也没有前后端扯皮问题；日志不存盘，直接让云服去容器控制台捞就好了。

总的原则就是降低人员成本，无论是运维人员还是开发人员。运维只需要把内网测试完毕的镜像推到云上让 k8s 滚动更新，对玩家来说就是永不停服。负载均衡会把流量路由到合适的节点。分片 Mongo 性能也能保证，热点数据丢 Redis 缓存。开发人员只需要招几个 Unity 客户端，写客户端逻辑的时候顺手就把服务端写了，反正都是 if else 。当然这套架构服务端如果换 C#可能会更方便，但我个人比较喜欢 Go 所以就没和客户端统一语言。

[funcman]

不谈和 Web 服务器差不多的卡牌游戏的短连接服务端。MMO 游戏服务端，除了负载，最主要是有状态且要执行复杂的游戏逻辑。像守望先锋，基本上服务端要处理近似物理模拟的游戏逻辑。国内的大部分不太会去做这么复杂的模拟，但至少到后来也是往 WOW 的 cell 架构去做的。当然现在很少有网游是 MMO ，随便拿些 Web 常见技术也能用。
高并发、低延迟的系统，用常见通用技术很难做出来。