New Light System and Art Collaboration Tool LookDevHelper (Software Project)

Before I started this project, the lighting system had been around for a long time — but it had serious issues with performance, usability, maintainability, and extensibility. Artists’ complaints were well founded. As the project kept growing, the old system’s limitations became increasingly apparent, and it simply couldn’t meet new production requirements.

So I redesigned and implemented a brand-new lighting system from scratch, and developed an art collaboration tool called LookDevHelper to go alongside it. The goal was to improve the system’s performance, maintainability, and extensibility, while giving artists much better tooling support.

The new light system (LightSystem + art collaboration tool LookDevHelper v1.3) is not just a drop-in replacement that preserves all the old functionality. It’s a full rethinking built on top of the old system — a completely new art workflow, plus a more extensible lighting framework, shaped by real production requirements.

Here are the key improvements the new system brings over the old one:

1. Code logic overhaul: Blueprint node count dropped by 95%, and asset dependencies went from 100+ down to fewer than 10. Fixed logic is encapsulated in C++, making the implementation cleaner and dramatically improving maintainability.
2. Vastly improved extensibility: No more restrictions on light types or categories. No more limits on the number of styles, style names, or style types an individual streamer can have. The data table supports both horizontal and vertical expansion. Sequence configurations are no longer capped at a fixed count. Lighting customization is now free for artists to express themselves — previously the logic was hard-locked.
3. Network sync support: All clients now show consistent results. This wasn’t supported before.
4. Centralized data table: Any change to the lighting data can be pinpointed quickly (previously almost impossible to track). It’s also easy to batch-edit JSON using script tools. Additionally, the shipped package and the editor now share the same parameters — previously they used separate data sets, which created unnecessary manual alignment overhead.
5. Better effect preview: The editor now supports monitoring package-side effects in Editor mode. The runtime implementation unifies what you see at Runtime versus in the Editor — including transition blending and Sequence preview, none of which were supported before (only static preview was available).
6. Artist-maintainable lights: Every generated light body is an independent light Actor (not a Blueprint), which fits naturally into UE’s Actor management model and makes it easy for artists to maintain.
7. Improved tag management: Lights can be grouped into custom categories, making it straightforward to apply different effects and logic to lights with different semantic roles.
8. Legacy data migration support: To ease the transition from old data, I built several migration tools that let teams quickly port existing data during the changeover period.

And more.

The entire project was completed by me alone in approximately 18 person-days, covering all requirements communication, analysis of the legacy system, and implementation of all new features. Total codebase exceeded 30,000 lines of code, plus some mesh and material assets used for collaboration. Roughly 90% of the code was produced by AI + MCP — my role focused on architecture, logic design, requirements organization, and data structure design, as well as reviewing the AI-generated code quality and making necessary revisions and optimizations.

Completing this project has significantly improved the lighting system’s performance, maintainability, and extensibility, laying a solid foundation for future lighting feature development.