如果主机游戏平台包括车机包括后面准备的扩展平台都支持 wasm，那只支持 wasm 也没什么问题
1赞
周一啦，上班啦，又听大佬吹水啦 
1赞
但是可视化编程是一定得做的，你看现在的热门引擎，都属于是好不好另说，但你得有。
二进制什么的问题既然是重新开始，可以再设计解决嘛。
这个在公司里主要是给非重度程序员用的，简单的需求连线有时候真的比写代码好实现，我们公司美术之类的就只用这玩意儿，一般不会整得太复杂。
而且，每家的 “蓝图” 本身其实都差不多，有一个比较一致的范式，也就是说你要是会用 UE 的蓝图，那么上手 Unity 的 VS 也很快，跟换一门编程语言不一样。
也由于蓝图做得都差不多，开发一个导入别家蓝图转换的工具也很好用和简单。
1赞
这个在公司里主要是给非重度程序员用的，简单的需求连线有时候真的比写代码好实现，我们公司美术之类的就只用这玩意儿，一般不会整得太复杂。
下面也说了，某些部分可以用类似蓝图的编辑器，例如AI（状态机/行为树）给策划用，Shader和动画给美术用。因为这些东西比较独立。
也由于蓝图做得都差不多，开发一个导入别家蓝图转换的工具也很好用和简单
你试试把UE的蓝图转Unity看看，除了那些基本节点Vec3差不多，其他的API全部不一样的，没什么地方可以转的。
你看现在的热门引擎，都属于是好不好另说，但你得有。
Godot 都放弃蓝图了，Unity也不管了。也就是UE比较偏执，没有中间语言就用蓝图，可以问问那些UE项目组，哪几个不中间再弄一层lua或者js的脚本引擎。
如果真正用过UE的蓝图，并且有修改过底层结构，或者说打过发布包的，都对蓝图的bug恨的要死，坑大的很。
1赞
我们 API 设计的时候可以考虑更加兼容 UE 或者 Unity，即使转换工具做不出来，由于使用的方式基本一样，学起来还是没什么门槛的。
我不是说要用蓝图充当主力语言什么的，只是认为可视化编程是必要的，与其它引擎情况不一样，我们已经有了脚本语言。
我没有这么深入使用过，但是可视化编程本身是不错的，这些只是具体如何实现的问题。
1赞
不是，应该是参考gamemaker8，或者gamemei
1赞
我觉得cc做可视化编程是当cc没啥好搞时才会弄。
可视化编程适合搞那些广告投放小游戏，反正不适合开发一定规模的游戏用。
如果你是开发时用可视化编程你会觉得很爽， 但要你去维护别人的可视化编程(有一定量的， 不是简单2至3个模块那种)， 你会恨不得手撕当初弄这个的人
1赞
噢这么 old school 啊 
像之前用过一段时间的搭建之星：
确实有时候我不知道为什么连线式更流行，而这种按行排列的可视化编程却没有那么流行，物联网那块好像挺多这种的。
大量使用维护起来确实也比连线式的好维护，但即是优点也是缺点，写起来和看起来都跟直接编码差不多。
1赞
嗯嗯同意确实没必要太着急，暂时没找到新范式能解决连线式维护性的问题。
1赞
在这个方向上，选用什么语言编写代码反而是阻力最小的一个问题
1赞
是的，没有完美的解决方案，只有合适的
1赞
说到可视化编程，我就想起几年前的唤境了，当时我还去玩过一段时间，然后发现它为了不写代码，整个流程用了一套非常复杂的事件系统，通过去选选项的方式创建各种事件，难用的一批。后来就凉了。我个人的一个理解是，可视化和低代码化是为了减少一些工作量，规范一些工作流程。例如群里某位大佬的xforge框架，创建配置之类的东西的时候，用的就是从ui面板点击创建。这样比指定一套规则，让开发者手写要快捷很多，同时也会避免不小心写错导致的问题。但是想要将所有的东西都变成不写代码的方式，是一种走火入魔的想法。写代码的难度也是分一二三四的，用简单的代码能够实现的东西，就应该用代码去做。
我现在想开发一个工具，基于数据和表现分离的原则。这个工具就只做数据层的游戏开发，也就是说用这个工具做完之后，你等于做成了一个纯数据，连文本游戏都算不上的游戏核心内容。然后再将这套内容结合具体的游戏引擎去开发表现层的业务。
1赞
确实是 数据是数据,表现是表现,只是大多数引擎用的开发都不是同一套语言,切换引擎也要改动语法结构上的,如果有语言特性上的不同,花的时间可能就更长了
1赞
蓝图垃圾蓝图垃圾蓝图垃圾
1赞
因为不是所有平台都支持wasm，如果你愿意放弃一部分，当然可以不编译为js。
1赞
我看重蓝图是为了解决 iOS 没有 JIT 的问题，他的易用性的缺点我都能忍受。要易用的话继续用 ts 就好了，没说要废弃 ts。
如果蓝图做得足够完备，配合引擎的原生化，理论上 iOS 上可以不跑任何一行 JS 代码。
1赞
不理解只是为了解决没有 JIT 而引入可视化编程。
主要可视化编程的问题不是易用性吧，易用性、入门门槛都没问题，但我想要性能，也不会想失去维护性和编码效率啊。
蓝图做的性能再好，它貌似也不能胜任写完所有业务代码的任务。
又看到个饼：React Native 的 Hermes JS 引擎正在做一个 “Static Hermes” 方案。
https://tmikov.blogspot.com/2023/09/how-to-speed-up-micro-benchmark-300x.html
它会将符合条件的有类型注释的 JavaScript（TypeScript）编译为本机代码，提供与 C/C++ 相当的可预测性能，与没有类型注释的代码进行混合执行。
表格来源：How to try Static Hermes · facebook/hermes · Discussion #1137 · GitHub
3赞
不跑代码， 那程序员将不会用cocos
1赞
蓝图能在ios上JIT? 不都是脚本吗？
1赞