…bazel 和前几个差别还挺大，这类系统都有专人维护内部规则吧，但是不配合 remote build 太折磨了

客户端肯定不合适，至少不能纯用某个语言来写，连个事实标准的图形 api binding 都没有，要我自己新造个轮子来解析 vulkan xml ，我还真嫌麻烦。

至于 elixir ，要例子的话，我记得一些日本公司有拿来做服务端用，在他们一些技术博客上看过，比如 cygames?

这一堆函数式语言里我觉得最有双端生产力的是 F#，只可惜 BDFL 自己都不在乎自己的成果了，微软剩下那几个全职开发同时负责编译器和内部支持，完全忙不过来，F#最后只会越来越和 C#脱节

Mac mini 也不贵啊，既然是前端用 rn 之类的本来就能跨平台了

挺好，我觉得做独游的都有 op 这执行力就好了，一个人开发，引擎之类的都是次要的，又不是多端的 3d 项目，顺手就 ok 了，实际上网页的 2d 性能可能比很多引擎好。

@chiaf 当然一样，就算你是美国公民也要上传手持 id 照片啊，没区别

@arac monogame 也有星露谷，同样是单人作品，按照当年的现象级表现，它如果在今年发布估计年度游戏提名就变它了。make game not game engine ，我见过太多人死在写引擎的路上了，谁顺手就用谁没毛病。

@iorilu 不直接盈利，靠定制咨询的晨风，一样的机器人框架，但是却更新着

@iorilu 并且，入侵计算机系统罪是要报案的，没有违法所得可不行

@iorilu 不一样的，不盈利法院就算受理了也不会重判，可能最多到律师函阶段，也不会直接引起其他机关注意主动代替权利人侦查。其实盈利了如果没前科，大概率也就没收违法所得加赔偿，参考最近的 qq 机器人框架，小栗子，120 万盈利，两个人都是缓刑，没收，赔偿，实质上不用进去。

有，如果你用了不公开 API ，可能有侵入计算机系统罪，但是不盈利或许没风险

上面有人非得把技术原因当成产品原因也是难绷

@drymonfidelia 工作量绝不是在公司层面衡量一个产品能不能行的首考。只做 windows 兼容的硬件工作量当然低，我也不知道上面很多人要否认什么，况且 steam deck 本身也兼容。

我自己的考虑：

1 ，steam 本质还是个软件公司，硬件能赚几个钱？做主/掌机的几个公司在靠硬件赚钱？ rog 也做了掌机，但用 windows ，这就是软件和硬件公司的区别。steam deck 以后也可能会出独占，甚至换 arm-based 的芯片，不过现在的保有率很难支持而已。

2 ，掌机玩 pc 游戏的用户容忍度是非常高的，在乎“我全都要”么？本来硬件就支持不住，起码我自己不会。steam 肯定之前就做过调研。

3 ，在这些条件下开始谈技术能不能做就合理了，答案很简单，可以。

git branchless 这样的工具应该就是给你现在这种用法设计的

才 2600 行就 200 次感觉 commit 里都是无效信息…写了点就 commit ？中间可能压根就没法用吧？喜欢这么用的话就用 branchless 的方法，detach 然后准备合并再 squash

不就是审计和过认证的价格么…给美国政府软件也要过 FIPS 140-2 ，汽车行业要过 ISO26262 (ASIL D)，你的替代先过了这些认证才能有上桌谈判的资格，至于选不选你，那另说

AI 时代下，sell 的能力明显比 build 的能力更重要。独立游戏要么美术，要么玩法、剧情，要么你自带流量，游戏行业是买量大户，你说的那种 low 但在排行榜上的基本是这一类，“卧槽，火了” 的机率太小了。

另外 op 这个新游…在 steam 退款政策下真能见到回头钱吗…

完全不写前端，只用 cursor 写 rust macro ，以及各种模版，宏类的东西真不是人写的。啊，还有帮我写开源项目的文档。

@Byleth 现在这种网站应该都被盗刷打烂了吧，不过确实要注意

这才是 aws 有各种认证考试的原因吧，我自己用也不会选 aws ，价格高还复杂