Core Concepts

Ongsoo Labs modules share a common foundation through OSL.Core and a consistent Unity integration style.

This page explains the general architecture style used across the asset guides.

Shared Runtime Foundation

OSL.Core provides reusable runtime services that reduce duplicate implementation across modules.

Typical shared concerns include:

Common result and error handling patterns
Logging and diagnostics
Network request/response conventions
Configuration and initialization utilities
Shared helper APIs used by multiple packages

The goal is not to force every module into one large framework. Each module should remain usable on its own, while shared behavior stays predictable across the ecosystem.

Module Independence

Each asset module should be treated as an independent product:

Principle	Meaning
Import only what you need	Do not add unused provider SDKs or sample assemblies to a project.
Keep setup explicit	Prefer setup assets, inspector fields, and editor windows over hidden global state.
Separate runtime and editor code	Runtime assemblies should not depend on editor-only APIs.
Keep public docs product-focused	Public pages should explain installation, usage, and basic troubleshooting only.

Assembly Definition Strategy

OSL packages are designed for .asmdef based Unity projects.

Recommended assembly layout:

OSL.Core: shared runtime contracts and utilities
OSL.<Module>.Runtime: runtime APIs used by game code
OSL.<Module>.Editor: editor windows, import tools, and setup helpers
OSL.<Module>.Samples: demo-only code and scenes
Provider-specific assemblies when a module supports optional SDKs

This keeps optional dependencies from leaking into projects that do not use them.

Soft Dependencies and Scripting Defines

Some modules support platform or provider-specific features through soft dependencies.

For example, a social login module can compile provider support only when the matching SDK and scripting define are present. This avoids forcing every supported provider into every project.

When using soft dependencies:

Import the third-party SDK first.
Enable the module's provider option through its setup window or scripting define.
Confirm Unity recompiles without missing namespace errors.
Test the provider on an actual supported platform.

Configuration Pattern

Most modules use configuration assets and inspector-driven setup to keep runtime behavior explicit and manageable.

Common configuration values include:

Project or environment selection values
Product IDs
Provider client IDs and app IDs
Timeout settings
Module-specific setup options

Do not place private credentials in scenes, prefabs, or public source files.

Logging

The logging layer provides a consistent way to record diagnostics and runtime events during development.

Good logs should answer:

Which module emitted the event?
Which setup value is missing or invalid?
Is the error recoverable?
What should the developer check next?

Avoid logging access tokens, identity tokens, receipts, private keys, or raw secrets.

Integration Philosophy

The Ongsoo Labs integration framework follows a practical rule:

A module should be simple enough to test in a sample scene, but structured enough to fit into a production Unity project.

Table of Contents