3.x在小游戏web技术栈上成就已经很大了。希望4.x能向原生上面转转。希望编辑器用qt或者.NET重构，Web electron套壳虽然方便，但是优化很难，大项目性能不好。编辑器本身的场景操作的框希望内嵌一个opengl/vulkan实现。希望原生推出一套可选的C++api来对接opengl/vulkan图形库，原来的ts可以用来开发小游戏。原生封装/重构（如果有精力的话）一遍，新原生不用ts，而是用c++。原生一键打包。
简单想法，欢迎共勉
引擎
- 统一原生和小游戏端文件系统接口（有文件系统的小游戏渠道）
- 原生端远程分包下载机制（类微小）
- iOS端WASM
- 原生Worker
- http接口现代化，不建议搞XMLHttpRequest，引擎为了提供XMLHttpRequest，原生端和小游戏端都做了非常复杂的封装，这完全没必要，建议用更现代化的类fetch或微小的接口方式，更简单直观。
- 压缩纹理fallback，只支持ASTC-fallback都可以
- iOS原生端图像解码改成苹果自带ImageIO库实现（本人提供源码），可避免引入libjpg/libpng/libwep以及兼顾ARM/x86等各种指令集，自测ImageIO性能非常强（jpg/webp格式比官方版耗时还短很多），支持格式多、不占包体、iOS/macOS/iPadOS都可通用
编辑器
- 分包构建缓存，不要一次构建就打所有分包，做个缓存判断有更新的分包再构建，对大项目更友好。
- 引擎engine跟主编辑器版本管理分离，官方可以用推补丁方式发布engine更新（从github直接pull也是一个简单办法），跟着大版本走周期太长
2赞
1.虚拟列表组件,列表项支持动态宽高.
2.UI状态控制器
要求不高,友商都有
局部（比如某节点下的所有子节点）动态合批、压缩纹理合批（生成RenderTextur?）
支持引擎ts层构建为webassembly，这样脚本可以用其他强类型语言编写并构建为webassembly，与引擎交互无额外成本
对对对，必须要绕开XMLHttpRequest，打包成web版本，这玩意有跨域限制。 
建议官方先自己做一款大一点的游戏，把出现的BUG修了吧。很多问题都是项目进行到一半然后出现问题…复现也很难
1赞
我先播放了一个背景音乐
然后连续播放了N个音效
结果背景音乐停了
这个优化一下
不要停背景音乐啊
对，自己用一下才知道痛点到底在哪
这个全局音效因为占用过多后，cocos会不报错直接全部静音不再播放，这个有很多帖子了，而且有零零散散的解决方法。我遇到后查过，我的bug核心的问题是，如果你用pause暂停一个音效A的播放，而不是主动stop这个音效，虽然这个音效不再播放了，然后甚至你可以用AudioClip去播放另一个音效B，我以为A音效资源已经完全释放了，实际上只要不stop，就一直占用一个音轨。在原生开发环境32个音轨用完后，声音全停，测试真机的音轨数量更少。主要解决问题的逻辑：在音效播放完成后主动stop就行。
3赞
原生平台在使用videoplayer播放视频支持在视频层级上面添加其他游戏UI控件，并能响应
Lable BitMap模式,能根据bundle打图集就好了,这样就不怕超一个图集了
我想写插件，但是除了抠抠丝我不想用其他的东西。
engine/pal/audio/minigame/player-minigame.ts中的OneShotAudioMinigame的函数stop没有释放_innerAudioContext，导致了内存泄漏，改为
public stop (): void {
this._innerAudioContext.stop();
this._innerAudioContext.destroy();
}
3赞
一键配置android sdk,ndk环境之类.
怪不得小游戏音效总是有各种奇怪的问题，比如音效播放太多就很卡，要么就广告切换声音还继续播，要么就广告切换声音没了 
不知道官方在hi什么 
，才更了一点点东西，引擎和编辑器一堆bug
2赞
希望升级下，包括地形什么的，不然场景编辑工作量有点大。
预制体的延迟加载功能是不是要加一下