ТЕМА: RPG Maker MZ

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Luar_Zero пишет:
Ну одна из причин. Сохранить 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 пишет: насколько я знаю, из основ пиксельной графики, то изменять размер можно именно в кратном увеличении, например, в 2, в 3, в 4 раза. Если увеличивать в рандомный процент, например, в полтора, есть высокая вероятность, что появятся ненужные пиксели, а пару ненужных пикселей очень сильно ломают линии.
п.с. хотя я и не спорю с тем, что едва ли они новые паки продавать хотели.

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:D:<

@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.