Overview
The getting-started guides cover how to do things; the API reference covers what exists. This section covers the part in between: which of several available approaches to reach for, and why. These are the opinions the engine's own development settled on — several of them learned the hard way during the modernization and platform-porting work, and written down here so you don't have to rediscover them.
Text Rendering
Cocos2d-Mono has two fundamentally different ways to put text on screen, and choosing the wrong one is the single biggest "works today, bites you at porting time" decision in the engine — because the difference only becomes visible when you target a new platform.
Content Pipeline or Not
Both packages ship the identical engine runtime (Cocos2DMono.dll). The only difference is build-time: the main package declares a dependency on MonoGame.Content.Builder.Task (the MSBuild task that compiles .mgcb content projects), and Cocos2D-Mono.Core does not.
Collections & Allocation
The engine's per-frame code (vertex assembly, particle updates, child traversal) runs hundreds of times per second — allocation there becomes garbage-collector pressure, and GC pauses become dropped frames. CCRawList is the engine's answer, and it's public API you can use in your own hot paths.
Platform-Specific Code
Cocos2d-Mono multi-targets DesktopGL (Windows/Linux/macOS), WindowsDX, Android, and iOS from one codebase, and the engine's platform story keeps growing. Two rules keep platform-specific code from rotting.
Saving Game Data
Three different needs, three different answers: settings go in CCUserDefault, game-state saves are yours to format, and one engine API must be avoided entirely.
Scene & Node Lifecycle
The samples all follow the same structural conventions; this page states them outright.