Golang 游戏开发框架选型

@librasolo #36

leaf 看上去甚至比 zinx 还差一些, 可能 zinx 毕竟要做课程所以毕竟略带着点"学院派"的工整. leaf 的年代更早点, 那时候 go 社区里轮子少, 国内 go 社区也非常活跃, 论坛和技术群都大把人, 随便写点什么宣传下, star 就上来了.
但那个年代的玩具项目多. 游戏行业的 go 服务端更是属于很多团队在摸索中的状态, 不能怪社区水平, 而是历史局限性

> 江湖不是技术来技术去 是打打杀杀 人情世故 天变了

@ugpu 其实除了元素数量太时 gc 的 cpu 压力, 以及其他类型的强 cpu 压力类的项目, go 还真是都能做. 街篮那种非重度 fps+类 moba 的, 房间人数不多, 也没有农药那种满地图建筑/怪物/兵之类的各种压力, 用 go 都绰绰有余. 那些中小游戏甚至便单机的游戏就更不在话下了. 所以很多团队用 go 是非常合理的技术选型, 跟人情世故没啥关系, 不用这么委屈自己

@picone
就目前国内开源社区的 go 游戏框架的玩具看, 我的 arpc 随便封装点日志/串行化的协程池就可以叫游戏框架了...太没含金量了, 都不好意思这样叫

还有些重度的, 好像 nano 是沿袭了网易那个 nodejs 的 pomelo, 这种定位重度 mmorpg 类业务的框架他们真是真敢做, 而且都是直接选择不适合的语言, 用 node 是错, 换到 go 赛道继续错, 作者是想为社区做出多大贡献猜不透, 但公司内 KPI 升职加薪的作用应该更实事求是. pemelo 当年做的早, 随着手游行业爆发, 吸引(骗)来了不少小白.

那年代的游戏团队, 不只是 go 的在摸索, 整个行业团队里, 多数都是技术不合格的. 因为原本没那么多游戏公司/团队/项目, 而是随着智能手机的发展, 大概 2012 国内一些团队创业成功, 开启了游戏创业潮, 然后大量资金人员涌入. 本来没那么多游戏行业的人才, 资金/项目突然爆发增长, 对应的人力也爆发增长, 不只是技术的人, 制作人/策划/美术, 都缺人, 大量成立的团队里的人力, 只能是拔苗助长的方式, 良莠不齐, 弱鸡居多.
游戏行业不像 web 领域那样, 不同公司不同业务不同规模, 但主要的通用的基础设施都是 web 前后端数据库之类的这些, 社区范围更大, 不管哪种语言也都用这套, 所以 web 领域的整体社区技术比较容易一脉下来形成不同的子派别, 卷这些的社区领袖人多水平也不错, 就容易弄得工程. 游戏则不同, 不论公司大中小, 几乎每家一套自己的, 这其中很多所谓的主程自己不具备开发底层和框架的能力, 就拿着以前公司师傅师爷的祖传代码拿来稍微改改.

而且当年好像真有脑残的大项目技术负责人拎不清, 用 go 做大型 mmorpg, 完全没考虑过 gc 甚至都没做个像样的压测, 一开服压力上来了就卡得不要不要的, 这种挖大坑很难有机会去优化, 线上运营口碑凉了项目直接就凉了

那没辙了，非技术原因那只能谁拳头大谁说了算。不然做游戏，找不出比 C# 更好用的。

@lesismal
@liuhan907
对我来说用啥都一样. 毕竟服务器不够就加. 集群就行. 什么单场景并发 负载. 不操那心 能遇上那种问题 在重构.
现在游戏基本差不多了.
游戏看的是 文化背景 & 美术

@lesismal #34 你这些的前提都是 server 和 client 都是自己写，如果没有 server 端源码只知道协议呢，类似你仓库下面 README 下面的 Pub/Sub 例子，客户端发送消息，然后数据都是在你的 onTopic 回调里处理的，如果有好几个地方需要用到实时数据呢

@guanzhangzhang #46

> 你这些的前提都是 server 和 client 都是自己写

这不废话吗. 如果是涉及已有的或者别人的, 你自己没法自己搞的, 当然得用已有的啊, 或者改造成新的. 你都有现在的限制了而且不想改造, 为什么还要来问其他的方案? 这不是浪费别人时间吗?

感觉你自己对技术不是太懂, 所以你不明白具体问题在哪里, 你问问题的时候也难把问题描述清楚. 如果不是不懂技术, 那就是纯伸手党了. 不管哪种, 建议不要白白浪费自己和别人时间, 问问题之前至少自己先搞明白一些基础, 这也是对别人的尊重