Погружение (диабло-лайк) (3 стр) / Оцените / Форум / Проекты / GameDev.ru

2.19full
Гуглдиск: https://drive.google.com/file/d/1h0VegT5NQhrbIeU6XqF1mMYVqE-C0tCV… w?usp=sharing

skalogryz
> Как насчёт настройки завести: "какой -лайк, вам больше лайк!". Ручной бой или автобой.
Это внедрено как-раз в вашей версии: 2.19 в настройках можно снять галочку с "Автобоя" и получите классическое управление с атакой на кнопку)
skalogryz
> а про периодически глюки Z коордианты монстров уже сообщали?
Благодарю, проверю, возможно есть где-то места в коде, где z-сортировка глючит.
skalogryz
> открытая дверь соединяющая две изведанных комнаты так и просится быть прозрачной
Подумаю что с этим можно сделать, просто убирать дверь с куском стены будет странно смотреться)

skalogryz
Участник

#32
(Правка: 7:35) 7:02, 27 сен 2026

elcar
> Это внедрено как-раз в вашей версии: 2.19 в настройках можно снять галочку с "Автобоя" и получите классическое управление с атакой на кнопку)
аха... удар: Ctrl, управление WSAD!

Ctrl+W - закрывает окно и игру (сначала нажимает ctrl, и сразу за ним W).... хмм.

т.е. либо не воевать, либо забеги на север не совмещать с ударами!

О! ещё баг.
1) запускаем игру попадаем в главное меню
2) нажимаем настройки!
3) ВАЖНО: главное меню всё ещё активно и откликается на мышку. А панель Настроек пропускает хиттест

+ Показать

Например, если щёлкнуть между "Эмоции" и "автоатака", клик попадёт на кнопку "Выйти" и игра выйдет!

elcar
Постоялец

#33
(Правка: 7:10) 7:06, 27 сен 2026

skalogryz
> аха... удар: Ctrl, управление WSAD!
Можно нажать кнопку "управление" в настройках и переконфигурировать кнопки как вам удобно.

skalogryz
Участник

#34
(Правка: 7:44) 7:09, 27 сен 2026

elcar
> Можно нажать кнопку "управление" в настройках и переконфигурировать кнопки как вам удобно.
а нельзя прибить стандартный хоткей браузера по закрытию таба?

+ Показать

− Скрыть

Если речь именно о приложении на базе Chromium/CEF, то Ctrl+W нужно перехватывать на уровне host-приложения, до того как Chromium обработает команду закрытия вкладки. Через JavaScript страницы надежно отключить Ctrl+W нельзя: браузерные accelerator'ы имеют приоритет.
Для CEF стандартный вариант — CefKeyboardHandler::OnPreKeyEvent():

bool MyKeyboardHandler::OnPreKeyEvent(
    CefRefPtr<CefBrowser> browser,
    const CefKeyEvent& event,
    CefEventHandle os_event,
    bool* is_keyboard_shortcut)
{
    if ((event.type == KEYEVENT_RAWKEYDOWN ||
         event.type == KEYEVENT_KEYDOWN) &&
        (event.modifiers & EVENTFLAG_CONTROL_DOWN) &&
        (event.windows_key_code == 'W'))
    {
        return true; // Chromium will not process Ctrl+W
    }

    return false;
}

И зарегистрировать handler через ваш CefClient:

CefRefPtr<CefKeyboardHandler> MyClient::GetKeyboardHandler()
{
    return this;
}

Если нужно блокировать также Ctrl+Shift+W:

if ((event.modifiers & EVENTFLAG_CONTROL_DOWN) &&
    event.windows_key_code == 'W')
{
    return true;
}

о есть наличие SHIFT уже не имеет значения.
Если же вы собираете сам Chromium из исходников, а не используете CEF, Ctrl+W обычно проходит через систему accelerator/commands Chromium и соответствует команде:

IDC_CLOSE_TAB

Там можно либо убрать binding Ctrl+W -> IDC_CLOSE_TAB, либо перехватить выполнение IDC_CLOSE_TAB в вашем варианте Browser UI. Это лучше, если вы строите собственный browser shell и хотите полностью исключить команду закрытия tab.
Если скажете, что именно используется — CEF, Chromium source tree, Electron, QtWebEngine или WebView2 — покажу конкретное место/метод, где Ctrl+W отключить.

− Скрыть

Можно попытаться:

window.addEventListener("keydown", (e) => {
    if (e.ctrlKey && e.key.toLowerCase() === "w") {
        e.preventDefault();
        e.stopPropagation();
        console.log("Ctrl+W intercepted");
    }
}, true);

Но в обычном Chromium это не гарантирует блокировку закрытия вкладки. Ctrl+W относится к browser-level shortcut, и Chromium может обработать его независимо от preventDefault() страницы.
То есть:

e.preventDefault();

может сработать для сочетаний, которые Chromium передаёт странице, но для Ctrl+W полагаться на это нельзя.
Если у тебя собственное приложение на Chromium/CEF, правильнее перехватывать Ctrl+W на уровне CEF/host. JS можно использовать дополнительно, например чтобы не дать приложению самому выполнить действие по Ctrl+W, но не как основной механизм предотвращения закрытия tab.

ЗЫ: добавил проблему с хиттестом.

elcar
Постоялец

#35
8:10, 27 сен 2026

skalogryz
> а нельзя прибить стандартный хоткей браузера по закрытию таба?
>
> ЗЫ: добавил проблему с хиттестом.
Да, хорошие баги. И чинятся несложно, на панель поставить подложку, "Ctrl" выпиливаю - как раз пропуск диалогов и "далее" в игре на пробел, как раз и атаку сделаю на пробел, будет удобно всё одной кнопкой, сразу фастфикс:

2.19fix
Гуглдиск: https://drive.google.com/file/d/1AGiiIHIeTzVQ6VMEw-FnMT1nCHor1IM3… w?usp=sharing

skalogryz
Участник

#36
(Правка: 5:13) 4:58, 28 сен 2026

elcar
> на панель поставить подложку,
фикс подтверждаю.

но в ту же кассу.

я правильно понимаю, что герои, стоящий визуальный на заднем фоне, получает мышинный приоритет над героем находящимся визуально перед ним
hittest2 | Погружение (диабло-лайк)
это особенно странно выглядит когда жмёшь в глаз волшебнице (в голову плуту), а играешь потом за рыцаря (валькирию).

+ Показать

− Скрыть

Да, для pixel-hunt это как раз очень типичный подход: держать отдельную невидимую ID-mask картинку, где цвет пикселя кодирует объект, и при клике читать цвет пикселя в координате мыши.

В PixiJS я бы не делал это через обычный hitArea, потому что hitArea рассчитан на геометрию. Для сложной пиксельной маски лучше загрузить маску отдельно и читать её пиксели.

Например, у тебя есть:

- scene.png — обычная картинка;
- mask.png — маска такого же размера;
- красный = объект 1;
- зелёный = объект 2;
- синий = объект 3;
- чёрный/прозрачный = ничего.

Простейшая схема:

const maskImage = new Image();
maskImage.src = "mask.png";

await maskImage.decode();

const canvas = document.createElement("canvas");
canvas.width = maskImage.width;
canvas.height = maskImage.height;

const ctx = canvas.getContext("2d");
ctx.drawImage(maskImage, 0, 0);

const pixels = ctx.getImageData(
    0,
    0,
    canvas.width,
    canvas.height
).data;

После этого можно сделать функцию hit-test:

function hitTestMask(x, y) {
    x = Math.floor(x);
    y = Math.floor(y);

    if (
        x < 0 ||
        y < 0 ||
        x >= canvas.width ||
        y >= canvas.height
    ) {
        return 0;
    }

    const index = (y * canvas.width + x) * 4;

    const r = pixels[index + 0];
    const g = pixels[index + 1];
    const b = pixels[index + 2];
    const a = pixels[index + 3];

    if (a === 0)
        return 0;

    if (r === 255 && g === 0 && b === 0)
        return 1;

    if (r === 0 && g === 255 && b === 0)
        return 2;

    if (r === 0 && g === 0 && b === 255)
        return 3;

    return 0;
}

И с PixiJS:

sprite.eventMode = "static";

sprite.on("pointerdown", event => {
    const p = event.getLocalPosition(sprite);

    const id = hitTestMask(p.x, p.y);

    console.log("Object:", id);
});

Но тут есть важный момент: если sprite масштабируется, вращается или имеет anchor, то getLocalPosition(sprite) уже очень полезен — он переводит координату клика в локальную систему координат объекта.

Если текстура изображения и маска имеют одинаковый pixel size, то обычно достаточно:

const p = event.getLocalPosition(sprite);

const maskX = Math.floor(p.x);
const maskY = Math.floor(p.y);

Если же Sprite отображает текстуру, например, 2048×1024, но визуально масштабирован:

sprite.width = 1024;
sprite.height = 512;

то локальные координаты обычно всё равно связаны с локальным размером Sprite, поэтому надежнее явно преобразовывать:

const p = event.getLocalPosition(sprite);

const maskX = Math.floor(
    p.x / sprite.width * maskImage.width
);

const maskY = Math.floor(
    p.y / sprite.height * maskImage.height
);

const id = hitTestMask(maskX, maskY);

Для твоего случая я бы пошёл ещё чуть дальше и не хранил RGB вообще после загрузки. Один раз преобразовал бы картинку в массив ID:

const objectIds = new Uint8Array(
    maskImage.width * maskImage.height
);

for (let y = 0; y < maskImage.height; ++y) {
    for (let x = 0; x < maskImage.width; ++x) {
        const src = (y * maskImage.width + x) * 4;
        const dst = y * maskImage.width + x;

        const r = pixels[src + 0];
        const g = pixels[src + 1];
        const b = pixels[src + 2];

        let id = 0;

        if (r === 255 && g === 0 && b === 0)
            id = 1;
        else if (r === 0 && g === 255 && b === 0)
            id = 2;
        else if (r === 0 && g === 0 && b === 255)
            id = 3;

        objectIds[dst] = id;
    }
}

Тогда hit-test становится почти бесплатным:

function hitTestMask(x, y) {
    x = Math.floor(x);
    y = Math.floor(y);

    if (
        x < 0 ||
        y < 0 ||
        x >= maskImage.width ||
        y >= maskImage.height
    ) {
        return 0;
    }

    return objectIds[y * maskImage.width + x];
}

И это уже очень хорошо подходит для pixel-hunt.

Причём я бы рекомендовал кодировать не обязательно RGB как red/green/blue, а использовать цвет как 24-битный ID:

const id =
    r |
    (g << 8) |
    (b << 16);

Тогда одна маска теоретически может описывать до примерно 16 миллионов ID:

Например:

function getMaskId(x, y) {
    const index = (y * width + x) * 4;

    const r = pixels[index];
    const g = pixels[index + 1];
    const b = pixels[index + 2];

    return r | (g << 8) | (b << 16);
}

Для игры я бы именно так и построил архитектуру:

scene.png
    ↓
PixiJS Texture / Sprite

scene_mask.png
    ↓
Canvas getImageData()
    ↓
Uint8Array / Uint16Array / Uint32Array
    ↓
mouse position
    ↓
local coordinates
    ↓
mask[x,y]
    ↓
object ID

И важная практическая деталь: маску надо сохранять без JPEG и желательно без какой-либо цветовой коррекции/сглаживания. PNG подходит. На границах объектов должны быть строго заданные значения пикселей, иначе вместо:

255,0,0

может появиться, например:

254,1,0

и точное сравнение цвета перестанет работать.

Для твоей задачи я бы вообще использовал PNG + integer ID mask и после загрузки сразу конвертировал её в Uint16Array или Uint32Array. Это будет и проще, и быстрее, чем каждый раз работать с CanvasRenderingContext2D.getImageData().

гидралиск
Постоялец

#37
(Правка: 6:22) 6:11, 28 сен 2026

Угу, честные попадания в спрайт - одна из множества рутинных задач, которые всё-таки надо выполнить, чтобы проект выглядел (чувствовался) профессионально.
Я такое делал, но моя реализация заточена под автосборку спрайтшитов из асепрайта другим моим скриптом, потому не годится для применения в этом проекте.

Тем более тут активные картинки статичны, это многое упрощает. Предполагаю, что каждая картинка героя тут должна быть отдельным канвасом, откуда при щелчке берётся imageData, проверяясь на прозрачность. Ну и способ, который подсказал skalogryz, даже проще и тоже годится.

Кстати, а как тут сейчас сделано выделение по контуру? Простым наложением вручную нарисованного слоя?

skalogryz
Участник

#38
(Правка: 8:05) 7:14, 28 сен 2026

гидралиск
> Предполагаю, что каждая картинка героя тут должна быть отдельным канвасом
картинка таверны, с четырьма героями - одна цельная. Без канвасов.
(это кстати дало мне ответ на вопрос: "а чё сложно было добавить отбовдку, на выбранного героя?")

гидралиск
> чтобы проект выглядел (чувствовался) профессионально.
...но это нудная рутина, за которую "спасибо" никто не скажет! (потому что воспринимают её как данное, а если её не сделать, будут гнобить)

гидралиск
> Кстати, а как тут сейчас сделано выделение по контуру? Простым наложением вручную нарисованного слоя?
вангую HitArea... хотя...

    //V74: все герои открыты сразу — силуэты UI/doll/0-3.png и проверка openHeroes удалены,
    //клик по любому герою выбирает его (спрайты UI/doll/T0-T3.png)
    //E-17: наведение на куклу открывает карточку героя (heroTip, как карточка врага в
    //enemyHover.js). hoverOpa здесь НЕ ставим: backend перезаписывает им funcShow/funcShowOut
    //V124: на шаге игрока 2 класс игрока 1 недоступен (правило коопа — классы разные)

и да, UI/doll/T0-T3.png - это как раз силуэты.

let heroesArr = [
    {"name":"hero.0.name","x":578,"y":488,"w":344,"h":489},
    {"name":"hero.1.name","x":1040,"y":440,"w":290,"h":523},
    {"name":"hero.2.name","x":924,"y":266,"w":279,"h":393},
    {"name":"hero.3.name","x":668,"y":297,"w":349,"h":358},
]

// 0 - плут
// 1 - волшебница
// 2 - рыцарь
// 3 - валькирия

@elcar
а вот эти все коды V74, E-17, V124 это всё нумерация требований, к нейронке?
написанные в коде комментарии вызывают двоякое мнения. Местами похоже на нейронку, а местами и нет.

просто интересно стало вот эти коды... это отсылка к какой-то системе учёта задач?! (excel файл?)

elcar
Постоялец

#39
(Правка: 9:29) 9:17, 28 сен 2026

skalogryz
> а вот эти все коды V74, E-17, V124 это всё нумерация требований, к нейронке?
> написанные в коде комментарии вызывают двоякое мнения. Местами похоже на нейронку, а местами и нет.
Так код писался руками, но потом поэтапно переносился на другой движок (с svg на ECS+PIXI.js) нейронкой.
Коды - это пункты этого из диздока:

## ИСТОРИЯ ВОЛН (одна строка; детали — git show, OpenViking, RENDER_MIGRATION.md)
- V1–V23: движок и контент (пул спрайтов, кэши, ловушки 15%/комната, этаж 3, главы,
двери эт.3; подробности — git-история этого файла до чистки).
- V24–V32: ярость/тень/горение/толпа/мини-карта/зум/рывок нетопыря (см. факты 6–10).
- V33–V38: клэмпы объектов эт.3; Библиотека (V35, ids эт.3); Журнал (V37, кап 200,
с V37 «лёгкий режим документации»); вой Хаунда (V38).
- V39–V44: пул отметок лобби; рамка мини-карты + сдвиг; многоуровневые способности
(V42); Демон и 4 столба призыва (V43/44), заставки final3.
- V45–V48a: фикс забега рыцаря; аудит доп-статов; soundBar; «Объекты» Библиотеки.
- V49–V52: статуя (4 складывающихся бафа); «учёность»; вампиризм; достижения (8 шт).
- V53–V56: сеты (2/4/6); алхимия; tombstone в screenPic + вторая рука; 4 сета.
- V57–V61: страницы сундука; Wings-фильтр; ЛОКАЛИЗАЦИЯ (V58); заставка (V59);
«ГЛАВНОЕ МЕНЮ» (V60); единая музыкальная шина (V61).
- V62–V64a: mapRender (быстрая карта); ловушки начисто (trapsFx); портал/рычаг/арена.
- V65 «Финал»: скейлинг гл.4, 4 этаж = одна арена 24×24, Циклоп voidBlob, comix/обвязка.
- V66–V66e: спрайты Циклопа; постфиксы «известность/корыстность»; «Новая игра» = полный
сброс профиля; лужи Отродья; reflectMagic дворфа.
и т.д.

п.с. пока правлю z-order и думаю что делать с дверями, думаю вместо открытых спрайтов менять на "полуразрушенные", так и перекрытия со спрайтом героя не будет. По выделению в лобби баг принял, пока думаю залить внутри спрайты выделения черным с 0.05 прозрачности, чтобы не замечалось визуально и детектить клик именно по этим пикселям, подумаю ещё:

гидралиск
Постоялец

#40
9:22, 28 сен 2026

skalogryz
Нейронку видно по комментариям: мало кто будет писать их так подробно, да ещё вставляя спецзнаки, типа × и ⇔.

elcar
Постоялец

#41
15:44, 28 сен 2026

Новым игрокам не очень понятно, почему у них "забирают прогресс" и можно переносить только 1 предмет (и перенос так же не всегда понятен). Сделал одноразовое информационное окно с кратким объяснением переноса предметов и прогресса Глав.

2.20
- информационное окно на экране переноса предметов после забега
- герои в лобби теперь выделяются "попиксельно", более точное выделение
- доработана система z-order, если увидите ещё неправильное наложение спрайтов друг на друга - пишите где, поправлю
- проходимость спрайтов дверей уменьшена с 4х до 2х клеток, всё ещё герой идёт задевая стену, но уже меньше, чем раньше
- перерисованы некоторые "растянутые" текстуры объектов, теперь должны меньше резать глаза
Гуглдиск: https://drive.google.com/file/d/1WBVMjSX2yAxZ-7L86RQti2m2eLpuD0pD… w?usp=sharing