1. What You Get
What Common Game System is, the 23 services it gives your project, and what it deliberately leaves out.
1.1 What is Common Game System?
Common Game System (CGS) is a C# foundation framework for Unity 6.3 LTS. It gives your project the plumbing every game needs — saving, audio, input, scene loading, timers, tweening, and more — as 23 ready-made services.
All 23 services start automatically when you press Play. One bootstrap component registers them before your first script runs. There is nothing to drag into a scene and nothing to configure. Your code simply asks for a service and uses it:
[SerializeField] private AudioClip clickClip;
private void OnButtonClicked()
{
var audio = ServiceLocator.Resolve<IAudioService>();
audio.PlaySfx(clickClip);
}
CGS is code-only. It draws nothing on screen and imposes no art style, no genre, and no project structure. You keep writing your game the way you like; CGS handles the machinery underneath.
1.2 The problem it solves
Most Unity projects start the same way: a "Managers" folder. A SaveManager copied from the last project. An AudioManager written from memory. A singleton for time scale, a helper for fading, a half-finished object pool. Each one is rewritten per project, rarely tested, and wired together differently every time.
CGS is that folder, finished. Every service is:
- Consistent. Every service is reached the same way, through one locator. Learn the pattern once and you know how to use all 23.
- Tested. The framework ships with 2,600+ automated tests. You can import and run them yourself (see chapter 3).
- Documented. Every service has its own reference page under
Documentation/Modules/in the package — and the same reference lives online as the service reference on this site. - Replaceable. Every service sits behind an interface. You can swap in your own implementation, or switch a service off entirely, with one line (see section 1.4 below).
1.3 The 23 services at a glance
Each service is an interface. The tables group them by what they do for your game. Every service name links to its full reference page.
Saving and settings
| Service | What it does for you |
|---|---|
ISaveService | JSON save files with named slots. Writes are atomic, so a crash never corrupts an existing save. |
IConfiguration | Typed settings groups (audio volume, graphics options, and so on) that persist between sessions. |
IAchievementService | Local player stats and achievements. Achievements unlock automatically when their stat crosses its threshold. |
Input and UI
| Service | What it does for you |
|---|---|
IInputService | Reads gamepad and keyboard input through named action maps ("Gameplay", "Menu"), with interactive key rebinding. |
IInputKeyMapSource | Supplies the input actions asset and stores the player's rebinding changes. |
IPanelStack | Pushes and pops UI panels (menus, dialogs) and keeps gamepad and keyboard focus on the right panel. |
ILocalizationService | Looks up display text by key and switches language at runtime — no restart needed. |
Audio, scenes, and assets
| Service | What it does for you |
|---|---|
IAudioService | Plays music, sound effects, and voice through an AudioMixer, with per-channel volume control. |
ISceneService | Loads scenes asynchronously with a loading screen, cancellation, and additive load and unload. |
IAddressableSceneService | Loads additive scenes that live in Addressables content instead of the build list. |
IAssetProvider | Loads Addressables assets and counts references, so an asset is released only when no one still uses it. |
Timing and motion
| Service | What it does for you |
|---|---|
ITimeService | Separate clocks for gameplay, UI, and background work. Pause or slow gameplay while menus keep animating. |
IScheduler | Timers: run something after a delay, every interval, or next frame. Also runs work on the main thread. |
ITweenService | Animates any value over time with 31 easing curves. Tweens pause when the game pauses. |
ITweenSequenceService | Chains tweens into ordered or parallel timelines, like an intro animation with several steps. |
Logic and utilities
| Service | What it does for you |
|---|---|
ILogger | Categorized, filterable logging that replaces scattered Debug.Log calls. |
IEventBus | Type-safe publish and subscribe. Systems talk through events instead of direct references. |
IDeferredBus | Queues events now and delivers them later, when you say so — useful during loading or cutscenes. |
IObjectPoolService | Reuses prefab instances (bullets, particles) instead of creating and destroying them every time. |
IRandomService | Seeded random numbers with named streams. Results are repeatable and survive a save and load. |
IStateMachineService | Builds simple state machines for AI or game flow, with enter, exit, and transition rules. |
IPushdownStackService | Manages nested game states — for example, a pause screen layered over gameplay, then cleanly removed. |
ICommandRegistry | A runtime command registry for developer consoles and cheats. You supply the console UI; a working example is included. |
1.4 Every service has an off switch
Each service ships with a "null" twin: a version that accepts every call and does nothing. If your project already has an audio solution, turn off the CGS one in a single line:
ServiceLocator.Replace<IAudioService>(new NullAudio());
The rest of the framework keeps working. Any code that talks to the audio service still compiles and runs — it just produces silence. The same one-line switch exists for all 23 services, and the same mechanism lets you substitute your own implementation instead of a null one (chapter 7 lists them all).
1.5 What CGS is not
Knowing the boundaries up front saves you time:
- No gameplay content. There are no characters, inventories, damage formulas, or levels. CGS provides mechanisms; your game provides the content. (A small RPG-shaped sample shows how the pieces combine.)
- No rendering. CGS contains no shaders, materials, or pipeline code. It works identically with URP, HDRP, and the Built-in pipeline.
- Single-player, PC-focused. CGS targets single-player games on Windows, macOS, and Linux. There is no networking layer and no mobile or console platform work.
1.6 Requirements
- Unity 6.3 LTS. CGS is built and tested on Unity 6.3 LTS.
- Three common Unity packages, each optional. The Input System package (used by the input service), uGUI (used by the UI panel stack and the demo scene), and Addressables (used by the asset and addressable-scene services). The Input System and uGUI ship with new Unity projects, and importing this package installs anything missing — including Addressables — through its dependency list, so most users need to install nothing by hand.
CGS is split into seven assemblies. The core assembly holds 18 services and depends on nothing except Unity itself. The other assemblies each wrap one optional package. If you remove a package — say, Addressables — its CGS assembly quietly excludes itself from compilation. The rest of the framework compiles and runs unchanged, and the UI panel stack degrades to a safe do-nothing service if uGUI is gone. You never see an error wall because of a missing optional package. The full assembly map is in chapter 7.1.