The 2D Game UI Kit Checklist
Fourteen element types in five classes, and the state multiplication that makes a finished UI set four to six times larger than the naive count.
You are about to commission a UI set, or generate one, or buy one. The question in front of you is not what style it should be. It is what has to be in the box.
Most kits answer that badly. They contain a beautiful panel, three button treatments and a scatter of icons, and look complete in the preview image. Then at week ten you need a disabled state for the options slider, an empty-slot frame that reads differently from a filled one, and a toast that does not look like a tooltip. None of those exist. The kit was not wrong. It was short.
This article is the manifest: the countable list of interface elements a finished 2D game needs, how many states each takes, and a test that says the set is done. Hand it to whoever produces the art, before they start.
The short version. A complete 2D UI kit is roughly fourteen element types across five classes: containers, controls, indicators, feedback, navigation. The real size of the job is element types times states, and that multiplication usually lands four to six times above the naive count. Build panel, button and bar first, because those three exercise every rule in your system. The kit is done when the element-by-state grid has no blank cells and every screen assembles from it without a new asset.
A kit is measured by coverage, not by the panel
The panel is the asset every kit gets right, because it is the asset in the preview image. Coverage is what you are buying, and coverage is invisible in a preview.
The failure mode is consistent. A missing element does not stop the game, so you fill the gap with whatever is nearest: a button standing in for a tab, a panel for a modal, a tooltip for an error message. Twenty small substitutions produce an interface players call confusing without being able to say why, because two different things on screen look identical.
So evaluate a kit the way you evaluate test coverage. Not "is this good" but "what is not in here". For scale: a character set of idle, walk, run, jump, attack, hit and death comes to about 47 frames, and the UI kit for that game is the same order of magnitude of work. Developers size the character correctly and the interface at a fifth of its real job.
The element manifest: fourteen types in five classes
Group by function, not by screen. Screens change constantly. Functions do not.
| Class | Element | What breaks without it |
|---|---|---|
| Container | Panel | Text sits directly on gameplay and is lost over motion. |
| Container | Modal frame | Blocking decisions look like non-blocking ones, so players click behind them. |
| Container | Tooltip | Every explanation lives in permanent on-screen text or a manual nobody opens. |
| Container | Divider | Dense panels read as one block and scanning cost rises everywhere. |
| Control | Button | The most-touched element has no pressed or disabled feedback, so input feels dead. |
| Control | Toggle | Binary settings become two buttons and the current value stops being obvious. |
| Control | Slider or stepper | Volume, sensitivity and difficulty become text lists that stop matching the game. |
| Control | Slot | Empty and occupied positions look identical, the top confusion in games with containers. |
| Control | Tab or segmented control | Grouped content needs a new screen instead of a switch, and depth grows. |
| Control | List row | Saves, quests and menu entries have no selected treatment, so controller focus shows nothing. |
| Indicator | Bar | Health, resources and progress become numbers, and numbers do not read peripherally. |
| Indicator | Icon set | Categories are told apart only by text, which is slow and fails small. |
| Indicator | Badge or counter | Stack sizes and unread counts need their own layout instead of attaching. |
| Feedback | Toast or banner | Transient events either persist on screen or are never shown. |
| Feedback | Empty and error state | An empty inventory looks like a bug, a failed action like nothing happened. |
| Navigation | Close and back affordance | Players press Escape and hope, and touch players have no exit. |
| Navigation | Scrollbar or overflow cue | Content below the fold is invisible and long lists look truncated. |
Seventeen rows, fourteen or so genuinely distinct types depending on how you count steppers against sliders. Delete the rows your game cannot use: that is your first draft.
State count is the multiplier that breaks the estimate
The naive count is the rows above. The real count is rows times states, and the three classes take different kinds of state.
Interactive elements take input states. Default, hover, pressed, disabled, focused, and selected where relevant. Six, decided once for the whole kit rather than per element.
Containers take variants, not states. A panel usually needs two, a standard surface and a recessed one. A modal frame needs one. Variants are cheap.
Indicators take value states. A bar is not hovered, it is full, low or critical, and if low shows only as a shorter bar, a player watching the center of the screen will miss it. Icons need a normal and a dimmed treatment at minimum.
Now the arithmetic. Six interactive types at six states each is 36. Buttons multiply again by the weight ramp: primary, secondary and ambient at six states each is 18 assets from what the design document calls one element. Four container types at two variants each is 8. Three kinds of bar at three value states each is 9. Two dozen icons at two treatments each is 48. Feedback and navigation, five types at two states, is 10.
That totals 129 assets from a manifest of seventeen lines. The ratio matters more than the number: seven to one here, four to six to one in most projects once you drop what your game does not need. Run the multiplication on your own manifest before you agree a price or a schedule. The number you get is the job. The row count is not.
One more multiplier, found late by almost everyone. Ship the interface at two pixel scales instead of scaling one set and every asset above doubles. Decide it before production.
Nine-slice is the lever that shrinks the number
The count above assumes every asset is drawn at its final size. It does not have to be. A nine-sliced container is one asset that stretches to any size without distorting its corners, so a single panel covers the inventory window, the dialog box and the settings sheet. The same applies to buttons, slots, bars and modal frames. If the term is new, the glossary covers it alongside the other terms in asset specs.
Specify it in the manifest, because it changes what you receive. A flat panel image at one size is a different deliverable from a nine-slice with stated slice margins, and only the second survives a layout change. Ask for the margins in pixels at handoff.
Nine-slice does not reduce the state count. A nine-sliced button still needs six. It removes size variants, not behavior variants, and people expect it to do both.
What a small game can genuinely drop
Most checklists pretend every line is mandatory. That is how a two-person team produces assets for screens that never exist.
Three questions decide it. Does the game have the mechanic at all? No containers means no slot and no badge. Does your input method need this state? Hover is meaningless on a controller or a touch screen, and focus is mandatory on a controller and optional on a mouse. Can an existing element carry the load without ambiguity? A toast can be a small panel of text, provided nothing else on screen is also a small panel of text.
Commonly droppable, as real drops rather than deferrals: tooltips with no numeric stats, tabs in a menu of one screen, scrollbars where every list fits, badges where nothing stacks, the modal frame where every decision is reversible, and the selected state where nothing stays selected.
Never droppable: the panel, the button at full state set, the disabled treatment, at least one bar, the empty-versus-filled distinction wherever there are slots, and a visible way out of every screen. Those six produce the confusion reports when they go missing.
Record the drops. A dropped element written down is a decision. One nobody wrote down is an omission, and six weeks later nobody can tell which.
Build in element order, not in screen order
The instinct is to build the main menu, then the HUD, then the inventory. That order produces a finished pause menu and no health bar, and proves nothing about the system until the budget is spent. Build in this order instead.
- Panel. It sets corner radius, border weight and the inset or outset convention, and everything inherits them. Getting it wrong later means redrawing the kit.
- Button, all six states. Here the state set gets proven rather than assumed. If your disabled treatment is indistinguishable from your ambient weight level, you find out on asset two.
- Bar. The hardest readability case, since it must hold against every environment while the player looks elsewhere. Composite it over your brightest, darkest and busiest scenes before drawing anything else.
- Slot, if the game has containers. It is the only element whose empty state carries meaning.
- Icons, in families. Two or three shape families covering all of them, not a pile of individual drawings.
- Feedback and navigation. Toasts, empty states, close affordances, scroll cues. These change most as the game changes, so they go last.
The reason for this order and not another: the first three elements exercise the palette relationship, shape language, weight ramp and state set together. If any of those four decisions is wrong, three assets tell you and sixty do not. Every other ordering defers the discovery.
The same order applies when swapping a kit in over placeholder interface art, and the mechanics of doing that without breaking layouts are covered in replacing placeholder art.
The manifest template
Copy this, fill it in, send it with the brief. It belongs in the interface section of your art bible, next to the rules governing how the elements look.
# [GAME] - UI Kit Manifest v0.1
## Decided once
Interactive states: default / hover / pressed / disabled / focused / selected
Input methods shipped: [mouse / controller / touch]
-> drop [hover | focused] accordingly
Weight levels: primary / secondary / ambient
Pixel scales shipped: [1] Nine-slice required: [yes / no]
## Containers variants assets
panel (nine-slice) [ ] [ ]
modal frame [ ] [ ]
tooltip [ ] [ ]
divider [ ] [ ]
## Controls states assets
button x [3 weights] [ ] [ ]
toggle [ ] [ ]
slider / stepper [ ] [ ]
slot [ ] [ ]
tab [ ] [ ]
list row [ ] [ ]
## Indicators value states assets
bar x [n kinds] [ ] [ ]
icon x [n icons] [ ] [ ]
badge / counter [ ] [ ]
## Feedback and navigation states assets
toast / banner [ ] [ ]
empty state [ ] [ ]
error state [ ] [ ]
close / back affordance [ ] [ ]
scrollbar / overflow cue [ ] [ ]
## Dropped on purpose
[element]: [reason]
## Totals
Element types: [ ] x states -> Assets: [ ] x scales -> Final: [ ]
The totals line is the point of the document. Fill it in before you commit to a delivery date.
The completeness test
Done is not a feeling. It is three checks, and each one passes or does not.
No blank cells. Lay the manifest out as a grid, elements down the side and states across the top. Every cell holds either an asset or the word "dropped" with a reason. A cell holding neither is what surfaces at week ten.
Every screen assembles from the kit. List every screen the game will have, including those not built yet, and walk each on paper naming the element every part uses. A screen needing something absent from the manifest means the manifest is short, found before the art was produced instead of after.
Every indicator survives three backgrounds. Composite each bar, icon, badge and toast onto your brightest scene, your darkest scene and your busiest scene. Most elements pass the first two and fail the third, because separation against a still background is a different problem from separation against motion.
A fourth check is cheap: nothing in the kit is unused. Coverage runs both ways, and an asset no screen references usually means a screen got cut and nobody updated the manifest.
Generating the set as one bound collection rather than as loose files makes the first check easier to pass, since the elements come out sharing a shape language and a palette relationship by construction. That is how Makko produces interface sets. The manifest is still yours to write and the test still yours to run.
Frequently asked questions
Can I tint states in code instead of drawing them?
For some, yes. Hover and pressed often work as a brightness shift or a pixel offset applied in code, and that legitimately removes assets from the count. Disabled rarely works, because a dimmed element and a low-contrast element look the same and the player cannot tell whether the control is off or just quiet. Focused almost never works, since it must stay visible against every state underneath it. Budget drawn assets for those two and tint the rest.
How do I tell whether a kit is complete before I buy it?
Ignore the preview image and ask for the file list. Count distinct element types, then look for states: one entry per element rather than four to six means the states are not there. Check for a disabled treatment, an empty slot and a scroll cue, since those three go missing most often and predict what else was skipped.
Does controller support change the manifest?
It changes the state set more than the element list. Hover becomes irrelevant, and focused becomes mandatory and highly visible, since focus is the only signal telling a controller player where they are. It also adds one thing most mouse-first kits omit: button prompt glyphs, treatable as an icon family.
Are fonts and text styles part of the kit?
Yes, as a short list rather than a free-for-all. Three sizes and two weights cover almost every 2D game. Decide them alongside the corner radius, since the typeface is part of the shape language, and check each at the smallest size it ships at before anywhere else.
When in the project should the kit be produced?
Write the manifest early, produce the art late. The manifest costs an hour and constrains everything after it, so there is no reason to delay. The art changes more than any other class as the game changes, so making it before the screens are stable means paying twice. Gray boxes at correct dimensions stand in fine, and make the eventual swap mechanical.