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

Turns vs Frames.

Basically, we need a standard unit of measure for time.
The ATB is simply a counter that also obeys that standard unit of measure of time: how fast the counter increases (or decreases, depending on implementation) "per frame of time".

"Act two times per turn" for example doesn't mean as much in TPBS because there's no context. How long is a turn? What is a turn? Who's turn? My turn or your turn? Battle turn? What about states? When do they start or end?

In standard turn-based system, a single turn is when all units have performed an action.

For example in RPG Maker, the battle system is separated into two phases: input, and action. Input is when everyone makes their decisions, and the action phase is when it calculates the order that they will act, based on the actions they have selected. Faster actors will perform actions first. Skills with less prep time will likely be executed first. Once all units have performed their actions, the turn ends, and the next phase begins.

In other turn-based games like fire emblem, a turn ends when all of your units have made a move, although they don't impose an order for your units to act.

Love this! I think you've pretty much summed everyone up who's commented on it in this thread.

Also love the spoiler -in- spoiler -in- spoiler hierarchy. So much blue (in light theme)!

This sort of battle system - individual turns over "group"-based - has always been a preference of mine.

I personally prefer FFX-type CTB over the progressing bars ATB-type, but it's good to see something similar being implemented into the base engine, as well as making sure to consider the need for "individual turns" and global "battle turns". (Something I had to previously add to battlers and reprogram states/etc for in one instance of my project. Maybe the VXA one?)

To be honest im still a little confused, does any of the new battle system allow a "true realtime" battle for example something like FF13 where your status effects tick based on time and not turns? For example poison ticks every X seconds no matter if your character had a "turn" or not?

And about this: "The TPB Speed of a character is based on the square root of the character’s Agility. The character in a fight that has the highest TPB Speed, is given a Charge Time of 4 seconds. " is there any way to change this formular inside the editor or only with a plugin?

For a "true realtime" fight it would make more sense to have some kind of attack cooldown as seconds instead of a TPB speed which is clamped(?) to 4 seconds.

That's why I don't understand if something like that will be possible with any of the new systems or if I still need a plugin, I don't know why but for some reason I assume that the new system allows "realtime" fights can not fake turns with turn speed clamped to a magic number of 4 seconds.

I am pretty new to rpg maker in general and just started with rmmv a few weeks ago.

But being a c++ and c# dev by trade I was really looking forward seeing ES6 in the core engine. And for me personally as a coder this was indeed the biggest selling point and main reason I preordered.
So seeing that we will once again get this awkward prototype stuff makes me kind of disappointed :confused:

Sure, we can use ES6 in our own code, but it would be much better from a coding perspective to have a coherent code style. Mixing classes and prototypes just seems strange.

Agree, I doesn't really make sense. If it turns out that the final code doesn't use ES6 then it was false advertising no matter how you put it. I don't see any reason to argue about this, it's like buying a blue t-shirt and then they send you a red one and tell you "yeah but do you really need a blue one, you can still wear the red one, right?"

Yeah...

the documentation... nice to have but not good.... but a good documentation show's all of the processes. It show's where and when a function is called so you can understand the processes inside without searching 100 times stuff in the core.

ES5... ES6...
I don't see any reason (except layer mapping) to buy the new maker anymore.
Maybe the new structure will make a better performance? Hudell mentioned it earlier, that the rendering is way better.

Let's see what the reviews will show.

Hello.
Can TPBS be controlled through battle events? Well, for example, turn it on only if the enemy has lost 50% of their health?

You mean changing battle system during the same battle? If so, I don't think it'll have such a thing even though it's definitely possible to implement, as it's very, very complicated and convoluted to implement without tons of severe bugs, and the lives of many plugin developers working with battle systems will become hellish nightmares :)

It's not "up in arms" just because of ES6.
People have been hoping for some real improvements in the next RPG Maker. And a lof of what could have been done didn't materialize. From the outside, RMZ looks like RMV + a couple updates on the core engine to make it work better plus a handful new features.

We were essentially told: you can't have all the shiny things, you already get an ES6 engine that had to be redone from the ground up.

If that immense overhaul of ES5 into ES6 doesn't materalize, and a lof of the code is the same, then the reason for the lack of other improvements starts to look very shaky.

And on the other hand, the argument of "being able to have an easier time to port stuff" isn't a windcatcher that'll change direction every time there's a breeze.

We were told that RMV plugins would be incompatible - the price for an entirely overhauled ES6 engine.
Okay, so plugins will break. We can deal with that.

Now the argument is "well, we didn't change a lot of ES5 things so porting plugins is easier". Is it? Now instead of going from ES5 -> ES6, you need to compare your plugin code to the engine and figure out where change is necessary and where it isn't. How much time will be saved by that?

And what of all the old RMV plugins where the devs left, that'll break a little, just enough to be non-functional, but could be ported with less difficulty, except no one will port them because the dev is no longer around?

It feels just so damn whimsical. If RMZ looks like an updated RMV, but the price for an overhauled engine is that most of the RMV plugins will no longer work out of the box, then go all the way.
If you're rewriting the entire engine, then don't pull punches, don't replicate old stuff that seriously needs to be overhauled, overhaul it. If you're doing it anyway, then why not improve the engine & editor from the ground up?

This half-way inbetween thing between "We had to break all the plugins because of the improvements" and "We didn't improve a whole lot, so the plugins that we broke can be ported more easily by devs long gone" is just really frustrating and disappointing. :dizzy:

I am a fan of the CTB-style system, too. I believe that with just a little custom scripting, you could make it so that the ATB bars are invisible, and characters' "ATB values" (how close they are to their next turn) fill up at light speed so the player might not even notice there's a wait.

If I've thought through it correctly, that would perfectly simulate how a CTB system; it's just that you wouldn't (by default) have a way to represent it visually to the player without a more significant scripting effort.

The Progress Time System can optionally be "true real-time" in the sense that the ATB keeps ticking even as you pick actions from the menu, so enemies can hit you while you're making a decision and multiple battlers can be "ready" at once.

However, as far as I understand, there is no way (without plugins) to make it "true real-time" in the sense that statuses tick or wear off based on time passed (or frames passed) rather than turns taken. This would definitely be possible with a plugin; I'm not sure how hard that plugin would be to make. Depends how the base code library's methods are written.

I'm less sure about your other questions but my instinct is that you'd need plugins or custom scripting for the rest of the stuff you mentioned.

I'm actually happy the changes in the codebase seem to be focused on performance improvement and new features rather than stylistic changes. Not everybody wants to try to figure out how to hack Pixi 5 into MV somehow. I plan on porting my project over to MZ, and hopefully this means I won't have to change too much of the code I've written. I've written some of my stuff with class syntax, but I don't see why folks seem to be upset over the engine not using it. It's cleaner and all that, but JS still uses prototypal inheritance under the hood. But admittedly I'm not a pro-level programmer.

You know what guys.
I can't wait to see how do they implement Window_BattleLog this time.
Will they keep it the same as MV does or worse better.

@Touchfuzzy I was wondering do we still get a steam code when we buy MZ through the store like MV did? For those of us who have Mac this is important to know and may change if we purchase at all or where we purchase it.

Edit: Nevermind I found it. It says yes on another thread.

oh no, the backend to MZ turned out to be so similar to MV you can practically drag-n-drop the old plugins into the new thing, despite them saying it is completely rewritten it, who could have seen that coming???

Hahahaha, I gotta say, I ain't surprised at how little things changed. Maybe a little disappointed, definitely annoyed, but not surprised. I'm still getting MZ, I got the cash to burn and not much to buy this August, but wooooof. I said it before that they have to do a lot of convincing and work to do to make this appear to be the upgrade from MV it is priced as, and the news of how little they done in moving from ES5 to ES6 is... not that.

I assume there will be still be an option to toggle between a front and a side view for the battles?

You can still use frontview, yes.

Thanks to the RM staff for the patience. Some negative attitudes since the first trailer (some in very rude and unrespectful ways) are surely mentally draining. More if you're just having to put your face here everyday while the real development is somewhere far away. It's even tiring for me sometimes when lurk around these threads, lol. :hsad:
The only thing I don't get is the "I don't understand why it's done in a different way that what I wanted/expected". There will be always someone happy and someone mad about whatever decision they make and the RM staff is allowed to share the information given by Kadokawa, as Touchfuzzy got tired of repeating since the first trailer, so they're not to blame for everything that you don't like.
I mean, some are completely respectful and I've seen some interesting dialogues have been exchanged, but others are just plain rude. Chill, people.


I'm pretty sure if that's the real situation a lot of non-programmers will be happy, cause there were many complaints because people just couldn't reuse their plugins from MV.

Pretty much, that's all it takes to go to real-time.
For example, maybe the code looks like this (it's basically the logic I wrote for my ATB )


In fact, this is real-time. There's no logic that prevents the game from continuing to increase frame count. Actors will continue to increase frames, enemies will continue to increase frames. The game will continue to check if anyone is ready to perform an action, and then execute it.

Stopping time from flowing is actually an additional restriction lol


In the worst case, we'll have to change it from a "turn-based" counter to a frame-based counter.

Tbh this was an miscommunication.

To me i was excited for es6 a lots since i just like how es6 works but if its es5 fine.

But i just hope its not when i will open the code it will be zero change from mv then now i will be very skeptical but regardless i am happy for the plugincommand change and is excited to change it.