Combo documentation has always been the awkward cousin of competitive play. You know the line, your teammates know the line — but the moment you try to write it down, you lose detail, context, or both. That gap between 'I know how to play this' and 'I can communicate how to play this' is exactly what we set out to close.
Why diagrams matter more than text lists
A plain ordered list of card names captures what happens but not why. It doesn't tell you which monster to target with which effect, when a hand trap changes your routing, or which branch you take if your opponent has Ash Blossom. A visual diagram, with each step as a discrete node, forces you to be explicit about those decisions.
When we studied how competitive teams were documenting combos before YGO Combo Builder existed, most used spreadsheets, Google Docs, or Discord threads with long bullet-point chains. The problem: anyone re-reading the combo three weeks later had to reconstruct the spatial and conditional logic from scratch. A visual representation cuts that mental overhead dramatically.
The original drag-and-drop problems
Our first pass at the combo editor had a draggable card list on desktop that worked reasonably well. On mobile it was a different story. Touch drag events would fire inconsistently — a slow press would trigger a scroll instead of a drag, and fast swipes would jump cards two positions instead of one. Players who built combos on the go, between rounds at locals or on the bus, kept running into the same frustrations.
The second issue was render performance. Every drag operation caused the entire card list to re-render because state updates were triggering too high in the component tree. On lower-end Android devices, that produced a visible stutter that made fine-grained reordering feel unreliable.
What changed
We isolated drag state into a self-contained context that only the active drag item and its immediate neighbour need to subscribe to. The rest of the list is stable during a drag. That single change eliminated the stutter on every device we tested, including mid-range Android phones from 2021.
For touch handling, we replaced the generic HTML drag API with pointer events. Pointer events fire consistently across mouse, touch, and stylus inputs, and we added a 150 ms press threshold so a quick tap-to-select doesn't accidentally initiate a drag. The threshold is short enough to feel instant but long enough to distinguish intent.
We also added snap-to-grid positioning in the diagram view. When you drop a card, it snaps to the nearest grid slot rather than floating at an arbitrary pixel offset. This keeps diagrams readable when exported as images or PDF, which is important for players who print lines for in-person testing.
Step annotations and branching notes
The most-requested feature from competitive players was the ability to annotate individual steps. Not every step in a combo is mechanical — some require a judgment call, a priority decision, or a note about what the opponent is likely to do. The annotation field on each card node is deliberately free-form so players can write anything from a one-word reminder to a multi-sentence explanation of the branch condition.
For teams prepping for specific matchups, annotation fields also double as matchup notes. You can flag exactly which step in your combo is vulnerable to Nibiru, which step your opponent's Ghost Belle will most likely target, and what your recovery line looks like if the interactive step resolves incorrectly.
Exporting and sharing diagrams
Diagrams export as a clean image with card thumbnails, step numbers, and annotations intact. The exported image is optimised for Discord sharing — it fits in the Discord preview without needing to click through, and the card thumbnails are large enough to read at a glance on a phone screen.
Public combos are also indexed on the Combos page, which means teammates can browse your shared lines without needing an account. The diagram viewer on public combo pages is read-only and renders the same visual layout as the editor, so there's no translation loss between what the author built and what a reader sees.