EA Color Theme Generator

Building color schemes manually is one of those tasks that looks simple from the outside but quietly eats hours. You’re eyedropping colors, checking contrast, building out tints and shades, making sure everything holds together as a system. For a team working with game IP — where every title has its own visual world — doing that from scratch for every asset is a real time sink. So I built a Figma plugin that does it for you.

How it works

You upload an image — a game screenshot, a character render, a key art piece — and the plugin extracts the primary color and builds out a complete color scheme from it. You can organize these into color groups as needed. The preview renders at 2x resolution so what you see in the panel actually looks good, not just functional.

One technical detail worth noting: Figma plugins can’t access locally installed fonts for security reasons — otherwise a plugin could theoretically interfere with files on someone’s machine. To get around this without hosting the font externally, I converted the font file into Base64-encoded data embedded directly in the plugin. It’s fully self-contained, so every user sees the right typography the moment they install it, no setup required and no external dependency to break.

Why it matters

The manual version of this workflow — eyedropping colors, building tints and shades, checking that everything holds together — is the kind of work that’s easy to underestimate until you’re doing it for the twentieth time. This plugin compresses that into seconds and keeps the output consistent. For designers working across multiple game titles, each with their own visual identity, that consistency and speed compounds quickly. Less time matching colors, more time making things.

Applying this to your project

1. What to clone and what to discard. Copy manifest.json, code.ts, ui.html, package.json, and tsconfig.json — that’s the whole plugin. Discard code.js (it’s a build artifact regenerated by npm run build; it’s even excluded in .gitignore), and swap out EAColorGeneratorPreviewImage.png / ea-figma-icon.png for your own preview image and plugin icon.

2. No environment variables or API keys needed. This plugin makes zero external network calls — manifest.json explicitly sets networkAccess.allowedDomains to "none". All color extraction happens locally via the browser <canvas> API on pixels the user already uploaded. If you extend this to call an external service (e.g. a hosted color-naming API), you’ll need to add real domains to that allowedDomains array or Figma will silently block the request.

3. What to rename/rebrand.

   • In manifest.json: change name to your plugin’s name, and generate a new random-looking id (Figma assigns these; don’t reuse 1481766140618943519).
   • In code.ts: the default style group name 'EA Colors' (line with groupName: string = 'EA Colors') is hardcoded — change this to your own namespace so generated Figma paint styles don’t collide with someone else’s “EA Colors” group.
   • In ui.html: search for any “EA”-specific copy, headings, or button labels in the visible HTML (not just the script) and swap for your own product name.

4. Critical integration points — where content plugs in.

   • The UI (ui.html) and the plugin’s main thread (code.ts, compiled to code.js) only talk to each other via figma.ui.postMessage / figma.ui.onmessage. If you want to add a new color source or workflow, you send a message of shape { type: 'create-color-styles', colors: {...}, sourceType, groupName } from ui.html and handle it in code.ts’s figma.ui.onmessage handler.
   • Colors are plumbed through as { r, g, b } objects in the 0–1 float range Figma’s Paint API expects (not 0–255) — see the ColorData interface and SolidPaint object in code.ts. If you’re generating colors elsewhere, convert to this range before sending.
   • formatStyleName() in code.ts branches on sourceType ('manual' vs. image-extracted) to decide whether a color is labeled “Base (0%)”, “40%”, “Dark”, etc. If you add a third color source (e.g. a palette import), you’ll need a new branch here or names will fall through to the generic capitalize-first-letter fallback.

5. Non-obvious gotchas.

   • There’s no color library (chroma.js, tinycolor2, etc.) — HSL↔RGB conversion is hand-rolled in ui.html (hslToRgb / rgbToHsl). If you need more color operations (contrast ratios, LAB space, etc.), you’re extending this math yourself or pulling in a library and updating manifest.json’s network policy if it’s CDN-loaded.
   • The canvas is rendered at devicePixelRatio internally but displayed at CSS pixel size (see the dpr scaling around the canvas setup in ui.html) — any new code that reads mouse/hover coordinates off the canvas needs to apply the same DPR correction or color picking will be off on high-DPI (Retina) displays.
   • createColorStyle() in code.ts checks figma.getLocalPaintStylesAsync() for an existing style with the same groupName/styleName path before creating a new one — re-running the plugin updates existing styles in place rather than duplicating them. Preserve this dedupe check if you refactor style creation, or every re-run will pile up duplicate styles.
   • The plugin auto-closes itself 1.5 seconds after creating styles (setTimeout(() => figma.closePlugin(), 1500) in code.ts). If you add more post-creation UI (e.g. a success screen with next steps), you’ll need to remove or extend this timeout.