WebAssembly

Мейкер обновился до версии 1.6, а это значит, что теперь над доступен WebAssembly .
Как вы думаете, как его можно применить в мейкере?
Первое, что приходит в голову: Поиск пути А*, Динамическое освещение с тенями, Коллизия спрайтов

Эффекты для изображений и прочего. Типа погоды, состояний... ИИ, квесты с задачей, использующей диалоги на основе ввода пользователя

Интересные вы

А что, собственно, даёт wasm, что нельзя было сделать на js?

А* давно написан под все мейкеры, попиксельная коллизия тоже есть. Освещение с тенями тоже есть + вы его всё равно, скорее всего. будете писать через js-библиотеку (pixi.js/tree.js), а не напрямую через WebGL-функции.

Или вы думаете что на wasm код волшебным образом сам себя оптимизирует и автоматически работает быстрее?

Вы, видимо, плохо представляете, что так WebAssembly. Вот хорошее описание, что это такое: ru.wikipedia.org/wiki/WebAssembly

А*, коллизия уже есть, согласен, даже я игрался с этим, но проседание фпс из-за вычислений не очень радуют. Лучше сложные вычисления перенести на с++.

Как там они пишут? "Calculations near the native". Дает сделать сложные расчеты быстрей, а затем передать результат в js, где уже готовые данные будут использованы для отображения или более простых расчетов.

Хотя я тоже не особо в это вникал, но вроде как скомпилированые модули передаются клиенту и выполняются тоже на его стороне, в отличие от модулей к ноде.
Думаю это больше пригодится тем, кто решит свои игры выставлять в веб, а не давать целиком, как десктопную - для десктопного и модули к ноде сойдут.

Хотя стоп. Зачем нам тогда поиск пути тут делать, если он все-равно будет делать движком на стороне сервера?
Остается только освещение и прочие эффекты. А также какая-нибудь быстрая проверка грамматики

Именно, и поэтому такие задачи, как поиск пути по графу будут вычисляться куда быстрее, чем на Js. Я сам еще ничего не пробовал на нем писать, но перспектива нравится.

DK, А* не требует каких-то тяжёлых вычислений, по крайней мере в масштабах мукер-карт (которые обычно не превышают 100х100 тайлов). Коллизии спрайтов тоже.

А что касается теней - эту функцию нужно возлагать на WebGL, а не процессор, поэтому особой разницы нету.

А если куча эвентов будут в реалтайме искать маршрут, чтобы не застрять или коллизия будет проверяться каждый фрейм и спрайтов будет много ? Js все-таки медленный язык.

Но, можно предрасчитать грубо несколько теней, которые сейчас не на экране или набор эффектов на ЦП, чтоб потом было проще рассчитывать их отображение.

Ну, вдруг нужно динамически пересчитывать маршрут. Это выгодней делать более быстрым методом.

Прикрутит ли теперь кто-нибудь физику к мукеру?

Простите за всё ту же шарманку, но если для игры на RPG Maker понадобились мощные вычисления и модули на C++, это знак, что игре пора переезжать на движок помощнее и погибче, такой как Юнити.

На Юнити из коробки доступна мощная система поиска пути, когда можно просто набросать 3D-сцену, задать радиус типичного моба и высоту шага, и движок сам создаст карту перемещений, по которой моб сможет ориентироваться даже не по узлам, а в реальном времени. Можно использовать движение из коробки и только регулировать "цель" и "скорость". Можно использовать встроенный поиск пути как вспомогательный, обрабатывая его самописными скриптами. Если не нравится встроенный поиск пути, до магазина один шаг, где ждут дорогие, дешёвые и бесплатные решения поиска пути на любой вкус . 2D Юнити тоже умеет, в том числе есть пакеты для тайловой RPG . А самое главное - все эти дополнения снабжены визуальными инструментами редактирования, и самописные модули тоже могут быть ими легко снабжены.

Создавая сложные модули для Мейкера на WebAssembly, мы тянем сразу два минуса: во-первых, нецелевое использование, делающее всё сложным (на Юнити эти вещи просты не потому, что Юнити волшебный, а потом что Юнити создавался под этим нужды - и наоборот, на Юнити сложно сесть и сразу начать делать JRPG, потому что она не предназначалась для определённого жанра); во-вторых, код станет нечитабельным. Авторы-пользователи модулей не смогут его ни понять, ни исправить. А в движке для любителей это очень важные возможности. Говорю вам я - человек, который структуру типичного графического игрового движка с фреймами и рендерами узнал из кода VX Ace.

Юнити не выход. Не думаю, что ради 2D игры кто-то станет качать редактор на 20+ гигабайт.
К тому же, как сказано в предшествующем сообщении "на Юнити сложно сесть и сразу начать делать JRPG, потому что она не предназначалась для определённого жанра", перейдя на Юнити только ради поиска пути, мейкеристы потеряют остальные уже готовые для jRPG средства.

Для действительно нецелевого использования (как платформеры на мейкере, которые периодически возникают), еще понятно, что Юнити будет удобней и более расширяемым, но не для обычного мейкеристского проекта.

Да и, используемый в юнити, C# не очень нравится своим синтаксисом, вроде названий функций с заглавной буквы, как и классов, что создает путаницу. Но, при этом и, если писать с маленькой, то выходит не по-стандарту и из-за сгенерированых и дефолтных функций, часть методов будет с заглавной, а часть со строчной, что создает еще большую кашу.
Вобщем, как сказал бы Амфи, хуе-хуе опять Поринг не может приспособиться к изменениям.

А на вопрос о второй проблеме. Как сказал бы ДК, "Не зачем тебе в коде копаться. Используй доку и не лезь!".
Типа пусть используют простые базовые модули как есть в своих плагинах.
Модули будут выполнять простые трудоемкие операции, а основная логика на JS.

Знаешь, когда я вижу на Стиме специализированные движки вроде Smile Game Builder, обещающие всё красивее и быстрее, чем РПГ Мейкер, я обычно воспринимаю их скептически: чаще всего их функционал не расширяем и иногда даже нельзя импортировать свою графику (если они 3D). Даже в RM2k можно было многого добиться без пропатчивания dll, если хорошенько заморочиться с ивентами. И всё же не хотелось бы возвращаться в этим дремучие времена. Большинство из новичков не закончит свои первые проекты, но что они вынесут из своего опыта на Мейкере - это опыт работы с алгоритмами и знакомство с игровым кодом. Ни один самоучитель "Как написать игру для DirectX" не дал мне столько, сколько фреймворк VX Ace.

Принцип "ешь что дают, не лезть в код" и лицензии, запрещающие редактирование, я глубоко не поддерживаю. Само собой, никто не может запретить потихоньку воспроизводить Юнити на РПГ Мейкере с помощью wasm/C++ - так же, как никто не может запретить делать свой Скайрим на Мейкере. Но мне кажется, что нам, старожилам, следовало бы передавать новичкам мудрость о целевом использовании Мейкера.

Хм... Мысль интересная. Фиг поспоришь насчет того, что мейкер неплохо подходит, чтоб в нем копаться, но не очень, чтоб сделать более-менее сложную игру.
Еще бы это поняли те, кто говорит, что web-приложения скоро совсем заменят нативные...
Главное не начать воспринимать код движка как идеал, потому что, по-моему, он во многих местах этому не соответствует.

Спасибо за понимание! Я не была уверена, что понятно выражаюсь.

Надо сказать, эти "понятные, но не идеальные" системы, типа фрейворка Мейкера, только побуждают попытаться сделать лучше... Что увеличивает их поучительность %)

Ну да. Чем больше за тебя реализовано, тем больше ограничений и навязанных путей реализации.
По похожей причине мне также не нравится тенденция за программиста исправлять ошибочные вызовы.
Во многих случаях это оправданно и избавляет код от лишних фрагментов и проверок, но в части случаев оно вызывает путаницу и поиск ошибки не там, где она в действительности находится.

Например, есть 2 способа отображения окна:
1. Просто рисуя контент нового окна поверх текущего
2. Заменяя контент текущего окна на новый, с сохранением истории перехода

Допустим раньше, если мы пытались показать новое окно, как замену текущего и не создали хранилище истории, программа генерировала ошибку и закрывалась.
В новой реализации, если хранилище истории не создано, то SDK показывает новое окно по 1-му способу.

Т.к. в обоих случаях контент старого окна не виден, после запуска, программист не подозревает о своей ошибке и, приложение падает совсем в другом месте, когда программа хочет вытащить старое окно из истории и не может (т.к. истории то нет).

В лучшем случае оно упадет с "variable undefined". В худшем с какой-нибудь ошибкой в духе "Window state is broken".
Отчего программист начнет искать ошибку не там, проверяя не вытащил ли он окно из истории до этого или не переписал ли он чего-то не того в этой истории.
Хотя при старом варианте, он мог сразу заметить ошибку. Еще на этапе показа нового окна.

DK пишет: Как вы думаете, как его можно применить в мейкере?

Для компиляции EasyRPG! Делаешь игру на 2000 мейкере, запускаешь в EasyRPG (целиком написанном на C++) и наслаждаешься высокой скоростью в браузере. Правда, оно и вне браузера хорошо работает, да и текущая браузерная версия на asm.js тоже достаточно быстрая.

Впихивать код на WebAssembly в мейкер MV кажется очень и очень подозрительной идеей. EvilCat отлично объяснила, почему.

DK пишет: Вы, видимо, плохо представляете, что так WebAssembly.

Писать на C++ для браузеров и получать высокую скорость можно было и раньше, с помощью asm.js. Это уже было. WebAssembly даёт некоторое ускорение, но ничего революционно нового в нём нет.

DK пишет: Первое, что приходит в голову: Поиск пути А*, Динамическое освещение с тенями, Коллизия спрайтов

Если уж ставится такая задача, то, наверное, стоит сначала реализовывать всё на JS, смотреть, что именно работает медленно, и оптимизировать именно его и только его. (Причём это может оказаться и стандартный код мейкера.)

Lekste пишет: Юнити будет удобней и более расширяемым, но не для обычного мейкеристского проекта.

Для обычного мейкерского проекта не нужно, чтобы «куча эвентов будут в реалтайме искать маршрут, чтобы не застрять или коллизия будет проверяться каждый фрейм и спрайтов будет много». Если человек делает что-то такое, то он(а) делает совсем не обычную JRPG, а игру какого-то другого жанра. В JRPG если и нужен поиск пути, то уж явно не такой экстремальный, и яваскриптового вполне хватит.