Привет. Я пресс атташе команды ГИГАХРУЩ — браузерный survival horror / ARPG shooter про вылазки внутри безграничной бетонной структуры.
Да, звучит как питч из папки после этого меня точно забанят, поэтому начну с технической части. Это не Unity WebGL, не Phaser, не Godot export, не React‑обвязка вокруг canvas и не набор купленных ассетов. Игра собрана как один браузерный билд на TypeScript/Vite, WebGL/canvas, процедурных текстурах, процедурных спрайтах, процедурном звуке и плоских структурах данных.
Идея была простая и неприятная: сделать не красивую демку на три комнаты, а живой survival loop, где игрок готовит еду, воду, патроны и документы, уходит в вылазку, встречает NPC, монстров, фракции, торговлю, квесты и самосбор, а потом возвращается не в абстрактный хаб, а в мир, который помнит последствия.
В этой статье не будет «мы сделали революционный продукт, поставьте звезду». Будет другое: как маленькая браузерная игра постепенно превратилась в инженерный мешок с WebGL‑рейкастером, A‑Life, процедурной генерацией, локальными сохранениями, самодельным HUD и миллиардами токенов черновиков, проверок, правок и выброшенных вариантов.
Почему браузер
Потому что установка убивает импульс. Человек увидел странную игру про самосбор, нажал ссылку, загрузил страницу, умер в коридоре. Идеальный сценарий.
Браузер при этом сразу ставит рамки:
нельзя рассчитывать на тяжелый runtime;
нельзя прятать долгую загрузку за лаунчером;
нельзя раздать полгига ассетов и надеяться, что игрок терпелив;
нельзя забыть про pointer lock, fullscreen, mobile viewport, iframe-хосты и localStorage;
нельзя делать вид, что WebGL/canvas сами решат UX.
Поэтому базовое правило проекта стало таким: ноль runtime‑зависимостей, один браузерный билд, максимум данных и поведения из кода.
Это сильно отрезвляет. Если у тебя нет папки с ассетами, то текстуры должны родиться процедурно. Если нет нормального 3D‑движка, то камера и мир должны быть достаточно простыми, чтобы держаться на raycasting и фейках. Если нет ECS‑библиотеки, то сущности должны быть плоскими объектами, а мир — typed arrays и маленькие регистры.
Мир как данные, а не сцена
Главная ошибка, которую хотелось не повторять: делать «уровень» как коллекцию красивых объектов. Для хоррора это приятно, но для survival loop быстро становится мертвым декором.
В ГИГАХРУЩЕ мир описывается как клеточная поверхность с комнатами, коридорами, дверями, признаками, текстурами, контейнерами, сущностями и событиями. Рендер читает состояние, системы меняют состояние, генераторы строят состояние. Никакая картинка не должна владеть геймплеем.
Пример разделения:
coreхранит примитивные формы и World;dataхранит определения предметов, оружия, фракций, квестов, монстров;genстроит этажи, POI, комнаты, маршруты и начальное размещение;systemsобновляют AI, бой, квесты, экономику, самосбор, сохранение;renderтолько рисует.
Звучит скучно, но это как раз та скука, которая спасает игру от превращения в кашу. Когда появляется новый странный этаж, монстр или терминал, он не должен лезть в главный цикл и говорить: «Я особенный, вызовите меня вручную из main.ts». Он должен лечь в существующий контракт.
Рейкастер вместо честного 3D
Честный 3D был бы красивее. Еще он был бы дороже, тяжелее, дольше и потребовал бы другой pipeline.
Для ГИГАХРУЩА важнее не геометрическая честность, а решение игрока:
вижу ли я коридор;
понимаю ли я, где опасность;
могу ли я оценить дверь, цель, NPC, укрытие;
успеваю ли я испугаться до того, как меня съели.
Поэтому используется WebGL raycasting с процедурными поверхностями, спрайтами и canvas HUD. Картинка не пытается конкурировать с AAA. Она делает другое: быстро показывает бетонный лабиринт, дистанции, туман, вспышки, монстров, метки, кровь, интерфейс и события.
Самая полезная мысль тут: фейк нормален, если он рождает то же игровое решение.
Если игрок обходит темный проем, потому что там слышен чужой шаг, ему не важно, сколько полигонов в этом проеме. Ему важно, что решение было понятным и страшным.
Процедурные ассеты как дисциплина
Когда ассетов нет, исчезает соблазн решить проблему картинкой из интернета. Это больно, но удобно.
Текстуры стен, пола, следы, пятна, шум, спрайты монстров, многие визуальные пакеты и звуковые события генерируются из кода. Плохо сгенерированная картинка выглядит бедно, зато хорошая процедурная картинка умеет быть системной:
ее можно привязать к типу комнаты;
ее можно менять после самосбора;
ее можно использовать как след события;
ее можно сделать дешевой для билда;
ее можно воспроизводить по seed.
Да, иногда это выглядит грубо. Зато грубость честная: она не маскирует пустоту высоким разрешением.
A-Life без театра одного игрока
Я не хотел делать мир, где NPC появляются из воздуха рядом с игроком, а потом исчезают, когда он отвернулся. Поэтому A‑Life устроена как компактный слой идентичностей.
В начале новой игры создается большой пул процедурных жителей. На активном этаже материализуется только нужная часть: живые NPC, их инвентарь, отношения, фракции, занятия, смерть, память о событиях. Остальные остаются компактными записями, а не симулируются покадрово в фоне.
Это компромисс между «все честно симулируем всегда» и «все вокруг игрока — декорация». Полная симуляция всего мира была бы дорогой и бесполезной. Полная декорация убила бы ощущение жизни.
Ключевые правила:
обычные NPC не восполняются бесконечным спавнером;
смерть остается фактом;
фракционные и экономические события могут оставить след;
текущий этаж живет полноценно, остальные хранят компактное состояние;
игрок участвует в тех же социальных числах, что и NPC.
Когда игра начинает помнить, кого ты убил, кому помог, где украл и кто после этого перестал торговать, даже грубый интерфейс внезапно получает вес.
Самосбор как мутация мира, а не эффект на экране
Самосбор — центральная угроза. Его легко было сделать как красивую заставку: включить сирену, наложить красный фильтр, заспавнить монстра, снять HP.
Но тогда это был бы просто погодный эффект.
В текущей модели самосбор — локальная мутация мира: предупреждение, герметизация, проверка укрытий, давление, монстры, последствия, перестройка части пространства и события, которые потом остаются в состоянии этажа.
Это важно для ощущения: игрок не пережил «ивент», он пережил изменение места. До него комната была маршрутом, после него стала проблемой. До него дверь была проходом, после него стала границей. До него NPC был торговцем, после него может стать записью в памяти мира.
Почему не «ИИ написал игру»
Потому что это плохая история и плохая инженерия.
LLM в проекте используется много. Очень много. На уровне «если посчитать все черновики, ревью, планы, проверки, переписывания и выброшенные варианты, счет ушел в миллиарды токенов». Это смешно звучит, и, наверное, именно эта фраза гарантированно разозлит часть людей.
Но важная деталь: токены не компилируются.
Компилируется TypeScript. Работает WebGL. Падает typecheck. Ломаются тесты. Не сходятся контракты. Генератор может закрыть комнату. Сохранение может забыть состояние. HUD может стать нечитаемым. Игрок может не понять, что делать в первые две минуты.
LLM здесь не «автор игры», а шумный ускоритель итераций, черновиков и ревью. Он хорошо производит варианты и плохо несет ответственность. Ответственность остается в коде, тестах, локальных правилах проекта и ручной проверке.
Самый неприятный урок: нейросетью легко нагенерировать контент, но трудно сохранить архитектурный вкус. Поэтому у проекта жесткие внутренние правила:
не добавлять новый runtime без причины;
не тащить геймплей в рендер;
не расширять enum под каждый красивый термин;
не делать refill NPC, который стирает последствия;
не писать новый системный слой ради одного POI;
не обещать в README то, чего нет в билде.
Именно эти скучные ограничения важнее любого «вау, AI».
Что уже есть в текущем билде
Сейчас это не финальная игра, но уже не прототип с одной кнопкой. В браузерном билде есть:
подготовка к вылазкам: еда, вода, патроны, медицина, документы;
бой, оружие, PSI и монстры;
процедурные и авторские этажи;
фракции, торговля, экономика и караваны;
сюжетные и побочные задания;
A‑Life NPC с перманентными смертями;
самосбор с предупреждениями, укрытиями и последствиями;
localStorage‑сохранение;
canvas HUD, карта, лог сообщений, настройки интерфейса;
опциональная НЕТ‑СФЕРА через Cloudflare Worker/D1, если включить онлайн‑контур.
Отдельно смешно, что самая тяжелая работа оказалась не в «сделать монстра», а в «сделать так, чтобы игрок понял, что сейчас вообще можно делать».
Что болит
Первый запуск. Интерфейс. Читаемость. Темп вылазки. Плотность текста. Баланс между «я ничего не понимаю» и «я хочу разобраться».
Системы уже умеют больше, чем новый игрок способен принять за первые десять минут. Это типичная болезнь игры, которая долго росла изнутри: разработчик видит связи, игрок видит шум.
Поэтому сейчас приоритет не в том, чтобы добавить еще двадцать монстров. Приоритет в том, чтобы один живой путь был понятен:
проснулся в жилой зоне;
взял еду, воду, патроны;
понял ближайшую зацепку;
вышел в вылазку;
получил опасность;
принял решение;
вернулся или умер с понятной причиной.
Когда этот путь работает, поверх него можно строить странность. Когда он не работает, вся процедурность превращается в дым.
Зачем я это тащу на Хабр
Потому что мне интересна не только реакция "нравится / не нравится игра", а техническая проверка: где такая архитектура выглядит разумной, а где я сам себе построил бетонный гроб.
Мне особенно интересны три темы:
насколько оправдана ставка на zero-runtime browser build для игры такого типа;
где лучше проводить границу между симуляцией и кинематографическим фейком;
как не дать LLM-ускоренной разработке распухнуть в набор красивых, но несвязанных систем.
Если хочется просто посмотреть, что это за странность, игра запускается в браузере:
Игра ГИГАХРУЩ (запустится в браузере)
А если хочется ругать — лучше ругать конкретно: первый запуск, HUD, WebGL‑картинку, A‑Life, procedural generation, самосбор или саму идею survival horror в браузере без движка.
ГИГАХРУЩ все равно уже существует. Теперь вопрос в том, получится ли сделать из этой бетонной массы игру, в которую человек не только зайдет из любопытства, но и вернется после первой смерти.
Комментарии (39)

GrigorGri
03.06.2026 14:40Зачем я это тащу на Хабр
Потому что мне интересна не только реакция "нравится / не нравится игра", а техническая проверка: где такая архитектура выглядит разумной, а где я сам себе построил бетонный гроб.
Попытался оценить\почитать статью но что-то больше вопросов чем комментов.
Вообще раз уж статья уже о "вайб кодинге", я бы посоветовал хотя бы статью писать руками, выглядело бы получше.
Многие мои вопросы как раз поэтому больше к кривым формулировкам не несущим никакого смысла чем о статье, была бы написана по настоящему может дискуссия вышла бы интересней.
Рейкастер вместо честного 3D
Честный 3D был бы красивее. Еще он был бы дороже, тяжелее, дольше и потребовал бы другой pipeline.
А чего не честного в рекйастинге? Рейкастинг это просто запуск лучей, это вполне себе часть честного 3д. Судя по всему вы имели в виду систему билбординга. Где все персонажи это спрайт который всегда на игрока повернут.
В начале новой игры создается большой пул процедурных жителей. На активном этаже материализуется только нужная часть: живые NPC, их инвентарь, отношения, фракции, занятия, смерть, память о событиях. Остальные остаются компактными записями, а не симулируются покадрово в фоне.
Если честно вообще не понятно о чем речь идет. Не все рендерятся? Они сгенерированы но "замарожены"? В чем разница генерации когда нужно против генерации с самого начала?
Что болит
Первый запуск. Интерфейс. Читаемость. Темп вылазки. Плотность текста. Баланс между «я ничего не понимаю» и «я хочу разобраться».
Системы уже умеют больше, чем новый игрок способен принять за первые десять минут. Это типичная болезнь игры, которая долго росла изнутри: разработчик видит связи, игрок видит шум.
Поэтому сейчас приоритет не в том, чтобы добавить еще двадцать монстров. Приоритет в том, чтобы один живой путь был понятен:
проснулся в жилой зоне;
взял еду, воду, патроны;
понял ближайшую зацепку;
вышел в вылазку;
получил опасность;
принял решение;
вернулся или умер с понятной причиной.
Когда этот путь работает, поверх него можно строить странность. Когда он не работает, вся процедурность превращается в дым.
Я попытался поиграть но чет вообще не понятно о чем игра и что делать надо. В первые 3-4 минут ничего не произошло ни зацепило. Поговорил, получил задание, побродил. Где оружейния не понятно, зачем я там тоже не понятно. Врагов, движа не увидел.
Миникарта есть но кстати тоже сложно читаемая, стенки сливаются с разными текстурами пола.
Отдельно смешно, что самая тяжелая работа оказалась не в «сделать монстра», а в «сделать так, чтобы игрок понял, что сейчас вообще можно делать».
Не понятно чего тут смешного, но логично. Фичи нужно минимизировать и полировать, а не генерировать больше и больше.
Поэтому базовое правило проекта стало таким: ноль runtime‑зависимостей, один браузерный билд, максимум данных и поведения из кода.
Это сильно отрезвляет. Если у тебя нет папки с ассетами, то текстуры должны родиться процедурно. Если нет нормального 3D‑движка, то камера и мир должны быть достаточно простыми, чтобы держаться на raycasting и фейках. Если нет ECS‑библиотеки, то сущности должны быть плоскими объектами, а мир — typed arrays и маленькие регистры.
Опять все это выглядит как то бесмысленно. Если нет ECS то нельзя рендерить не билборды? или о чем речь идет?
И вернемся к
Потому что мне интересна не только реакция "нравится / не нравится игра", а техническая проверка: где такая архитектура выглядит разумной, а где я сам себе построил бетонный гроб.
О какой архитектуре речь идет не понятно, в статье практически ничего о ней не сказано, исходников тоже не видно.
Вообще тема мне немного близка. В индустрии давно работаю и делаю себе проект для души тоже.
Тоже выбрал браузер для input-output но вся логика на бэкенде .net. То есть, есть webserver который всю логику обрабатывает и браузер который все рендерит. Идея в том, что браузер легко использовать как часть интеграции автоматических тестов (с помощью playwright), итерации намного быстрее чем в Unity. Идея в том чтобы в итоге если взлетело можно будет очень легко перенести на Unity. Unity-подход также диктует и сносную архитектуру рендеринга, компоненты, game objects, это все.
Полный отход от ассетов имхо это скорее слабость чем что то позитивное. Есть генерация ассетов и они выходят намного лучше в среднем чем генерация их через код. Для 2д билбордов можно использовать pixellab например. Они дешевые и можно тысячи нагенерировать если хочется.
В целом для проекта я бы посоветовал следующее. Меньше фичей, больше внимания к каждой фиче. Сместить фокус на геймдизайн, определить циклы, вовлечение, удержание внимания. Убедиться что игроку в первые 1-3 минуты придется делать что то важное и будет понятно как.

TENEVIK Автор
03.06.2026 14:40Спасибо за столь детальный фидбек!
По крайней мере на этот комментарий вам ответит человек.)
По поводу рейкастера, имелся в виду игровой мир, который представляет собой двумерную плоскость. Так сказать "2.5" как в думе или wolfenstein. Мы осознано отказались от трёхмерности, чтобы достичь наиболее чистой и элегантной эмерджентной архитектуры игрового мира.
Имеется в виду, что полная симуляция мира происходит только на активном этаже, остальные этажи намеренно замораживаются, иначе бы невозможно было создать живой гигахрущ с сотней тысяч жителей.
Да, вы правы, это проблема с которой сталкивается большинство игроков Гигахруща - непонятно, что делать. Игра позиционируется как песочница симулятор гигаструктуры, но мы понимаем, что любому игроку нужна зацепка и осязаемый геймплей луп, так что работает над этим.
Почти все фичи в игре являются частью монолитной единой системы основная проблема которой это слишком широкий размах, но с каждым обновлением цельная картина собирается всё больше и больши, и мы надеемся, что в скором времени сможем показать вам тот Гигахрущ, который соответствует видению большинства любителей вселенной Самосбора.
Мы отказались от всех готовых систем, в том числе и ECS, потому что сама игра представляет собой и движок и систему. Основная парадигма игры в том, что Гигахрущ существует без игрока и живёт своей жизнью, игрок здесь не Бог и не царь, а самый обычный житель, причём далеко не самый сильный.
Спасибо ещё раз, архитектура игры Гигахрущ это предмет отдельного разговора и следуя вашему комментарию мы опубликуем полноценный текст посвящённый именно архитектурной организации Гигахруща. Поверьте, там есть про что рассказать в деталях.
Мы используем web для мультиплатформенности и наиболее широкой доступности игры. Поскольку Самосбор как культурный феномен зародился в интернете в анонимных онлайн сообществах, игра Гигахрущ следует этой традиции и позиционируется как абсолютно бесплатный, анонимный браузерный опыт. Надеемся, что и новые игроки смогут через Гигахрущ приобщиться к хаотичной культуре анонимных имиджборд.

Wesha
03.06.2026 14:40Взаимоисключающие параграфы детектед

получится ли сделать из этой бетонной массы игру, в которую человек не только зайдет из любопытства, но и вернется после первой смерти.
Я — не зайду. Например, потому, что игра рассчитана на людей с идеальным зрением —
текст без лупы не прочитать


TENEVIK Автор
03.06.2026 14:40Спасибо за фидбек, постараемся увеличить шрифты, где это необходимо.
Также спасибо за указание про мышку, имелся в виду курсор мышки, тоже поправим.

avttrue
03.06.2026 14:40Мышиного курсора нет - так и задумано? Текст не помещается в диалоги, обрезается. В ячейках инвентаря какой-то текст скролится, не смог прочитать, очень мелко. Не смог выйти из интерфейса первого контейнера. Дальше играть не смог.

LyuMih
03.06.2026 14:40Первое впечатление по улучшениям:
- Шрифт сисстемный 100% увелчивать. Раза в три.
- Если есть возможность, сделать чуть лучше шрифт на стенах - менее размытым на расстоянии
- Уменьшить скорость поворота чувствительности мыши. У меня она как реактивная поворачивается
- Подсказка "Кликните по экрану" - на двух языках. Если я выбрал Русский, то оставьте подсказку только на русском
- ДОБАВИТЬ (пожалуйста) кнопку-подсказку с горячими клавишами куда-то в UI (вверх или вниз). Кнопку настроек, если она есть. "?" например в правый нижний угол.
- Ну и улучшать, тестировать, и ещё раз улучшать UI текстов. У меня часто накладывались надписи друг на друга
TENEVIK Автор
03.06.2026 14:40Благодарим за детальный фидбек
- поменяем шрифты
- шрифты на стенах это отдельный случай кодового преобразования текста в текстуры, постораемся улучшить, но не гарантируем быстрого решения
- чувствительность мыши можно менять в настройках клавиш, но если вы меняли и не помогло, то это реальная проблема
- хорошо, это не выглядит принципиальной проблемой, но можем исправить
- поняли, сделаем по классике олдскула - на F1 окошко мини туториал со всеми клавишами
- да
Ещё раз благодарим за ваше время, надеемся, вы продолжите играть в Гигахрущ, апдейты выходят регулярно!

ApxuTechTop
03.06.2026 14:40Почему решили на голом WebGL, а не с использованием three.js например?

TENEVIK Автор
03.06.2026 14:40Решили на голом WebGL не потому, что three.js плохой, а потому что ГИГАХРУЩ не строит обычную 3D-сцену с мешами, ассетами и камерой. Это кастомный raycasting-рендер под конкретную симуляцию: процедурные текстуры, процедурные спрайты, canvas HUD, typed-array мир и один браузерный билд без runtime-зависимостей.
Three.js дал бы удобства для типового 3D, но здесь большую часть его абстракций пришлось бы обходить или подстраивать. Голый WebGL дает прямой контроль над пикселем, памятью, draw calls, стилем картинки и интеграцией с игровой логикой. Для проекта важнее минимальный слой между симуляцией и изображением, чем универсальный движок поверх браузера.
Коротко: three.js хорош для общей 3D-графики, а здесь нужен узкий, контролируемый и процедурный renderer под конкретную игру.

Hrodvitnir
03.06.2026 14:40Ну вы бы хоть отвечали сами, ей богу)
А то игру навайбкодили, статью генерировали и в комментах тоже с нейронкой отвечаете)

TENEVIK Автор
03.06.2026 14:40Мы просто не всегда знаем, что лучше ответить, поэтому по техническим вопросам обращаемся к помощи агентов.

domix32
03.06.2026 14:40нельзя раздать полгига ассетов и надеяться, что игрок терпелив;
ну какой-нибудь doom3 тянет и ничего. главное покэшировать не забыть, что второй раз не перекачивать, а сразу грузить.
нельзя делать вид, что WebGL/canvas сами решат UX.
не понял причём тут UX. Это дизайнераская проблема, не техническая.
Это сильно отрезвляет. Если у тебя нет папки с ассетами, то текстуры должны родиться процедурно.
ну поглядели б как тот же emscripten делает виртаульную файлуху. С одной стороны текстурная генерация добавляет новизны, с другой - загрузка ассетов заменяется генерацией ассетов - не сказать чтобы сильно более лёгкая задача, разве что чуть более стабильная по времени.
Если нет ECS‑библиотеки,
то что мешает её написать? кажется не настолько космическая задача. Добавить пулы/арены, добавить типизацию, добавить генеративных индексов чтобы переиспользовать убитые компоненты и будет тебе счастье.
делать «уровень» как коллекцию красивых объектов.
непонятно что это значит. пропсы на уровне в том или ином виде всё равно появятся. не обязательно делать их все полезными.
Рейкастер вместо честного 3D
так рендеринг картинки сводится либо к raycast либо к raymarch. Что одно, что другое будет "честным" 3D, т.к. честный 3D это проекция сцены на 2D плоскость экрана.
Демка выглядит неплохо для прототипа, но определённо есть проблемы:
поворот камеры мышью очень медленный. не мышью тоже
нет не мышиной кнопки назад, хотя чисто с клавиатуры кажется удобнее играть. повесьте хотя бы на backspace.
подписи/надписи не слишком контрастные. Что там можно рассмотреть в меню торговли - непонятно. быстрым решением будет сделать интерактивные элементы кнопкой с фоном. в том числе и для интерактивных элементов на сцене.
система диалогов несколько странно работает. иногда пункты диалогов просто не реагируют на ввод. кажется не хватает пункта "уйти"
для предметов в инветаре не хватает какого-нибудь окошка с информацией о предмете. в магазине тоже. Плюс к порогу входа для новчиков.
Есть миникарта которая крутится во все стороны. Было бы нелпохо сделать хотя бы минимальный компас, чтобы понимать направление. А то прапор выдал мне квест про северную сторону, а я и хз где север искать, когда всё уже сто раз по всем осям повернулось.
уберите с сайта здоровенную картинку в начале и прибейте канвас в начале страницы, а не как щас - спустя пол экрана торчит половинка невидимого канваса. смотрите как на itch делают, например.
- чувствительность мыши можно менять в настройках клавиш, но если вы меняли и не помогло, то это реальная проблема
а где их искать-то? in-game меню нет, а при старте там нет конфигурации.

Teneviker
03.06.2026 14:40Критиковать каждый может. А что вы сами делали?

domix32
03.06.2026 14:40Всякое разное делал. Включая игры. Только вам-то моё зачем? Я открыл, поиграл, дал фидбэк.

TENEVIK Автор
03.06.2026 14:40Спасибо вам за столь детальный фидбек!
Но у нас не дум 3, а процедурный рогвелайк симулятор Гигахруща!
Да, это факт, Гигахрущ как игра довольно сурова и не слишком дружелюбна к игроку.
Да, решили генерить всё процедурно и постепенно развивать проекту по модульной системе - однообразные контент пакеты.
Мы решили придерживаться дата ориентед подхода, нпц не создаются (за редкими исключениями) и не исчезают, и являются такой же честной частью мира как и сам игрок.
Да, у нас это делает в три этапа - сперва генерится геометрия этажа, потом назначенные комнаты заполняются декорациями, а уже после на существующие декорации навешиваются интеракционные маркеры.
Имеется в виду, что в игре нет стен, нет потолка, а есть только двумерные плоскости этажей, так что Гигахрущ является честной 2д игрой с триде рендером (как дум и вольфнштайн) это было осознанное решение на самом низком уровне при заложении архитектуры игры.
- даже при настройки чувствительности мыши?
- в настройках клавиш можно выставить доп кнопку для назад, но придумаем, что можно сделать (просто так поставить какую-то клавишу на назад не выйдет, потому что в игре присутствует ввод текстов)
- спасибо, попробуем улучшить кнопки
- логично, добавм меню выхода из диалога (это интерактивное меню)
- постараемся добавить, но вроде в инвентаре справа должно быть описание предмета- постараемся разобраться, но вроде миникарта не крутится и север фиксирован наверх
-попытаемся пофиксить
Ингейм меню на ENTER

domix32
03.06.2026 14:40Да, у нас это делает в три этапа
на кдпв у вас там какое-то мясо было и я подумал у вас там полноценные модельки и текстуры 2к. Поиграв, понял что в таком формате как есть вообще не проблема. Carry on.
2д игрой
2d игрой зовут игры в которых степеней свободы всего две - либо вверх вниз, либо влево вправо. Какой-нибудь meat boy, teleglitch или binding of isaac - 2D. У вас же полноценный 3D - камеру можно крутить во всех 4 направлениях. Модельки с псевдо трехмерностью, да.
- даже при настройки чувствительности мыши?
chrome windows - мышиная скорость была адекватная. linux/ firefox 151 - скорости сильно не хватало, переключение раскладки на русский ломает все буквенные кнопочные действия, отсутствует звук. firefox 145 windows - мышиная скорость была нормальной, но ощущались просадки fps при повороте камеры.
- спасибо, попробуем улучшить кнопки
работа с инвентарём и с торговым интерфейсом отличается. Взаимодействие с ящиками (положить предмет в инвентарь или из него) рисует ложную подсказку про [E] вместо [Enter]. В интерфейсе торговли этих подсказок нет вовсе. Тоже работает через Enter. Вообще для предметных интерфейсов очень хочется мышью поорудовать, но курсора в них вы пока нам не завезли.
но вроде в инвентаре справа должно быть описание предмета
описание в обоих меню снизу под панелями инвентарей. При бОльших экранах надписи будут мелковаты. Плюс на самих предметах тоже есть нечитаемые надписи, которые ещё и бегущей строкой рисуются. Лучше оставить немного места и сделать описания как в инвентаре.
Навигация по меню с квестами никак не отображается визуально ввиду отсутствия все того же курсора.
Отдельно забавляет надпись "данная играя является fps и НЕ использует мышь. ЛКМ атака, ПКМ назад." bruh.
постараемся разобраться, но вроде миникарта не крутится и север фиксирован наверх
не знаю то ли новая версия появилась, то ли были приколы с firefox, но сейчас карта зафиксирована. Прикольно идти "по приборам" глядя только на открытую карту. При открытии карты там какие-то серые подсказки про кнопки появляются, но их не видно т.к. они серые и рисуются только частично.
Annsky
Это же популярный тренд с joyreactor?)
TENEVIK Автор
Да, это он.)
Teneviker
с имиджборд же.
TENEVIK Автор
Именно, с /b/ Самосбор тредов!