Опубликовано: 16.10.2026 | Источник: OpenNET

CSS-рендеринг DOOM в дипломе: 3D-графика без canvas и WebGL

Проект cssDOOM показал то, во что до недавних пор мало кто верил: спрайты, текстурированные стены и целые уровни DOOM можно выводить на экран вообще без элемента <canvas> и без WebGL. Всё построено на стилизованных <div>, размещённых в 3D-пространстве средствами CSS transform и transform-style: preserve-3d, а игровая логика на JavaScript восходит к открытому коду id Software и распространяется под GPLv2. Дата релиза наработок — 28 марта 2026 года.

Для выпускника это не курьёз, а готовая рамка исследования: есть измеримый инженерный компромисс (DOM вместо GPU-конвейера), есть эталон для сравнения и есть общепризнанная игровая логика, которую не нужно писать с нуля. Ниже — как превратить этот кейс в защищаемую главу ВКР, а не в пересказ новости.

Коротко о боли: вопросы, с которыми приходят с этой темой

«Руководитель считает тему игрушкой. Чем её усилить?»

Сместить акцент с «я сделал игру» на «я исследовал метод рендеринга и его границы». Игра — стенд, а предмет — сравнительная оценка производительности клиентской графики в браузере по метрикам ISO/IEC 25010.

«Можно ли брать код DOOM под GPLv2 в диплом?»

Да, но лицензия копилефт: производная работа тоже распространяется под GPLv2. В тексте ВКР нужна отдельная подглава о правовом режиме заимствования, а в приложениях — полный текст лицензии и перечень использованных модулей.

«Как доказать, что DOM-подход вообще имеет смысл?»

Только цифрами: frame time, FPS, число long tasks, количество слоёв композитинга и потребление памяти. Без замеров тема рассыпается на первом же вопросе комиссии.

«Что писать в приложениях — весь движок?»

Нет. По ГОСТ 19.402 и 19.701 в приложения выносится ограниченный набор листингов: точка входа, модуль обновления сцены, сериализация уровня. Остальное — ссылкой на репозиторий с указанием хеша коммита.

Темы ВКР, которые вырастают из кейса

• Тема 1. Движок рендеринга 3D-сцен на CSS-трансформациях.
  Актуальность: cssDOOM доказал принципиальную осуществимость DOM-рендеринга DOOM-подобных уровней, но границы применимости метода не описаны.
  Цель: разработать подсистему вывода 3D-сцены на DOM-элементах с сохранением интерактивности.
  Задачи: обзор подходов (DOM, Canvas 2D, WebGL); проектирование конвейера «геометрия → проекция → слой DOM»; реализация прототипа и уровневого загрузчика; измерение производительности.
  Структура: Гл.1 — анализ методов вывода графики в браузере; Гл.2 — архитектура и реализация движка; Гл.3 — эксперименты и оценка по ISO/IEC 25010.

• Тема 2. Сравнительный анализ методов клиентского рендеринга: CSS 3D против Canvas и WebGL.
  Актуальность: выбор технологии вывода в веб-проекте почти всегда делается «по привычке», без замеров.
  Цель: построить методику сравнительной оценки на едином наборе сцен.
  Задачи: формализовать критерии; собрать три реализации одного уровня; снять метрики; построить модель выбора технологии.
  Структура: Гл.1 — теория рендеринга и композитинга; Гл.2 — стенд и методика замеров; Гл.3 — результаты, регрессия, рекомендации.

• Тема 3. Разделение игровой логики и слоя представления при портировании DOOM на JavaScript.
  Актуальность: открытая кодовая база id Software используется как эталон, но её монолитная структура плохо ложится на современную веб-архитектуру.
  Цель: выделить независимое ядро симуляции и сменные бэкенды рендеринга.
  Задачи: реверс-анализ эталонной логики; проектирование интерфейса рендерера; реализация двух бэкендов; проверка эквивалентности состояний.
  Структура: Гл.1 — анализ исходного кода и лицензии; Гл.2 — проектирование по C4; Гл.3 — тестирование и метрики.

Куда именно вшивать материал статьи в главы

Глава 1: анализ — от статьи к постановке задачи

Опишите cssDOOM как объект анализа, а не как новость. Нужны: краткая история программного рендеринга в браузере, разбор механизма transform-style: preserve-3d, объяснение, почему DOM-узел становится самостоятельным слоем композитинга и как это перекладывает нагрузку с CPU на GPU-композитор. Здесь же — подглава о лицензии GPLv2 и границах заимствования. Итог главы: таблица «метод → сильные стороны → ограничения → применимость».

Глава 2: проектирование и реализация

Основные артефакты — диаграмма контекста и контейнеров по C4, диаграмма классов ядра симуляции, диаграмма последовательности кадра. Конвейер кадра удобно показать ASCII-схемой прямо в тексте:

[Ввод] ──▶ [Симуляция: тик логики (fixed dt)]
                        │
                        ▼
              [Обновление модели сцены]
                        │
        ┌───────────────┴───────────────┐
        ▼                               ▼
[Проекция в экранные            [Отсечение невидимых
 координаты + z-order]           полигонов и спрайтов]
        │
        ▼
[Запись transform в style DOM-узлов]
        │
        ▼
[Композитор браузера → кадр]

В этой же главе — листинг критичного участка. Показывать весь движок бессмысленно, покажите два-три узла, где принимаются архитектурные решения:

/* слой сцены: включаем 3D-контекст и перспективу */
.stage {
  position: relative;
  perspective: 900px;
  transform-style: preserve-3d;
  contain: layout paint;      /* изолируем перерасчёт */
}

/* стена уровня: текстура вместо полигона */
.wall {
  position: absolute;
  width: 64px;
  height: 128px;
  background-image: var(--tex);
  transform-style: preserve-3d;
  will-change: transform;     /* подсказка композитору */
}

/* псевдокод игрового цикла */
function frame(now) {
  const dt = now - state.last;
  state.last = now;
  stepLogic(dt);              // фиксированный шаг симуляции
  projectScene(state);        // мир → экран
  paintDom(state);            // один батч записи style за кадр
  requestAnimationFrame(frame);
}

Ключевое правило, которое стоит защитить в тексте: никаких чтений геометрии из DOM внутри цикла. Все координаты живут в JS-модели, DOM получает только запись style.transform. Иначе получите layout thrashing и просадку кадра в разы.

Глава 3: эксперименты и метрики

Стенд должен быть воспроизводимым: одна и та же карта, три бэкенда вывода (CSS 3D, Canvas 2D, WebGL), фиксированный сценарий прогона, минимум 5 повторов на конфигурацию. Снимайте метрики через Web Performance API:

const frames = [];
let prev = performance.now();

const obs = new PerformanceObserver(list => {
  for (const e of list.getEntries()) {
    console.log('long task', e.duration.toFixed(1), 'ms');
  }
});
obs.observe({ entryTypes: ['longtask'] });

function probe(now) {
  frames.push(now - prev);
  prev = now;
  if (frames.length < 600) requestAnimationFrame(probe);
  else {
    const avg = frames.reduce((a, b) => a + b) / frames.length;
    console.table({
      frameTimeMs: avg.toFixed(2),
      fps: (1000 / avg).toFixed(1),
      p95Ms: frames.sort((a, b) => a - b)[Math.floor(frames.length * 0.95)].toFixed(2)
    });
  }
}
requestAnimationFrame(probe);

Средний FPS сам по себе ничего не доказывает — обязательно приводите p95 и p99 frame time и число кадров, выпавших за бюджет 16,7 мс. Дополнительно фиксируйте количество композитинг-слоёв (панель Layers в DevTools) и объём памяти: рост числа слоёв — типичная плата за DOM-подход, и об этом честно стоит написать в ограничениях.

Чему вы научитесь на этой теме

Во-первых, проектировать конвейер рендеринга и объяснять его на языке архитектуры, а не на языке «так работает». Во-вторых, снимать воспроизводимые метрики и защищать числами инженерный компромисс. В-третьих, корректно работать с чужим открытым кодом под GPLv2 и оформлять заимствования. В-четвёртых, строить модели по C4 и UML и укладывать их в ГОСТ 19.402/19.701. Наконец, в-пятых, писать работу, которую видно в поиске: у темы «реализация 3D-игры на CSS» почти нет русскоязычных методических материалов, а значит, у вашей ВКР есть шанс стать первоисточником.

Источник: Реализация игры DOOM, использующая для отрисовки только CSS (опубликовано 2026-03-28)