Do you guys think after RM Unite, GGG will use babylon.js for next RM ?

[Neptrone]

As we know GGG introduced RM Unite as their new product. But there are several cons regarding RM Unite.
1. RM Unite technically just package for unity (built on top of unity), RM Unite probably will compete with other Unity package.

2. Massive difference of programming language. Unlike MV and MZ which use JS, RM Unite will use C#. Which i am not interested learning it. (My time already invested in other complex software such as After Effects and DAW)

I know it's too early to discuss it but what i find interesting is according to their recent interview they want to make better and efficient workflow for veteran of RM Dev. They want to change the workflow because the main problems of game development in general is " it's always easy creating game in beginning but as complexity of your game development grow, finishing your game would be very hard" , GGG want to tackle that problem. i think that interview is applicable not only for RM Unite, but as a whole RM Ecosystem/product in general.

this is why i think next RM (after Unite) Should use babylon.js. There are several advantages that i know.

1. Babylon.js has very well documentations than pixi.js

2. Unlike Unity (a game engine which has own editor) Babylon.js does not have editor specifically for game creation although you can still make awesome game with it. Babylon js is simply a real time 3D engine using a JavaScript library for displaying 3D graphics, everything must be created using coding approach which more holistic, (You can even create data oriented design or ECS in Babylon.js) . I think GGG can take advantage of this by creating their own editor specifically in top of babylon.js with more modular functionality similar like Unity or UE Editor but more focused on RPG creation.

3. Javascript and typescript support, perhaps most MV/MZ plugins will work and typescript (which superset of Javascript) will give less compile error than pure javascript.

4. WEBGPU. It's still experimental stage, but the demo of WebGPU in babylon js is very promising compared to WebGL, a massive boost of performance which would benefit for RM Dev. here is for example : a demo of ocean simulation.

5. https://github.com/BabylonJS/BabylonNative Babylon native which deploy your game project into more native app. Babylon native does not use Dom or HTML Rendering instead it will use native graphics APIs (DirectX on Windows, Metal on iOS/MacOS, OpenGL on Android, and OpenXR devices such as HoloLens 2 and Oculus) which would give better performance in general.

6. Babylon js is free and open-source.

So what do you guys think ?

 

[Zeireth]

I do not mean to be rude but you mention "As we know". I honestly do not know. As I know, GGG to me is Grinding Gear Games. A company founded and lead by Chris Wilson. I have been playing the new league on Path of Exile.

I saw something familiar such as GGG and laughed. GGG could mean "Good, giving, and game". It could mean a nickname for Gennadiy Gennadyevich Golovkin. It could mean girlsgogames. Those three things show up in a search engine.

Ah I understand. Sorry I write this as I am searching and know I understand what you mean by GGG. You mean Gotcha Gotcha Games. Sorry about that. Honestly never heard of them until I looked at RPG Maker Unite on Steam just now.

I have now read their about section on their website. I see they created "Maker" (Tkool) series. I also saw that Kadokawa Corporation owns 100% shares of Gotcha Gotcha Games.

I hope my discovery of Gotcha Gotcha Games has given context to others that read your post.

I think acronyms are good in certain circumstances. Acronyms can confuse those without prior knowledge or understanding.

Well anyways, my opinion about RPG Maker Unite is positive. I have been meaning to learn C# and get into Unity. I have attempted in 2011 when in college. Unfortunately it was too much too handle all at once for 18 year old me.

I see you are interested in Babylon.js and WEBGPU. I never heard of those until now. Have you tried implementing them to your project. You could try making an engine using them, or try adding integration into your RPG Maker project.

I wonder how the older users felt when RPG Maker moved from Ruby coding language to Javascript. I welcome the new changes. It might bring in more people into the community that may have not been interested in RPG Maker because of Ruby or Javascript, and now C# may entice them to give it a try. I know in particular some random plugin developer will be happy about C# in RPG Maker.

I think it is interesting. I thank you for sharing. I hope you have a nice day.

 

[chaucer]

Interesting topic!

As we know GGG introduced RM Unite as their new product. But there are several cons regarding RM Unite.

Your forgetting two other cons that I can think of just off the top of my head.

Unity does not have true 2D support, unity does "2D" via an orthographic camera in 3D space. What does this mean? it's a bit more expensive than real 2D rendering. This also comes with problems with shadows in unity via 2D( at least there was last time I used it ), which causes shadows to not be rendered precisely.

Unity also has paid licenses, which means not much for the average user, however if you don't want your game to have the unity splash screen, it's gonna be $399/year lol which is a huge bummer, the rest of the features of a paid license really probably won't ever apply to the average game dev in this forum.


I personally like the move to C# it's a far superior language and far easier to understand than javascript imo( albeit a bit harder to master as it's much stricter ). It's also much faster than javascript, although I personally don't like the move to unity I'm on the fence with picking up this engine, i may get it just to own it but I don't know if I'll ever truly use it myself.

I'd have preferred to see them move to Godot, since it supports C#, I believe they also use a more modern version of mono. It also comes with it's own language called GDScript which super easy for beginners to learn, it's pretty similar to python. There's also no license fee's it's free and open source, Godot also has true 2D rendering as well.

1. Babylon.js has very well documentations than pixi.js

Babylon.js is a 3D rendering library, PIXI.js is a 2D rendering library, PIXI.js is also very well documented with many examples of how to use it as well.

3. Javascript and typescript support, perhaps most MV/MZ plugins will work and typescript (which superset of Javascript) will give less compile error than pure javascript.

This is extremely unlikely, MV/MZ plugins are written for 2D if they used babylon js everything would have to be rendered in 3D, meaning that the code itself would largely be very different. Especially anything graphics related. there would be almost 0% compatibility, I say almost cause nothings certain, but it's very, very unlikely any existing plugins from MV/MZ would be re-usable.

4. WEBGPU. It's still experimental stage, but the demo of WebGPU in babylon js is very promising compared to WebGL, a massive boost of performance which would benefit for RM Dev. here is for example : a demo of ocean simulation.

I think webgpu is going to be awesome! I think there's still going to be limitations when building web games, but that's going to definitely be a game changer, I haven't looked into webgpu in over a year is it officially suported on any browsers yet?

 

[Neptrone]

Interesting topic!

I personally like the move to C# it's a far superior language and far easier to understand than javascript imo( albeit a bit harder to master as it's much stricter ). It's also much faster than javascript, although I personally don't like the move to unity I'm on the fence with picking up this engine, i may get it just to own it but I don't know if I'll ever truly use it myself.

why would C# is far superior language ? Because Static syntax ? Typescript would handle it

Why would C# is much faster than Javascript ?

To be honest i find hardly any meaningful comparison between JS and C# in real-life scenario in terms of speed. But If you mean C# is fast because it's use in unity, it's not really accurate since Unity runtime is using C++. Babylon native runtime also using C++ too (and hopefully will use Rust)

 

[chaucer]

why would C# is far superior language ? Because Static syntax ? Typescript would handle it

Why would C# is much faster than Javascript ?

While Typescript does make javascript a bit more usable, it's still essentiallly just javascript, just in an easier to use format. The performance gain is what makes C# superior, not just the syntax.

C# is a more efficient language, this isn't just opinion this is just fact. Below is an example of approx. how much faster C# is than javascript.

https://medium.datadriveninvestor.com/how-fast-is-javascript-to-c-or-c-29d104f4f255

To be honest i find hardly any meaningful comparison between JS and C# in real-life scenario in terms of speed. But If you mean C# is fast because it's use in unity, it's not really accurate since Unity runtime is using C++. Babylon native runtime also using C++ too (and hopefully will use Rust)

I'm not talking about Unity's runtime, this is besides the point of what I'm talking about, C# is faster, in nearly if not all aspects see the above link, this is only one example. of the performance difference.


I disagree with this completely, there is a lot of benefits in real life scenarios from the speed increase.
Running a C# app on android/ios is much much faster, especially for lower end devices, this could drastically improve your target audience for your game. Same with PC as well, because of the speed of C# you can target lower end hardware. It also allows for more room for more computationally expensive/advanced plugins.

In short the speed boost will allow for more complex plugins and increase a developers target audience. Both of these things are good.

As for babylon js, again this is only a 3D library, while unity doesn't implement true 2D rendering it at least has 2D, if they used Babylon js they would be forced to write their own 2D implementation, Which by the looks of RPG Maker Unite, it IS utilizing the 2D mode of unity, and not 3D.

 

[Neptrone]

While Typescript does make javascript a bit more usable, it's still essentiallly just javascript, just in an easier to use format. The performance gain is what makes C# superior, not just the syntax.

C# is a more efficient language, this isn't just opinion this is just fact. Below is an example of approx. how much faster C# is than javascript.

https://medium.datadriveninvestor.com/how-fast-is-javascript-to-c-or-c-29d104f4f255

that is just microbenchmark from 2020 and like that blog said "Nothing from this thin cross-section mirror real world examples, and there are futher optimizations that could be considered here."



I can give you recent benchmark that show JS >= C# in speed. here is for example : https://github.com/kostya/benchmarks

I disagree with this completely, there is a lot of benefits in real life scenarios from the speed increase.
Running a C# app on android/ios is much much faster, especially for lower end devices, this could drastically improve your target audience for your game. Same with PC as well, because of the speed of C# you can target lower end hardware. It also allows for more room for more computationally expensive/advanced plugins.

That is not what i am saying. What i am saying is the speed gap between JS and C# is hardly relevant and does not give any meaningful performance gap marginally in real world scenario. What really relevant is the architecture of Software framework which usually consist of multiple programming languages. If that software framework has really good design pattern, algorithm, and data structures then that software obviously will have good performance.

 

[chaucer]

in those examples there are clear cases for both sides, but a few of the things that node.js is outperforming on are things that aren't necessary to use in C#( or JS ), for game development, such as base64. node.js however does appear to outperform in matrix multiplications, which seems pretty impressive.

However I still disagree with you especially when it comes to mobile and lower end devices, since JS uses webgl, and for js to send data to webgl, this is very slow, I garuntee you there WILL be real world performance differences especially on lower end devices and mobile platforms, even if js itself is on par with( or even surpasses ) C#.

webgpu closes that gap a bit more but like you said this is still experimental.

 

[Synrec]

Both JS and C# are compiled* languages.

Code in JS is most likely written differently when adapted for C#.

If you all wanna argue speed, why not write up a game engine in Assembly? Rarely would you require the speed difference in real applications.

 

[Ronyunderen]

I'm happy RM always trying to be better and break the limit but still have the cores, but ... for me ... it's not about the engine, it's about the resources. I pay freelancer to make my OC art, monsters, music, etc, i pay dlc so i can have new contents, so my game try not to use RTP.

(that's why I'm very very grateful there are alot of kind people in this forum try to help my scripts. But, if my game make money someday, i don't care if i must pay it too)

How about the engine? I can handle it. RM engine has been created intended to be easy for newbie and powerful for veteran lol. Even i made my game with VXACE, if the content is unique, people will buy and play it.

And for example, even if i get my 'RPG maker Unreal', if i still use RTP, people always think twice lol.

 

[chaucer]

Both JS and C# are compiled* languages.

Code in JS is most likely written differently when adapted for C#.

If you all wanna argue speed, why not write up a game engine in Assembly? Rarely would you require the speed difference in real applications.

You're only looking at one aspect of the argument. While the extra speed may be "rarely required", your missing out on the fact that lower end devices would largely benefit from that. So sure for a higher end machine the difference will never be seen, but for lower end devices it will.

Basically your arguments are that there's no real world scenarios where this performance gain will ever be noticable.

Well here's a real world example for you.

The Unity Angry Bots demo( available on the google play store, wont link it it's easy enough to find ), a demo made in unity( an old one at that ), a 3D third person shooter utilizing rigged/animated 3d models, runs at a perfectly playable frame rate on a cheap 100 dollar phone I picked up in order to help optimize my plugins I write for MV/MZ.

On the other hand! Running a freshly made project in MV/MZ no extra plugins, struggles to keep a steady frame rate, however to further demonstrate the point, downloading the MZ3D demo( which utilizes babylon.js according to the title of the thread ), and packaging it into an apk and running it on that same phone, the entire project is running at under 10 fps. Again, this is the same phone.

One could argue "get a better phone" and I can definitely do that, but is that really something you wanna tell someone who just bought your game? I know I don't. Heck by that logic programmers shouldn't feel the need to optimize their code, your can't run the plugin? not my fault, get a better pc, right? While there is a limit to what optimization can do, I've always strived to make my plugins as efficient as possible, especially cause the lack of performance on lower end devices.

This isn't just restricted to mobile devices, it's noticeable on really low end pc's as well.

As for using Web Assembly, that's definitely a viable option if you really want to stick with javascript, Web Assembly is something I've looked into, although I don't plan to utilize, it is great, but it has it's negatives as well.

 

[Synrec]

You're only looking at one aspect of the argument. While the extra speed may be "rarely required", your missing out on the fact that lower end devices would largely benefit from that. So sure for a higher end machine the difference will never be seen, but for lower end devices it will.

Basically your arguments are that there's no real world scenarios where this performance gain will ever be noticable.

Well here's a real world example for you.

The Unity Angry Bots demo( available on the google play store, wont link it it's easy enough to find ), a demo made in unity( an old one at that ), a 3D third person shooter utilizing rigged/animated 3d models, runs at a perfectly playable frame rate on a cheap 100 dollar phone I picked up in order to help optimize my plugins I write for MV/MZ.

On the other hand! Running a freshly made project in MV/MZ no extra plugins, struggles to keep a steady frame rate, however to further demonstrate the point, downloading the MZ3D demo( which utilizes babylon.js according to the title of the thread ), and packaging it into an apk and running it on that same phone, the entire project is running at under 10 fps. Again, this is the same phone.

One could argue "get a better phone" and I can definitely do that, but is that really something you wanna tell someone who just bought your game? I know I don't. Heck by that logic programmers shouldn't feel the need to optimize their code, your can't run the plugin? not my fault, get a better pc, right? While there is a limit to what optimization can do, I've always strived to make my plugins as efficient as possible, especially cause the lack of performance on lower end devices.

This isn't just restricted to mobile devices, it's noticeable on really low end pc's as well.

As for using Web Assembly, that's definitely a viable option if you really want to stick with javascript, Web Assembly is something I've looked into, although I don't plan to utilize, it is great, but it has it's negatives as well.

I really don't want to get into the particulars of why it's not exactly fair to compare a 3D engine to a 2D engine running 3D non-natively but your argument does have a point in that a base APK should run on mobile without any adverse problems.

Haven't really used Unity but does it compile to android on its own or does it work like RPG maker and make you do that yourself? That could be causing a difference in speed as well.

 

[chaucer]

That's kind of the point though, even when MV/MZ is running in 2D, Unity in 3D outperforms it, again this isn't just due to android, the difference in performance is apparent on lower end pc's as well. so it's not exclusive to just mobile devices.

I'm well aware of the differences in 3D and 2D, I've rolled my own 3D renderer in javascript, and have started another in C++. No matter how you look at it, 2D should be faster than 3D especially after you calculate in lighting, and shadows for 3D. But like I said, even a fresh, 2D MV/MZ game, is slower than that 3D Unity demo.

With that said compiling C# into an apk and JS into an apk, are quite a bit different, so there's no doubt that a portion of that difference is from the fact that a MZ/MV games are forced to run in webview. However I'm dubtful that is the only reason.

I've used Unity quite a bit in the past, I've also messed around with Unreal, and Godot( Godot is by far my favorite of the 3, just my opinion ), But I have no doubt that Unity in general is faster than Rpg Maker MV/MZ, and I doubt all of it is due to the difference in apk compilation, since it's noticeable on low end PC's as well.

Either way though any performance gains are a good thing and it's clear with this new RPG Maker, there's going to be quite a substantial one. I just don't know If I'll personally use it, not a huge Unity fan.

In reality I'll probably just stick with MV/MZ( and hoping that they launch official Linux Support for MZ, like they did MV,using proton is a bit annoying :/ ).

In short though, I don't think jumping to babylon.js anytime soon( especially if they stick to 2D ), will be of any benefit. However I would love to see a new JS engine when/if PIXI.js utilizes webgpu( or if they choose to go 3D, Babylon.js instead ). ^^

 

[Synrec]

That's kind of the point though, even when MV/MZ is running in 2D, Unity in 3D outperforms it, again this isn't just due to android, the difference in performance is apparent on lower end pc's as well. so it's not exclusive to just mobile devices.

I'm well aware of the differences in 3D and 2D, I've rolled my own 3D renderer in javascript, and have started another in C++. No matter how you look at it, 2D should be faster than 3D especially after you calculate in lighting, and shadows for 3D. But like I said, even a fresh, 2D MV/MZ game, is slower than that 3D Unity demo.

With that said compiling C# into an apk and JS into an apk, are quite a bit different, so there's no doubt that a portion of that difference is from the fact that a MZ/MV games are forced to run in webview. However I'm dubtful that is the only reason.

I've used Unity quite a bit in the past, I've also messed around with Unreal, and Godot( Godot is by far my favorite of the 3, just my opinion ), But I have no doubt that Unity in general is faster than Rpg Maker MV/MZ, and I doubt all of it is due to the difference in apk compilation, since it's noticeable on low end PC's as well.

Either way though any performance gains are a good thing and it's clear with this new RPG Maker, there's going to be quite a substantial one. I just don't know If I'll personally use it, not a huge Unity fan.

In reality I'll probably just stick with MV/MZ( and hoping that they launch official Linux Support for MZ, like they did MV,using proton is a bit annoying :/ ).

In short though, I don't think jumping to babylon.js anytime soon( especially if they stick to 2D ), will be of any benefit. However I would love to see a new JS engine when/if PIXI.js utilizes webgpu( or if they choose to go 3D, Babylon.js instead ). ^^

Well, I'd need to play around with myself to agree with that but yes, for now this does qualify for Unity being faster if you're targeting low end.

Now, another real life example, what PC isn't capable of running an RPG Maker RPG these days? You need to use the distribution of PCs which aren't able to run RPG Maker RPGs and determine if it is worth it to even consider the speed difference.

As for mobile, I haven't extensively tested that so I'll opt out of that one.

 

[chaucer]

You asked for a real world example I'll give one, the god ray filter for pixi.js, on around say a pentium G4560 with integrated graphics, try running that filter on a 720p resolution project. Try out MZ3D for that matter on that same chip. Then go play something like Yooka Laylee, which was a game made with Unity, more complex lighting, and a 3D game.

I'm speaking from experience as I use a pentium G4560 w/integrated graphics to test plugins on a lower end device. Considering this chip is capable of running something like tales of berseria with a steady frame rate at 720p, which was a game that released on PS3... It's not too shabby for an $80 CPU.

I've also had the experience of implementing the god rays filter personally for the game Revenant Prince, and can say that it's not exactly an enjoyable experience on integrated graphics...

I personally know quite a few people who game on integrated chipsets, it's not that uncommon, especially for people who do casual gaming on laptops where they don't have a dGPU.

 

[Synrec]

You asked for a real world example I'll give one, the god ray filter for pixi.js, on around say a pentium G4560 with integrated graphics, try running that filter on a 720p resolution project. Try out MZ3D for that matter on that same chip. Then go play something like Yooka Laylee, which was a game made with Unity, more complex lighting, and a 3D game.

I'm speaking from experience as I use a pentium G4560 w/integrated graphics to test plugins on a lower end device. Considering this chip is capable of running something like tales of berseria with a steady frame rate at 720p, which was a game that released on PS3... It's not too shabby for an $80 CPU.

I've also had the experience of implementing the god rays filter personally for the game Revenant Prince, and can say that it's not exactly an enjoyable experience on integrated graphics...

I personally know quite a few people who game on integrated chipsets, it's not that uncommon, especially for people who do casual gaming on laptops where they don't have a dGPU.

Normal filters in Pixijs can lag on my comp I can imagine what would happen on a dead end PC.

Maybe the issue then given that the common trend is that Unity has code designed specifically for game development whilst RPG maker relies on user creating that code or downloading it?

There's also differences in the nature of the code itself. JavaScript is single threaded (well last I remember), you can only run one thing at a time per instance. RPG maker has some kinda weird loop in MZ to get a 60 FPS thing going (unless I read that wrong, haven't needed to look too closely at it)

The C languages usually allow for multiple threads so there's that.

Eh, you can check out the scenes core script and see how it looks.

If the difference in speeds is really that great by modern day standards and a lot of people run low end CPU then yeah, you wanna use an engine which allows multi-threading. Those engines should be really good for mmorpg design in which you need a background event to manage client-server data, an event to handle data (graphics, etc) and whatever else event that needs concurrent running.

RPG maker games though, really don't need much in which all that is required is the data handling (they have terrible graphics handling however).

You can optimise the code for your needs (in both engines) and there are very fast executing JavaScript games out on the internet just as there are unity or rather, C#.

I'm thinking C# allows Unity to do parallel processing to speed things up compared to JavaScript.

 

[chaucer]

Yeah filters can be expensive depending on what they do, and whether they're optimized as possible.
On a lower end pc it's pretty apparent.

It is true Unity is designed specifically for games, but PIXI.js isn't too bad either, there are plenty of impressive games built with it. Same with Babylon.js, the thing is though even the some of the most impressive games written in JS( Babylon.js, or PIXI ), just can't compete with even a mediocre Unity Game.

Also Unity has it's own asset store where users can sell or share their code that they've made, as well as other assets, Unity itself also heavily relies on users to create code. Infact as far as I understand, RPG Maker Unite is just going to be a Unity plugin created by Kadokawa. So there's not much difference in that regard.


Not necessarily true, C# can use multi threading, true, but to say JS can't is not entirely true. while normal javascript can't that's true, but node.js however, is capable of utilizing multi threading. ^^ It's just not something that you'd really have a use for in traditional game development. :/

Don't get me wrong there are some impressive looking games using JS out there, although there's nothing on the same level of what can be done in an engine like Unity, Stride, or Godot. and even if they did, the hardware requirements would be much higher.

The biggest detriment to JS would probably be that it's stuck using webgl. As I said in a previous post, JS->WebGL interactions are very slow. :/ maybe webgpu will help bridge that gap whenever it's official.

 

[Synrec]

Yeah filters can be expensive depending on what they do, and whether they're optimized as possible.
On a lower end pc it's pretty apparent.

It is true Unity is designed specifically for games, but PIXI.js isn't too bad either, there are plenty of impressive games built with it. Same with Babylon.js, the thing is though even the some of the most impressive games written in JS( Babylon.js, or PIXI ), just can't compete with even a mediocre Unity Game.

Also Unity has it's own asset store where users can sell or share their code that they've made, as well as other assets, Unity itself also heavily relies on users to create code. Infact as far as I understand, RPG Maker Unite is just going to be a Unity plugin created by Kadokawa. So there's not much difference in that regard.


Not necessarily true, C# can use multi threading, true, but to say JS can't is not entirely true. while normal javascript can't that's true, but node.js however, is capable of utilizing multi threading. ^^ It's just not something that you'd really have a use for in traditional game development. :/

Don't get me wrong there are some impressive looking games using JS out there, although there's nothing on the same level of what can be done in an engine like Unity, Stride, or Godot. and even if they did, the hardware requirements would be much higher.

The biggest detriment to JS would probably be that it's stuck using webgl. As I said in a previous post, JS->WebGL interactions are very slow. :/ maybe webgpu will help bridge that gap whenever it's official.

I have yet to see MZ take true advantage of asynchronous function capability. So can't really argue in its favour yet.

I know well how slow webgl is. It's also rather "heavy".

I so know that node.js is capable of multi-threading but NodeJS is also not exactly JavaScript as it's build on a c++ engine, V8. So I didn't really bring it up. RPG Maker runs within NodeJS and as such appears to be following normal JavaScript rules.

I have seen a lot of garbage unity games as well. There's even a very recent popular one that made gaming headlines because of how terrible is was. Dreamworld...

As for 3D, well, MV/MZ are natively 2D and as such it's not something I'm going to discuss or make a point if. Ever. If I want 3D, I'd need to scrap the 2D renderer for a 3D one and then re-work how data is interpreted from the engine front.

That's basically writing a new engine. That cutievirus achieved that, I applaud them but it is completely non-native and rather complex to be quite honest. Goodie for them

I was able to quickly dive on the internet and run some JavaScript games on my phone so JavaScript is definitely not the cause for slow down. It is likely the background processes running alongside RPG maker.

There's also something you need to understand. When you open RPG maker, you have a crap ton of code written for you already. You don't need to setup the player code, the map code, the whatever code. Lots of stuff basically. Unity just hands you an empty scene and tells you to build up from that.

It's really hard for a lot of new people to be justed handed an empty scene and be told the asset store has everything for them and be expected to just work off that hence the asset store thing really makes no sense bringing up.

Now, back to the code, since JavaScript isn't the issue, it is likely the code itself for RPG maker. The same code that allows for easy RPG making is the same code that can slow down your project without modifying it.

You need to deconstruct rather than construct in the case of RPG maker whereas Unity is construct rather than deconstruct.

By real example I was referring to the above∆

With that, it is easier to see why Unity is always faster than RPG maker in the situation provided where you claimed a demo built in unity ran faster than native RPG maker.

 

[Neptrone]

Regarding Single-Threaded JavaScript Historically, the platforms that JavaScript ran on did not provide any thread support, so the language was thought of as single-threaded. But it's different when web worker introduced (although it's implementations is not mature enough) but there are definitely uses case of it in game development.

For example web worker used in babylon.js when you building navigation mesh (since navmesh can be time and resource heavy.) you can see in this documentation : https://doc.babylonjs.com/extensions/crowdNavigation/createNavMesh#web-worker

also for Node.js While your JavaScript code may run, at least by default, in a single-threaded environment, that doesn’t mean the process running your code is single-threaded. In fact, many threads might be used to have that code running smoothly and efficiently. It’s a common misconception that Node.js is a single-threaded process. Modern JavaScript engines like V8 use separate threads to handle garbage collection and other features that don’t need to happen in line with JavaScript execution. In addition, the platform runtimes themselves may use additional threads to provide other features.

But In my opinion using multi-threaded is not always great. Especially if developers lacks some high coding skill to use it. It's all fast and great until your multi-threaded code get "race condition" problems which make your game buggy and even slower than single-threaded.


Regarding why MV/MZ is slow in performance due to MV/MZ has a bad loop that is always executing over and over with no calls to allow the CPU to sleep. ideally the main loop for MZ should be asynchronous and check if an update was occurring. But i know that would be pain to implement promises and coroutines in MZ due to how core script was designed.

This is why i think they should use babylon.js and make it more modular and implement promises and coroutines natively. Babylon.js already have great documentation regarding those.

Promises

Promises | Babylon.js Documentation

Learn all about the power of promises in Babylon.js.

doc.babylonjs.com

Coroutines

Coroutines | Babylon.js Documentation

Easily extend logic over time with Babylon.js coroutines.

doc.babylonjs.com

there are even documentation about floating origin (Huge Scenes Support)

Floating Origin (Huge Scenes Support) | Babylon.js Documentation

Learn how to manage huge scenes using floating-origin trick

doc.babylonjs.com

 

[chaucer]

I have yet to see MZ take true advantage of asynchronous function capability. So can't really argue in its favour yet.

In what situation would async be useful? Perhaps for something like weather, or loading objects? But not much more than that.

I so know that node.js is capable of multi-threading but NodeJS is also not exactly JavaScript as it's build on a c++ engine, V8. So I didn't really bring it up. RPG Maker runs within NodeJS and as such appears to be following normal JavaScript rules.

Again in which situation though would multithreading be useful aside from loading, or a handful of non-important tasks. I'll admit I haven't looked into multi threading a whole lot, but from what I've seen it's not something that can be applied to just anything. Since it runs at it's own speed there's no garuntee of when the code will get run/returned. Which can make anything using multithreading tricky to properly utilize.

I have seen a lot of garbage unity games as well. There's even a very recent popular one that made gaming headlines because of how terrible is was. Dreamworld...

I won't deny this, asset flips are especially common in unity. But my point wasn't that there's not garbage games made in unity. My point was that if you take the best looking HTML5 Game, be it ThreeJS or Babylon, and you compare it to a mediocre Unity Game, something like Yooka Laylee, it's clear Unity can produce higher quality games. it would more than likely also run more efficiently.

As for 3D, well, MV/MZ are natively 2D and as such it's not something I'm going to discuss or make a point if. Ever. If I want 3D, I'd need to scrap the 2D renderer for a 3D one and then re-work how data is interpreted from the engine front.

That's basically writing a new engine. That cutievirus achieved that, I applaud them but it is completely non-native and rather complex to be quite honest. Goodie for them

That's kind of part of it. It seems rpg maker is still sticking to 2D, If they went with Babylon.js( a 3D rendering library ), to build a 2D game, it'd be the same as using a 2D renderer to do 3D work. Hence why cutie virus used Babylon.js and why I wrote my own custom renderer(shameless self promotion lol).

I was able to quickly dive on the internet and run some JavaScript games on my phone so JavaScript is definitely not the cause for slow down. It is likely the background processes running alongside RPG maker.

Phone specs? Here's mine, on that test phone I mentioned earlier.

There's also something you need to understand. When you open RPG maker, you have a crap ton of code written for you already. You don't need to setup the player code, the map code, the whatever code. Lots of stuff basically. Unity just hands you an empty scene and tells you to build up from that.

It's really hard for a lot of new people to be justed handed an empty scene and be told the asset store has everything for them and be expected to just work off that hence the asset store thing really makes no sense bringing up.

This is true, but the asset store is not much different than browsing for assets on this forum the only difference is that Unity is a game engine that gives you freedom to build exactly what game you want. While RPG Maker is targeted specifically at rpg's.

Unity has code designed specifically for game development whilst RPG maker relies on user creating that code or downloading it?

This was the reason I brought it up. Both engines rely on users creating code/downloading code.

Now, back to the code, since JavaScript isn't the issue, it is likely the code itself for RPG maker. The same code that allows for easy RPG making is the same code that can slow down your project without modifying it.

Can you pinpoint specifically what code is causing this slowdown? RPG Maker MV/MZ is pretty efficient in how it runs, it's not perfect, sure there's room for improvement, but by default not much is running when you just boot into a fresh project. The Game_Interpreter doesn't run unless an events been started, Weather doesn't run unless a weather is specified. the main things in a fresh project is the map update loop, and the player update loop. and the render process.

I've tried looking into improving the loop myself especially for my 3D engine, and I really couldn't find anything causing slowdown, the biggest slowdown was from the 3D render process itself, which when i tested, was already pretty efficient, since I didn't add light sources at that time, and I was only rendering a single 3D model.

For example web worker used in babylon.js when you building navigation mesh (since navmesh can be time and resource heavy.) you can see in this documentation : https://doc.babylonjs.com/extensions/crowdNavigation/createNavMesh#web-worker

Again, yeah there's not much use except for loading/creating resources, and other small insignificant tasks.

Regarding why MV/MZ is slow in performance due to MV/MZ has a bad loop that is always executing over and over with no calls to allow the CPU to sleep. ideally the main loop for MZ should be asynchronous and check if an update was occurring. But i know that would be pain to implement promises and coroutines in MZ due to how core script was designed.

Yeah it could be improved a bit. But is it really the cause of all the performance slow down in low end and mobile? I'm a bit skeptical, the render loop itself takes far more time to complete than the update loop itself. This is from a blank 2D project, the update loop itself seems to run pretty well, I'm not sure promises or coroutines are quite necessary. at least not for everything, I could see them being useful in some regards though.

 

[Synrec]

In what situation would async be useful? Perhaps for something like weather, or loading objects? But not much more than that.



Again in which situation though would multithreading be useful aside from loading, or a handful of non-important tasks. I'll admit I haven't looked into multi threading a whole lot, but from what I've seen it's not something that can be applied to just anything. Since it runs at it's own speed there's no garuntee of when the code will get run/returned. Which can make anything using multithreading tricky to properly utilize.


I won't deny this, asset flips are especially common in unity. But my point wasn't that there's not garbage games made in unity. My point was that if you take the best looking HTML5 Game, be it ThreeJS or Babylon, and you compare it to a mediocre Unity Game, something like Yooka Laylee, it's clear Unity can produce higher quality games. it would more than likely also run more efficiently.




That's kind of part of it. It seems rpg maker is still sticking to 2D, If they went with Babylon.js( a 3D rendering library ), to build a 2D game, it'd be the same as using a 2D renderer to do 3D work. Hence why cutie virus used Babylon.js and why I wrote my own custom renderer(shameless self promotion lol).




Phone specs? Here's mine, on that test phone I mentioned earlier.
View attachment 226922




This is true, but the asset store is not much different than browsing for assets on this forum the only difference is that Unity is a game engine that gives you freedom to build exactly what game you want. While RPG Maker is targeted specifically at rpg's.



This was the reason I brought it up. Both engines rely on users creating code/downloading code.


Can you pinpoint specifically what code is causing this slowdown? RPG Maker MV/MZ is pretty efficient in how it runs, it's not perfect, sure there's room for improvement, but by default not much is running when you just boot into a fresh project. The Game_Interpreter doesn't run unless an events been started, Weather doesn't run unless a weather is specified. the main things in a fresh project is the map update loop, and the player update loop. and the render process.

I've tried looking into improving the loop myself especially for my 3D engine, and I really couldn't find anything causing slowdown, the biggest slowdown was from the 3D render process itself, which when i tested, was already pretty efficient, since I didn't add light sources at that time, and I was only rendering a single 3D model.



Again, yeah there's not much use except for loading/creating resources, and other small insignificant tasks.



Yeah it could be improved a bit. But is it really the cause of all the performance slow down in low end and mobile? I'm a bit skeptical, the render loop itself takes far more time to complete than the update loop itself. This is from a blank 2D project, the update loop itself seems to run pretty well, I'm not sure promises or coroutines are quite necessary. at least not for everything, I could see them being useful in some regards though.


View attachment 226924

MMORPG development is a key case for multi-threading. There exist the concept of 2D mmorpgs.

The point I'm making is not whether Unity is faster than JavaScript, I agree that it is. My point is that whether or not it makes sense for a speed argument to even occur in the first place.

Yes I can jump on the internet and run a few javascript games no problem. That's it. I don't need to go over specs and all that. The real world application is game runs smoothly. The end.

For reference it's one of those tabs, blackview or something. Could care less, not very important. Main points are:
- JavaScript is not the problem, it's RPG Maker itself which carries bloat code to make RPG Making easier for a lot of new people.
- C# is faster than normal JavaScript
- NodeJS is multi-threaded due to the nature of the engine it is run on, V8.

Given what I gloss over of the core scripts, I have no doubt they could spend a death march month or a few months and refactor the code for 3D but is it worth competing with Unity or (lol)Unreal? No.

There are also other basic 3D engines out there yet RPG Maker focuses on doing what it's supposed to do, let people in real life make runnable RPGs out-of-box with no game development/design experience (And there are some rather un-holy examples of why this was a bad idea). If you wanna make RPG Maker "parallely" faster, change the code to use full asynchronous functionality. All the failed image drawing, delayed audio and whatever else should be fixed thanks to that.

Better yet, recode RPG Maker to pre-load all data required for a scene before the scene is loaded. Recode webGL to be more in-line for gaming. That's up to you but in no way would the casual developer even want to consider going to those extremes when they could just go for Unity or, even better, Unreal. There's also a free 2D option, Godot which is open source and allows you to make 2D games much in the same bottom-up approach as Unity and Unreal.

There is no speed argument here. The convenience of the engine is enough for what it aims to accomplish, letting people make an RPG game in seconds. Using load map, slapping a few dumb dialogues, generating a few random characters and running the RNG dungeon generator can get your complete garbador game up and running before your brain forces your eyes to blink. That's NOT possible in unreal/unity/godot which you need to spend a few minutes at least putting stuff together.

So, your point of it runs easier on older machines, ok, I get that. I agree even. But you need to spend a lot more time building out everything VS RPG Maker's top-down approach.

Because it is top-down you can probably just delete whatever code or refactor whatever you don't need into something else.

I had to modify the entire battle system for my personal project because the absurd number of passive processes was clashing with a non-native system I wanted to implement. It still has a good few jitters I need to sort out to get it up to speed but it runs pretty well on the devices it was tested on and I have a target specification in mind which is key when developing a game. RPG Maker default fixes that specification for you so you don't have to consider that whilst Unity/Unreal/Godot allows you to make for something running on a potato CPU all the way up to RTX 9999 or whatever they have going right now.

SO real world example? Yeah, it runs, no choppy gameplay, suitable FPS for normal javascript games. I don't need more speed on normal javascript games when the speed is enough for the game type already. It's not like I'm building and running a game like S4 League which has stylish action movements and crazy stunts all in a multiplayer TPS game. You use Unreal/Godot/Unity for that.

Played a lot of games made with Unreal and Unity. I'm sure you won't get a potato PC running a game like Fall Guys no problem yet nearly every RPG Maker game has the same exact specification. That's a real world example as well.

It's all about using the tools on hand.

As for the run times presented, try nuking most of the code that allows for easy RPG Making and then re-present that same argument. The gap in speed difference may become smaller if that is what you want.