The Early Problem

Earlier versions had systems that made sense for a particular game but did not belong in a general Unity package. The CHANGELOG tells that story clearly.

In version 0.12.7-beta, the boot screen system was removed.

In 0.13.0-beta, the scene service was removed.

In 0.13.1-beta, the UI service was removed.

Then 0.14.0-beta removed a large set of game-specific systems such as quests, achievements, character systems, environment systems, map systems, and other genre-specific layers.

That was not a loss of scope. It was the engine becoming clearer.

Unity already has good primitives for scenes, input, UI, and many game-specific patterns. LoL Engine should not wrap everything just to look complete. The systems that stayed are the ones that tend to be rebuilt, debugged, and hardened across projects.

After the cleanup, the engine’s center became:

– Service management and initialization
– Event dispatch
– Save and load infrastructure
– Audio playback and music playlists
– Resource loading with Addressables support
– Object pooling
– Localization
– Time and scheduling
– Notifications
– Logging
– Deterministic RNG
– Model/content registry utilities
– Probability helpers such as typed pools and anti-pity odds

This is the difference between a template and a framework.

A template says:

Build this kind of game this way.

A framework says:

Here are the systems you are likely to need, with clean boundaries, so your game code can stay yours.

Moving Toward the Release Candidate Phase

The release candidate phase forced another kind of cleanup. For Version 1.0.0-rc.1 I made a decision to lower the Unity baseline to 6000.0, unified editor menu items under Tools > LoL Engine, removed stray shipping files, and corrected public API naming before the 1.0 line froze.

That kind of work is not flashy, but it matters. A framework becomes useful when it is predictable in someone else’s project, not just in my project.

That is also why I describe the LoL Engine as “production-ready systems, not a genre template.” The point is not to replace your game. The point is to remove the repeated infrastructure work around it.

What This Means for Developers using the LoL Engine Framework

If you import LoL Engine, you should be able to start small.

Use the setup wizard. Enable the services you need. Keep the ones you do not need switched off. Add your own game services through the registration hooks. Use Unity’s own systems directly where that makes more sense.

That philosophy shaped the rest of the engine:

– The save system uses pluggable storage backends.
– The audio system supports both simple playback and richer playlist orchestration.
– Localization supports basic key lookup and structured runtime strings.
– Deterministic RNG can be used by games that need reproducibility, but it does not force a genre.
– The Asset Store package declares platform limits instead of pretending every target is equal.

The Dev Log Plan

This dev log series will walk through the main systems and the decisions behind them:

– How service initialization and custom registration work
– Why the save system includes migration, reports, and quarantine
– How the audio system grew into music playlists with crossfade and metadata
– Why localization moved toward structured `LocString` values
– How deterministic RNG, `ModelDb`, and odds utilities help content-heavy games
– What changed during Asset Store hardening, especially around IL2CPP