Buying a Game UI Kit vs Building Your Own

UI is the part of a game almost nobody enjoys making and everybody has to. A kit looks like an easy
saving, and sometimes it is. Here is how to tell which case you are in.

What a kit actually saves

Not the design work — the production work. Drawing a button is quick. Drawing a button in
four states, at three sizes, with a matching panel, a matching slider, a matching checkbox, a matching
dropdown and a matching scrollbar, all in one visual language, is a week.

A kit gives you that week back, provided it is complete. An incomplete kit gives you the awkward
half of the work with none of the easy half.

The single most important feature: 9-slice

9-slicing lets a panel graphic stretch to any size without distorting its corners. Without it, every
differently-sized panel needs its own image.

A kit without 9-slice-ready sprites is close to unusable in a real project, because your dialogue box,
your settings panel and your tooltip are all different sizes. Check that borders are drawn with
consistent margins and that the pack states 9-slice support.

In Unity this means sprites with border values set in the import settings; in Godot, a
NinePatchRect-ready texture. A well-prepared pack ships these already configured.

The states nobody remembers

Every interactive element needs four visual states, and packs frequently ship two:

• Normal — the default
• Hover / focused — essential on desktop, and for gamepad navigation
• Pressed — the feedback that makes a UI feel responsive
• Disabled — the one packs skip, and the one you need for every greyed-out option

If a kit only has normal and pressed, you will be creating the other two yourself in a style you have
to match. That is the work you were trying to avoid.

When to build your own instead

Three situations where a kit is the wrong answer:

The UI carries your identity. If your game’s look is partly its interface — a
diegetic UI, a distinctive art direction, anything where the menus are part of the experience — a
recognisable kit works against you.

You need unusual components. Skill trees, inventory grids, node editors, map screens.
Kits cover the standard set; anything beyond it you are building anyway, and mixing custom components
with a kit’s style is harder than being consistent from the start.

Your game is small. If the whole UI is a title screen, a pause menu and a settings
panel, a kit is more configuration than construction.

Customising a kit without breaking it

Most kits are designed to be recoloured. What works:

• Recolour rather than redraw. A palette shift over the whole kit keeps consistency.
• Change the corner radius, not the layout. Sharper or rounder corners shift the feel
  substantially at low cost.
• Swap the font. Typography changes personality faster than any other single edit.
• Keep the spacing. The kit’s internal padding and margins are usually its most
  carefully judged property; changing them is what makes a customised kit look wrong.

What a complete UI actually contains

Before evaluating any kit, it helps to know the full list. Most projects need more than they expect,
and the gaps are what cost time.

The last row is the one to plan for. Almost no UI kit ships the icons a specific game needs — the
inventory categories, the status effects, the ability symbols. Budget for sourcing those separately in a
matching style.

Layout is the part a kit cannot give you

A kit provides the visual pieces. It cannot provide spacing, hierarchy or flow — the decisions that
determine whether a UI is comfortable to use.

Three principles that matter more than any asset:

• Consistent spacing scale. Pick a base unit (8 pixels is common) and make every gap
  a multiple of it. Inconsistent spacing reads as sloppy even when every element is well drawn.
• One clear primary action per screen. If everything is emphasised, nothing is.
• Group by relationship, separate by function. Related controls sit close; unrelated
  ones get real distance, not a divider line.

Gamepad and touch

Two requirements a mouse-designed UI will not meet, and both are cheaper to handle early.

Gamepad navigation needs an explicit focus state — visually distinct from hover — and
a defined navigation order. Both Unity and Godot support this natively, but the kit must have a focus
visual for it to be legible. Many do not, which means creating one that matches.

Touch targets need a minimum size regardless of visual size: roughly 44×44 points on
iOS, 48×48 dp on Android. A visually small button can have a larger invisible touch area, and this is
usually the right solution rather than making everything bigger.

Scaling across resolutions

The setting that determines whether your UI works on a phone and a monitor: Canvas Scaler
in Unity, set to Scale With Screen Size with a reference resolution matching your design
target, and Match set between 0.5 and 1 depending on whether width or height matters more.

In Godot the equivalent is the project’s stretch mode — canvas_items with an aspect
setting of expand covers most cases.

Test at your extremes: the narrowest phone and the widest monitor you intend to support. Elements
anchored incorrectly will drift off screen at one end or float in the middle at the other, and that is
an anchoring problem rather than a kit problem.

Fonts are the part of a kit you cannot use

Almost every UI kit is mocked up in a font the seller cannot licence to you. Sometimes the kit says so; often the screenshots simply use something the artist had installed. Either way, the font you liked in the preview is frequently not in the download, and swapping it changes the look more than any other single element.

Before buying, find the licence note. If a font is included, check what its own licence permits — a font licensed for the artist’s mockups is not automatically licensed for your shipped game. If no font is included, plan to pick your own early, because a kit’s spacing and panel proportions were designed around specific letterforms and a very different face will need the padding retuned.

Colour: swappable, or baked in?

There are two ways a kit can be built. In the first, every element is a flat sprite with the colour painted into the PNG. Changing the palette means re-exporting every asset, which means going back to the source files, which means you need the source files. In the second, elements are authored in greyscale or white and tinted at runtime, so one sprite serves every state and every theme, and a palette change is a handful of colour fields.

The second kind is dramatically more useful and is worth paying more for. You can tell which you are looking at from the preview images: if the kit shows the same panel in four colourways, it is almost certainly tintable. If every screenshot is one colour scheme, assume it is baked.

Icons, and the count that actually matters

Kits advertise icon counts in the hundreds. The number that matters is how many of them are icons your game needs. A menu needs roughly fifteen: settings, audio on and off, close, back, confirm, cancel, inventory, map, save, load, pause, play, next, previous. A pack of 400 fantasy item icons does not cover a single one of those.

Check that the icons are on a consistent grid, at a consistent optical weight, and supplied as vectors or at a size well above your target. Icons upscaled from 32px are one of the most visible tells of a stitched-together interface.

Sound belongs to the interface too

Very few UI kits include audio, and an interface without it feels broken in a way people struggle to name. You need four sounds to start: hover, click, confirm, and error. They should be short — under 150 milliseconds for hover and click — and quiet enough to sit under dialogue. Budget for these separately rather than assuming the kit covers them.

The integration cost nobody quotes

Assume roughly a day to wire a kit into an existing project properly: importing, setting slice borders where they are missing, building prefabs for each control, hooking up the state transitions, and fixing the two or three sprites whose padding is wrong. That day is still much cheaper than authoring the art, but it should go in the plan. A kit that arrives as loose PNGs with no prefabs can easily take three.

Checklist before buying

1. 9-slice ready, with borders configured
2. All four states for every interactive element
3. The components your game actually needs, not just buttons and panels
4. Source files, so you can add the component the kit lacks
5. Vector or high-resolution raster, so it scales to your target displays
6. A font that is licensed for embedding, if one is included

Our 2D assets section lists which states and components each
UI kit includes. Interface critique is welcome on the 2D art board.