@xchaoinfo
为了简单可靠，还是 gunicorn 吧, 出活快, 容易维护.
为了性能... 就不要折腾 Python, 换 Go 吧.

@sunny352787 你说的有一定道理。我就是觉得 client (Go<->C<->Unity) 绕的弯有点长.

@sunny352787 主要考虑客户端嵌进去 Go 是不是方便，如果客户端嵌进去 Go 非常自然原生，那就好。但是 Unity 好像是支持原生嵌进去 C/C++, 不是 Go，所以你看你其实把复杂度移入了 client (Go<->C<->Unity)，而 client 一般限制更多，困难更大，不知道这样搞是不是以后潜在问题也更多.

@sunny352787 为什么不把 client-server 公用的代码用 C 写, 然后 client 端用 Unity C#调用 C, server 端用 cgo 调用 C ?

确实最后都成了争论 err != nil 好不好, 哈哈哈

@movq 你内存太小, 我 16G 内存，用 PyCharm, Goland, WebStorm 从来不卡

@jizhihaoSAMA
在项目根目录运行 go mod tidy, 一般 goland 就同步好了.
你运行后才有智能提示, 是因为 go build, go run 可能会暗含一步 go mod tidy.
当然有时 go mod tidy 后, goland 还是傻的，这时候只能重启 goland.

@levylll ES 太重了，好不好

你为啥要执意进军娱乐圈?

Ruby 的圈子和 Scala 一样，鼓励发明各种没有必要的 DSL.
这种语言都是长久不了的, 废了是应该的.

推荐用 join 的确实都是小白

因为没人用 Vert.x 啊

1. 几百行的 SQL, 各种外键连查.
2. GraphQL, 让前端把后端当 SQL 用.

1, 2 都是错误的路子. 1 应该入土埋了. 2 应该拿去枪毙. XD

如果有网络功能 /支持就叫云游戏的话, 那大多数游戏都可以叫云游戏了...
目前来说, 这一波 “云游戏" 其实特指那种 video streaming based gaming service

@Torpedo
嗯，就是要求高的游戏, 云游戏做不好
休闲游戏的话, 甚至是 3A(播片)游戏, 其实未来可以"云游戏"...

关键是"云游戏"有没有拿得出手的现象级作品,
就像 clash of clans, candy crush 这种手机游戏, 虽然被核心玩家鄙视, 但是还是赚钱.

@neetrorschach
高级点的 ACT 类联网游戏都有这种 move prediction 来降低延迟

你们觉得 5G 能搞好云游戏，是不是太高看 5G 了
5G 只是能方便最后的接入网络, 对其余的真正困难的部分(所谓 End-to-End latency)没有帮助...

@Laforet
我说的是低延迟的 ACT 类联网游戏, 最优的技术实现方案 -- 和现在宣传的 video streaming based cloud gaming, 技术上是完全不兼容的.
当然, 如果只是单机游戏的话, 都放在客户端当然最好了.

云游戏的真实延迟, 应该是一个完整的 RTT: client_input-->server-->client_video,
在真实的网络中, 即使网络条件很好, 单程 RTT 也得 15ms~50ms 的样子, 完整的 RTT 就得 30ms~100ms.

然而一个实现的得很好的 ACT 类联网游戏 (非 lock step 实现), client 和 server 是同时跑 simulation 的,
client 一直在做 (deterministic) simulation for character movement prediction, 同时接收 server 的 simulation state syncing or conflict resolving. client 自己的 character movement prediction 在大多数情况下是正确的 -- 用户感觉到就是控制自己的 character 一般无延迟! 只有预测状态和 server 的 simulation 不一致时 (自己和对方玩家互相攻击到的 frame 中), client 才会去 resovle state conflict -- 用户感觉到延迟, 或者跳帧, 或者卡.
这个是最先进的 ACT 类联网游戏的做法. (video streaming based) 云游戏跟这个完全不搭 -- 属于点错了科技树!