> For the complete documentation index, see [llms.txt](https://docs.kouch.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kouch.dev/docs/adr/0025-realistic-controller-icons-in-kouch.md). # 0025: Kouch ships realistic controller-type icons, logos stripped * Status: accepted (owner overrule, 2026-09-29: "i need like authentic controller icons, not just drawn shit, like the ones that look very close or the same, but with logos stripped". Asked to choose between realistic icons only in `.kod` files, realistic icons shipped with Kouch, or a better generic set, they chose "realistic icons FOR controllers shipped with kouch".) * Plan: `docs/CONTROLLER_TYPES_PLAN.md` (T3) * Relaxes: ground rule 1 (no third-party console imagery in Kouch's own assets), for controller-type icons only * Related: ADR 0009 (Workshop themes may carry device imagery), ADR 0024 (a `.kod` may carry its own icons) ## Amendment, 2026-09-29 (the same evening): the source and style The owner pointed at the style they want: flat, single-colour device icons tinted per player, "icons HAVE to look like this", from **Kenney's Input Prompts pack** (, "use from like here"). So: * **Source:** Kenney's Input Prompts 1.5, **CC0 1.0** (public domain; credit to Kenney is optional, and Kouch gives it in About's credits). Its `License.txt` is kept beside the icons. No generated renders are used. * **What we take:** only the controller-body icons that match Kouch's classes, renamed to neutral class names (`remote-upright`, `remote-sideways` (the upright icon turned 90°), `remote-attachment`, `classic-pad`, `pro-pad`, `split-pair`, `split-half` (a half turned 90°), `standard-pad`, `touchpad-pad`, `trackpad-pad`, `handheld`, `keyboard`, `mouse`, `cube-pad`, `tablet-pad`). Never the pack's logo, wordmark or button-glyph icons. * **Style:** white vector shapes, drawn by the UI as masks in theme colours (the player's colour on the connect screen and the accent in pickers). No gradients, so they fit the built-in theme as they are. * **Checks done before commit:** each chosen SVG was rendered and inspected (no marks, no letters, no logos), and none contains text, fonts or embedded images. The rest of the decision stands: the Simple line icons as a setting, neutral names, controllers only, and the recorded risks. **Button glyphs (owner, the same evening: "also glyphs, default to steam controller").** * **Shipped glyphs:** Kouch also ships the pack's **Steam Controller** button glyphs (face buttons, d-pad, bumpers, triggers, sticks, grips, pads, menu/view) as its own glyph set, under neutral names (`glyph-south`, `glyph-lb`, …). * **The default:** Settings › Controllers › Button glyphs is **Steam Controller**. **Auto** (each pad's own family, as Steam supplies at run time) stays a choice. * **Why Steam's family is fine:** Steam is Kouch's own platform, and its controller's glyphs are what Steam Input already shows. * **Other families' glyph images stay out of Kouch's assets:** they come only from Steam at run time (`glyph_get`), as before. The keyboard keeps its keycaps. ## Amendment, 2026-09-30: d-pad, keyboard glyphs, cursors and a few UI icons These are all Kenney CC0 packs, imported under the same rules: paths only, neutral names, the licence file alongside, and each image checked before commit. * **D-pad glyphs:** from the pack's **Steam Deck** set. The owner: the Steam Controller set's d-pad "does not match the actual one from 2026, the dpad in the steam deck one matches". * **Keyboard prompts:** Kenney's **Keyboard & Mouse** glyphs replace the drawn keycaps (owner: "use kenny's glyphs for keyboards"). This supersedes "the keyboard keeps its keycaps" above. * **Cursors** (Kenney **Cursor Pack**): * the motion pointer is a hand per player: pointing, closed while A is held, open at rest, tinted in the player's colour with a dark outline; * Kouch's mouse cursor is the pack's shaded arrow (`pointer_b_shaded`), everywhere, with no switch to a hand over clickable items. The owner chose it by picture from a comparison page, then asked for the arrow alone: a hand over clickables only if it matches the arrow's style. * **UI icons** (Kenney **Game Icons** and its **Expansion**): * the owner compared every UI icon side by side and kept Kouch's own line icons ("mostly all of our icons are better"); * four switch to Kenney's: players (a gamepad), friends, online play, and chat (the Cursor Pack's speech bubble); * new icons come from the packs: signal bars for connection strength, cloud and cloud sync, controller and handheld tilt, achievements, a ranking, recenter, and locked; * the Expansion's hand "pointer" icon was declined. * None of these packs has brand marks. The Game Icons packs include generic lettered button icons (A/B/X/Y, L1/R1, START); those aren't taken. ## Context Controller types (CONTROLLER\_TYPES\_PLAN) show an icon on the game page, in the picker and in the Quick Menu. The owner finds line drawings too plain and wants icons that look like the real controllers: the same shapes and proportions, without logos. Ground rule 1 keeps third-party console imagery out of Kouch's own assets. A controller's shape is recognisable even without a logo (its trade dress), so realistic icons raise the risk the rule guards against: * a store-policy problem on Steam; * a takedown request; * confusion about affiliation. In 2023 an emulator was pulled from Steam over a platform holder's objection (key material, not imagery, but the same holder). ## Decision * **Kouch's own assets may include realistic controller-type icons:** illustrations of controllers as players hold them. Each is drawn for Kouch: made by us, or generated and then reviewed by us. Never copied from photos, press kits, manuals or anyone's artwork. * **Limits, all required:** * **No marks of any kind:** no logos, wordmarks, button-face lettering that spells a brand, console names, or packaging. Each icon is checked for marks before it's committed. * **Neutral names:** file names, ids and labels use Kouch's classes (`remote-sideways`, `remote-attachment`, `classic-pad`, `pro-pad`, `split-pair`, `split-half`, `standard-pad`, …). Brand-lint and the commit-msg hook still apply to all of them. * **Controllers only:** no consoles, screens, box art or game imagery. * **Illustration rules:** PNG or WebP at a few fixed sizes (icon and picker card), transparent background, one consistent illustration style across the set. They're art, like cover art, so the built-in theme's no-gradient/no-shadow rule for UI chrome doesn't apply inside the image. * **The simple set stays:** the in-house line icons (T3's drawings) remain, used when an icon is missing and as a user setting, Settings › Display › "Controller pictures: Realistic / Simple". The default is Realistic, as the owner asked. * **Profiles and `.kod` files** keep choosing an icon by class (`kouch:`), or carrying their own (ADR 0024). ## Risks, recorded * **Trade dress:** a platform holder could object to shapes that closely match its controllers, even without logos. Answer: switch the default to Simple or remove the set in an update. Nothing else depends on it. * **Steam review:** a reviewer could read realistic controller art as implied affiliation. The store page and screenshots use the Simple set or no controller imagery at all (a GO\_PUBLIC\_CHECKLIST item and a store-asset rule). * **Generated art can hide marks:** each icon is inspected at full size before commit, and the review is recorded in the commit message. ## Consequences * A second icon set to keep in step with the classes: every class needs both a realistic and a simple icon. * Brand-lint can't see marks inside images, so the review step is manual and required. * If the risk materialises, the owner can switch the default to Simple and the realistic set can be removed without code changes elsewhere. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kouch.dev/docs/adr/0025-realistic-controller-icons-in-kouch.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.