RPG Maker MZ

Vincent RPG пишет:

Leprikon01 пишет: Как говорится найдите 3 отлмичия.

Неужели трудно сделать человекоподобных персонавжей?!

Была бы возможность создавать ХР персонажей, думаю всем бы понравилось. А так редактор вроде бы норм

Да надо будет пилить свой редактор, это на самом деле не очень сложно сделать. На еу форуме есть шаблон детей/подростков/взрослых в размере 48х72. Нет только анимаций для боёвки, виду сбоку и доп.анимациями, а так же одежды.

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

Интересно, что с тайлами и спрайтами? Есть предположение, что сетка будет 60х60.

Демий пишет: Интересно, что с тайлами и спрайтами? Есть предположение, что сетка будет 60х60.

По скриншотам из Стима видно, что сетка будет 48*48:



Кроме того, была официальная информация, что почти вся графика от MV будет подходить. Так что размеры тайлов и спрайтов вряд ли изменятся.

ссылка на саму новость


пока кроме обещаний "код стал лучше, работает лучше" ничто меня не привлекает

1) функцию смещения в генераторе персонажей по ходу добавили только для фейса. причем если мы сместим глаза на лоб сделав перса уродливее то в "чаре" все-равно глаза будут обычные, хотя на разрешении 48*48 довольно сильно заметно где находятся глаза. ну и как обычно выглядит недоделкой: "фейсам мы прикрутили смещение, а вот опустить туловище пониже,тем самым зрительно уменьшив ноги или поднять голову повыше чтобы сделать герою шею подлиннее мы решили не делать"

2) сделали больше цветов. ну прям как в играх начала 90ых - делаем персов разными, меняя цвета. строчек пять кода. подобных генераторов тонна в сети и делаются они довольно легко, вполне можно было сделать выбор размера сетки и напрмиер дополнительный слой в котором можно самому нарисовать пару пикселей.

3) в менеджере плагинов тоже добавили один чекбокс и две текстареи - обалдеть сколько трудов вложено. сделали бы возможность создателям плагинов самим определять какие текстареи будут доступны

4) аргументы для оптравки параметров в команду конечно неплохо,но опять же косметическая мелочь.

5) обновили фреймворки до последних версий. пока этот движок будет существовать хром и остальное тоже обновятся. интересно, разрабы будут параллельно тоже обновлять мукер, поддерживая его в актуальном состоянии?

6) "Обновить команду меню Corescript" - ну обновится раз пять мукер. ну воспользуюсь я пять раз этой командой. ну сломает она пару плагинов и один черт придется лезить во внутренности и искать изменения.

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

обещания "будет стабильнее" меня тоже не особо волнует - у меня МВ и так работал хорошо. и косяков с загрузкой графы напрмиер я тоже никогда не наблюдал,так как графа в моих проектах весит оч мало - как один стандартный тайлсет в МВ.

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

yuryol пишет: ссылка на саму новость


пока кроме обещаний "код стал лучше, работает лучше" ничто меня не привлекает

1) функцию смещения в генераторе персонажей по ходу добавили только для фейса. причем если мы сместим глаза на лоб сделав перса уродливее то в "чаре" все-равно глаза будут обычные, хотя на разрешении 48*48 довольно сильно заметно где находятся глаза. ну и как обычно выглядит недоделкой: "фейсам мы прикрутили смещение, а вот опустить туловище пониже,тем самым зрительно уменьшив ноги или поднять голову повыше чтобы сделать герою шею подлиннее мы решили не делать"

2) сделали больше цветов. ну прям как в играх начала 90ых - делаем персов разными, меняя цвета. строчек пять кода. подобных генераторов тонна в сети и делаются они довольно легко, вполне можно было сделать выбор размера сетки и напрмиер дополнительный слой в котором можно самому нарисовать пару пикселей.

3) в менеджере плагинов тоже добавили один чекбокс и две текстареи - обалдеть сколько трудов вложено. сделали бы возможность создателям плагинов самим определять какие текстареи будут доступны

4) аргументы для оптравки параметров в команду конечно неплохо,но опять же косметическая мелочь.

5) обновили фреймворки до последних версий. пока этот движок будет существовать хром и остальное тоже обновятся. интересно, разрабы будут параллельно тоже обновлять мукер, поддерживая его в актуальном состоянии?

6) "Обновить команду меню Corescript" - ну обновится раз пять мукер. ну воспользуюсь я пять раз этой командой. ну сломает она пару плагинов и один черт придется лезить во внутренности и искать изменения.

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

обещания "будет стабильнее" меня тоже не особо волнует - у меня МВ и так работал хорошо. и косяков с загрузкой графы напрмиер я тоже никогда не наблюдал,так как графа в моих проектах весит оч мало - как один стандартный тайлсет в МВ.

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

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

Leprikon01 пишет: Как говорится найдите 3 отлмичия.

Мдэ,… вот теперь точно смысла покупать 0

Вся надежда была, что уберут этих мутантов «головастиков», но увы
Это единственное, что меня интересовало в редакторе, а так когда-нибудь своё доделаю.

Mur пишет:

Leprikon01 пишет: Как говорится найдите 3 отлмичия.

Мдэ,… вот теперь точно смысла покупать 0

Вся надежда была, что уберут этих мутантов «головастиков», но увы
Это единственное, что меня интересовало в редакторе, а так когда-нибудь своё доделаю.

Если ты это все-таки доделаешь, то спасешь миллионы художников от пыток пиксельартом.

Leprikon01 пишет:

Mur пишет:

Leprikon01 пишет: Как говорится найдите 3 отлмичия.

Мдэ,… вот теперь точно смысла покупать 0

Вся надежда была, что уберут этих мутантов «головастиков», но увы
Это единственное, что меня интересовало в редакторе, а так когда-нибудь своё доделаю.

Если ты это все-таки доделаешь, то спасешь миллионы художников от пыток пиксельартом.

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

Dmy пишет:

Демий пишет: Интересно, что с тайлами и спрайтами? Есть предположение, что сетка будет 60х60.

По скриншотам из Стима видно, что сетка будет 48*48:

Кроме того, была официальная информация, что почти вся графика от MV будет подходить. Так что размеры тайлов и спрайтов вряд ли изменятся.

То что размер тайлов останется x48 и ежу должно было быть понятно. Ибо нафига менять размер тайлов когда как кучу ДЛС было выпущено для МВ и продолжает выпускаться вроде как. Речь шла о том будет ли несколько размеров включая x48 или будет только x48. Но подозреваю второй вариант.

yuryol пишет: ссылка на саму новость


пока кроме обещаний "код стал лучше, работает лучше" ничто меня не привлекает

1) функцию смещения в генераторе персонажей по ходу добавили только для фейса. причем если мы сместим глаза на лоб сделав перса уродливее то в "чаре" все-равно глаза будут обычные, хотя на разрешении 48*48 довольно сильно заметно где находятся глаза. ну и как обычно выглядит недоделкой: "фейсам мы прикрутили смещение, а вот опустить туловище пониже,тем самым зрительно уменьшив ноги или поднять голову повыше чтобы сделать герою шею подлиннее мы решили не делать"

2) сделали больше цветов. ну прям как в играх начала 90ых - делаем персов разными, меняя цвета. строчек пять кода. подобных генераторов тонна в сети и делаются они довольно легко, вполне можно было сделать выбор размера сетки и напрмиер дополнительный слой в котором можно самому нарисовать пару пикселей.

3) в менеджере плагинов тоже добавили один чекбокс и две текстареи - обалдеть сколько трудов вложено. сделали бы возможность создателям плагинов самим определять какие текстареи будут доступны

4) аргументы для оптравки параметров в команду конечно неплохо,но опять же косметическая мелочь.

5) обновили фреймворки до последних версий. пока этот движок будет существовать хром и остальное тоже обновятся. интересно, разрабы будут параллельно тоже обновлять мукер, поддерживая его в актуальном состоянии?

6) "Обновить команду меню Corescript" - ну обновится раз пять мукер. ну воспользуюсь я пять раз этой командой. ну сломает она пару плагинов и один черт придется лезить во внутренности и искать изменения.

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

обещания "будет стабильнее" меня тоже не особо волнует - у меня МВ и так работал хорошо. и косяков с загрузкой графы напрмиер я тоже никогда не наблюдал,так как графа в моих проектах весит оч мало - как один стандартный тайлсет в МВ.

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

Частично с тобой соглашусь однако там много мелких полезных изменений а отговорка продать заново служит (Мол мы весь движок перелохматили). Естественно щас они пытаются привлечь людей чтоб многие повторно MV купили. Честно говоря походу это и работает. Я та за полную ценну полкупать не стану но прийдется учитывая что пираток в жизни не дождешься.

Mur пишет:

Leprikon01 пишет: Как говорится найдите 3 отлмичия.

Мдэ,… вот теперь точно смысла покупать 0

Вся надежда была, что уберут этих мутантов «головастиков», но увы
Это единственное, что меня интересовало в редакторе, а так когда-нибудь своё доделаю.

Черпали идеи из фотошопа. Честно говоря не самый лучший дизайн на мой взгляд. Хотя функционал побольше мукеровского. Надеюсь удобства у него на томже уровне так как тот что в MV хоть и очень слаб на функциональность но удобный хотябы.
Да и надеюсь есть возможнгость менять тему ибо увы но не всем нравиться темная тема.

Юриоль, ты забыл упомянуть, что теперь кодеры могут задавать зависимости плагинов и устанавливать порядок их установки. Все - таки это действительно полезная вещь. И улучшение команды плагина считаю неплохим. Будет очень удобно.
Я не оправдываю новый мейкер, просто говорю, как разработчик, что это реально крутые функции.
Ну и хорошо, что на ES6 переписали все. Будет удобнее читать исходники.

Мун, ты и сейчас можешь пользоваться импортами в МВ. Просто для браузеров и мобильников тебе нужно транспайлить плагины. Точно также нужно будет делать и в МЗ.

DK пишет: Юриоль, ты забыл упомянуть, что теперь кодеры могут задавать зависимости плагинов и устанавливать порядок их установки. Все - таки это действительно полезная вещь. И улучшение команды плагина считаю неплохим. Будет очень удобно.
Я не оправдываю новый мейкер, просто говорю, как разработчик, что это реально крутые функции.
Ну и хорошо, что на ES6 переписали все. Будет удобнее читать исходники.

Мун, ты и сейчас можешь пользоваться импортами в МВ. Просто для браузеров и мобильников тебе нужно транспайлить плагины. Точно также нужно будет делать и в МЗ.

О, прикольно, не знал. Просто читал исходники янфлая, и там все сралось в глобал видимость.А на ес6 сейчас писать можно?

Меня больше волнует когда наконец они укажут цену на RPG Maker MZ.

MoonGuard пишет:

DK пишет: Юриоль, ты забыл упомянуть, что теперь кодеры могут задавать зависимости плагинов и устанавливать порядок их установки. Все - таки это действительно полезная вещь. И улучшение команды плагина считаю неплохим. Будет очень удобно.
Я не оправдываю новый мейкер, просто говорю, как разработчик, что это реально крутые функции.
Ну и хорошо, что на ES6 переписали все. Будет удобнее читать исходники.

Мун, ты и сейчас можешь пользоваться импортами в МВ. Просто для браузеров и мобильников тебе нужно транспайлить плагины. Точно также нужно будет делать и в МЗ.

О, прикольно, не знал. Просто читал исходники янфлая, и там все сралось в глобал видимость.А на ес6 сейчас писать можно?

Конечно. Мои плагины написаны на ES6, есть асинхронные функции и прекрасно чувствуют себя в современных браузерах и телефонах.

Судя по зарубежным форумам не станут они добавлять поддержку мнеожество размеров тайлов. Спихивают на то что для них такая реализация непомерно большой работы стоит а для пользователей такая фишка будет адски дорого стоить тогда. Так что с вероятностью 90 процентов размер тайлов останется 48 x 48

Меня всегда мучил вопрос: А почему в итоге стало 48х?
Я, конечно, не специалист, но ещё со времён маппинга под Doom и HL1 запомнил, что стоит сохранять степень двойки (16х, 32х, 64х, 128х, 256х, 512х и т.д.).
Если бы они сделали в MV 64х, то было бы в разы проще переносить те же тайлы с VXA, т.к. нужно было бы умножать их размер на 2, а не на 1.5.
В итоге у меня есть куча костылей, чтобы "ресайзить" графику, но по итогу всё равно появляются какие-то замыленности, полосы и т.д.

Если бы они сделали в MV 64х, то было бы в разы проще переносить те же тайлы с VXA

Вот ты сам на свой вопрос и ответил. Им нужно паки продавать, а не что бы ты их переносил из мукера в мукер (лицензия-то позволяет это делать). Скажи спасибо, что 48х48 сохранят.

Luar_Zero пишет:

Если бы они сделали в MV 64х, то было бы в разы проще переносить те же тайлы с VXA

Вот ты сам на свой вопрос и ответил. Им нужно паки продавать, а не что бы ты их переносил из мукера в мукер (лицензия-то позволяет это делать). Скажи спасибо, что 48х48 сохранят.

Ну одна из причин. Сохранить 48 им пришлось чтоб не вызвать хейта и побыстренькому пересодить MVэшников на MZ.

Еще причина почему 48 а не x64 это трудномоштабность рисовать тайлы под x64. В том плане что для них менять на 48 было оптимальным решением.

Так что увы но отмазка продать dlc и чтоб пользователи сами не конвертили не единственная причина. И даже не основная. Гдето читал на оф форуме (давненько. Еще в самый разгар MV) причину по которой поменяли размер тайла. Вроде как им не хватало 32 пикселя для рисования нового RTP и было решение увеличить до 48 как оптимальный вариант чтобы не перегружать движок и увеличить качество графики.

Да и плюс это традиция. В 2000 - 2003 был x16.
В XP, VX, VX Ace это x32
В MV, MZ это уже x48.
Да. VX выбивается из традиции но там по сути хоть и тотже размер но сама структура тайлсетов у них разная.
Так что еще 1 причина это дань традиции.

Alexandr_7 пишет:

Luar_Zero пишет:

Если бы они сделали в MV 64х, то было бы в разы проще переносить те же тайлы с VXA

Вот ты сам на свой вопрос и ответил. Им нужно паки продавать, а не что бы ты их переносил из мукера в мукер (лицензия-то позволяет это делать). Скажи спасибо, что 48х48 сохранят.

Ну одна из причин. Сохранить 48 им пришлось чтоб не вызвать хейта и побыстренькому пересодить MVэшников на MZ.

Еще причина почему 48 а не x64 это трудномоштабность рисовать тайлы под x64. В том плане что для них менять на 48 было оптимальным решением.

Так что увы но отмазка продать dlc и чтоб пользователи сами не конвертили не единственная причина. И даже не основная. Гдето читал на оф форуме (давненько. Еще в самый разгар MV) причину по которой поменяли размер тайла. Вроде как им не хватало 32 пикселя для рисования нового RTP и было решение увеличить до 48 как оптимальный вариант чтобы не перегружать движок и увеличить качество графики.

Да и плюс это традиция. В 2000 - 2003 был x16.
В XP, VX, VX Ace это x32
В MV, MZ это уже x48.
Да. VX выбивается из традиции но там по сути хоть и тотже размер но сама структура тайлсетов у них разная.
Так что еще 1 причина это дань традиции.

насколько я знаю, из основ пиксельной графики, то изменять размер можно именно в кратном увеличении, например, в 2, в 3, в 4 раза. Если увеличивать в рандомный процент, например, в полтора, есть высокая вероятность, что появятся ненужные пиксели, а пару ненужных пикселей очень сильно ломают линии.
п.с. хотя я и не спорю с тем, что едва ли они новые паки продавать хотели.

MoonGuard пишет:

Alexandr_7 пишет:

Luar_Zero пишет:

Если бы они сделали в MV 64х, то было бы в разы проще переносить те же тайлы с VXA

Вот ты сам на свой вопрос и ответил. Им нужно паки продавать, а не что бы ты их переносил из мукера в мукер (лицензия-то позволяет это делать). Скажи спасибо, что 48х48 сохранят.

Ну одна из причин. Сохранить 48 им пришлось чтоб не вызвать хейта и побыстренькому пересодить MVэшников на MZ.

Еще причина почему 48 а не x64 это трудномоштабность рисовать тайлы под x64. В том плане что для них менять на 48 было оптимальным решением.

Так что увы но отмазка продать dlc и чтоб пользователи сами не конвертили не единственная причина. И даже не основная. Гдето читал на оф форуме (давненько. Еще в самый разгар MV) причину по которой поменяли размер тайла. Вроде как им не хватало 32 пикселя для рисования нового RTP и было решение увеличить до 48 как оптимальный вариант чтобы не перегружать движок и увеличить качество графики.

Да и плюс это традиция. В 2000 - 2003 был x16.
В XP, VX, VX Ace это x32
В MV, MZ это уже x48.
Да. VX выбивается из традиции но там по сути хоть и тотже размер но сама структура тайлсетов у них разная.
Так что еще 1 причина это дань традиции.

насколько я знаю, из основ пиксельной графики, то изменять размер можно именно в кратном увеличении, например, в 2, в 3, в 4 раза. Если увеличивать в рандомный процент, например, в полтора, есть высокая вероятность, что появятся ненужные пиксели, а пару ненужных пикселей очень сильно ломают линии.
п.с. хотя я и не спорю с тем, что едва ли они новые паки продавать хотели.

С точки зрения графики это так но сточки зрения а потянет ли это движок это уже большой разговор. Движок MV крайне нестабильный. Об этом сказали сами разработчики выпуская MZ где движок по сути тотже самый. Да и они сами сказали что размер больше плиток движок бы не потянул на должном уровне. Для них 48 стала вынужденной мерой плюс 64 действительно громадный размер тайла. Честно уже не скажу почему был выбран 48 точно. Да и причин масса как коммерческих как и ленивых.

Вот кстати и ответ одного из зарубежных пользователей (Почему не 64x):

Anyone пишет: Multiplication is relevant when talking about asset conversion, but you actually weren't supposed to convert VXA assets to RMV. (You can still do so, but you have to multiply up to the number that has both as denominator, which would be 96. So to get from VXA to MZ, you'd multiple by 300% 32->96 and then divide that by 2. Size increase is done via nearest neighbor, but for the decrease you have to go with bilinear or bicubic interpolation. The result is okay, but not the same quality level. But even at 64, you wouldn't have a decent result either, because you'd just have doubled the pixels for every pixel, leading to assets that will feel as if they don't appropriately use the pixels they have)

The main reason why they shied away from 64, I think, is two-fold:
1. 64 tiles & chars are a lot more bigger than 32 and thus require more detail to make use of the added pixels. So making a 64 chair in your tileset, for example, would require more work than a 32 chair.

2. Size. 32x32 has a total of 1024 pixels drawn on the canvas. 64x64 is twice the size in length & height, but quadruple the file size! 4096 pixels are drawn on the canvas.

That effectively means that any tileset in 64 size would require 4 times the loading times and engine ressource than a 32 tileset. And MV, from what I've heard, was already just barely scraping past issues with the number of pages for the tileset. So a 64 tileset would've very likely lead to bloated filesize of all assets and would've caused issues with RMV.
In fact, you can - if you load bitmaps via JS in RMV - already come across issues where files that are too large and can't be loaded in time - forcing you to preload or to update the scene when the image has been loaded.
So you'd probably end up with loading times before every scene change, since every tileset would require quite a bit of time to preload.

And in order to make the editor itself work...you'd probably have to force tilesets to be smaller and scrap 1 or 2 pages.

Little known fact: if you have too many tilesets in your RMV editor...your editor can crash while the JS tileset data is open, corrupting your entire tileset data, forcing you to either load from backup if you have one, or do the whole thing anew.
(How do I know? That's exactly what happened to me.)

That's because the editor has serious issues when you have a lot of images or animations loaded in your database, which you may recognize by how saving becomes very slow, opening the database also no longer is instant, and when you've got too much of it...the editor goes haywire and crashes.

This also extends to other parts of the editor, btw.
If you're using a bust plugin and you're loading bustsheets made of multiple busts into the face image browser when selecting the face in a dialogue conversation, if that image is too big (around 7000x7000 or so) it simply cannot deal with the filesize of the image and your editor crashes.
If you managed to assign that bustsheet to a character via other ways and got it written into your JS DB, it'll actually corrupt the entire database insofar as it becomes impossible to open the database without crashing. The only way to resolve that problem is to directly use notepad++ or similar to edit the JS DB file of your actors and remove the file directly inside the JS code.

TL;DR:
Bigger files cause BIG issues. Bigger project sizes, more workload, and lots and lots and lots and lots and lots of engine issues that'll drive users insane. :distrust::dizzy:<

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

И еще 1 ответ на ответ выше:

Sharm пишет: @Anyone According to my brother, due to the way memory is allocated in computers 48x48 tiles take up exactly the same amount of memory as 64x64, so I don't think that's the reason. Granted, I don't know if it was active memory or storage memory he was talking about at the time. I think it was something more simple. They were focusing on being able to export to phones, and it needed to be a size that you could click on with your finger.

Им нужен был оптимальный размер тайла под палец для телефонов. 64 был бы слишком велик а 32 мелковат так что 48 вполне себе оптимальный тайл для поддержки телефонами.