Javascript 6

Или, точнее, стандарт ECMAScript 6... Я не раз упоминала, какой он хороший и замечательный , хотя и новый (что в случае браузерных стандартов минус). RPG Maker MV неожиданно его поддерживает, поэтому я стараюсь писать скрипты на нём - а именно, используя конструкции let и class. Но сразу оговорюсь, что движок RPG Maker MV написан целиком на JS5, то есть перечисленных ниже проблем он не имеет. Эти проблемы имеют только мои скрипты

Но должна сказать, что поддерживает MV его всё-таки не идеально. Например, такая штука как super, очень похожая на аналог в Руби, работает только в конструкторах и только в простой нотации super(аргумент, аргумент). Нельзя автоматически вызвать родительский конструктор с теми же аргументами, что и текущий. Нельзя сделать super.apply(this, arguments), чтобы вызвать его с произвольным списком аргументах. В методах super вроде бы работает, позволяя вызывать родительские версии этих же методов... Но только при включённой консоли (которая по F8)! Если её не включить, игра жалуется на использование super вне метода (неправда) и останавливается. Такой вот квантовый эффект наблюдателя. В результате придётся писать ужасную конструкцию <родительский_класс>.prototype.<название_метода>.apply(this, arguments) и исправлять её, если родительский класс или название метода изменились. Или же использовать самописную функцию extend() вместо новой классовой нотации, чтобы сократить эту запись всего-то на пару пунктов.

Вероятно, JS6 нужно также учитывать при экспорте на Андроид, ведь вроде бы оболочку нужно собирать самому, и она в таком случае должна поддерживать JS6 (если используются плагины с JS6).

И, наконец, браузеры. Про поддержку JS6 браузерами есть большая интерактивная таблица , где указаны различные фишки JS6 и их отношения с версиями браузеров. Как видно, у современных браузеров поддержка замечательная (не стоит смотреть, что она неполная, ведь особенности ECMAScript 6 обширны, но даже самый простой "синтаксический сахар" оттуда способен сильно облегчить жизнь и обслуживание кода). Но я боюсь за Оперу. Популярность всех её версий (мобильных, настольных...) в русскоязычном пространстве не угасает, а со стандартами она дружит хуже IE - несмотря на то, что вроде бы она внутри Хром. Почти наверняка игры, чьи плагины используют JS6, не будут идти в Опере.

Но я верю в светлое будущее JS6, поэтому постараюсь пользоваться им в тех пределах, в которых его поддерживают Хром и основная оболочка MV.

P.S. Я беру свои слова назад, столкнувшись с реальной необходимостью выкатить игру в браузер. Лиса только в этом месяце будет поддерживать ключевые фишки js6. Опера застыла в развитии (и, к сожалению, не сдаёт позиций в рунете) и даже отсутствует в справочных списках поддержки js6. Буду писать плагины в старом стиле. Можно было бы писать в новом и транслировать Бабилем, но тогда итоговый код выглядит ужасно.

Спасибо за развёрнутый интересный рассказ, но боюсь тут для многих и просто JS хватит пока за глаза Это уже тебе как профессионалу видны все неудобства и корявости, а нам всё в диковинку (ну почти всем, почти в диковинку).

То-то и оно: обучение новому языку у кого угодно начинается с копирования и модифицирования готовых работающих программ. Мне не хотелось бы стать ответственной за то, чтобы моим примером или плагинами воспользовались, а потом обнаружили, что игра не идёт в Опере. С другой стороны, есть утилиты, которые делают код JS6 совместимым с JS5, так что это было бы не смертельно. Так что отказываться от удобного подхода шестой версии ради универсальной совместимости я не готова, тем более что через год наверняка все и думать забудут, что был какой-то Яваскрипт до шестого стандарта... %)

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

К счастью, не обязательно переписывать старые скрипты под новый стандарт, чтобы начать в той же среде пользоваться этим самым стандартом.

Если кому интересно, консоль отладчика выдаёт такую версию среды:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36

Отталкиваться следует от версии Хрома. Во всяких таблицах совместимости можно смотреть, что есть в Хроме 41, а чего ещё нет. Жаль, многие удобные фишки доступны только с 45-го Хрома, а в отличие от браузера, сборку MV не проапгрейдишь...

EvilCat пишет: Если кому интересно, консоль отладчика выдаёт такую версию среды:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36

Отталкиваться следует от версии Хрома. Во всяких таблицах совместимости можно смотреть, что есть в Хроме 41, а чего ещё нет. Жаль, многие удобные фишки доступны только с 45-го Хрома, а в отличие от браузера, сборку MV не проапгрейдишь...

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

Что касается классов, то я вовсю и успешно ими пользуюсь (только ключевое слово super работает как хочет, а также конструктор нужно обязательно объявлять). А вот стрелочные функции - ни-ни...

P.S. Что касается того, будут ли обновлять - ничего не пишут... Мне на вопрос про версию Яваскрипта вообще не ответили, возможно, американский персонал не разбирается.

Так поддерживаемая версия джаваскрипта же вроде определяется браузером на котором будешь игру запускать?
Мейкер здесь только позволяет удобно редактировать ресурсы и копировать папку с движком. Насколько я видел.

При запуске в браузере - да... А когда тестируешь или на самостоятельной виндовой сборке...

Там используется оболочка с гитхаба, которая насколько видел, основана на Chromium и, которую скорей всего можно обновлять, выкачивая новые версии с гитхаба ( github.com/nwjs/nw.js ) и подменяя то, что мейкер копирует в проект (если в папке с мейкером покопаться, можно найти где она лежит).

В мобильных тоже используется какая-то либа для выполнения nodejs + WebView.

В любом случае плагины, написанные для версии Хрома старше 41, будут непортируемыми на другие (чистые) установки Мейкера.

А у спрайта есть событие клика?

onclick - это часть не Яваскрипта, а модели DOM, которая используется в браузере. Яваскрипт - это только само понятие об объектах, прототипах, синтаксис языка и так далее, а структура, в которой он работает - это уже надстройка. Структура веб-страницы называется DOM , и в среде, где запускаются игры Мейкера, она наличествует... Но! Сама графика Мейкера не использует её, а использует более быстрые способы отрисовки, такие как Canvas или WebGL (в зависимости от настроек и решения движка). Объекты, используемые графическим движком PIXI, которым пользуется Мейкер, не имеют никакого отношения к модели DOM, поэтому стандартных событий типа onclick, CSS и прочего на них нет. У базового класса Object их тоже нет.

Что касается того, как засечь клик по спрайту... В самом движке Мейкера такие задачи выполняются через ручную проверку координат мыши на попадание в прямоугольную область. См., например, метод Window_Selectable.prototype.processTouch и следующие за ним. Вместо того, чтобы ловить событие, анализируется состояние мышки (или тача) каждый кадр. Предлагаю списать механизм оттуда.

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

Вот тебе и задачка, сделать такое для мукера)

Результаты свежего исследования среды...

Если ввести в консоль такую конструкцию:
То можно увидеть, что помимо ключей от 0 до 2 в массиве проявились также ключи equals, clone и contains - названия дополнительных методов, для которых забывчивый программист забыл выключить свойство "enumerable". Можно открыть новую вкладку браузера (без какого-либо сайта) и проделать с консолью то же, чтобы увидеть, что лишних ключей там не будет. Но на некоторых сайтах их будет гораздо больше, как я подозреваю, из-за jQuery.

Если мы проделаем то же не с массивом, а с объектом:

То результат окажется чистым, мы увидим только ключи meow, woof и hiss. Что ожидаемо, поскольку изменение прототипа Object считается прямо-таки первым смертным грехом в Яваскрипте, непредсказуемо изменяющим поведение всей системы.

Это значит, что предостережение не использовать for..in и for..of для массивов, к сожалению, оказывается верно для MV. В отсутствие стрелочных функций остаётся писать громоздкую формулировку for (var i=0; i<arr.length; i++) { ... } или arr.forEach(function() { ... }). Кроме того, не все авторы плагинов отличаются идеальным стилем (и хорошо, иначе плагинов не было бы столько!), и пространство параметров массивов будет замусориваться и дальше. Чтобы далеко не ходить за примерами, амбициозный плагин MVCommons добавил к массиву удобные методы min() и max(), тоже не подумав отключить у них enumerable.

В то же время Object можно использовать как ассоциативный массив, не опасаясь лишних ключей. Единственное, с чем может выйти конфуз - это если записать ключ __proto__, который ради совместимости со старыми браузерами меняет прототип объекта, читай, его класс, наделяя его новыми, непредсказуемыми свойствами. Если нужен ассоциативный массив с неопределённым (не контролируемым программистом) списком ключей, следует использовать объект Map . Он к тому же поддерживает любые типы в качестве ключей, даже другие объекты, как в Руби.

Маленькая, но важная и постоянно используемая особенность Яваскрипта.

Как думаете, каков результат выражения 0 || 2? В Руби результат был бы true, если я верно помню, как и в большинстве языков. Но в Яваскрипте результат 2.

Конструкция A || B || C возвращает A, если оно сводится к истине (например, непустая строка), или B, если оно сводится к истине, или C, если оно сводится к истине, а если ни одно из них не сводится к истине - то последний аргумент.

Аналогично конструкция A && B && C возвращает C, если все элементы сводятся к истине, или первый (слева направо) неистинный элемент, если таковой имеется.

Это используется, например, в присваивании недостающим аргументам значений по умолчанию или в создании недублирующихся объектов в одну строчку. Например:

Это поведение не то что бы совсем удивительно. Большинство языков программирования считают логические операторы за нечто большее, чем просто получение "да" или "нет". Например, в конструкции A || B, если первый пункт сводится к истине, то второй даже не вычисляется. И наоборот, в конструкции A && B, в которой первый пункт ложный, второй не вычисляется. Это не только для экономии ресурсов: туда часто помещаются команды, которые не имели бы смысла и бы привели к ошибке, если бы до них дошла очередь неожиданно, например, $obj instanceof Cat && $obj->canPurr() (используется синтаксис php).

Kian Ni пишет: EvilCat, еще вопрос, как текущие определить координаты курсора(TouchInput не канает)?

Тут тебе и правда придётся обрабатывать событие Яваскрипта, потому что TouchInput сохраняет их только в обработанном виде. Посмотри, как сделано здесь :


Вызов к этому методу передаётся через метод TouchInput, а именно:

Да, в системе координат графической области.

Обрати внимание на mouseEvent.pageX. mouseEvent в данном случае - специальный объект, описывающий событие мыши (какие кнопки зажаты, какие координаты у курсора...). У метода, который мы рассматриваем, есть этот объект потому, что он был передан ему в качестве аргумента здесь:

А сам метод TouchInput._onMiddleButtonDown вызывается, когда TouchInput получает событие о клике мышью и в свою очередь вызывает либо _onLeftButtonDown, либо _onRightButtonDown, либо _onMiddleButtonDown, передавая им объект события. Ему самому объект события поставляет Яваскрипт (точнее, модель DOM). По такой цепочке данные о мышином клике доходят до рассматриваемого метода.

В Scene.update им взяться неоткуда, потому что они не глобальные: mouseEvent существует только пока разные методы обрабатывают это событие. Код в Scene.update обычно обращается к данным, сохранённым в TouchInput в результате событий, произошедших с предыдущего кадра. Например, в случае клика левой кнопкой мыши TouchInput делает следующее:

Во всяких апдейтах обычно считываются TouchInput.isTriggered(), TouchInput.x, TouchInput.y, которые отталкиваются от сохранённых после последних событий данных (чисто технически, если игрок кликнет несколько раз за 1/60 секунды, то посчитается только последний клик).

Если TouchInput не канает (например, потому что он не обрабатывает среднюю кнопку мыши или потому что не сохраняет положение курсора, когда клавиша не зажата), но хочется считывать положение курсора в Scene.update, всё равно придётся перехватывать их похожим образом и где-то сохранять, пока они не понадобятся.