整的真复杂...

我也写游戏后端, 进来看到大家都在批楼主, 就放心了

万人同屏的... 啥游戏? MMORPG, ACT, FPS, 还是联众棋牌? 区别可太大了

那 three.js 是有点弱啊

@cs8425 那 three.js 是优点弱啊

@jamfer Octree + Capsule 才是 character 碰撞检测正确的做法吧
为啥你要"优化"成射线检测? 你射线射出去难道不也是在全局的 Octree/BSPtree 里面穿行么?
没玩过 three.js, 看来碰撞检测机制还不是很高级，还需要知道 Octree/BSPtree 这类底层概念.
character 是个人物就应该用 Capsule; character 是一发子弹的话, 可以用射线 :D

上次看过一眼, 忍不住说一句: 为啥角色还在穿模和浮空? 能先把 character control 这种主要逻辑整好么?
如果你游戏要联网, 并且角色有类 ACT 互动的话, 联机版的 character control 工作量会有好几倍...

@notokoy
底层没有 ffmpeg 或者其他的 C/C++ lib 依赖么?

大点的公司靠轮值，人多的话，很久论到一次

有些小公司的 oncall 那真是比 周扒皮 的半夜鸡叫 还要狠...
没办法, 人少, 所有后端自动进入 oncall 待机状态

@frostming PDM 有没有跟 PyCharm 集成的计划?
Poetry 现在被 PyCharm 支持了, PyCharm 新建项目会在其 Terminal 里自动设置好虚拟环境

WebSocket (turned) --> WebSocket (turn based)
打错字了

以程序为主的小团队, 就用 Unity.
研运功能主要靠 Unity Asset Store 上买, 而且要买流行的带源码的 Asset/Plugin.
有问题可以看着源码问作者, 可以理解为"付费开源", 比在 Github 上瞎找效率高太多了.

先把游戏本身做好是关键, docker, ci/cd Jenkins, DevOps 这堆没用而耗时间的东西先别研究.
剩下的时间好好研究 Blender, Affinity Photo (PS 太贵), 因为你程序员自己得担任"技术美术".
要做联机游戏, 也应该好好研究 WebSocket (turned), UDP (real-time), 别研究 DevOps...

按照我上面写的做, 可以少走很多弯路.
游戏成功发布了, 回来给我发个红包吧. :D

辟谣针对外键的谣言: "国外基本都推荐外键"

我就在硅谷, 一般都是在写 micro/distributed services, 基本不会写外键
从我认识的人里聊天, 基本没见着用外键的,
除非是针对 legacy services, 单体 DB 那种才会用...

@lanlanye
"非跨库的情况下你做的无非是自己实现了一遍数据库做的事。"
是的, 以一种更加通用的方式. 只要理解更通用更强大的概念: transaction, lock 就行.
喜不喜欢这种思维方式, 其实是个设计思路的差异.

场景-1
如果全体同意: 我家数据库就是, 静态, 单体, 永远不变, 并且大家爱专研 SQL tricks, 完全可以.

场景-2
现实世界是, 这种纯 SQL 情况越来越少见了. 现在不是 20 年前, 只有 Oracle / mySQL 流行的时代了.
现在设计和研究纯 SQL 的 tricks, 对于公司和程序员来说，性价比都很低.
我重复下这句话, 研究这个*性价比都很低*, 通用方法能搞定的话, 不用深究, 除非公司要求.

这里要说个历史遗留问题, 为啥纯 SQL 这些知识就该是程序员要掌握的基础?
为啥不是 MongoDB, DynamoDB, ElasticSearch, Redis 的细节知识更基础?
其实 SQL 更早流行, 但是不等于是说, SQL 的知识就能基础, 更基石.
相反, 我觉得 SQL 的流行, 其实算是点错了科技树...
我知道这样说很招喷, 但是这个问题太大了, 一两句说不清楚...
大家现在有意无意选择少专研 SQL tricks 是很有道理的.

@xhcarlin
@lanlanye
你们说加外键的操作, 有时可以避免 transaction, 甚至更低级的锁, 我同意.
但是外键远远不能完全避免它们, 所以直接把 transaction 和锁用熟悉性价比更高.
其实从本质上讲, 底层都是锁.
可以直接用 transaction + 逻辑外键 来处理跨多个表的修改.
甚至有时上 serializable transaction + conflict 处理.

另外跑个题, 我开发的很多 features 是跨 services 和不同数据库的.
最后我的经验是, 分布式锁用熟悉了, 其实性价比最高...
真正值得研究的是 分布式锁 + 分布式 transaction, 当然你们会喷我跑题...

@foveal
告诉你 GF, 所有东西都有系统严谨的理论支持的... 是数学物理
计算机编程里面，很多设计是比较烂的历史问题, 只能直接上手尝试

@iseki 不爱学 DSL. 更精确说, 不爱学应用面狭窄技巧, 甚至思维方式.
比如外键, join 相关的很多知识就是. 折腾它们性价比低.
你说 SQL tricks xxx 可以抵得上 100 行自己实现, 极端情况有可能. 但是何必呢? 我还可以说 database stored procedures 能抵得上 1000 行用通用代码写的逻辑, 但是大家爱用 stored procedures 么? 反而是精通它的 DBA 都失业了...

而且一旦按照 SQL 全家桶思路设计了, 各种 migrate 都不方便. 比如我就用 uuid 作为"逻辑外键了", 回头我把这部分数据 migrate 到另外的 service B with database Y, 一点问题没有. 但是我把 SQL 外键, join 这些都一股脑全用上了, 那 migrate 就麻烦了! SQL 这套东西, 自成一派, 不灵活, 不通用, 全家桶都用上的话, 容易作茧自缚. 你可以说, 我家就这么用, 以后永远不改设计了, 但是谁知道呢...

@iseki 也是最重要的要求，schema+index 搞好了其余都是次要问题.
你对"正确地"使用(SQL)工具, 确实有点执着, 哈哈
但是从程序员自身收益来看, 不爱研究 DSL 是可以理解的

@iseki
数据库查询要高效，主要靠认真设计好 schema 和 index
本质上是面向 schema+index 编程, 效率靠底层的 BTree 这些.
并不是搞折腾好 SQL 这种 DSL 的各种无聊 tricks.