Golang 游戏开发框架选型

你写啥类型的游戏?

不同类型的游戏 实现差很多的。

看看 Nakama ？

@dcoder
@zhaoahui
主要是网络 & 日志 & orm & 分布式. 这几个点 不知道有啥可以匹配的.
游戏业务现在都大差不差了 看自己怎么设计

@paoqi2048 看了下 挺好的 提到了游戏. 下载下来看看
感谢

我用过 https://github.com/aceld/zinx
框架内置 go-kcp 用的是 kcp + fec
所以我魔改了个 cpp 的 kcp+ fec
目前用起来非常丝滑

另外啥游戏啊，招人吗？

@asuraa 看了下架构图 感觉有点意思 不知道实际用起来怎么样.

emmmm 暂时不招人了.

@ugpu golang 撸这种代码是真的快 一把梭，比 c 舒服，没有内存管理的心智负担

golang 的 orm 就一个 ent 能用,不过也是个残疾

游戏框架之前找过几个 golang 的,最后选了 pitaya,你可以看看

> 主要是网络 & 日志 & orm & 分布式. 这几个点 不知道有啥可以匹配的.

@ugpu

网络部分可以试试我的这个, 本质是个网络库, 游戏行业缺少统一的技术规范, 所以蹭热度用来 rpc 的名字:
https://github.com/lesismal/arpc
性能应该也足够用:
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/
网络协议随便你选, tcp,websocket,kcp,quic 各种, 只要实现 net.Listener 和 net.Conn 就可以了
client 只有 go 和 javascript, 其他语言如果自己熟悉这块自己实现一份也不难

golang 没有好用的 orm, 游戏业务的 sql 需求也不是特别大所以 raw sql 足够了, raw sql 确实有点麻烦, 可以试试我这个:
https://github.com/lesismal/sqlw
能省掉字段绑定的很多麻烦

日志:
随便选哪个知名的都可以, zap zerolog 之类的各种, 功能和性能都足够, 自己根据自己喜好稍微封装下细节就可以了

分布式:
除了 bigworld 那种大型游戏有相对固定的框架体系, 其他多数游戏都没有个固定的, 以上所述的几个点, 其实都算是脚手架. 但 bigworld 这种, 单位太多, gc 压力太大了, golang 并不适合.
其他的 fps moba 之类的, 都算是比较容易对房间扩容的, 匹配服调度下然后战斗服堆机器就可以了.
还有一些类型, 大型全球同服 slg, 一些 arpg 之类的挂机游戏, 或者其他一些依赖服务端做大量数学计算的或者服务端渲染的, 也都是需要自家定制优化.
而分布式本身, 抛开这些特殊的业务优化需求, 分布式主要是通信, 仍然是网络库在不同服务之间建立连接收发指令处理逻辑就可以了. 至于大概 10 年前一些 web 领域渗透到游戏里的技术, 例如服务注册与发现, 这至少二十年前游戏行业就有了, 集群里通常都有特定的服务承担特定的集群管理角色, 只是不像 web 领域那样技术栈通用和用户广泛所以没有那么被人熟知.
OP 没有提到我上面说的几种特殊业务类需要, 所以对于 OP 而言, 分布式的需求其实自己随便搞搞就行了, 比如用 arpc 随便写写就好了.

@asuraa #6
zinx 属于脚手架, 和其他几个早期开源的游戏框架类似, 都是比较简单的封装, 而且有些封装其实是垃圾封装, 既没必要, 又可能浪费性能.

刚简单扫了几眼 zinx, 举下例子:
比如 timer, 标准库 time 包足够用了, 四叉堆性能足够好, 而且精确度最高, zinx 里面自己用时间轮自己搞个没必要, 而且时间轮一是精度低, 二是如果想精度高就要更小的轮间隔, 则 tick 频率高空转有点浪费 cpu. 另外, 看代码实现, 作者并不太注意性能细节, 例如创建一个新的定时器, 多次调用 time.Now(), 而这本是可以只 time.Now()一次复用的:
https://github.com/aceld/zinx/blob/master/ztimer/timerscheduler.go#L79
https://github.com/aceld/zinx/blob/master/ztimer/timer.go#L71
https://github.com/aceld/zinx/blob/master/ztimer/timewheel.go#L137
https://github.com/aceld/zinx/blob/master/ztimer/timewheel.go#L96
https://github.com/aceld/zinx/blob/master/ztimer/timer.go#L58

再看下异步任务协程的吧, 讲真, 刚看了几眼, 之前没看过, 都没想到能写这么差.
固定 2048 个, 够不够用另说, 写死这个本身就是挺不可思议的设计了:
https://github.com/aceld/zinx/blob/master/zasync_op/async_op.go#L45
按 opId 取模作 index 取对应 worker, 业务层对 opId 可以各种定义, 模块 id userId 之类的, 如果大量任务的 hash 不均匀则会导致单个 worker 协程忙死其他的 worker 闲着, 任务调度分配不均衡, cpu 利用率和性能存在不稳定的可能:
https://github.com/aceld/zinx/blob/master/zasync_op/async_op.go#L53
https://github.com/aceld/zinx/blob/master/zasync_op/async_op.go#L67
而且就这个 getCurWorker()方法, 你都 array 了, 抛开上面说的调度分配不均衡问题, 考虑到满载性能利用, 还不如启动阶段创建好都跑起来, getCurWorker()直接就 index, 连锁都不用加

更多的不看了, 这是属于造屎山的项目, 但作者是作技术培训, 用于简单教学之类的也无可厚非.
如果是游戏小白, 或者做中小项目的团队拿来用, 可以拿来用用图个省事, 也算凑合吧, 毕竟解决了一些人的轮子问题.
如果是对自己技术有追求的, 或者规模大点的项目对代码性能有要求的, 就不建议用了, 也不建议推荐给其他人用.

@asuraa 补充 #12

timer 里这个 IDGen 是存在溢出可能性的, 运气不好的话可能遇到任务丢了或者相关的:
https://github.com/aceld/zinx/blob/master/ztimer/timerscheduler.go#L69
https://github.com/aceld/zinx/blob/master/ztimer/timerscheduler.go#L32
而且 addTimer 相关的逻辑的锁粒度比较大, 这个锁完全可以在操作数据结构的小范围加上, 其他的那些时间计算与判断的应该放在锁的范围外边并发竞争的 cpu 浪费

搞游戏招点逆向人员储备，Golang 有 GC 不适合搞大型游戏，内存都不知道怎么爆的。

@paoqi2048 #3

nakam 算假开源吧，卖他自己的云服务的，开源部分不支持集群。自己玩还行，大项目需要完全自己魔改

可以看看 nano ，网易 pomelo 的 go 版本，actor 模型都是面向高并发高响应

@lesismal 非常感谢.受益颇多

https://github.com/topfreegames/pitaya 可以参考下

@lesismal #12 那 golang 游戏客户端库呢

@lolizeppelin 还是 sqlx ，看到 gen 类型的框架我就头痛