A Per-Asset Notes Workflow for Unreal Engine Teams

Why notes should follow the asset, not the wiki

Every Unreal team has the same documentation problem. The knowledge about a Blueprint lives somewhere other than the Blueprint. It is in a Notion page nobody updated, a Confluence space three reorganisations out of date, a Slack thread that scrolled off the screen, or in one senior engineer's head. The moment that knowledge is more than one alt-tab away from the asset, it stops being maintained, and stale documentation is worse than none because people trust it until it burns them.

The fix is not a better wiki. It is making the documentation live with the thing it describes. If you want a real Unreal Engine team asset documentation workflow, the notes for a Blueprint should open when you open that Blueprint, save when you stop typing, and travel through source control alongside the .uasset itself. That way the docs are reviewed in the same pull request as the gameplay change, and a stale note becomes a visible diff rather than a forgotten tab.

Markdown 4 Blueprints is built for exactly this. It is an editor-only documentation tool that adds a WYSIWYG notes surface inside Unreal, writes each note as a plain .md file under your project's Documentation/Blueprints folder, and auto-detects which note belongs to the asset you are currently looking at. Because the output is plain Markdown sitting in your repository, your existing Git or Perforce workflow handles versioning, blame and review with no extra tooling.

How the per-asset model is laid out on disk

The whole approach hinges on a predictable, mirror-image folder layout, and Markdown 4 Blueprints keeps it simple. A note attached to an asset is written to Documentation/Blueprints/{AssetPath}.md, so the documentation tree mirrors your content hierarchy one-to-one. The note for a Blueprint sitting at a particular content path lands at the matching path under Documentation/Blueprints, which means anyone browsing the docs folder can navigate it exactly as they navigate the Content Browser.

Notes that do not belong to a single asset, such as a system overview or an onboarding page, are written as standalone notes under Documentation/Blueprints/Standalone. That gives you a clean split between per-asset reference material and the higher-level prose that ties systems together, without forcing everything into an artificial hierarchy.

Both kinds of file are ordinary Markdown, so they are reviewable, greppable and diffable. When a reviewer opens a pull request, the documentation change is a readable text diff next to the Blueprint change. Storage path is not even fixed: the plugin exposes a configurable documentation storage path through Project Settings (under the Blueprint Markdown settings), backed by a UDeveloperSettings class, so a team can standardise where docs live across every project.

Auto-detection: the notes switch when you switch Blueprints

The feature that makes this workflow actually stick is auto-detection. Markdown 4 Blueprints loads the documentation that matches the active asset, and it can switch the displayed content as you switch Blueprints. Open one Blueprint and you see its notes; click into another and the panel follows you. There is no manual file-opening step and no risk of editing the wrong document, which is precisely the friction that kills wiki-based approaches.

To work this way day to day, dock the documentation tab alongside your Blueprint editor and leave it open. Open it from the 'Window' menu via 'Blueprint Documentation', or use the button the plugin adds to the Level Editor toolbar and the Blueprint Editor toolbar. With a Blueprint focused, click 'New Note' to start documentation for that asset; type, and the note auto-saves 500ms after you stop, so there is no save ritual to forget.

For a team this turns documentation from a separate chore into a side effect of normal work. You are already in the Blueprint making the change; the note for it is right there, already loaded, and a sentence about what you just altered costs you nothing. Multiply that across a codebase and you get living per-asset documentation that was written by the person who actually knew what changed.

Jump-to-Blueprint: navigating the other direction

Auto-detection handles asset-to-note. The reverse direction matters just as much when someone is reading the docs to understand a system rather than editing a specific Blueprint. Markdown 4 Blueprints offers an optional auto-open of the associated Blueprint when you select a note, so reading the documentation and opening the asset it describes become a single action.

Turn this on when you are onboarding someone or doing an architecture review, where you move through the documentation top to bottom and want each asset to surface as you read about it. A new team member can sit in the notes sidebar, click through the system one note at a time, and have the relevant Blueprint open automatically beside each entry, which is a far gentler introduction than handing them a content folder and wishing them luck.

Because it is optional, you are not forced into it during heads-down authoring, when you would not want every note click to throw open another Blueprint editor. Treat it as a reading mode you switch on, rather than a permanent behaviour.

Organising the sidebar for a real project

Once a project accumulates real documentation, the sidebar becomes the thing you live in, so it is worth setting up deliberately. The sidebar mirrors the same Documentation/Blueprints structure described above, which means the discipline you apply in the Content Browser pays off twice: a tidy content hierarchy produces a tidy documentation tree for free.

Use the expand-all-folders toggle when you need to see the whole tree at once, for instance when auditing which assets still lack notes or when searching for where a system is documented. Collapse it back down for everyday focus so you are only looking at the area you are working in. This single toggle is the difference between a sidebar you scan quickly and one you fight.

Editing notes is plain WYSIWYG: headings, bold, italic, code blocks, tables and images, all without writing raw Markdown by hand. Build tables with the visual table editor in the toolbar rather than typing pipe syntax, insert and resize images through the native file picker, and use the keyboard shortcuts Ctrl+B for bold, Ctrl+I for italic and Ctrl+U for underline. When you do need to remove a note, delete is guarded by a confirmation dialog, so a stray click will not silently destroy documentation that lives in your repository.

It is worth being precise about what this tool is: it is an editor-only authoring tool for documentation that lives in your project, rendered through the engine's built-in WebBrowserWidget and matching the editor's dark theme. It does not render Markdown into your in-game UI at runtime. If you need to display formatted text or documents to players, that is a different job for different tools, covered below.

Shipping the docs out for handoff

Per-asset notes are valuable inside the editor, but sooner or later someone outside it needs them: a publisher doing due diligence, a contractor without your project open, or your own archive of a finished milestone. Markdown 4 Blueprints handles this with a one-click 'Export Notes' action that dumps everything to an external '{ProjectName} Documentation' folder while preserving the same file structure.

Because the export is ordinary Markdown that mirrors your content tree, it drops cleanly into a static-site generator, a docs portal, or simply a zipped handoff bundle. You author once, inside the editor, next to the asset, and you get a portable documentation set out the other end without retyping anything into a separate system.

The whole thing is fully offline with no external libraries and no internet dependency, which matters for studios working behind a locked-down network or under an NDA. Your documentation never leaves your machine unless you deliberately export it.

Where this fits alongside the rest of your toolkit

Markdown 4 Blueprints documents your project for the people building it. It deliberately stops at the editor boundary, so a few sibling tools cover the jobs it does not. They share the same Windows-only, UE 5.5 to 5.7 footprint, which keeps a toolkit consistent.

If you actually need to show a document to the player rather than to a developer, reach for Simple PDF Viewer. It rasterises PDF pages to textures and displays them on in-world meshes or actors, with full page navigation, which is the right tool for an in-game manual, lore book or kiosk. Note that it shows pages as images and is not a text-selectable viewer, so use it for display, not for interactive document editing.

For data rather than prose, Fast Chart Widgets adds a Blueprintable UMG widget that draws eight chart types entirely in Slate, with a library of pre-configured templates you can drop in from the Widget Blueprint toolbar. It is the counterpart for runtime dashboards and debug overlays, where Markdown 4 Blueprints is for static written notes. And when your tools need to talk to a backend, EasyHTTP wraps the engine's HTTP module into clean Blueprint nodes for calling REST APIs, with multiple auth schemes and a built-in local test server. Together they form a small, consistent toolset: write the docs, chart the data, fetch the data, and show the documents.

Which MythicLemon tool for which documentation job

All four are Windows-only and target UE 5.5-5.7. Use this to pick the right tool rather than as a feature ranking.

FAQ