Get AI summaries of any video or article — Sign up free
Obsidian - Lets Talk Learning Curve thumbnail

Obsidian - Lets Talk Learning Curve

Josh Plunkett·
5 min read

Based on Josh Plunkett's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Obsidian’s core TTRPG usefulness comes from Markdown-based note formatting, not programming.

Briefing

Obsidian is positioned as a practical, low-barrier campaign manager for TTRPGs—because most core note-taking features rely on Markdown, not programming. The central claim is that the “you need to code” objection misunderstands what Markdown is: a lightweight formatting syntax (headings, bold, italics, links, callouts) that can be used quickly through shortcuts and right-click menus. For many tables, that’s enough to run sessions faster by keeping stat blocks, encounters, maps, and references tightly organized.

The walkthrough starts by reframing Markdown as the opposite of coding. In “source” view, formatting is just text markers—like underscores or star pairs for italics and bold—while common actions can also be done with keyboard shortcuts such as Ctrl+B or via live preview. Callouts are presented as another example of non-coding complexity: instead of memorizing the underlying symbols, users can insert callouts through right-click menus, then adjust type, colors, and icons visually. Tables and images follow the same pattern. Even when the underlying syntax exists, the interface can generate it (for tables), and images can be added by simply pasting them into the note—then optionally adjusting alignment and size through theme/CSS behavior.

From there, the argument shifts to “how deep do you need to go?” Obsidian can indeed become highly complex through advanced features—custom character sheets, interactive widgets, and “metabind”/JavaScript-style logic. A character sheet example is shown as a case where table-breaking changes can occur when Obsidian updates table behavior. But the takeaway is that this depth is optional. The recommended approach is to focus on what a DM needs at the table: delivering information clearly and quickly, not building software. If someone wants a fully polished character sheet without tinkering, the speaker suggests buying established tools like D&D Beyond rather than constructing custom systems inside Obsidian.

Plugins are treated similarly: they can be powerful, but they don’t require users to learn coding from scratch. Data View is highlighted as a key plugin for dynamically listing notes—such as generating a “get my minis off the shelf” list by scanning for referenced monsters or magic items. The workflow described is pragmatic: copy example queries from community sources, adjust filters to match personal note properties (like a “source type” field), and save them as templates. A query builder wizard in community support channels is offered as a no-code path for common needs like listing notes by tag.

Finally, the transcript emphasizes community and setup. Obsidian TTRPG Tutorial’s Discord is framed as the place to ask beginner questions, use vault-focused discussion (“Vault chat”), and reserve code-heavy talk for an “Advanced chat.” A “starter vault” download is pitched as a fast way to begin with a working folder layout, plugins, and theme settings. The overall message is that Obsidian’s complexity scales with ambition: stay at the Markdown-and-templates level for most campaign management, and only chase JavaScript-level customization if it’s personally rewarding.

Cornell Notes

Obsidian is presented as an effective TTRPG campaign manager that doesn’t require programming for everyday use. Most essential features—headings, bold/italics, links, callouts, tables, and images—come from Markdown and can be applied through shortcuts, live preview, and right-click menus. Advanced functionality (interactive character sheets, metabind-style logic, JavaScript-driven widgets) is optional and can be avoided if the goal is simply to deliver clear information at the table. Plugins like Data View can also be used without coding by copying example queries, adjusting filters, and using a query builder wizard in community channels. The practical path: start with templates and community support, then go deeper only when a specific need demands it.

Why does the transcript insist that Markdown isn’t coding, and what does that mean in practice?

Markdown is treated as a text formatting syntax rather than programming. In source view, formatting appears as simple markers—like underscores or star pairs for italics/bold—while live preview shows the result instantly. Common actions can be done via keyboard shortcuts (e.g., Ctrl+B for bold) or through UI options, so users don’t need to memorize “code” to make notes readable and consistent.

What are concrete examples of “no-coding” features for campaign notes?

The transcript highlights headings (using a hashtag), bold/italics (stars or underscores, plus Ctrl+B), callouts (insertable via right-click menus with adjustable colors/icons), and tables (insertable via an interface that generates the underlying structure). Images are added by pasting directly into the note; removing the “exclamation mark” changes whether the paste behaves like an embedded image or a link. Theme/CSS can further control alignment and sizing without user coding.

How does the transcript draw a line between useful complexity and rabbit-hole complexity?

It acknowledges that Obsidian can support highly interactive character sheets and widgets, including metabind-style behavior and JavaScript. A character sheet example is shown as complex and even fragile when Obsidian changes table behavior. The recommended boundary is DM-focused: if a feature forces the user to stop and debug code during note creation, it’s likely too far for most play needs.

How can plugins like Data View work without learning to write queries from scratch?

Data View is described as scanning a vault for referenced notes (e.g., monsters or magic items) and generating lists/tables dynamically. Instead of writing queries from memory, the workflow is to find example code from community discussions, modify filters to match personal note properties (like a “source type” field), and save the result as templates. A query builder wizard in the community Discord can generate queries by selecting options like “list” and filtering by tags.

What role does community support play in making Obsidian approachable?

The transcript points to a structured Discord with beginner chat and vault chat for non-coders, plus an advanced chat reserved for code-heavy tinkering. Users can ask questions, search prior threads by category, and use documentation links and wizards (like the Data View query builder) to avoid memorizing syntax. A starter vault download is also offered to get users running quickly with a prebuilt folder layout, plugins, and theme settings.

What’s the “DM-first” principle for deciding how much to customize?

Campaign notes should optimize what happens at the table: delivering information clearly and quickly so players can react. The transcript argues that templates, links, and structured notes speed gameplay, while deeper automation is only worth it if it reduces friction rather than adding maintenance overhead. The guiding question is what makes session delivery easier—not what’s technically possible.

Review Questions

  1. Which specific Markdown features (headings, bold/italics, callouts, links, images) does the transcript claim can be used without memorizing syntax?
  2. What workflow does the transcript recommend for using Data View queries—especially how to handle filters and templates?
  3. How does the transcript justify avoiding JavaScript/metabind-level customization for most DMs?

Key Points

  1. 1

    Obsidian’s core TTRPG usefulness comes from Markdown-based note formatting, not programming.

  2. 2

    Keyboard shortcuts (like Ctrl+B) and live preview reduce the need to learn raw formatting syntax.

  3. 3

    Callouts, tables, and images can be added through right-click menus and paste workflows, with UI handling most underlying structure.

  4. 4

    Advanced character sheets and interactive widgets are optional; they can be fragile and often aren’t necessary for running sessions.

  5. 5

    Plugins like Data View can be adopted without coding by copying community examples, adjusting filters, and saving templates.

  6. 6

    Community support channels and a query builder wizard help users generate plugin queries without memorizing syntax.

  7. 7

    The DM-focused test is whether a customization makes table delivery easier; if it adds debugging or maintenance, it’s likely too deep.

Highlights

The transcript treats Markdown as “not coding,” emphasizing that formatting markers are simple text syntax and can be applied via shortcuts and UI menus.
Data View is framed as a practical “shelf list” system: it dynamically generates lists/tables by scanning note references for monsters or magic items.
A key boundary is drawn between helpful automation (links, templates, dynamic lists) and rabbit-hole complexity (metabind/JavaScript character sheets).
A community-driven workflow—copy examples, tweak filters, use a query builder wizard—turns plugin usage into a template-and-adjust process rather than a programming task.

Topics