VX ace or MV

[Sneep Snorp]

So both softwares are onsale on humble store and I am ind of strapped for cash but intend to get one. VX ace is much cheaper but with that I feel it might somehow be inferior. As I know very little about the two, what major differences are there and is it worth an upgrade?

[JohnDoeNews]

I feel like Ace is more powerful, and it has a big online community with recources and scripts.

MV on the other hand, supports plugins, which are overal easier to use. Also MV can export your game to HTML, Android, I-phone, and ofcourse windows, where Ace only exports to Windows.

In my experience: For huge projects, pick Ace, and for smaller online games or mobile games, pick MV.

[Wolfe]

I'm going to disagree that VX is a better choice or more powerful for large projects, I own both and absolutely prefer MV, especially for the the use of plugins, it allows you do all kinds of stuff that you can't do easily in other RPG Makers.

VX might yield you a smaller file size, but these days people expect to have some big game files, ARK Survival at 50GB+, etc. I personally have over 3TB of storage for games.

Also there's more scripts for ACE at present, but MV is growing all the time in that regard as people convert their old scripts to MV.

Of course it's only my opinion, but MV is the better choice even at the moment and will only continue to be more viable as more plugins are released.

[JohnDoeNews]

Well, the things, if you run an older computer, big projects may lag in MV. At least that was my experience when I first bought MV. I did read then, in this forum somewhere, what Ace would be more stable.

I must say I am working on a heavy game right now, in MV, and everything seems to run fine. So I can't anything else than agree with you.

I must say, there is not one script I missed, that I can't find a plugin replacement for in MV. So maybe that "bigger community" I stated is not accurate anymore either?

[SimProseStudios]

MV is much better in a number of ways: cross-platform support, much higher resolution and easier to use plugins and extensibility. IMO it's the only choice for RPG Maker these days.

[Xuande]

Have they improved MV's performance from being a flickery/laggy interface as it was at launch?
(i7-4770k/780Ti/16GB DDR 3/Win 10). It was so intolerable that I requested a refund after buying in near launch. I never got to the point of actually launching something, but if I can't get something at least as good as stable 30 FPS during runtime, then its not worth moving to me.

I want to migrate because VX Ace is getting bloated at this point (I'm seeing variable 15-30 fps with modded resolution near 1080p, in and out of combat), but I'm so dependent on a variety of scripts that likely haven't all migrated yet. Things like:

* Idle animations during combat (enemy sprite movement, resizing based on status effects, etc), some of which I can credit Hime for but much of which is self-made custom script.
* Custom resolution (though I understand MV is supposed to have this, and is the main reason I want to migrate, it might run smoother than VX Ace's workaround resolution)
* Enemy levels (which I adjust on the fly, rather than linear scaling)
* Chained battles
* Conditional counter-reactions to skills
* A hell of a lot of events that may or may not import correctly
* Custom HUD to show things such as gold count while on the world map

I personally lack JavaScript experience, though I assume its about as easy to learn as Ruby was. Even so, my habit has generally been to use someone else's script as a starting point so I can read and understand what it does, then write my own version to accomplish what I'm looking for.

[Caethyril]

İlk olarak Xuande tarafından gönderildi:

Have they improved MV's performance from being a flickery/laggy interface as it was at launch?

The recent 1.5.0 patch came with an Angle version (accessible through Steam's Betas system) aimed at fixing glitchy editor interface issues. I don't know whether it would work for you, though.

* Idle animations during combat (enemy sprite movement, resizing based on status effects, etc), some of which I can credit Hime for but much of which is self-made custom script.

For animated enemies I'd recommend Yanfly's Animated Sideview Enemies plugin[yanfly.moe] (I gather it works for front-view, too). For battle sprite motions: Yanfly's Battle Engine Core[yanfly.moe] and associated Action Sequence Pack plugins can do a lot of stuff. Yanfly has another plugin called Visual State Effects[yanfly.moe] that can assign animations to loop on anyone affected by the state in question. Resizing battle sprites on the fly is something I don't recall seeing, though.

* Custom resolution (though I understand MV is supposed to have this, and is the main reason I want to migrate, it might run smoother than VX Ace's workaround resolution)

Now it's even part of one of the default plugins, just change the numbers in the Plugin Manager, save, & playtest! =D

* Enemy levels (which I adjust on the fly, rather than linear scaling)

Again, Yanfly's Enemy Levels plugin[yanfly.moe] should cover that; I'm not sure what you mean by "adjust on the fly", but the default "plus or minus from the player's level" can be overridden by Javascript, which Yanfly likes to call Lunatic Mode. ^_^

* Chained battles

I guess you mean multiple battles where you aren't returned to the map in between each battle? I don't recall seeing a plugin to handle that, though with a couple of plugins (e.g. Himeworks' End Phase Triggers[himeworks.com] and an enemy spawning plugin, or maybe something like Triacontane's TroopUnlimited plugin[github.com]) you could probably use a battle event to handle it.

* Conditional counter-reactions to skills

Yanfly's Counter Control plugin[yanfly.moe] may be worth a look. =)

* A hell of a lot of events that may or may not import correctly

Can't tell until you try! But I guess you're using Shaz's VX Ace to MV conversion script[forums.rpgmakerweb.com]?

* Custom HUD to show things such as gold count while on the world map

Hudell, as the name may suggest, has a nice modular set of plugins called OrangeHud[github.com], fairly sure they could help you there.

I personally lack JavaScript experience, though I assume its about as easy to learn as Ruby was.

You may be pleasantly surprised! I find it considerably easier to understand than Ruby. xP

Even so, my habit has generally been to use someone else's script as a starting point so I can read and understand what it does, then write my own version to accomplish what I'm looking for.

I think that's pretty normal, especially with this plugin/add-on type coding where you are literally creating overrides to the base code.

[Xuande]

Thanks for the detailed reply.

To clarify a couple of points:

Resizing, I was using a bug-fixed version of Hime's Battle Sprite Zooming, combined with a few Common Events I wrote running in parallel process (using Hime's Global Common Events) to animate the sprite if its size exceeded the screen size (I had status effects for 1/4x,1/2x,2x,4x size, and I use front-view to maximize the available screen area for enemies), making it pan vertically/horizontally if needed. I have searched for and seen script designed to change sprite size, so as long as I'm able to move sprites in battle I should be able to recreate something similar enough.

Yeah, I'm using the VX Ace version of Yanfly Enemy Levels. (What I meant by "on the fly" is that I assign Enemy Level to a variable that frequently changes. At the start of a battle, I have any enemies present "transform" into themselves to "apply" level changes. For example, one of my games involves being presented with random parties of four, controlled by autobattle. Players bet on what level of enemy encounter they think that party can beat, while also applying a secret + or - modifier to all players' combat that round. The fights play out, and winning bets get paid in the form of stat buffs with higher bets paying out more. In this setup, I'm constantly changing Enemy Level based on player bets.)

In a lot of cases, it sounds like the toolset I use already has been ported. A lot of my reliances are based on scripts from Hime/Yanfly/Luna, with few exceptions.

[Xuande]

It would seem that $gameVariables.Value[id] cannot store decimal values, even on a script call - this is different behavior from VX Ace, and my scaling code relied on that. Thankfully, its easy enough to use a variable created in a script call to get around this restriction. In an hour of dabbling, I came up with this:

Control Variables: V[1] = 1 // set to whatever integer scale the enemy sprite is
Control Variables: V[2] = 1 // this variable will track frames the resize is using
Loop
  If V[2] <= 50 // so, this resize will take place over 50 frames
    Script
      "var x = $gameVariables.value(1) // base scale
      x += 0.02 * $gameVariables.value(2);  // set x to increase scale by 2%
      SceneManager._scene._spriteset._enemySprites[0].scale.x = x; // update scale
      SceneManager._scene._spriteset._enemySprites[0].scale.y = x;" // update scale
    Control Variables: V[2] + 1 // update tick count, and the value of x next loop
    Wait : 1 frame // makes the resize an animation, instead of instant
  Else
    Break Loop // when the desired time and size are reached, end the loop
  End
Repeat Above

Mostly just posting this in case someone else runs into this specific problem, but hey. This obviously isn't the optimal way to implement it, but its simpler than the version I'm working towards.

[Caethyril]

İlk olarak Xuande tarafından gönderildi:

It would seem that $gameVariables.Value[id] cannot store decimal values, even on a script call

Hmm, turns out there's a floor function in the Game_Variables.prototype.setValue code (found in rpg_objects.js), so all inputs going through that will be rounded down to the nearest integer. For reference, though, this script call does seem to work:

$gameVariables._data[1] = 5.5;
$gameVariables.onChange();

The onChange function is there to refresh the map/interface (it was present in the original code, so thought I'd better keep it in there).

[Xuande]

I'll try poking around with the ._data[id] syntax tonight, while not strictly needed it would make my code a lot cleaner if I could control the decimal values with gameVariables.

Would you happen to know the call for moving the x and/or y location of "SceneManager._scene._spriteset._enemySprites[0]" (or whatever syntax it ends up being?) Taking a break after working on this most of the night, and I didn't come up with it after some research and guesswork. If I can come up with that, then I can replicate all my VX Ace scripts, everything else appears to be in order. I don't believe the Yanfly scripts work in this case, but I'm fine being corrected if I overlooked anything. Again, thanks for the help.

[Caethyril]

İlk olarak Xuande tarafından gönderildi:

Would you happen to know the call for moving the x and/or y location of "SceneManager._scene._spriteset._enemySprites[0]" (or whatever syntax it ends up being?)

Assuming that's the correct object (looks plausible, though I'm not all that savvy with the battle code), it looks like Sprite_Battler, superclass of Sprite_Enemy (rpg_sprites.js) has _homeX, _homeY, x, & y properties. I think the former two are used for resetting the sprite position after movement, whereas the latter two represent the sprite anchor's current screen coordinates. So maybe something like this:

SceneManager._scene._spriteset._enemySprites[0].x += 10;
SceneManager._scene._spriteset._enemySprites[0]._homeX = x;

For completeness, the sprite anchor I mentioned comprises anchor.x and anchor.y properties, with default values of 0.5 (halfway across the image) and 1 (bottom edge of the image).

[Xuande]

_homeX / _homeY seem to be exactly it. I had tried .x (and some other guesses) earlier to no visual effect, but those calls do what I need. Thanks!

[Caethyril]

İlk olarak Xuande tarafından gönderildi:

Thanks!

Happy to help! ^_^

[Amelia]

I've used VX (not ACE, mind you. VX) for nearly 6 years and ACE for 5 years, 99% of which was before the steam port. I've been using MV on and off for about two years. I'm saying this first because I may be a bit biased.

I feel like working with XVA is an overall better experience. The UI is much cleaner and the script editing UI is easy to read, and the default assets make it easier for new users to jump into. It's honestly just as powerful as MV, at least from an eventers point of view, if you have a decent knowledge of how variables, switches and events work, you can do some really creative things without the use of RGSS3. MV is the same, only with a few more options that make it easier.

MV also has an arguably better generator. I say arguably because it looks nicer, but the overall variety in what you can do is much less than ACE. In ACE, I could make a character with 30+ expressions, in MV I struggle to make a character look like they're below the age of 20. Granted, I use a lot of Generator add-ons for both, but still.

MV is more powerful in the sense that it's more versatile, though. It can be played on other consoles and the Javascript capability makes it more readily accessible for programmers.

I'd say both are as good as the other. I prefer VXA, but moved onwards to MV.

[Caethyril]

İlk olarak why did you boingloings me tarafından gönderildi:

the script editing UI is easy to read

Well, MV doesn't have a built-in script editor, but if, rather than Notepad or something, you use a program that can be tailored to JS editing (I believe some examples are: Notepad++, Sublime, Netbeans, Eclipse, Visual Studio, ...) then it should be just as readable.

the default assets make it easier for new users to jump into.

Yes, the base data files seem to come and go now and then (always optional) with updates. Not sure why. Though I feel MV's range of default resources, covering basic fantasy + modern/sci-fi, is better than VX Ace's.

It's honestly just as powerful as MV, at least from an eventers point of view, if you have a decent knowledge of how variables, switches and events work, you can do some really creative things without the use of RGSS3.

Yes...but the same pretty much goes for every entry in the series. Plugins (an end-user-friendlier format of scripts), simpler multi-platform export, and GPU rendering are the big differences between MV and VX Ace.

in MV I struggle to make a character look like they're below the age of 20.

Oh. That hasn't happened to me, using only the base generator resources. Maybe you could try looking for child character generator parts?

MV is more powerful in the sense that it's more versatile, though.

I'd argue the framerate thing (GPU rendering) is also pretty important, particularly where map-scrolling or weather effects are concerned. MV seems to use around 1 GHz from the CPU (as expected, given mobile export is an option!) and achieves a smooth 60 fps, whereas VX Ace often struck me as much more geared towards, say, 30 fps games unless you're using a 3 GHz+ capable processor. That's with MV having a larger screen resolution than VXA by default, too.