跪拜 Guibai
← All articles
Frontend

Cocos 4.0 Is Out — Why Are Devs Still Shipping on 2.x?

By 亿元程序员 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

For Western developers evaluating game engines, this is a real-world signal that engine version churn doesn't always mean progress. The Cocos 2.x-to-3.x migration is so costly that many teams treat it as a separate engine, not an upgrade. Understanding this friction is critical for anyone building cross-platform 2D games, maintaining legacy projects, or choosing between Cocos and alternatives like Unity or Godot.

Summary

A Chinese Cocos developer recently reverse-ported an entire mini-game collection from Cocos Creator 3.8.7 back to 2.4, after fielding multiple requests from developers still stuck on the older version. The exercise exposed just how different the two engines really are — not a simple upgrade path, but a near-total rewrite.

The core reasons for staying on 2.x are pragmatic: millions of lines of legacy code, expensive third-party plugins, and projects that are already profitable. For pure 2D games like card games, slot machines, and match-3, 2.x is still perfectly adequate. The developer also notes that the 2.x ecosystem — plugins, tutorials, and commercial frameworks — remains dominant in China's asset stores.

The porting process itself was painful. Scripts had to move from global `cc.xxx` calls to ES6 module imports. Coordinates shifted from `Vec2` to `Vec3`. Shaders required a near-complete rewrite, with different entry points, changed include paths, and stricter batching rules. The 3D puzzle game in the collection had to be dropped entirely — 2.x simply couldn't handle it.

Takeaways
Many production Cocos projects remain on 2.x because migration to 3.x/4.x requires months of work with no direct revenue gain.
2.x is still sufficient for most 2D game genres — card games, slot machines, fishing games, and match-3.
The 2.x ecosystem in China (plugins, tutorials, commercial frameworks) is larger and more mature than 3.x's.
Porting from 3.x to 2.x involves rewriting scripts from ES6 modules to global `cc.xxx` calls.
Coordinates change from `Vec2` in 2.x to `Vec3` in 3.x, even for 2D games.
Color and opacity are handled via `node.color` and `node.opacity` in 2.x, but split into `Sprite.color` and `UIOpacity` in 3.x.
Shader `.effect` files share the same name but require near-total rewrites — different entry points, changed include paths, and stricter batching rules.
3D games built in 3.x cannot be ported to 2.x; the developer had to drop a 3D puzzle game from the collection.
The developer's Collection 1.0 2.x version is available for purchase, with a discount for existing customers.
Conclusions

The decision to stay on 2.x is less about technical merit and more about business risk — a reminder that engine choice is often a financial decision, not a technical one.

The fact that the 2.x ecosystem is still dominant in China's asset store suggests that engine vendors may overestimate how quickly their user base will adopt new major versions.

The shader porting pain — especially the stricter batching in 3.x — reveals that 3.x's rendering pipeline is fundamentally different, not just an incremental improvement.

The developer's willingness to reverse-port a project from 3.8.7 to 2.4 highlights a real gap in the market: there is demand for 2.x-compatible resources that the official ecosystem is not fully serving.

The comparison to Windows 7 vs. Windows 11 is apt — users stick with what works, especially when the upgrade offers no clear benefit for their specific use case.

Concepts & terms
Cocos Creator
A cross-platform game engine popular in China for 2D and 3D mobile game development, similar to Unity but with a focus on lightweight performance and the Chinese market.
cc.Class vs. ES6 Class
Cocos 2.x uses a proprietary `cc.Class` syntax for defining components, while 3.x switched to standard ES6 classes with decorators — a breaking change that requires rewriting all scripts.
Sprite batching
A rendering optimization where multiple sprites are drawn in a single draw call. In Cocos 3.x, per-node uniform modifications can break batching, forcing developers to use workarounds like smuggling data through color channels.
Shader .effect file
Cocos uses `.effect` files to define shaders. Despite the same file extension, the internal YAML structure and include paths differ significantly between 2.x and 3.x, requiring a full rewrite during migration.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗