NEW RPG MAKER INCOMING?
Posts
Sooz
They told me I was mad when I said I was going to create a spidertable. Who’s laughing now!!!
5354
Like for serious is this the first time their marketing department has encountered RPG Maker?
ATB boiz
(cant link the video for some reason but type in "RPG Maker MZ Time Progress Battle Skit!" in Youtube)
Default menu looks pretty poo although I do like the left/right page icons on the top left... At least the default font looks decent, for those who are adamant in changing the font in their games XD
(cant link the video for some reason but type in "RPG Maker MZ Time Progress Battle Skit!" in Youtube)
Default menu looks pretty poo although I do like the left/right page icons on the top left... At least the default font looks decent, for those who are adamant in changing the font in their games XD
I think my only worry is that the new animation system won't work very well with the pixel art form I usually tend to go with.
Particles look like they have to be high resolution.
Particles look like they have to be high resolution.
If there's no way to switch back to Sprite-based animations instead of particle based ones, I assume it's going to be devastating for pixel art games. Granted, I don't know how much extra effort it takes to do sprite animations in a particle editor, if that's even possible.
I feel like they're really pushing people to use RTP or an RTP-like style with this.
I feel like they're really pushing people to use RTP or an RTP-like style with this.
I'm 90% sure it's going to be way easier to do sprite/pixel animations on EffekSeeker than is on any current RPG Maker.
I mean, do you really think someone placed these frame by frame?
Starting from the Potion animations:
That's a single pixel art animation on a spritesheet, that you'd place on the screen on effekseeker and play out. You just duplicate it two more times with a timing offset and it'll look exactly the same.
On RPG Maker you can't just place a spritesheet and have it play out like that, you either place each frame individually (from a spritesheet limited to 45 frames) or use the Tween function (then risk messing up the more different frames you need to tween from / to)
And to make an animation like FFVI's potion effects you only need cells that are 32x32 pixels large. Yet you were still forced to use 192x192 cells even then.
Other pixel effects are a matter of doing the exact same thing, but moving the cells around from point A to point B. Instead of typing in initial and final coordinates, you'll type in initial coordinates, motion and particle death, for example. You can have the pixel cells move along with easing rather than the annoyingly linear movement of the Tween function.
It's powerful. It's gonna take a while to learn, but by learning he most basic functions you'll already be able to do way more, way easier, than on any RPG Maker.
And the time you save not hand placing stuff from a limited 45 cells sheet already justifies the learning investment.
edit: Look at the White Magic casting effect. Think about how HELLISH hand-animating each of these little dots would be. Not to mention, it'd be almost impossible on rpg maker because of the 16-cells-per-frame limitation.
I don't know if EffekSeeker supports paths (so you can have the particles move along the heart-shaped path) but that's certainly what FFVI did -- either that, or a rather complex formula in the position field.
Speaking of which, I also don't know if that's how effekseeker works but, yeah, on some particle engines on the "position" field of a given cell you can type a formula. Like, for example, X = 100 + T*2, which would mean that the X position of a given cell would be 108 at frame 4, or 120 at frame 10.
edit:
there you go

this features random placement while FFVI's tonic is fixed placement, but not using random placement is just a little bit more work (since you need initial coordinates for every sprite etc)
I mean, do you really think someone placed these frame by frame?
Starting from the Potion animations:
That's a single pixel art animation on a spritesheet, that you'd place on the screen on effekseeker and play out. You just duplicate it two more times with a timing offset and it'll look exactly the same.
On RPG Maker you can't just place a spritesheet and have it play out like that, you either place each frame individually (from a spritesheet limited to 45 frames) or use the Tween function (then risk messing up the more different frames you need to tween from / to)
And to make an animation like FFVI's potion effects you only need cells that are 32x32 pixels large. Yet you were still forced to use 192x192 cells even then.
Other pixel effects are a matter of doing the exact same thing, but moving the cells around from point A to point B. Instead of typing in initial and final coordinates, you'll type in initial coordinates, motion and particle death, for example. You can have the pixel cells move along with easing rather than the annoyingly linear movement of the Tween function.
It's powerful. It's gonna take a while to learn, but by learning he most basic functions you'll already be able to do way more, way easier, than on any RPG Maker.
And the time you save not hand placing stuff from a limited 45 cells sheet already justifies the learning investment.
edit: Look at the White Magic casting effect. Think about how HELLISH hand-animating each of these little dots would be. Not to mention, it'd be almost impossible on rpg maker because of the 16-cells-per-frame limitation.
I don't know if EffekSeeker supports paths (so you can have the particles move along the heart-shaped path) but that's certainly what FFVI did -- either that, or a rather complex formula in the position field.
Speaking of which, I also don't know if that's how effekseeker works but, yeah, on some particle engines on the "position" field of a given cell you can type a formula. Like, for example, X = 100 + T*2, which would mean that the X position of a given cell would be 108 at frame 4, or 120 at frame 10.
edit:
there you go

this features random placement while FFVI's tonic is fixed placement, but not using random placement is just a little bit more work (since you need initial coordinates for every sprite etc)

















