字节都入股中国unity了。。。怎么会看得上
1赞
你们为啥会期望一个把游戏部门都裁的企业，会做一个游戏引擎？我是真心不懂这里面的逻辑，虚心求教。
2赞
不是又重新拉团队做了吗今年
我做开源框架的时候就想做到尽可能的标准化、规范化。
因为确实即便一个项目内，大家各有各的想法，作为leader管理项目也是相当费脑筋。
所以说，大部分人的想法，“假大空”的居多，一点也不结合实际或者一点实操经验也没有。类似儒家学说，咋一听都对，细一想毫无实现之可能，也无验收之标准。
以前的2dx 做到了性能至上！只是上限比较低
想知道cocos 现在的发展方向， 感觉没动静了
深奥。补丁补丁补丁补丁
留给cocos的时间不多了
1赞
挖个楼也YY下，如果让我做引擎，我会从以下几点做
- 抛弃双核，底层彻底WebGL化，跟着2.x的老路子继续深耕webgl jsb，深度优化webgl性能，增加多线程甚至多进程渲染机制，非Android系统集成ANGLE
从3.x开始，引擎原生转向C++化是引擎团队的一个方向，但目前看来这个方向带来的问题很多，甚至走了不少弯路，诸如很多的优化功能小游戏/Web能用，原生不可用，反之亦然，明确的说原生比小游戏无论是稳定性还是优化潜力都差的很远
另外为维护gfx的OpenGL/WebGL统一，引擎团队也似乎耗费大量精力和时间，论坛上一大半问题都是在说两平台的效果不统一，开发者也不满意：做的插件不兼容、优化两边各搞一套、c++优化gfx的门槛又高。
原生化本意是为提升Native上js运行较差问题（特别iOS缺少JIT），这可以在jsb给jsruntime增加Worker/WASM（还是iOS）来弥补，Worker还可以跟物理引擎进行深度结合绑定。
抛弃jsb2.0，彻底的去拥抱v8，jsb2.0使用确实方便，不用碰v8API就能扩展js，但中间有大量的胶水层代码去弥合游戏c++和v8之间的API差异，这部分如果去除掉，相信可以提升不少性能。
另外一点，WebGL性能如果优化好其实并不算很差，可以使用共享内存、多线程渲染（JS线程和OpenGL线程分离）来处理，像微小的WebGL现在还不是可以跑中大型游戏吗
- 引擎API往小游戏API上靠拢（文件系统、Http/Sockets、），开发者开发的小游戏，只需小改即可发App原生，同时模仿小游戏提供API接口规范，开发者照着规范去对接其他渠道的登录、广告、支付，而js层几乎可以保持不动。
如引擎层提供cc.login接口，
而对应的原生java/OC，则提供一个接口或者抽象类去实现login的逻辑，用模块注入方式，这样做好以后很多渠道第三方甚至都主动帮Creator去写登录适配层（2dx时代很多第三方sdk都提供cocos对接文档和代码）。
- 除了做CocosStore，也做一个AppStore，专用于cocos游戏上架的游戏盒子
3赞
提议很好，但是你说的这些其实都是在无意识的往h5小游戏方向靠，这个路太窄了，上限很低。
3赞
但现在的原生方案也没见得能做中大型游戏呀
其实如果能解决双平台表现不一致， 不用让开发者维护两边代码已经好很多。
如果以app包webview基于WebGL 做中型游戏也没问题呀， 只要ios提供类似高性能模式方案就行， 比如拿v8改良为属于cc自己的游戏v8引擎， 目标以中小型游戏为主力方向也是一个不错的选择， 市场最忌实力不够又想様様都要， 最终甚麽都不讨好。大型的只能看将来webgpu 能否带来改变了。
1赞
可以明确的说 未来也不会有太大的什么变化，除非浏览器的使用方式发生翻天覆地的大变化，但是不可能，因为要统一标准就是一件登天的难事儿，h5 网页端，就意味着现用现加载，资源太大，根本就不适合web，你不能让用户每次进都重新去下载那么多资源，等待那么长的时间，所以网页游戏 性能只是一方面，体量也是影响的主要因素，我这里说的上限低就是指框架本身的上限很低，就目前的技术架构来说，它就是一个偏h5发展的框架，你要硬套在原生和pc 其他平台，吃力不讨好。为啥现在creator 还能活着，有一个很大原因是因为政策限制，等小游戏也需要版号了，目前这块市场就逐渐落幕，海外h5小游戏市场一直是属于一个占有率极低的小蛋糕。
这里jare已经说了，重复造轮子去做引擎的确已经不是一个很好的选择，就比如你还在研究怎么让原生表现流畅的时候，别人功能都已经做完一两个了，你在研究怎么实现功能的时候，别人已经通过自己丰富的生态找到了解决方案。其实行业已经很成熟了，除非你的确有亮眼的技术壁垒，或者有独特的市场眼光，不然想活得轻松的确很难。
我只是想表达，作为这行的从业者，要随大流，看看世界发生了啥变化，头部的从业者他们在做什么，我深有体会。因为我所在的公司就有几个部门是用unity，一个是creator，明显的资源倾斜，以及薪资待遇结构不同，你就打开招聘网站看看，招unity creator 虚幻的 薪资上限对比，就知道了，以及招聘人数，就能大概明白它的上限到底大概在什么水平，假使这个东西真不行了，你再尝试去转你还来不来得及。也比如，你是想职业生涯做无数款快餐式游戏，还是想做几款有点内容的东西，当然这只是我的一些个人看法。
2赞
你这是laya的路线，可以看下laya
我觉得加载不是问题， 你看看IndexedDB， 可以把文件以bin形式储存， 需要时从IndexedDB拿回就行 ，不需要每次大量下载， 所以加载太文件不会是h5游戏发展阻碍.
而IndexedDB 能储多少东西 你可以看这里， 我一台M1 的mac笔记本都允储存100GB内容， 只是跟你实在硬盘当前可用空间无关， 但侧面证明H5 是可以本地储存大文件
你说的没错，可以用indexedDB 二进制数据存储，那么这个会把问题抛给用户，页面关闭就等于应用关闭了，那么每个游戏都这样使用 你的存储空间是不是就爆炸了。又该怎么进行合理的管理，其实就是浏览器发展这么多年一直都没有统一的标准。也有可能是网页应用本身属于轻应用属性决定的，什么东西缓存 什么东西不用缓存由浏览器和服务器决定。
你説的在我眼中也不是甚麽问题， 储存空间爆了， 你的游戏在调用indexedDB是能感知的， 直接弹窗或弹出一个操作界面让用户删除自己游戏以外的db就好了。 还是那句h5生态发展下去浏览器提供商是会改变的， 在html5与之以前的html比较， 前端拥有了更多权限对以前是无法想像的， 你怎様猜到html6推出时会没改呢？ h5 没法用 udp， 但现在有webtransport， 等到全面推广 H5游戏也有upd了，只能説随着未来网速， h5生态发展， 前端能用的东西会越多， 需然短时间是看不到。h5平台拥有的易传播， 免安装的特点始终会是有一大群人买单的.
回到最开头， 我建议的webview方案， 是可以基于把资源预先放到app内， 以file协议运行游戏， 所以储存和热更也不是啥问题。
如果前端语言还是js这种宿主脚本语言，我依然不看好网页端作为游戏主要载体，管它是不是v8引擎，还是wasm，我这里说的空间爆了，不是指游戏没空间存储了，而是用户无法像app一样管理自己系统的存储空间。当然我们俩讨论这个其实没啥意义，还是那句话 它的上限就在那里，你就看creator这么多年 一个中大型的游戏都没憋出来过，因为没有厂商会选择这个技术路线来做。如果web如你所说以后权限越来越多，用户的隐私问题就是更大的难题，甚至浏览器还能留后门，因为厂商太多了 鱼龙混杂。
説真的， creator 又发展了多少年呢（我们不考虑2dx， cocos-js）？10多年前unity 也是被很吐嘈就是个估小游戏的引擎， 到现在可以做出老头环， c#也被吐嘈冷门性能不好(window vista 就是c#搞出来的)， 到现在呢？
未来用cc做大型网页游戏可能存拟， 但中型真不好説。
1赞
以前是C# 不支持linux 冷门， unity刚出来的时候那时候游戏引擎都没怎么有，只有flash, unity 利用1两年的时间证明了不是小游戏引擎， 而cocos 都发展10几年了还是没有进步啊 ，这就是差距
2赞