usourcecontrol

2.6Shared plugins

Promote a subfolder to a plugin, mount it into your other projects, and update it deliberately.

Section 6 of 7 in this chapter

Studios accumulate things worth reusing: a character controller, a material library, a dialogue system. The usual fate of those things is a copy in every project, three of which have diverged and one of which has the bug fix.

A plugin is a subfolder of one project, promoted so other projects can mount it. The source of truth stays in one place and flows outward.

        CombatKit  (lives in ToolsProject)
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
     MyGame      SpaceGame     Prototype
   /Plugins/    /Plugins/     /Plugins/
   CombatKit    CombatKit     CombatKit

   edits flow down, never back up
Figure 2-5. One plugin, one home, mounted into as many projects as you like. Changes flow one way.

Creating one

The app detects folders containing a .uplugin and offers to promote them. Once promoted, the subtree syncs one way: from the plugin's home project out to everywhere it is mounted.

Updates are explicit, and this is deliberate

Syncing a project checks its plugins and queues what is available, exactly the way incoming file changes are queued. Nothing is written into your working tree until you say so.

A silent plugin update is one of the worst things that can happen mid-session: your project changes underneath you, in code you did not write, while you are debugging something else. The Plugins button in the sidebar carries a badge when a mounted plugin is behind its source, and it waits for you.

Sharing across organizations

A plugin can be granted to another organization by slug — useful for a contractor, a partner studio, or a toolkit you sell. The consumer pays for their own storage of it, and revoking the grant cascades: the plugin stops flowing immediately.

Was this helpful?

Back to top