- Joined
- Aug 6, 2014
- Messages
- 387
- Reaction score
- 618
- First Language
- English
- Primarily Uses
- RMMV
This would really only be the case for the server, and not the client. speaking from experience with building an mmo.MMORPG development is a key case for multi-threading. There exist the concept of 2D mmorpgs.
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.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.
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...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.
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 ^^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.
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.
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.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.
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.
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!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.
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.
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.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.
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.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.
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.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.
