Does MV uses Async functions at all?

After some time learning JS, I came back to a MV project of mine. Out of curiosity, I took a look at its core js files(all the rpg_* .js) and notice that none of them have the words "Async", "Await" and "promise". After testing my game, and turning off a loader pluging(made by SRD) that I had installed, I also found that loading, events(parallel, common, whatever the type),etc all impact the main thread a lot.

So before suggesting, I would like to know: Does MV take advantage of Async functions to do CPU expensive tasks?

Async functions, despite of being a lot harder to handle(IMO), can automatically offload tasks to other threads(at least on PC, where the browser/nwjs handles the game. I can't speak por mobile). Using it would allow to load all (possible) next maps in the background(by checking all events active in the current map searching for map transfers in them, preloading those maps and their resources using a async function as soon as you enter the map), offload parallel events so they won't lag the game,etc.

MV is not multi-threaded. Everything runs on the main thread.

mv was initially written before the async functionality was standard. So in short - no.

MV uses javascript, javascript is mainly single thread, not completly. Using async functions, you can process stuff in a non-blocking-the-main-thread-way(what means that if the main thread can't process it without blocking the current work, the function is handle in another one). There's also web workers to do this multi-thread work, but they wouldn't work as simple/well as async functions here. Also node.js is experimenting with something like a webworker but that seems to allow much more control over the thread and communication between threads, so at least on PC it's becoming a thing.

And honestly I never liked this kind of answer when I was researching stuff about MV/Javascript in this forum. Many many people simple say "It's impossible, don't even try" whenever someone would ask if they could do something new (that would be potentialy hard). That's why I took some time off to learn and get to know some new stuff outside. Simply saying "You can't do, don't try" is a lie, and is probably the main reason why people don't try to make innovative plugins for MV, like they would for XP/VX/VXA, even though javascript has much more potential than ruby ever had.


It seems to be the case. But after so many performance updates in the javascript part in the past years, I wonder why didn't they try? Async functions are getting every day more and more popular, as it allows for better scalability of applications

Have you considered trying to write in that functionality and see if you can still port to mobile? As it is the only reason I could see to not have it is so it still supports mobile games.

Async functions are a standard in the javascript now, and according to mozilla doc page, it's supported in both android and iOS.
I don't know exactly how this method works, since I haven't checked it again yet, but as long as it supports ECMAScript 2017 (javascript standard specifications of 2017, I think) it should be fine.
There was also another easy method to export to android If I remember correctly, which seemed to be just chromium apk modified to load the game in it once opened. If that chromium is updated to that ECMA version too, it should also handle it


I still am learning async functions. The way they work is still a bit confusing to me(with all their promises, callbacks,etc) and since I came back to my project recently I didn't try to change anything yet.

Yes, MV uses asynchronous functions, no MV does not use the 'await' and 'async' keywords.

The version of NWjs bundled with MV did not support the 'await' and 'async' keywords until the most recent version (MV v1.6) and the devs did not rewrite the core code.

Asynchronous functions are used to load the database JSON files, for example.

Ah so they do seem to be slowly moving things toward it. Well, no need for me to open a topic making it a suggestion, case closed.

Before closing I would like to ask: how exactly they make those functions asynchronous without writting "async" before them? I thougth it was a necessary thing. I saw the use of promises inside their functions but as I said, I don't understand those well enough to tell what they're supposed to do.

@elpeleq42 I never said it was impossible, I just said MV was not written that way. If you want to support threads, you will be rewriting a good portion of the engine. You will also be rewriting a good portion of available plugins out there as well since they operate on MV's single main thread. You will also need to be using MV 1.6+ if I am not mistaken. Feel free to write a multi-threaded version of MV using async functions but it will be a ton of work.

I know you didn't mean to, but many times I received answers "too direct" like that, which makes curious yet "newbie" people come to think that something is simply impossible, and not worth researching, and thus kills curiosity/the will to find out and learn(IMO)

Javascript is indeed single thread, since you, in the end, will always need to send information back to the main thread to work with things. But the way you put your message made it look like that MV itself can only use one thread, no matter what you do.

Actually, async doesn't mean they're passed on to other threads in js.

Async still takes up space in the main thread. In particular it has some free room at the beginning of each animation frame, if I say it like that. The only difference between sync and async functions is, async functions don't execute for longer than x ms so that they don't block the main thread.

As for web workers, you're greatly limited in terms of them. They can't access the DOM and they communicate with the main thread only using messages, which are strings.

Not necessarily. I would imagine that the asynchronous functions that load the database have been there from the very start.


"async" is just a keyword. Asynchronous functions have existed in JavaScript for many years, for example, XHR (XmlHttpRequest). You may also have heard it referred to as AJAX (Asynchronous Javascript and XML).

I know it doesn't completly passes(As said, in the end the data always needs to go back to the main thread) but if it's possible to reduce the main thread work, it's a good thing to do.

Also I never heard of that limited amount of time it keeps executing. Are you sure about it?

I see, but it's a separated thing(from js), isn't it? Now that it's in javascript standard, it probably has a lot better support on most platforms.

about the Json: It seems you're right, the code contains xml-stuff to load the Json

Yes. Asynchronous functions have a dedicated portion of time each frame. If they fill it without finishing, then the execution gets paused until they get their time window again in the next frame. Etc., etc. When they finish, an event fires.

MV doesn't even make use of pixi's event emitter class. Which if it did, and it SHOULD IMO, it would be able to perform things in a much more asynchronous manner. So yea, because of things like that, I think that full asynchronicity is not main priority for the dev team.

I recommend you read Node.js's article on how they implement the the JavaScript event loop: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

No, the way the database is loaded is still a Javascript asynchronous function even without the" async" keyword. I think that you're getting hung up by the "async" keyword and believe that asynchronous functions are new to Javascript.

The "async" keyword is just syntactic sugar for Promises, that makes it easier to write asynchronous functions. It's the better, cleaner way to handle asynchronicity in today's world, instead of callbacks.

Note that plugins are actually loaded in a synchronous manner.

Yup, this, 100% agree here and it would make things much easier on plugin developers. Just imagine all events for game save, game load, new game, map load, and on and on it can go, I've been wishing for this for a long time now.

@elpeleq42 MV does not use much of anything other than ES5, in fact the repo on Github for the core scripts mentions that they do not plan on using or converting any code to use the latest JS standards.