10
2026The Scope Creep Purge: What LoL Engine Had to Cut
A good product is built by adding features; a stable product is built by having the courage to delete half of them.
One of the most important parts of building LoL Engine was not adding features, it was deleting them.
At one point, the engine was trying to be too many things at once. It had framework code, game systems, wrappers around Unity features, experimental combat mechanics, character management, questing, UI, scene flow, boot screens, and pieces of specific game ideas all living too close together.
That was useful while prototyping, but it was bloat. It took a deliberate cleanup pass to admit the obvious: LoL Engine should not be a game pretending to be a framework.
Scope Creep
The scope creep was
understandable.
When you are prototyping games, every missing system feels like something the engine should solve. You need a character system, so you add character management. You need quests, so you add a quest service. You need combat, so you add combat events, damage types, dice logic, abilities, and status effects. You need UI flow, so you build a UI service. You need scenes, so you wrap scene management. Each addition seems reasonable.
The problem is what happens after months of that carefree thinking without a plan. The engine stops being a reusable foundation and starts becoming an unfinished game with a generic name.
The CHANGELOG shows that phase clearly.
The First Cuts
Boot, Scene, and UI
Version 0.12.7-beta removed the Boot Screen system.
That system had controllers, UI components, build validators, configuration assets, startup diagnostics, and documentation. It was useful for a specific kind of startup flow, but Unity projects often need their own boot and loading behavior. Keeping it in the engine meant the framework was already making assumptions about presentation.
Version 0.13.0-beta removed the SceneService.
That was another important call. Scene flow is highly project-specific. A visual novel, roguelike, puzzle game, RPG, and menu-heavy mobile game all make different choices around boot scenes, loading screens, additive scenes, addressable scenes, and transitions. Wrapping Unity scene management did not make the engine better. It made it more opinionated.
Version 0.13.1-beta removed the UIService.
Again, the issue was not that UI is unimportant. It is that UI architecture belongs very close to the game. A reusable engine can provide audio, events, saves, localization, and utility services. It should be careful about owning the player’s screen flow.
The Big Purge: Game-Specific Systems
The biggest trim came in 0.14.0-beta.
That release removed 19 game-specific or wrapper systems from Core, the entire GameObjects assembly, related events, persistence data, samples, tests, and documentation.
The removed systems included:
– Interaction
– Dialogue
– Quests
– Combat
– Achievements
– Currency
– Relationships
– Tutorials
– Items and inventory
– AI
– Map
– Environment
– Stats
– Character customization
– Perception
– Character management
It also removed wrapper services for VFX, camera, quests, and spawning.
That was the moment LoL Engine stopped pretending every common game feature belonged in the shared framework.
Some of those systems might become useful in a game someday. Some might become separate packages. But they did not belong in the LoL Engine core.
Killing the Character System
Character systems are especially tempting.
Once you start adding characters, the scope expands quickly:
– Base character classes
– Player characters
– NPCs
– Character factories
– Persistence
– Health
– Stats
– Equipment
– Abilities
– AI hooks
– Animation bridges
– Audio bridges
– Death handlers
– Damage events
That can be valuable in a specific game. It can also become a trap in a general framework.
The CHANGELOG shows a lot of character work: character stats, combat components, NPC types, quest NPCs, shopkeepers, persistence, equipment, critical hits, death handlers, knockback, stuns, and status effects.
The problem was not effort. The problem was ownership.
A game should own what a character means. The engine can provide object pooling, save infrastructure, events, audio, logging, localization, and deterministic utilities. It should not decide the shape of every game’s actors.
Questing System
At one point, the engine had quest data, quest runtime logic, quest services, quest events, quest rewards, quest trackers, quest-giver components, quest UI, quest chains, timed quests, and journal-style examples.
That sounds useful until you ask: useful for which game?
A quest in an RPG, a contract in a strategy game, a checklist in a cozy game, an objective chain in an action game, and a progression task in a mobile game can share concepts, but the actual model is game-specific.
The reusable layer is lower-level:
– Event dispatch
– Save/load
– Localization
– Notifications
– Data models
– Logging
– Time/scheduling
Those let a game build its own quest system without forcing every project into mine.
The Battle Engine and Dice Experiments
Earlier CHANGELOG entries will show a separate Battle Engine with weighted dice, tri-dice rolling for Skill/Light/Shadow, simplified d20 attacks, abilities, pressure, signatures, resonance, tactical systems, power sources, combat styles, resolution, focus, combat logs, and simulators.
That was game design, not engine infrastructure.
In 0.15.4-beta, the entire Battle Engine was removed: around 42 files, plus combat audio config, editor tools, combat documents, balancing sheets, implementation notes, and deprecated combat documentation.
That was the correct cut.
The useful framework idea was not ship my battle system. The useful framework idea was provide deterministic RNG, model/content IDs, saveable odds state, event dispatch, logging, and audio hooks so a game can build its own battle system.
The dice idea did not disappear completely. It moved down to a reusable foundation.
Wrappers Were Also a Problem
Not every bad fit was a giant game system. Some were thin wrappers around Unity features.
Input was one example. Version 0.15.0-beta removed the Input Service because it had hardcoded player actions and UI components. The engine now tells users to use Unity’s Input System directly in game code. If Unity already provides a strong system, LoL Engine does not need to wrap it just to claim another feature. Wrappers have a maintenance cost, and a weak wrapper is worse than no wrapper.
What Stayed
After the trim, the engine kept the systems that make sense as reusable infrastructure:
– Service management
– Configuration
– Setup Wizard
– Events
– Object pooling
– Resource management
– Save/load
– Serialization
– Compression and encryption
– Localization
– Audio
– Time management
– Notifications
– Logging
– Deterministic RNG
Those are systems that many games need but should not have to rebuild from scratch every time. The difference is that they do not decide what your game is.
The Hard Lesson
A framework gets worse when it tries to be impressive by being bigger.
It gets better when it has a clear boundary.
For LoL Engine, the boundary became:
- Keep reusable production infrastructure.
- Cut game-specific design.
- Do not wrap Unity when Unity is already the right API.
- Move specific game ideas into game projects, samples, or future optional packages.
That trim made the engine smaller, but stronger. It also made the Asset Store positioning much clearer: LoL Engine is not a genre template. It is the layer underneath the game.
That cleanup is why LoL Engine is finally something I can explain in one sentence:
LoL Engine is a modular Unity 6 framework for reusable production systems, not a complete game template.
LoL Engine will be available for Unity 6000.0+.
– Asset Store: TBD
– Documentation: TBD