Standalone modules
Use ATT, GDPR, CMP, AppReview, ads, analytics, attribution, liveops, remote config, save systems, and other game services as separate UPM packages.
Provider-agnostic Unity modules for mobile games
Use SDK-heavy game modules without locking your game to providers.
DRG solves the recurring pain of SDK updates and platform flows in Unity games. Add modules for ATT, GDPR, CMP, AppReview, ads, analytics, attribution, liveops, remote config, save systems, and other services. Use them standalone or compose them into a larger architecture later.
- Standalone UPM modules
- No provider lock-in
- Framework optional
Why DRG
The modules are the product. The framework is the direction.
Each DRG package is meant to be useful without adopting a full framework. The framework layer is an evolving concept: a way to compose modules, expose more useful context to LLMs, get better code generation results, and spend fewer tokens explaining the project.
Problems teams search for
When a Unity SDK integration starts spreading through the whole game.
"How do I replace an ads, analytics, attribution, or CMP SDK in Unity without touching every feature that calls it?"
"How do I keep ATT, GDPR, remote config, save systems, AppReview, and liveops flows out of gameplay code?"
"How do I give an LLM enough Unity project context to change a module safely without pasting the whole codebase?"
Features
Ready-to-use modules first. Architecture when you need it.
Provider-agnostic APIs
Game code depends on narrow module interfaces while Applovin, IronSource, Google UMP, and future providers stay behind adapters.
SDK update isolation
When an SDK changes callbacks, setup, privacy rules, or package versions, the fix stays in one adapter instead of every feature.
Use outside the framework
Adopt one useful module without migrating the whole game architecture or committing to the full DRG framework concept.
LLM-friendly direction
The framework layer is being developed to make module contracts, flows, and boundaries easier for LLMs to understand.
Swap, add, remove
Change monetization, analytics, consent, liveops, remote config, or save providers without forcing a game-wide rewrite.
Packages
Install only the modules your game needs.
Core
Provider-independent contracts for signals, commands, service location, logging, and main-thread dispatching.
Logging pageFramework Concept
Optional runtime composition layer for module lifecycle, service scopes, signal buses, Unity bridge code, and richer LLM context.
Framework pageUtils
Main-thread dispatcher, debounced executor, static MonoBehaviour helpers, and out-of-the-box AppReview flow.
com.drg.utils
Save Systems
Provider-neutral typed save records with PlayerPrefs backend, Unity serializer, and Newtonsoft adapter.
Data Storage pageAds
Provider-neutral ads controller, fullscreen ad auction, and adapters for Applovin MAX and IronSource LevelPlay.
Ads pageConsent
ATT, GDPR, and CMP-facing consent contract with Applovin MAX CMP and Google UMP adapter packages.
CMP pageModule pages
Dedicated pages for the main DRG module areas.
Each page targets a specific Unity SDK or game-service pain and keeps the module-first positioning clear for search engines.
Ads
Provider-agnostic monetization, rewarded ads, interstitials, banners, and auctions.
Analytics
Stable game event contracts for analytics, attribution, and liveops providers.
Data Storage
Typed save systems with PlayerPrefs backend and pluggable serializers.
CMP
ATT, GDPR, Google UMP, Applovin CMP, and provider-neutral consent state.
Logging
ILogger contracts for modules, provider adapters, and Unity Debug-backed output.
Framework
Optional module composition and LLM-friendly Unity architecture direction.
Platform roadmap
Upcoming provider-agnostic modules for the DRG platform.
These modules are planned next so the same "integrate once, replace providers later" rule applies beyond ads, consent, and saves.
Install
Add only the modules you want through Unity Package Manager.
Use Git URLs in Unity Package Manager. Start with a concrete module such as Ads, Consent, Utils, or Save Systems, then add the framework concept only if you want composition.
https://github.com/yanmasharski/drg.core.git#1.0.0
https://github.com/yanmasharski/drg.framework.git#1.0.0
https://github.com/yanmasharski/drg.utils.git#1.0.0
https://github.com/yanmasharski/drg.data.git#1.0.0
https://github.com/yanmasharski/drg.ads.git#0.9.0
https://github.com/yanmasharski/drg.consent.git#0.9.0Minimal Unity entry point
public class GameEntryPoint : UnityRuntimeBridge
{
public override IModuleServiceLocator ServiceLocator { get; } = new ModuleServiceLocator();
protected override ILogger Logger { get; } = new LoggerUnity(ILogger.LogLevel.Debug);
protected override void SetupModules(IModuleNode root, IModuleServiceLocator locator, ILogger logger)
{
locator.Register<IMainThreadDispatcher>(new MainThreadDispatcherAdapter());
_ = root.InitializeAsync();
}
}Use cases
A module library for live Unity mobile games.
Use DRG when ATT, GDPR, CMP, AppReview, ads, analytics, attribution, liveops, remote config, and save flows should work out of the box as modules.
Use it when game code should not depend directly on Applovin, IronSource, Google UMP, attribution SDKs, analytics SDKs, liveops SDKs, remote config SDKs, or save backends.
Use it when you want useful packages today and an optional framework path later for better structure and LLM assistance.
FAQ
Questions Unity developers search for.
Is DRG mainly a framework or a module library?
DRG is module-first. The main value is reusable Unity modules for ATT, GDPR, CMP, AppReview, ads, analytics, attribution, liveops, remote config, save systems, and other SDK-backed flows.
Do I need to adopt the DRG framework?
No. Modules are designed to be useful outside the framework. The framework is an optional concept for composing modules and making project context more useful for LLM-assisted development.
Can DRG work with mobile ads and consent SDKs?
Yes. DRG includes provider-neutral ads and consent contracts with adapters for Applovin MAX, IronSource LevelPlay, Applovin MAX CMP, and Google UMP.
Can DRG support attribution, analytics, liveops, and remote config?
Yes. The same provider-agnostic module pattern used for ads and consent is intended for attribution, analytics, liveops, remote config, save systems, and other SDK-backed game services.
Start small