游戏引擎大体上就是前端宿主+游戏相关 SDK+编辑器，
godot 是通用游戏引擎，2D 3D 什么都能做，还有用它来开发软件的（例如 MaterialMaker 和 CozyBlanket ），优点就是经验可以沿用到下一个项目，网络学习资源相比几年前也多了不少，包括国内外。用 godot 时不想写 gdscript 也可以写 C#，godot 很重视对 C#的支持。
另外两个通用游戏引擎，UE 做小游戏属于杀鸡用牛刀了，而且没有网页导出。
Unity 日薄西山，近期几乎没有什么正面新闻，再加上国内运营纯粹添堵的，你下一个非特供官方编辑器都要折腾半天，Unity 的独立开发者群体在逐渐向 godot 迁移。

其它的第二梯队引擎普遍没那么泛用，都有那么几个比较关键的缺点，导出平台受限/仅支持 2D 或 3D/游戏 genre 相对固定/教学资源少文档不完善，不太推荐使用，不过有的引擎也出现过独游神作。属于上限高下限低很看个人操作。
（顺便说下很多收费游戏引擎在 Steam 也有卖，就比如那个 RPG maker 系列，旧版史低时很便宜，官方主要靠卖资产包 DLC 。不过它主要是开发 topdown 回合制的 RPG ，如果你对游戏玩法有更多想法就不太适合。）

如果你已经计划好了游戏最终成品是什么样的，会用到什么功能，那么秉持 MVP 原则，用自己熟悉的语言和开发库，加上一些第三方编辑器，拼个自制引擎来开发也未尝不可。可以看下这篇文章： https://noelberry.ca/posts/making_games_in_2025/ ，蔚蓝的主程写的。

@drymonfidelia #8 如果你说的是图层优先级，单纯让衣服显示在人物前面，那么确实能做，但也只是视觉上的掩耳盗铃，真穿模时该有问题还是有问题，因为本质上并没有解决穿模的问题（也就是物理空间冲突），只不过穿模时不显示交叉部分而已。（更别提这个 hack 可能带来的更多问题）

以及这样实际上不是“内/外”的关系，而是“前/后”的关系，要判断内外必然涉及到碰撞检测相关概念，然后就是大家说的情况

如果你想解决的问题，实际上是你另一个帖子里关于角色/人物几何体绑定动画导致穿模的情况，那么应该是 3D 建模软件的相关问题，跟游戏引擎关系不大，没人会把角色全身的布料都放进游戏物理引擎里，个别组件例如衣摆穿模一下也无伤大雅（此时碰撞也都是和物理引擎的刚体碰撞，不是和人物网格体碰撞），贴身部分可以直接烘培进动画。
最简单的就是那个帖子里 1L 说的，衣服里面完全看不到的面直接隐藏/删除就行了，“某个角度看到是空的”——但能让玩家看到里面本身就是个问题（袖口领口之类的贴合一下，或者用内衬填充，或者只显示入口一小段然后过渡到全黑挡住，类似枪口。）。其它方法还有 shape key 微调等。
以及 V2 上基本都是程序员，你很难找到 3D 资产创作方面的专业答案，建议去行业论坛，或者直接搜，常见问题基本都能在视频网站上找到解决方法。（以及现在有 AI 了可以直接问 AI ）

再说回原来的标题，“永远”“彻底”等绝对词，让人以为你要在物理引擎中完美模拟双方来解决布料网格体与人物网格体穿模的问题。而实时计算下无微不至的模拟，在正常程序员眼中基本等于创造永动机

因为你感觉很简单的事情，实现上并不一定简单，比如整个布料“在外面”，你如何在计算机中表示？你如何判断布料当前是否“在外面”？若发生冲突又如何处理？尤其在碰撞两边都有物理模拟都有动画，每帧都要解算，你又如何保证以上算法的性能？

https://youtu.be/qDM6bCt1Gic
关于网格形变不自相交，去年 SIGGRAPH 上已经有论文得奖了，什么时候能实际应用就不知道了

m3u8 吧，反正条条大路通 ffmpeg 生态

小狼毫按 F4(或者 CTRL+`)可以切换简繁输入

@wednesdayco #105
1. 如果你有在用 vite ，对于 vue 就像#103 所说的用 vite-plugin-vue-inspector/unplugin-vue-inspector （这俩是同一个），如果是 react 可以用 https://github.com/hunghg255/vite-plugin-reactjs-inspector ，svelte https://github.com/sveltejs/vite-plugin-svelte/tree/main/packages/vite-plugin-svelte-inspector ，以此类推。

如果你没有用 vite ，但是有用 vue/react 等，可以用相关 devtools 查看组件树，然后用定位功能定位组件，相比上面的方法，多了几次交互，精度到文件。

如果你没有用 ui 框架，但你页面内容和文件组织结构比较相似，那按目录直接找应该不是太大问题。如果文件很乱，还看不出单独组件，或者你觉得麻烦，那估计只能是搜类了。就像你用 scss 时搜单个类，tailwind 你可以直接搜整个 class 属性，本地 vscode 检索很快的，记得把 node_modules 等目录排除。

2. 生僻感觉大致分两种情况，

第一种你不知道想要的样式需要什么类名/属性，这种可以直接去 tailwind 上搜索关键词就行了，如果 tailwind 不能满足再去 mdn ，例如自定义的 grid 排列方式，这种我知道 tailwind 没有，也就知道该去哪查文档了。

第二种你不知道 tailwind 类名如何影响元素（这种装了 vscode 插件可以直接悬浮显示 css 属性，或者直接去浏览器看元素样式也不是不行），也是先去 tailwind 看属性看效果样例，如果不了解属性值/没有例子，才是去 mdn 查属性值。

一般都是先查 tailwind 再查 mdn ，等大致了解了 tailwind 能做什么不能做什么，也就不用跑两边了。

3. 关于 hot reload ，最差情况是你需要刷新网页来刷新状态，但多数情况 vite 及 ui 插框架件已经帮你处理好了，很少会遇到不能用的情况。不过和查找元素的一样，不是决定用不用 tailwind 的因素，其本身就是对前端开发体验的极大增强。

总而言之，能直接用 utility class 省事太多了，个人习惯是可以适应和改变的，但 utility class 减少的工作量是实打实的，所以才会流行。

cf worker+自定义域名，反代套个壳试试

> 看着满屏的样式写在 html 上就头疼
对于重复的、长的 class 属性，你完全可以抽离出来放到 css 类里并使用 apply ，就如同#51 Pipecraft 截图那样，或者放到 js 里作为字符串，对于 vue 单文件组件或者 jsx 来说就是前后脚的事。
此外，utility class 与 css 不是互斥的，只是 css 的特化，如果你不喜欢它写出来的样子，你完全可以很方便地转换成更原始的方式，例如用各种 tailwind to css 工具或者 unocss 的 compile mode 转换成 css 。
不过很少人这么做，因为 tailwind 的主要优点之一就是非常适合快速原型开发，后面我举个例子你就懂了。

> 点开 devtools element 想找个节点都难找
我将工具方式写在 #103 了，不过一般用这个工具是因为定位元素源码本身就是一个独立需求，而不是受用不用 utility class 影响。（以及以防你说的是在 devtools 自身面板里找不到对应元素，不是定位元素点一下就找到了嘛，除非你嵌套了 N 层元素还不加间距。）
此外用 tailwind 都是直接在源码上修改并看效果的，很少会去 devtools 里看元素，一般都是因为 UI 组件库增加了额外嵌套元素导致 flex grid 等失效需要 debug ，或者不熟悉的属性快速尝试所有可能选项时才会检视元素，所以不太清楚为什么这一点成为了阻止你使用 utility class 的原因。

> 生僻一点的样式就还得去翻下文档
熟悉了就好了，很少会用到的是要查，但生僻的 css 属性不也是该查还得查，不知道你在哪里查 css 属性，但至少和 MDN 比，tailwind 的文档还是更好查的。

我举一个极端的例子，假设一个父元素 div 有 4 个子元素 div 。
然后按照以下步骤修改：
1. 父元素 grid 布局分 10 列，子元素分别占 2 、2 、3 、3 列，
2. 对于子元素，占 2 列和占 3 列的，把各自其中一个元素设置为背景绿色，另一个元素背景红色。
3. 对占 2 列的绿色背景元素，设置鼠标悬浮时背景变为白色，红色背景的悬浮时变为黑色。占 3 列的反过来。
4. 给占 3 列绿色背景的元素添加边框。
5. 删除红色背景元素的悬浮样式。
6. 删除占 2 列的元素并剔除无效样式。
过程上：
- 如果是 utility class ，我所有的更改都在对应元素上完成，批量修改时基本上用一下垂直选择或者 ctrl+D 即可，不用考虑给类起名，不用考虑拆分选择器，不用担心变更样式时会影响到外部元素，只需要在当前行查找对应类名并修改，不用考虑类的前后/层级作用关系以及选择器优先级。
- 如果是原生 css 或各种预处理器，假设你还想尽可能地降低重复内容，你每一步可能都要考虑如何写类/选择器，各自包含哪些属性，在修改时你可能需要在 html 和 css 中反复检索来避免影响到其它元素，在这个过程中你可能要起很多次类名/选择器才能适配每一个变化
结果上：
- utility class 没有样式文件，就是类列表可能比较长。
- 原生 css/预处理器，最后对 css 代码精简，最直观的结果可能有两种：
1. 每个元素对应一个类，类名失去复用性，每个类都包含很多属性，
2. 每个选择器只包含一个属性，需要对应属性的元素复用相应的选择器。
前者相当于 apply 写法，但要赘余很多。
后者就是 utility class 。

@wednesdayco #102
tailwind 流行的原因还有一点就是恰逢前端组件框架兴起，组件框架发展同时迭代了工具链。
就比如 vue ，安装 vite-plugin-vue-inspector 插件（如果用的 Nuxt ，内置 Devtools 自带），使用定位元素功能可以直接在 vscode 中跳转到对应源码位置。
不过用 utility class 时，元素的 class 本身就很少会很相似，比如开头单词、整体长短等，比较容易对应上。

@UnluckyNinja #4 也怪谷歌给 auth 更新改了运作方式，突然离线不显示绑定的密保了，联网成功才显示。第一次打开新版给我吓坏了，否则我不能想着去看看备份/迁移什么样导致误操作

前不久不小心误操作把谷歌 auth 清空了（谷歌那个验证器你点了迁移，绑定多的话会依次显示好几个二维码，右下角按钮是“下一步”“下一步”“确定”，然后确定那里是个选项，问是否移除当前全部绑定，默认是“是”……我只是想看看迁移什么样按快了直接全清空了）
然后就正常解绑重绑，可以用恢复码，也可以用手机上的 github app 验证，方式其实挺多的，印象中十年前绑定时提示是 2FA 丢失就无法找回帐号了，还好虚惊一场

之前遇到个强制中文的问题，即中文版美式键盘就是会在 uwp 和 win 系统 ui 下输入中文，感觉微软认为这是 feature 不是 bug 所以不给关。微软拼音这个也是积重难返。
于是就换成英文美式键盘+小狼毫了，至少这么多年相安无事

尽可能简单那就是 codepen/jsfiddle 嵌入，最简单最省事。

css 图标没加载出来时就这样，检查你的代理规则，switchomega 或者 f12 看一下就知道了

@asuraa #18 我觉得你的理解正好反了，如果一个语言只改语法不修改目标语言，那相当于只修改 parser 的部分，其它基本不用动，如果你把目标语言从 native 改成了源码，反而需要从零实现 AST 到源码的转换，难度不比前者低。

猜你想找：右键上下文菜单自定义命令，注册表里抄一下或者看看其他软件怎么添加的（比如 vscode ），路径就在启动参数里，再通过任意进程通信方式，发送到正在运行的应用就行了（或者直接启动新实例）。
通过窗口获取信息太 hack 了，非常容易兔子洞

@UnluckyNinja #32 如果是为了应付甲方，改一下二维码算法算了，变一下样式，三大一小定位方块也改成别的形式，让微信扫码等识别不出来就可以了

我是这么想的，

你在前端拍一张照片，把照片发到后端去识别解析再，等价于在前端识别一张二维码，包含原本应拍得的照片编码数据，发送到后端去解析判断。如果在前端通过自定义算法进行识别/验证，那么只能是防君子不防小人，这个自定义算法一定会被逆向出来。

前端显示成什么样不重要（除非你用法币那种物理意义上的高难度/高成本防伪技术），重要的是前端代表的编码信息不被人破解，那么你需要实现的其实是在线验证注册码的机制。

注册码自身要做到高熵，冗余、稀疏、无序、自校验等等。
在线验证要做到一号只能验证一次，验证后即失效，验证失败次数过多后限制频率（风控），还可以绑定在线账号对应到用户。
还要加上涂层防止被随意验证，只让终端用户来进行，用户看到图层被刮开就知道有问题。用简洁的格式还能省点涂料。

你更需要注意的是，如果伪造方从头到尾包办了整个验证流程，你怎么让用户发现出来？（那种发送注册码到陌生手机号的我真的是没眼看）。