@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) 云游戏跟这个完全不搭 -- 属于点错了科技树!

还没有人说关键的技术问题, server video streaming 这种思路是不能解决网络延迟问题的.
要知道, 最好的 real-time game (FPS, ACT, MOBA) 都是 client 和 server 同时模拟游戏逻辑 (非 lock step),
然后 sync states, resolve state conflicts, 才能达到最低延迟效果.
要是像现在 "云游戏" 那样, input 发到 server, server streaming video 回来... 黄花菜都凉了...

@gz911122 回头 Vue3 出来后, 又新学一波新的 best practices, 好麻烦...

你们都不等着 Vue3 出来后再学么?
"你们"指的是业余前端, 比如日常是写后端的人