RPG Maker MZ, Preview #5: TPBS, A Closer Look

● ARCHIVED · READ-ONLY
Started by RPGMakerWeb 236 posts Page 9 of 12 View original ↗
  1. Hudell said:
    MZ can still have a much better performance than MV, all I meant by that was that the one thing I know hits very hard on performance hasn't changed, but they can have improved things on any other corner of the engine.
    I had high expectations about this. Now I'm disappointed.
    Well, it remains to be expected that at least the performance will be good, and not the flop that was the MV in beginning.

    I just hope.
  2. I think if you look at what we know about the engine now and think you would be "ripped off" or whatever then that just means the engine (at this stage at least) is not meant for you.

    Including a bunch of functionality that once was only possible with plugins/scripts in the base of MZ increases it's validity as being THE engine for novice game makers. It's the branding for these makers. So the arguement of "I can already do that with plugins in X maker" is irrelevant because you clearly aren't the main target audience. Do see a reason to buy MZ? Then don't, all the previous makers will still work just fine and won't just magically stop working all of a sudden when MZ drops. Nobody is forcing you to buy it.
  3. Hudell said:
    , all I meant by that was that the one thing I know hits very hard on performance hasn't changed, but they can have improved things on any other corner of the engine.

    I still have faith and I need to have. And in case this is not fixed, hopefully it will be, after a first update or something. This really must be done. If MZ games will perform good, it is enough for me to pre-order to be honest. I don't need the assets. What I need is an optimized engine.
  4. From the perspective of an artist, I still like what I'm seeing from MZ, so I'll definitely be getting it as a preorder. Having said that and about programming on MZ, the information that has been revealed about the core API so far might not be the final product. Furthermore and assuming that the coding format used for the core API sticks, the MZ core scripts might be written differently from how the core API has been written. In other words, the MZ core scripts could get the VX Ace treatment and be made more readable and understandable than the MV core scripts. I don't want to get anyone's hopes up about that as I don't know how the final version of the MZ core scripts will look like before RMMZ is released, but at the same time, I want to give Kadokawa and Ojima-sensei the benefit of a doubt as RGP Maker does have a track record on having the scripts changed/improved on each RPG Maker since after RMXP. Also, I wonder if there's truly no Z-position/Z-layer on MZ (let alone, a way to implement that if MZ doesn't really have it). Z-rotation is possible on MZ when it comes to the animations on MZ, so I don't buy that Z-position isn't possible on MZ.
  5. _Shadow_ said:
    I still have faith and I need to have. And in case this is not fixed, hopefully it will be, after a first update or something. This really must be done. If MZ games will perform good, it is enough for me to pre-order to be honest. I don't need the assets. What I need is an optimized engine.
    I also still hope mz will not be a lagfest then mv, but whenever I mention mv and talk about why it is so laggy in the first place, people always get defensive and hell.
    We can only pray to heaven that they actually changed the optimization and code enough, so that it not will be another mv, and with that, another disaster... specially the first months...
    And to b bloody honest, knowing it will be again WEBGL and again JS, and the code will stay mostly the same, gives me little hope...

    Let me remind you guys of:

    Asynchro Loading system , lag spikes for the most little thing, like show or play animations, sound, transtions and other normally simple tasks for an engine to perform, heck... let me remind you of the 1-4 sec audio delay and even hue animation delay... that all made mv already shutter.
    And that stays true till this day... even with 0 plugins and default resscoures only.

    So it is kinda naive to think mz will magically fix it all, if it stays in its core the same thing...
    VXace and older did not have asynchro loading and not WEBGL, which are a big cause to those delay... MZ will still use this system, for the sake of being crossplattform...
    I will stay hope with you all, but the reality of code and logic looks rather grim.
  6. Hi! A question, which version of Pixi does MZ use?
  7. boringprotagonist said:
    Hi! A question, which version of Pixi does MZ use?
    I saw it somewhere, If I recall correctly it was something like v5.2 or slighty above
    Here is also a link to the API Documentation that is out so far:
    RPG Maker MZ API Documentation
  8. Heartless_Angel said:
    Asynchro Loading system , lag spikes for the most little thing, like show or play animations, sound, transtions and other normally simple tasks for an engine to perform, heck... let me remind you of the 1-4 sec audio delay and even hue animation delay... that all made mv already shutter.
    And that stays true till this day... even with 0 plugins and default resscoures only.

    So it is kinda naive to think mz will magically fix it all, if it stays in its core the same thing...
    VXace and older did not have asynchro loading and not WEBGL, which are a big cause to those delay... MZ will still use this system, for the sake of being crossplattform...
    I will stay hope with you all, but the reality of code and logic looks rather grim.
    Async loading is actually better than sync, as it doesn't cause lag. MV had flickering because of async loading but it can easily be fixed with a tweak to the game interpreter, which they may have done as the interpreter file was not included on the API they released.

    I believe the audio lag is fixed too. I haven't tested but they said it was fixed and the audio code changed drastically, so there's no reason to doubt them.

    WebGL is also a lot better than the software rendering that Ace had.

    boringprotagonist said:
    Hi! A question, which version of Pixi does MZ use?
    I think someone said it's 5.2, but I don't remember where. From the code I can say it's at least 5.0
    5.3 was released after MZ was announced, but it's an easy update from 5.0 so they may be changing to it
  9. Hudell said:
    Async loading is actually better than sync, as it doesn't cause lag. MV had flickering because of async loading but it can easily be fixed with a tweak to the game interpreter, which they may have done as the interpreter file was not included on the API they released.

    I believe the audio lag is fixed too. I haven't tested but they said it was fixed and the audio code changed drastically, so there's no reason to doubt them.

    WebGL is also a lot better than the software rendering that Ace had.


    I think someone said it's 5.2, but I don't remember where. From the code I can say it's at least 5.0
    5.3 was released after MZ was announced, but it's an easy update from 5.0 so they may be changing to it
    Sounds good, I just hope you are right Hudell, if not I have to switch to a other game engine, MZ is the last hope for making my game without coding everything from scratch in a different engine.
    If MV system in generally speaking better then VXACE etc, then it not did a good job using that system, causing it to lag and shutter, over the most simple actions.
    The way it loaded things was really bad.
    But lets not lose hope just yet, that MZ learned from those mistakes that MV made, since MV was in my opinion a test engine for the change to WEBGL JS etc. thats the feeling I got from it.
  10. Heartless_Angel said:
    Sounds good, I just hope you are right Hudell, if not I have to switch to a other game engine, MZ is the last hope for making my game without coding everything from scratch in a different engine.
    ...
    Unity and Unreal have a asset store with "rpg template projects", the good ones cost money, but so does RPG Maker and you don't have to write everything from scratch, the good ones also include editor tools to setup the game data so you don't have to write code unless you want specific features and you can still create a decent rpg with them
  11. The audio load lag is 100% gone.

    Also, I had a map playing something like 60 animations playing a second with no noticeable lag on my computer. Which if you tried to do that in MV would have destroyed it.
  12. Kaliya said:
    My point is, the engine hasn't released yet, NONE of this info actually affects any developer because no developer has begun plugin development for MZ yet.
    Untrue. I've already written two. (Using only the released core doc as reference.)

    Shaz said:
    Seriously - I'd question if many people preordered MZ because it was all rewritten as ES6. Surely you'd want some better reasons than that to part with $60-$80?
    Literally, the main reason for me. I literally have no reason now to purchase mz as the core code shows me how little has actually changed, and I also have no need for any of the code that is yet to be released.. I mean, I'm still gonna get MZ on day 1. But yea, the codebase was the only selling point for me. I literally only open the editor to press playtest (edit: and track hours on steam - at 2514 hours atm :p).. has been that way for at least 5 years now...

    Kupotepo said:
    @Uzuki, @??????,@ImaginaryVillain, @DoubleX and @nio kasgami , just say hello. I hope you are well. :kaohi:
    Hello. I am well, I hope you are too!

    My own thoughts: There is no way to deny the fact that the mz core codebase does not use es6. At least not as initially advertised. False advertising is a huge thing that affects companies both large and small. Lots of people around the world have been sued for lesser crimes...

    Its very clear at this point that MZ isn't much more than MV+effekseer+default atb (sorry, tbs - cause 'atb' systems are patented by square enix I believe). Either accept that, purchase it, and move on, or dont purchase it, and keep using other outdated makers. The choice is yours alone.

    Eventually a sale will happen where you can get it for $10 as part of a humble deal or something anyway. If you feel that MZ doesnt contain enough value for the initial asking price, dont pay it, wait for a sale, and get yourself something that is more cost effective/worthwhile.
  13. I'm going to buy MZ somedax, but looks like it will be only for music.
  14. Hudell said:
    Async loading is actually better than sync, as it doesn't cause lag. MV had flickering because of async loading but it can easily be fixed with a tweak to the game interpreter, which they may have done as the interpreter file was not included on the API they released.
    Sync loading won’t cause lag if done at the right time. Similarly, async loading won’t automatically solve lag by itself.

    Loading large assets that cannot be streamed but must be in memory in their entirety (textures, ie. tilesets, character sheets and so on) on demand “just in time” is guaranteed to cause delays and visual artefacts, like how we’d see in MV with audio and images missing for several frames at times. This is why you’d either want to preload the map or you’d eager load in advance of when assets are needed — something game engines generally call asset streaming. The same goes for audio if you need to time the playback to within a certain precision of frames / sub second timing, even if audio can be streamed. Because when you’re dealing with JS you’re not given direct disk access; you request it through a browser intermediary. This is why I tend to preload audio into memory in JS games because I need to know I can sync SFX properly to animations.

    I’m curious to see what MZ does on this front.
  15. @ShadowHawkDragon
    Thankyou.
    That's basically what i've been trying to ask.
    As long as the grid is even, it can be any size.
  16. Hudell said:
    As I continue reading the new code, I realized there's no new layer. The extra layer added to the editor was already there on MV but used only internaly by a few A tiles that supported transparency. It's only "new" because you can select them manually now.
    It's been there since Ace (or even VX). So yeah, not exactly new. Took them long enough to add a manual select layer.
  17. The thing who change now is that you can put WHATEVER tiles u want on any layer which wasnt possible before so technically yes 4 layers was already existing but its behavior changed
  18. nio kasgami said:
    The thing who change now is that you can put WHATEVER tiles u want on any layer which wasnt possible before so technically yes 4 layers was already existing but its behavior changed
    Yes, the point of this was to say that map files are compatible between versions. Even though you can access an additional layer on MZ. You can even use MZ to work on your MV project maps using this extra layer.
  19. Hudell said:
    Yes, the point of this was to say that map files are compatible between versions. Even though you can access an additional layer on MZ. You can even use MZ to work on your MV project maps using this extra layer.
    sadly because of how RM is hardcoded on the file it will overwrite the extra data :c
    (well not really since it's the same amount of layers)
  20. Touchfuzzy said:
    The audio load lag is 100% gone.
    Also, I had a map playing something like 60 animations playing a second with no noticeable lag on my computer. Which if you tried to do that in MV would have destroyed it.

    @Touchfuzzy one question. If we bought MV on Steam, how can we get a discount on your website store? I mean, what if I want the full discount, but also wanna give the money directly to Degica?