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

[chaucer]

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

This would really only be the case for the server, and not the client. speaking from experience with building an mmo.

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.

I mean that's subjective based on the hardware, and the software. Regardless my only point was that you mentioned there's no benefits to having a faster engine as javascript is fast enough. I'm simply saying there ARE benefits, I.E. a wider target audience.

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.

An engine written in JS would never compete with Unity, especially not Unreal, at least not anytime soon. Which was part of the point, Why go from JS -> Unity then back to JS, only to lose the performance gained with the initial switch...

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.

Async is not a magic bullet that's going to solve all the issues with rpg maker, nor is multi-threading. If you can point out one instance where multithreading will benefit rpg maker MV/MZ aside from loading resources, heck I'll go build that plugin myself and release it for the public to use, I'm all for more performance, and I would love to help others build games that are easier for low end devices to digest. I'm not being sarcastic here, I'm serious if you have any ideas I'll write it up myself and credit you of course ^^

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.

Technically this is already done hence the loading screen. the only things that don't get loaded up front in MZ is sound effects, and pictures iirc, as for MV I've written a preload/auto caching system for it, because loading resources on the fly causes fps dips there. All the developer has to do is play through the game once, and then it builds a cache of what resources are used in what scenes/maps. This cache can be shipped with the game, so that all resources for each map or scene is loaded before the scene ever starts.

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.

That's true, there's tradeoffs my only argument was that the increase in performance was a benefit. I still believe that's the case. and with an RPG Maker plugin in unity you will still have that ease of use.

I'd personally love to get my hands on the new version and benchmark it on low end hardware compared to rpg maker MZ, but like I said several times before. I'm personally going to stick with MZ/MV anyways I'm just not a fan of Unity.

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.

I mean.. it can be just as easy to build a game in Unity... That's why asset flips Occur... Just search for RPG Builder in the Unity store, it's a framework for building 3D rpg's with no programming requireed to use it. and that's just one tool in the store.

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.

That's cool bro, game gonna be commercial? I'm always interested in checking out unique rpg maker games! If you have a forum thread or video or something PM me with it lol I'd love to check it out!

It is true your games targeted devices is pretty much set for you but you can always break those boundaries, with plugins, I.E. MV3D, MZ3D, Rose Engine, QABS, or if your a programmer you can completely drop the default scenes and go in the opposite direction, make something even lighter! But For the average user, yeah, the targetted device range won't vary all to much.

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.

Again that's subjective based on the end users hardware, but yeah most would jump to a better engine lol, but for people like me, It's fun to push the boundaries in rpg maker.

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.

Even fall guys can run at a steady 60fps on a pentium G4560 w/integrated graphics. It's not like it's a processor from 20 years ago lol. Even so some rpg maker games struggle to run on that chip, which is kinda what I'm saying extra performance is always a good thing.

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.

The speeds for the update loop was already really low was my point, in a blank project there's very little actually running. The rendering is what's taking up the majority of the resources in a blank project, not the actual game code, here's a more clear example on mobile.

 

[Synrec]

Even fall guys can run at a steady 60fps on a pentium G4560 w/integrated graphics. It's not like it's a processor from 20 years ago lol. Even so some rpg maker games struggle to run on that chip, which is kinda what I'm saying extra performance is always a good thing.

I see, then what about a processor from 20 years ago then? Some people do use really old PCs and if you're aiming for a wider audience should they not be included? I brought up fall guys exactly because it is made in Unity and your aim is "Wider audience". There are limits and developers/designers need to learn how to pick a large enough target audience as well as target a specific niche within that audience. Unity/Unreal/Godot excel at allowing you to pick a target audience thanks to their bottom-up approach to game design. If not fall guys, what's stopping me from bringing up any high spec game made on those engines?

Other than that, yes the rest of my argument is subjective because that's the point. There is no objective comparative measure between RPG Maker and Unity/Unreal/Godot other than speed and there is no real reason to bring it up given what rpg maker is targeting.

The speeds for the update loop was already really low was my point, in a blank project there's very little actually running. The rendering is what's taking up the majority of the resources in a blank project, not the actual game code, here's a more clear example on mobile.

This involves removing all those game objects RPG Maker creates for you in a new project (Game_Map, Game_Player, Game_Temp, etc)? Unity/Unreal/Godot start with none, gotta put em in yourself.

Technically this is already done hence the loading screen. the only things that don't get loaded up front in MZ is sound effects, and pictures iirc, as for MV I've written a preload/auto caching system for it, because loading resources on the fly causes fps dips there. All the developer has to do is play through the game once, and then it builds a cache of what resources are used in what scenes/maps. This cache can be shipped with the game, so that all resources for each map or scene is loaded before the scene ever starts.

I suppose so but eh, some dude told me they were getting sound lag and I can agree with that. It happens once but after it's normal (RMMZ).

There's the option of creating a cache during game startup but that EATS system memory.

Async is not a magic bullet that's going to solve all the issues with rpg maker, nor is multi-threading. If you can point out one instance where multithreading will benefit rpg maker MV/MZ aside from loading resources, heck I'll go build that plugin myself and release it for the public to use, I'm all for more performance, and I would love to help others build games that are easier for low end devices to digest. I'm not being sarcastic here, I'm serious if you have any ideas I'll write it up myself and credit you of course ^^

It's not but it can help if performance is really what the developer/designer wants. My idea would be to determine what the game needs and just delete and modify everything up until I get a solid piece of code that works. Basically, emulate a style that's seen in other bottom-up game engines.

An engine written in JS would never compete with Unity, especially not Unreal, at least not anytime soon. Which was part of the point, Why go from JS -> Unity then back to JS, only to lose the performance gained with the initial switch...

And this is why RPG Maker works for what it does. It's an easy top-down engine for new developers with no know-how to get into game dev. If you wanna go harder than RPG Maker, there's Unity, Unreal or Godot. There are people who can push RPG Maker beyond it's boundaries but it isn't designed for such.

---------
Eh, was fun but there's nothing to really gain here from comparing so I'll opt out. I'll message you regarding my project.

 

[Arctica]

Ruby -> Javascript -> C#..?

I'm not sure a lot of people wanna make a third language jump.

 

[chaucer]

@Synrec I was simply saying there IS a jump in performance from PIXI.js to Unity, and that that's a good thing. Free performance increase is a good thing no matter how you look at it.

I suppose so but eh, some dude told me they were getting sound lag and I can agree with that. It happens once but after it's normal (RMMZ).

There's the option of creating a cache during game startup but that EATS system memory.

Interesting I swore that they preloaded BGM/BGS in MZ before the scene started, maybe I was mistaken. :/

Also yeah creating/loading a single cache would eat up memory, that's why my plugin caches per scene( and per map ), so it only loads whats needed per scene, it also caches audio and waits for them to be loaded before starting the scene, it slightly increases load times, but it makes scenes a lot smoother for sure. However it does have it's issues still. :/

There are people who can push RPG Maker beyond it's boundaries but it isn't designed for such.

It is fun though! lol

Eh, was fun but there's nothing to really gain here from comparing so I'll opt out. I'll message you regarding my project.

Yah I agree, it was fun! and cool! I already messaged back lol it sounds awesome!

 

[Arthran]

No, I don't think they will use babylon.js for whatever version comes after Unite. If they finally decide to make a 3D RPG Maker, I can't imagine why they would then decide to drop Unity (an engine that is very suited for 3D games) and switch to back to a web technology. That would make no sense.

If they decide to make a 3D RPG Maker after Unite, they would almost certainly just stick with Unity. It would make more sense in terms of their (GGG) time and resource expenditure, and frankly, it would probably yield better results. Not to mention, I think that game devs would prefer that, because it would then allow them to use Unity's asset store.

 

[peq42_]

1. 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)

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


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. Babylon js is free and open-source.

1) C# and Javascript are extremely similar. Actually, C# syntax was based on actionscript, an old small "modified version" of javascript made by microsoft.

2) Very well documented yes, but purely 3D as far as I know, which ads a whole lot more complexity to it

3) no it won't. Almost ALL scripts made for MV and MZ depend on MV's and MZ's internal core scripts, so just because you're using the same language, doesn't mean it'll work easily like that

4) WebGPU is barely supported anywhere, even less than WebGL2. So although yes, its much superior, mainly in performance, its compatibility makes it inviable.

5) Free and Open-source doesnt mean easy integrated into software. I'm not sure what their software license is, but anything other than MIT or public domain could implicate problems to GGG

 

[Neptrone]

I will respond some other discussion later.

No, I don't think they will use babylon.js for whatever version comes after Unite. If they finally decide to make a 3D RPG Maker, I can't imagine why they would then decide to drop Unity (an engine that is very suited for 3D games) and switch to back to a web technology. That would make no sense.

If they decide to make a 3D RPG Maker after Unite, they would almost certainly just stick with Unity. It would make more sense in terms of their (GGG) time and resource expenditure, and frankly, it would probably yield better results. Not to mention, I think that game devs would prefer that, because it would then allow them to use Unity's asset store.

well, GGG will stick to 2D Game Development there is not debate on that obviously.

We know Yoji Ojima does not even involve in development of RM Unite which means RM Unite is Not exactly a direct successor of MV/MZ. I would say RM Unite probably will have same treatment like Pixel Game Maker MV.


regarding GGG time and resource i am really not so sure about that. Unity is very oversaturated Game Engine. Is adding package to unity good decision ? there are even package similar like RM Unite in Unity Assets store. And Unity assets store adding more layer of TOS and EULA which probably make even more complex to use.

There are a lot of Business complexity around GGG, Deciga, and Kadokawa combined with how they accept with Unity TOS or Agreement it would probably adding a lot of time and resource than using growing/ developing open source library like babylon.js.

for those who don't know there are already custom editor made by one person in babylon js community similar like Unity/UE. if one person able to make it then simply adding implementation of 2D RPG Editor should be no problems at all for company like GGG.

 

[Neptrone]

1) C# and Javascript are extremely similar. Actually, C# syntax was based on actionscript, an old small "modified version" of javascript made by microsoft.

4) WebGPU is barely supported anywhere, even less than WebGL2. So although yes, its much superior, mainly in performance, its compatibility makes it inviable.

5) Free and Open-source doesnt mean easy integrated into software. I'm not sure what their software license is, but anything other than MIT or public domain could implicate problems to GGG

1. Are you sure about that ? C# is statically typed, class based inheritance languages with block scope while JavaScript is an untyped, prototype based inheritance language with function scope and closures.

4. It's matter of time actually. It will get supported anywhere in foreseeable future.

5. Babylon js use Apache License 2.0. Both MIT and Apache license 2.0 are good, so i believe there will not be a problems.

 

[Arthran]

well, GGG will stick to 2D Game Development there is not debate on that obviously.

That already kinda answers your own question then, right? Why would they use babylon.js (a 3D library) for a 2D game engine?

regarding GGG time and resource i am really not so sure about that. Unity is very oversaturated Game Engine. Is adding package to unity good decision ? there are even package similar like RM Unite in Unity Assets store. And Unity assets store adding more layer of TOS and EULA which probably make even more complex to use.

There are a lot of Business complexity around GGG, Deciga, and Kadokawa combined with how they accept with Unity TOS or Agreement it would probably adding a lot of time and resource than using growing/ developing open source library like babylon.js.

But the thing is, they've *already* spent those resources on Unity. They've already spent the time/money/effort to make a RPG Maker framework for Unity, so why would they just throw it away and switch to babylon.js, when there's no clear advantage to doing so? That's what I meant by a waste of resources. It's not really a matter of whether Unity or Babylon requires more resources, because Unity is going to be a thing regardless. It's a matter of whether or not it makes sense to spend resources on Babylon *after* they've already spent resources on Unity.

for those who don't know there are already custom editor made by one person in babylon js community similar like Unity/UE. if one person able to make it then simply adding implementation of 2D RPG Editor should be no problems at all for company like GGG.

That's cool and all, but why would they want to have to build yet another 2D RPG Editor, when they already have one that works? GGG has to be careful with resources, because RPG Maker has a big issue where users like to stubbornly stick to older versions. The current newest version (MZ) has already been out for almost 2 years, yet not even 25% of active RPG Maker users are currently using it.

Every time they release a new version of RPG Maker, the customer base will just continue to get more and more divided. And considering that RPG Maker is a fairly niche product to begin with, I honestly doubt that GGG can really afford to make major overhauls every release.

 

[Neptrone]

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.

Higher Quality games would simply means there are a lot of investment (a lot of man power, and money) to create such games. A lot of HTML 5 Games most of them are created by one person or very small teams, sure unity is popular, that is why there are tendency of economic agglomeration in popular game engine.

Since Games technically are just set of complex rules of algorithm and data structures, we can reduce such things with only showcasing graphical rendering demo. Let say you want to make high quality graphical rendering demo like in Unity You can already do that with babylon.js or three.js , there are a lot of demo already published.

for now it's just matter of how to gain more attraction to big company that will invest to create big game in babylon.js or Three.js

i don't know what are the criteria of mediocre or high quality games (since everything is relative) but the fact you can play game like this in browsers is already impressive.

Townscaper

oskarstalberg.com

 

[peq42_]

1. Are you sure about that ? C# is statically typed, class based inheritance languages with block scope while JavaScript is an untyped, prototype based inheritance language with function scope and closures.

4. It's matter of time actually. It will get supported anywhere in foreseeable future.

5. Babylon js use Apache License 2.0. Both MIT and Apache license 2.0 are good, so i believe there will not be a problems.

1) yes, I am. (1) (2)

4) A matter of time, yes. A LONG time. WebGL started development in in 2013, finished in 2017 and only became compatible with all major browsers in february 2022(and as a side note: its all major BROWSERS, not DEVICES. Many phones don't support webgl 2.0, and it was only that fast because it was merely an evolution of webGL). WebGPU was first showcased in 2017, and first published in 2021. It won't be supported in most devices for a LONG while. I'd say at least 5 to 10 years.

 

[Neptrone]

That already kinda answers your own question then, right? Why would they use babylon.js (a 3D library) for a 2D game engine?

Well the reason is because babylon js have a lot more of useful native feature than pixi.js. As we know Pixi.js is a rendering engine not a framework unlike babylon.js.

Babylon.js actually has sprites feature support such as "Sprite Map" which able to render thousand to millions of animated sprites on screen.
https://doc.babylonjs.com/divingDeeper/sprites https://doc.babylonjs.com/divingDeeper/sprites/sprite_map

And here is quick feature comparison between pixi.js and babylon.js

But the thing is, they've *already* spent those resources on Unity. They've already spent the time/money/effort to make a RPG Maker framework for Unity, so why would they just throw it away and switch to babylon.js, when there's no clear advantage to doing so? That's what I meant by a waste of resources. It's not really a matter of whether Unity or Babylon requires more resources, because Unity is going to be a thing regardless. It's a matter of whether or not it makes sense to spend resources on Babylon *after* they've already spent resources on Unity.

The premise of this thread actually "what GGG will use after Unite". "Throw it away" is not accurate sentences since GGG Dev definitely will do regular maintenance or update to RM Unite after it's release not abandoning RM Unite.

Honestly i am still believe they will stick to JS library due to it's nature being open source and cross-platform.

4) A matter of time, yes. A LONG time. WebGL started development in in 2013, finished in 2017 and only became compatible with all major browsers in february 2022(and as a side note: its all major BROWSERS, not DEVICES. Many phones don't support webgl 2.0, and it was only that fast because it was merely an evolution of webGL). WebGPU was first showcased in 2017, and first published in 2021. It won't be supported in most devices for a LONG while. I'd say at least 5 to 10 years.

So 2025 then would be good year for GGG to release next RM.

 

[chaucer]

Babylon.js actually has sprites feature support such as "Sprite Map" which able to render thousand to millions of animated sprites on screen.
https://doc.babylonjs.com/divingDeeper/sprites https://doc.babylonjs.com/divingDeeper/sprites/sprite_map

Sprite support is not 2D sprites, if you read the documentation it's a 2D sprite in 3 Dimensional space. In short, it's a Billboarding plane. It's not 2D support.

As for this "Sprite Map" this is basically the same thing as a pixi particle container. It pretty much batch draws which reduces the amount of JS-> WebGL.

https://pixijs.download/dev/docs/PIXI.ParticleContainer.html

This can already be used, and this would definitely be useful for things like weather however it's not implemented anywhere in MV/MZ.

And here is quick feature comparison between pixi.js and babylon.js

This is not a really good comparison. Babylon.js is 3D and PIXI.js is 3D, there's many things listed in Babylon.js that pertain only to 3D, which is why they have so much more features listed. 3D is more complex than 2D After all.

As a side note there's very little difference between a library and a framework, In esence it would be counter productive to use a 3D library( or framework ) solely to make a 2D game engine out of it. It'd be more work and time to turn that 3D renderer, into a 2D renderer, instead of just using a 2D renderer to begin with.

^^;

 

[Zeriab]

The thing is, JavaScript and C# are both slow and costly in terms of power consumption. The GPU tends to be able to do more per unit of power. Yeah, pushing stuff to the GPU is frequently a good idea. With phone games doing so can also reduce battery usage.

When exporting a build with Unity it will compile a whole bunch of shaders for the target platforms. Yes, shaders can differ from platform to platform. The specialized Android shaders have a not unimportant part in making Unity games run well on mobiles.


Here's a couple of ideas if you want to look into optimizing MZ

• Cull sprites not currently visible. (I remember it as all sprites for the current map has a graphical object present)
• Use maps to keep track of event coordinates for faster events on (x,y)-location lookup
• Play around with introducing pools for reusing objects. (Useful for objects with high creation cost. May also reduce the impact the garbage collecting hits)

Of course there's also the matter of playing various games with the profiler on to see if patterns appear.

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.

I don't understand this argument.
RPG Maker Unite will surely include a project template so you have something to start out with just like the current RPG Makers.

1) yes, I am. (1) (2)

You are getting things mixed up.
C# has close ties to Java, not Javascript. (C# is basically Java done right)
Javascript got its name to try and piggybag on Java's popularity. I know, it's confusing.

@chaucer Multithreading can be useful when dealing with blocking calls.


Personally I don't think GGG will use babylon.js in their next RM.
My guess is that the next release is also in Unite. The release after that though... maybe Godot?

*hugs*
- Zeriab

 

[Synrec]

I don't understand this argument.
RPG Maker Unite will surely include a project template so you have something to start out with just like the current RPG Makers.

That was pure Unity not RM Unite

 

[Neptrone]

Sprite support is not 2D sprites, if you read the documentation it's a 2D sprite in 3 Dimensional space. In short, it's a Billboarding plane. It's not 2D support.

As for this "Sprite Map" this is basically the same thing as a pixi particle container. It pretty much batch draws which reduces the amount of JS-> WebGL.

https://pixijs.download/dev/docs/PIXI.ParticleContainer.html

This can already be used, and this would definitely be useful for things like weather however it's not implemented anywhere in MV/MZ.

Personally i would not matter it too much since technically you can restrict yourself to X-axis and Y-axis camera when developing 2D Games in 3D Environment. Btw my Projects also focus only on Windows and Linux, so i am not really care about mobile gaming environment.

This is not a really good comparison. Babylon.js is 3D and PIXI.js is 3D, there's many things listed in Babylon.js that pertain only to 3D, which is why they have so much more features listed. 3D is more complex than 2D After all.

As a side note there's very little difference between a library and a framework, In esence it would be counter productive to use a 3D library( or framework ) solely to make a 2D game engine out of it. It'd be more work and time to turn that 3D renderer, into a 2D renderer, instead of just using a 2D renderer to begin with.

^^;

Well they could just make 2D Game template in babylon.js.

But there are a lot of useful tools in babylon.js which suitable for supporting 2D Game development.
there are also Javascript library which help you designing game AI (Yuka Game AI) in babylon.js

Yuka | A JavaScript library for developing Game AI

A JavaScript library for developing Game AI

mugen87.github.io

example :








https://pixijs.io/guides/basics/what-pixijs-is-not.html
As you can see pixi.js does not have GUI Editor, native web audio technology, performance profiler, coroutines (most mainstream game engine support coroutines), physics system and a lot of optimization features.

If i remember correctly isn't GGG want to make 2.5D support in MV ? But it was turn out very hard to implemented such things in pixi.js, So Babylon.js would be a good choice for them.