规则自己写一份简单的协议就可以了, 用协程 + protobuf 写一个。CPU 不够这简单, 加机器, Go 挺适合的。代码量也很少, 部署等都很方便直接, 性能很好。通讯层写好了外面加层你自己喜欢的语言写的业余处理就行了。

今年 2 月看到预告特意入了 ps4 然后预购了豪华版,上周三预下载, 周四晚 12 点开始可以玩, 周末历时 10 小时通关。好久没遇到这种大作了, 我就看什么时候 v 站有人提出来。

周末已通关, 请看我头像 2333

@18889242351 #32 到目前位为止，接触不多，不过我很赞同你说的学一点基础的东西，最近学习一些绘画基础帮助很大，不止工作中用到机器学习 /opencv 的图像处理会用到，处理摄像头成像也会用到，设计本身也很有帮助。

@18889242351 #32 谢谢你的建议，我现在从 Adobe XD 和 Photoshop 学起，配合手绘板学速写联系快速出原型的能力。我写后端为主，不过业余主要是学习 Android 准备首先出一个设计简洁的 APP 看看样子怎样。

显卡不能看参数买, 而是看游戏在不同显卡下的评测买。根据实际经验, 在特效全开时, 你的定位在 2k 分辨率下保持 60 比较合适。因为 4k 下 1080Ti 在比如古墓丽影崛起这类游戏上都在 45 左右, 显存吃了 5g 左右, 那不是一张显卡能解决的了, 同时新电脑若 2k 下连特效都不能全开就不理想了。这几年的游戏要求硬件提升不多, 优化较差的古墓丽影崛起依然是很好的参照物。

另外内存太小了, 8g 会占掉 20%常驻, 这会在普通游戏下比较吃紧, 若是大型 RTS 游戏就会不足,那类游戏大量的单位会需要 16G 最好 32G 的内存, 比如说 Titan, 英雄连。

还有一个就是 CPU。CPU 对于大部分游戏都足够, 但是对于某些祖传单核游戏比如钢铁雄心等, 单核更强劲的 Intel 比较合适。玩这类游戏为主可以适当放低显卡要求提交内存和处理器。再说处理器不贵。

最后是硬盘。SSD 硬盘对于读条严重的游戏提升很大, 比如全面战争, 比如角色扮演, 这部分读条可能会产生超过 30 秒的时候会带来明显的体验下降, 尤其是那类剧情氛围类游戏, 生化奇兵很快, 但星球大战前线 2 就会加载非常久。

我建议把显卡提升到 2k60 的程度, 因为我用 1080Ti 因为 4k 不到 60 降到 2k 那么就存在性能过剩问题(价格也过剩)。其次内存 16G 是必须的, 还可以跳出游戏保持一些基本软件的运行。CPU 对特殊游戏有要求, SSD 不贵时入一个也很好用。假如有 PS4 还可以把你的 SSD 装到 PS4 不影响保修。

@shimomiaizo 我今晚看设计时 https://www.youtube.com/watch?v=CnfXJ2qjv5I 时看到 https://www.youtube.com/watch?v=m1diVY4Uzjc。Flutter，我不知道对于设计来说难不难，但我用了不到 1 个小时就写完了整个 demo 并运行在自己的 Android 手机上（我从未写过移动 app，毫无概念可言，只有后端基础） ： https://flutter.io/get-started/codelab/，移动端实际上体积更少，设计更多的 UX 设计，并且 Flutter 直接运行在 web/ios/android，我觉得你会感兴趣。相比于 swift/java 这些开发适合于个人项目（但这个很新，而且普遍做空这个框架，假如你要往前端发展还是学 Vue/React/Ng 之类吧，但单纯说个人项目，我觉得很好很好，相对于混乱的前端生态圈和学习成本）。

@n3hatv2 #9 我觉得你现在的方法很好了，那样做就完全不用考虑原先的问题了，walk round 同时也是一种风格更好的 design。Queue 模块放在 multiprocessing 虽然没问题但共享 Queue 比较麻烦，所以 Redis 更方便，就是多了个 Redis 依赖。

1.不会
2.是的，假如 session 是同一个，就会覆盖掉了。因为 Model.attr = 'xxx'时相当于塞进了预备被提交的 box 里面，commit 就全部提交了。假如相同 id，应该是原有 box 已有内容被覆盖了一遍（我猜，源码我就不看了= =）。

性能还好，我对比过 peewee 和 sqlalchemy 的性能都差不多。如果不存在锁或其他等待，速度一般卡在大批量数据插入时比较慢，sqlalchemy 有个 bulk_insert 的方法，不过大量时间会花在构建对象或 append 插入数据里面。但具体执行插入到插入完成这个阶段，到底是数据库是瓶颈，还是网络，还是对象的构建销毁比较耗资源，就没测过了。

@n3hatv2 pool 子进程没用过耶，pool 线程池就用过，还是 subprocessing ？ executor ？所以我猜你有两个担心的地方，一是 multiprocessing 这块可能共享，二是 threading 这边可能会共享。前者我一般用一个 docker 一个 process 所以不熟悉，不过据搜索结果看 multiproccessing.array 专门用于共享内存的，并用 actor 模型处理消息，所以我理解是不会共享的，所以这里我们是一样的，不用管。至于 threading 嘛，是会的，我也很常用 threading_pool.map 然后通道来传消息，还能共享变量。假如你的 Model 绑定了 session，在使用 Model 时，session 在 commit 的时候会把所有都包含进来……所以每个线程应该单独使用 session 来完成。比如这样：

```
# 用调用函数的方式加括号()，一种明确的信号来建立连接
with session_scope() as session:
do_something()
```
不过我觉得更好的方法是用 Queue （线程安全的），集中处理所有的存储步骤。pool.map(worker_lambda, args)来执行任务，在 def worker_lambda 里面处理好后结果 push 到 Queue 里面：queue.push(result)，然后做一个 while True 的消费者，从 queue 取出结果，然后 session.add(result)来保存结果，result 包含多个结果，单独塞 X, Y, Z 变量也可以，但是多线程下顺序有可能会乱，所以有多个结果就一起塞。设置 timeout/retry/queue.empty 作为超时 /重试 /中止信号。这样就不用担心这种问题了，虽然每个自己处理也可以，但是我觉得那样会增加许多脑资源消耗，而且更容易出错和更难维护，其他人接手修改也容易出现 bug。不然你可以用协程，最后看看数据库的锁默认设置。最后最好避免全局变量这种东西，以后会搞坏自己。

flask-sqlalchemy 那个我不大记得，我记得是最后 db.session.commit()就提交了，或者有的人直接 auto_commit。这在多线程里面的确会有问题。如有错，请指出。