cocos是否应该摒弃TS,转为c#或者go

大型游戏用COCOS的占有率始终上不去,到底是什么原因

Ue也有用ts开发的

:rofl: 终极大招,底层ts转成C++再编译进so里面.

kotlin ?还是 uts

bug多,成本维护大。编辑器卡顿,不适合开发大型项目。

1赞

恕我直言,后面两个 没比前面的好多少也

编辑器卡顿第一步就劝退了大项目,造成的影响的是成倍上升的开发时间

个人观点:
大不大型游戏和脚本无关,某大厂也在用UE+TS的组合。 开发的基本都是重度手游。 Cocos的优势就是轻量游戏、快速开发。 不过编辑器卡我认为不是electron的问题

功能不全啊,物理组件,渲染管线差UE UNITY太远呗。
COCOS在3D上距离 他们是有代际差距的。。。。

是真卡啊,真的

是成本以及能力的问题

大一点确实卡成翔,,

2.x大项目很卡,3.8.x目前还行有一点就是修改脚本后回到编辑器刷新要好几秒这点优化一下,一般项目可以了

转rust,你看看vue的roll down

要不转回c++,到时候还能转ue

底层C++(webgl渲染也在C++层适配),上层kotlin编译wasm,可以考虑;
现在的原生端适配很蛋疼,各种js函数原型链替换适配,看起来真吃力。

可以参考cocos2dx(不是cocos-creator)在微信小游戏上的适配

你们用的什么版本卡啊?

话说ue和unity的编辑器是啥玩意开发的

Unreal Engine(UE)和 Unity 的编辑器作为游戏开发的核心工具,其底层开发技术各有侧重,既包含了主流的系统级编程语言,也结合了脚本语言和特定框架来实现复杂功能。以下是两者编辑器的开发技术细节:

一、Unreal Engine(UE)编辑器的开发技术

UE 的编辑器与引擎本身深度耦合,采用 多语言混合开发 ,核心技术栈如下:

  1. 底层核心:C++
    编辑器的核心功能(如窗口管理、资源加载、渲染管线集成、物理引擎交互等)几乎全部由 C++ 实现,依托于 UE 自研的 C++ 框架(如 Unreal Header Tool 用于反射机制、 Slate UI 框架)。C++ 保证了编辑器的高性能和对硬件的直接控制能力。

  2. UI 框架:Slate
    编辑器的界面(如属性面板、视口、菜单栏等)基于 UE 自研的 Slate 框架 开发,该框架同样由 C++ 编写,支持声明式 UI 设计,同时提供了跨平台的一致性(Windows、macOS、Linux)。

  3. 脚本扩展:Blueprints(蓝图)
    虽然蓝图主要用于游戏逻辑开发,但编辑器也支持通过蓝图扩展部分功能(如自定义工具面板、资源导入规则),本质上是对 C++ 底层功能的可视化封装。

  4. 辅助技术

  • 资源管理系统(如 UAsset 格式)基于 C++ 实现,支持热重载。
  • 跨平台适配通过 C++ 的条件编译和平台抽象层实现。

二、Unity 编辑器的开发技术

Unity 编辑器的设计更注重跨平台兼容性和开发效率,技术栈相对灵活:

  1. 底层与核心逻辑:C++
    编辑器的性能敏感模块(如渲染引擎接口、内存管理、平台适配层)由 C++ 开发,确保与操作系统和硬件的高效交互。

  2. 上层功能与 UI:C#
    编辑器的大部分交互逻辑、窗口系统、插件系统等由 C# 实现,依托于.NET Framework(Windows)和 Mono 框架(跨平台)。C# 的优势在于开发效率高,且便于与 Unity 的脚本系统(C# 为主)无缝集成。

  3. UI 框架:IMGUI 与 UIToolkit

  • 早期版本依赖 IMGUI(Immediate Mode GUI) ,一种即时模式的 UI 系统,用 C# 编写,适合快速开发工具界面。
  • 2020 年后逐渐转向 UIToolkit (基于 HTML/CSS-like 语法),支持 retained-mode(保留模式)UI,更适合复杂界面设计,仍通过 C# 绑定到编辑器逻辑。
  1. 插件与扩展:C# 与.NET
    Unity 编辑器的扩展性极强,第三方插件(如 ProBuilder、ShaderGraph)几乎均通过 C# 开发,利用 Unity 的 Editor 命名空间接口(如 EditorWindowCustomEditor )扩展功能