CrimsonExperience
An Experience is a data asset that answers one question: what is this session made of? It lists the Game Feature plugins to activate and the UGameFeatureActions to run, and the plugin drives them through a replicated load state machine. Swapping a match for a lobby, or a lobby for a front end, becomes a matter of pointing at a different asset rather than writing a different AGameMode.
The value is composition. A Game Feature action that adds an inventory component does not know a skill tree exists; an Experience that lists both gets both. Adding a system to a mode never means editing the mode's C++.
This plugin does not ship a GameMode
It ships the experience machinery - the assets, the manager component, and the policy. You point your own
AGameStateBase subclass at UCrimsonExperienceManagerComponent and your own AGameModeBase at an experience id. Quick Start walks exactly that.What's included
| System | Key types | Purpose |
|---|---|---|
| Experience assets | UCrimsonExperienceDefinition, UCrimsonExperienceActionSet | What a session is made of. The action set is a reusable bundle shared across experiences. |
| Load state machine | UCrimsonExperienceManagerComponent, ECrimsonExperienceLoadState | Replicated component that loads assets, activates plugins, runs actions, and announces completion. |
| Front-end descriptor | UCrimsonUserFacingExperienceDefinition | Tile metadata (title, icon, description) plus the hosting request for a mode the player can pick. |
| Ready signal | UAsyncAction_ExperienceReady | Blueprint async node that fires once the experience is fully loaded. |
| Feature policy | UCrimsonGameFeaturePolicy | The project's GameFeaturesManagerClassName. Decides client/server data loading. |
| PIE arbiter | UCrimsonExperienceManager | Engine subsystem that reference-counts plugin activation so PIE clients and server do not fight. |
| Pawn data anchor | UCrimsonPawnDataBase | Empty base an experience points at, so this plugin never learns what your pawn data contains. |
| Actions | UCrimsonGameFeatureAction_SplitscreenConfig | Turns splitscreen off for the duration of an experience. |
Plugin dependencies
| Group | Dependency | Why |
|---|---|---|
| Crimson plugins | None | Fully standalone. Loading-screen styling and session hosting are exposed as hooks; CrimsonCore wires them. |
| Engine plugins | GameFeatures | UGameFeatureAction, UGameFeaturesProjectPolicies, the features subsystem. |
| Engine plugins | ModularGameplay | UGameStateComponent, the base of the manager component. |
| Engine modules | GameplayTags | The loading screen tip category tag. |
| Engine modules | UMG | The soft widget class on the loading screen block. |
| Engine modules | NetCore | Replication of the current experience. |
Which path do I choose?
Setting a project up for the first time -> Quick Start. Need the subsystem, component or asset in hand -> How-To: Get the Building Blocks. Want a mode the player can pick from a menu -> How-To: Add a Front-End Experience. Something depends on the experience being live -> How-To: Wait for the Experience.
Using with other Crimson plugins
CrimsonExperience works on its own. When you own other Crimson plugins, CrimsonCore (free to download, but compiles only with all Crimson plugins installed) contains the full-suite wiring for it in
Source/CrimsonCore/.../Integration/Experience/: UCrimsonCoreExperienceStatics turns a UCrimsonUserFacingExperienceDefinition into a session hosting request, and UCrimsonCoreExperienceLoadingScreenBridge styles loading screens from each experience's LoadingScreen block. To wire it yourself, read CrimsonCommon -> Concept: Connecting Crimson Plugins; to see how CrimsonCore does it, read CrimsonCore -> Concept: The Integration Layer.Show Plugin Content
Plugin content is hidden in the Content Browser until you tick Settings -> Show Plugin Content. Any
/PluginId/... path in these pages needs it on.