Стратегия для обсуждения 19 мая 2026 Mobile-first Tanks

Production-ready графика для «Танков»

Как перейти от текущей кодовой/SVG-графики и AI-концептов к красивым, стабильным и проверяемым ассетам, не сломав board-first UX и игровую читаемость.

Не заменяем всё сразу Идём фазами: gallery, board objects, tanks, effects.

Гибридный подход SVG/CSS для точности, raster для художественного качества.

AI не финальный этап Генерация даёт материал, production-ready даёт pipeline.

1. Короткое решение

Нам не нужно выбирать между векторной графикой и красивым raster-art. Для этой игры нужен гибрид: технические слои остаются управляемыми кодом, художественные слои становятся полноценными ассетами.

Оставляем кодом

SVG / CSS / React

UI-иконки, HP bars, подсветки клеток, маркеры, простые служебные объекты.

Делаем артом

Raster PNG/WebP

Танки, камни, аптечки, флаги, дым, взрывы, gallery portraits, splash.

Собираем вместе

Atlas / Sprite sheet

Маленькие повторяющиеся объекты и эффекты, чтобы не грузить десятки файлов.

Крупный арт

Responsive exports

Галерея, reveal и hero получают несколько размеров, а не один тяжёлый файл.

2. Как выбирать формат

Простое правило: если объект должен быть точным и управляемым состояниями, оставляем его кодовым. Если объект должен создавать ощущение качества, фактуры и света, делаем production raster asset.

Тип ассета	Решение	Почему так
UI-иконки, кнопки, glyphs	`SVG` или icon library	Чётко на любом размере, легко перекрасить, минимальный вес.
Подсветки клеток и planning markers	`CSS / SVG`	Это часть игровой логики и состояний, её нужно тестировать и точно позиционировать.
Танки, камни, аптечки, флаги	`PNG/WebP` с прозрачностью	Именно здесь raster даст видимый рост качества: материал, свет, силуэт.
Взрыв, дым, muzzle flash	Sprite sheet	Эффект выглядит живее, но остаётся дешёвым и контролируемым в runtime.
Gallery / reveal / splash	Responsive `WebP/AVIF` + fallback	Большой арт не должен грузиться в одном размере для всех экранов.

3. Целевой pipeline

Production-ready ассет рождается не в момент генерации. Он проходит понятные шаги: brief, batch, style lock, export, manifest, integration, QA. Если asset плохо читается в реальном размере, возвращаемся к brief или style, а не маскируем проблему кодом.

4. Что делает команда на каждом шаге

Это операционная модель. Она нужна, чтобы генерация не превратилась в бесконечное «ещё один красивый вариант», а каждый принятый asset можно было проверить и откатить.

Art brief

Фиксируем место ассета, размер в интерфейсе, состояния, фон, iPhone constraints.

Concept batch

Генерируем 8-20 вариантов одного направления, а не один случайный финал.

Style lock

Закрепляем ракурс, палитру, тень, детализацию, правила повреждений и эффектов.

Production source

Храним master-исходник отдельно от оптимизированного runtime export.

Export + manifest

Задаём размер, anchor, версию, состояние и файл, который реально грузит игра.

Visual QA

Проверяем на целевых viewport, в игре, рядом с маркерами и текущей UI-обвязкой.

5. Дорожная карта внедрения

Не начинаем с полной замены всех runtime sprites. Сначала берём зоны с высоким визуальным эффектом и низким игровым риском, затем двигаемся к полю и эффектам.

Style Bible

Одна страница visual direction: палитра, свет, top-down перспектива, размер в клетке, approved/rejected примеры.

Gallery и Splash

Быстрый визуальный скачок без риска для hit testing. Уже есть raster gallery pipeline.

Board Objects

Камни, аптечки, флаги. Проверяем центрирование, clipping, contrast с markers, editor placement.

Tanks

Самый важный слой: сторона, направление дула, damaged/destroyed states, размер на 9x9/13x13/17x17.

Effects

Muzzle flash, impact explosion, smoke/fire, heal pickup. Проверяем timing, layer order и читаемость поля.

6. Definition of Done для ассета

Ассет не считается production-ready, пока он не прошёл не только художественный отбор, но и техническую проверку в реальной игре.

Есть source или source pointer.

Есть runtime export, который реально грузит игра.

Есть manifest entry: размер, anchor, версия, состояния.

Asset читается на 393x852 и не размыт.

Центр совпадает с центром DOM-клетки.

Маркеры selected/reachable/shot не конфликтуют с картинкой.

Bundle size не вырос неожиданно.

Есть screenshot/contact sheet и понятный rollback path.

7. Риски и защита

Главный риск: мы получим красивые отдельные картинки, но игра станет хуже читаться. Поэтому защита строится вокруг style lock, manifest, visual QA и маленьких фаз.

Риск	Как защищаемся
Красивые ассеты ухудшат читаемость боя.	Проверяем не на preview, а в реальном размере клетки на mobile viewport.
Разные AI-генерации дадут разный стиль.	Сначала Style Bible и style lock, потом batch внутри одной системы.
Raster увеличит вес приложения.	Atlas, compression, lazy-load и responsive exports для крупного art.
Тени и прозрачность сломают ощущение hit testing.	Логика выбора остаётся на DOM-клетках, anchor задаётся явно в manifest.
Темы начнут конфликтовать с артами.	Gameplay assets получают theme compatibility gate, особенно для notebook.
Ручная оптимизация будет забываться.	Экспорт и сжатие автоматизируются, проверка веса входит в gate.

Внешние источники и best practices

web.dev: Responsive images - responsive images, srcset, sizes и оптимизация доставки изображений.
web.dev: Image performance - WebP/AVIF, компрессия, DPR и управление количеством вариантов.
MDN: Including vector graphics in HTML - практическая разница между raster и vector graphics.
Unity Manual: Sprite Atlas workflow - почему маленькие спрайты группируют в atlas.
Apple HIG: Images - изображения для экранов с разной плотностью пикселей.
Apple HIG: Icons - простота, узнаваемость и консистентность interface icons.

Эта HTML-версия самодостаточна: схемы встроены в страницу, поэтому её можно открыть локально без отдельной загрузки картинок.