@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.

@iseki
你说的这个 SQL 高效论, 可以 apply 到任何一个小领域的 DSL.
但是大家就是不愿意专研各种 DSL, 因为性价比低下.
除非自己是个 data scientist

@iseki
即使是小场景应用, 程序员会想: 我少专研 SQL 这些技巧, 一样可以写好写清楚逻辑，为啥还要研究它们?? 剩下时间, 做做自己的项目, 或者刷题跳槽都行.

👆上面的原因同时符合公司和程序员的利益
大厂: 禁止复杂且不 scale 的 SQL tricks
程序员: 终于不用折腾 SQL/关系函数 这弱鸡破玩意儿了
所以这个趋势, 未来还会继续.

本质原因是 SQL 就是个弱鸡抽象工具, 因为历史原因流行被滥用.
如果不使用 SQL 和关系函数那堆东西, 外键, join 都不需要用.
比如只使用"逻辑外键"的话, SQL 基本可以当成 KV store 使用.
由于 KV Store 做分布式 scale 容易, 大厂就干脆强制这样用了.

努力刷题进 Facebook, 继续写 PHP XD

你们这些天天吼 16G 不够用的, 能不能把 docker 这个垃圾关掉...
如果实在不行, 能在 LAN 里跑个 Linux server 来跑 docker 么?

支持

老上是真的 vim/emacs 老铁

@f64by
要做引擎吃饭, 确实该去大厂.
不过一个真正喜欢游戏的人, 最终还是会觉得能做的有限,
于是下一个专职方向肯定是 独立游戏制作人. 哈哈哈

真心不看好这破玩意儿