Suggestions for the next RPG Maker

[Andar]

Do you experience lag or skippiness on RPGMaker engines easy?


I just wanna make sure I'm not the only one.


I saw a Let's Play of an RPGMakerVXAce game on Youtube and it was lagging for them

RM is basically a two-level interpreter running. I don't want to get too technical into the differences between program compilers and program interpreters, but yes, a language interpreter runs the programs always slower than a compiled program.
However, that does not mean that the games have to be slow.


It just means that when you don't take care of the way you use your events, then it's easier to create lag in the game. In a test I once made in this area a single event (which intentionally used a lag-inducing script call) was enough to slow a simple map down to the point where it could not be played.


However, if you take care of how you make your maps and events, then you can make a game that has no danger of lag.

 

[Mouser]

However, if you take care of how you make your maps and events, then you can make a game that has no danger of lag.

I'll have to try that on my Compaq Armada. I've got it upgraded to 192 Meg of RAM so it runs XP pretty smoothly.

For some reason a lot of games seem to lag on it though.

 

[whitesphere]

The problem is Ruby is an interpreted language, not a compiled one.  So I'm sure it runs more slowly than a compiled language like C++.

The trade-off is that you can insert scripts and run them pretty much instantly, without doing a recompile of the entire game.  And you only need a text editor to make new scripts.

In theory, RPG Maker could be written in Java, which would still allow plug-ins and would probably do better cross platform.  But I don't know how well Java would perform for that type of game.

Of course, if it were ported to Java, all of the existing scripts would become useless...

 

[shiori4me]

So, is there a way to make a complex and lengthy game without there being a considerable amount of skippiness to where it can be played without being gave up on due to performance issues.

I know about parallel processes and how you shouldn't run too many and how you should put at least one frame of waiting at the beginning of the event process, and my game isn't too content-heavy. However, I also know that my computer isn't the best and can't handle Galv's Pirate Rush. The player stops working.

Games are made with Flash and on Game Maker and run fine.

That means that RPGMaker can be done the same way. However, those take a tad more scripting knowledge because you can't make a scriptless game like you can with RPGMaker.

And each new release, most scripts lose compatibility anyway, then people either make ports or make entirely new scripts.

 

[Zalerinian]

One of the min reasons RPG Maker games run slower than most people would like is irrelevant to Ruby. It is true that ruby is interpreted and runs slower than a compiled language, however the way RM was designed, everything runs on the CPU, and if I had to take a guess I'd say one thread. What does that mean, exactly? Well, with running everything on the CPU, the actual graphics you see are not processed by your graphics card. The CPU has to take time to do that, which slows down everything else. Audio is also one by the CPU, however this behavior is much more common than graphics being processed by the CPU. As you can probably imagine, graphics drawing takes a lot more time than setting a little space in memory to a number, so that slows down processing considerably.

*If RPG Maker is run on a single thread (I am not sure of this), that means that everything is processed in a line. It will go something similar to

-  Update Graphics

-  Update Audio

-  Update Scripts

This is logical programming behavior, and is expected. However, back to the CPU needing to draw graphics and drawing graphics taking a lot more time than simple variable comparison and setting, the audio will not be updated until the graphics are done. This leads to more time being taken to update each time, and if it is bad enough, visible lag would be the result.

I'd like to recommend RM gets rewritten to use the graphics card for graphical elements and the CPU for audio and script processing, as this would greatly reduce lag strain on the game. Additionally, as a programmer there are several improvements I'd like to see with the encrypted archives.

First, please allow us to add data into the archive during runtime. This can be used to allow us to save settings that should not be cleared into the archive where the user wouldn't be able to delete them unless they were to delete the majority of the data.

Secondly, it is common knowledge that there are decryptors available to get the contents of an encrypted archive out and available to users. Please allow us to create our own methods for encryption and decryption. This way, each game has the ability to use a custom encryption method so that creating a general RM decryptor would be more difficult, and would allow us to better protect our game data for a time. I am aware that a crack will be made eventually if people find it worth it, however I'm more concerned with having the time it takes to get that crack made be longer than releasing a game a year after the maker comes out and a ready-to-use decryptor can get all my game's data out immediately.

By all means keep a default encryption method, but allow the possibility for the developer to use a custom one if they are willing to put the effort in, or to pay someone else to make it for them.

*Upon writing the middle of the second paragraph/example I realized audio does continue to run when the game window is not selected and regardless of graphics lag, so it is probably multithreaded. However, it is still possibly both graphics and scripts are processed in the same thread (as both won't update unless the window is selected).

 

[whitesphere]

@Zalerinian

It looks like the game is using Ruby Fibers for "cooperative" concurrency.  That is Windows 3.1 style concurrency, where the Fibers aren't pre-emptively scheduled, but rely on each task to politely relinquish control.

So, no, it's definitely not very multi-threaded, unless the underlying Ruby engine translates the Fibers to true threads.

I would guess some things like audio are explicitly spawned off on their own threads, but I have no idea.

Interestingly, there is an actual Ruby Thread class, so in theory it shouldn't be too difficult to implement, except for the countless concurrency issues that arise from true multithreaded programming.

 

[Zalerinian]

Oh, I know of fibers. What i was saying was that the audio continues playing (rather annoyingly, especially during specially timed cutscenes) after the window has been unselected. Unless they made it so that the thread updates audio and then checks to see if its selected for graphics and scripts, I'd think the audio has its own thread.

Turns out, RPG Maker is actually multithreaded. Proof:

Spoiler

Of course it still runs slow at times, so who knows how well these threads are made, and exactly what they're doing, but it's multithreaded. I'd still recommend rewriting the engine, however. From scratch. In my experience, it's almost always better to remake things from scratch. It'll take longer, yes, but the end result will be better because you will have the entire code process in your head at the same time, rather than the process of the new code and trying to remember the old code.

I'd recommend taking a look at the SDL website and library for the next version. It's native in C, is fully compatible with C++, and there was a C# port somewhere. SDL will let you use the full keyboard, the mouse, the graphics card, threads, and tons of other features, and ALL SDL code is cross-platform between Windows, Mac, and Linux. I highly recommend at the very last looking into using it. Oh, and SDL is maintained by a Valve employee, and has been used in very Valve game(Gold Source and Source both use SDL)

 

[Mouser]

I'd still recommend rewriting the engine, however. From scratch. In my experience, it's almost always better to remake things from scratch. It'll take longer, yes, but the end result will be better because you will have the entire code process in your head at the same time, rather than the process of the new code and trying to remember the old code.

Once your programs get past a few hundred thousand lines of code, rewriting from scratch suddenly doesn't look so appealing anymore. Yes, RM could benefit from concurrency, but let's be honest, the engine doesn't need to handle a whole lot of processing to get the job done. It's a simple 2D tile based graphics engine with some bells and whistles on top so it can handle scripting and parallax and things like that.

For the life of me I don't understand how parallel process events can lag this thing so badly - 60 checks a second is _nothing_ to a CPU that handles millions of operations a second per core. That's something internal to the engine itself that's slowing it done.

If they were going to rewrite from scratch I'd suggest ditching the tile based entirely, but then it's not so simple to use.

*shrug* it is what it is. They're in a tough spot: if they put in the work to really improve the engine like you're suggesting, they'd have to raise the price significantly to recoup those costs. Raise it too high and suddenly you find yourself in the same range as a bunch of more powerful engines, and you lose your market niche.

They've set themselves up as a low-cost one trick pony for people who want to make old school jRPG style games easily. There are a lot of simple things they can do (global search through all scripts, for example) that would make using the program easier, but I don't expect too many improvements on the performance side.

 

[SoulPour777]

Mouse Capabilities for Menus

Instead of the traditional button based selection on the menu, RM built games can use mouse as an optional choice.

Camera Support

Instead of the whole 544 x 416 catch for the screen, the future RM can concentrate the camera / viewpoint of the game to a certain place. This is to mimic the popular feature for Adobe Flash called VCAM.

 

[TheoAllen]

One of the min reasons RPG Maker games run slower than most people would like is irrelevant to Ruby. It is true that ruby is interpreted and runs slower than a compiled language, however the way RM was designed, everything runs on the CPU, and if I had to take a guess I'd say one thread. What does that mean, exactly? Well, with running everything on the CPU, the actual graphics you see are not processed by your graphics card. The CPU has to take time to do that, which slows down everything else. Audio is also one by the CPU, however this behavior is much more common than graphics being processed by the CPU. As you can probably imagine, graphics drawing takes a lot more time than setting a little space in memory to a number, so that slows down processing considerably

This explains everything. I was experimented on RGSS3 in countless time. And I'm aware the one that causes lag a most is drawing functions. Such as refreshing the window contents, setting pixel, and drawing text. Also loading a big sized image may causes frameskip. Such as load animation graphics. You may notice it if you using sideview battle where one frame is important. It won't be noticed if you're using frontview battle system.

I was once made a bullet hell shooting using RGSS3. I do all check collision, move object, and such in primitives (add+, sub-, multiply*, etc ...) like default RTP does. As long as in screen objects aren't exceed 125 objects, it won't causes many lag.

Mouse Capabilities for MenusInstead of the traditional button based selection on the menu, RM built games can use mouse as an optional choice.

I believe that RPG Maker was designed to be able to play both keyboard and Joystick at the first place. Considering how key mapping was handled in input module.

Btw, back to topic!

The one I really need is to be able to modify Tilemap more free. For example, in this current RGSS3 version, you can not set tone for tilemap, zoom, like sprite does.

 

[SoulPour777]

Drag and Drop Menu System

This is to abolish the sadness of users who can't script a good menu system of their own. It retains CMS scripting, but for beginners who wants to change their menus and remove items on it easily, such functionality should exist.

 

Customizable Font for Windows

Instead of scripting the font name and font colors which are specific for each window, such functionality should exist, where customizing them easily through a few clicks.

 

Level 4 Encryption System

To provide a secure and cheat-engine free game, future RPG Maker should impose a Level 4 or higher encryption system should be created, where Audio files should be encrypted by default and converted into files specific for the RM to read. This is often seen in many company produced games.

 

GIF Support

The ability to play gifs.

 

Partial Map Copy

The ability for the user to copy portion or parts of the map through a selection and paste it on another empty map regardless of the tileset used (adjust which tileset it uses).

 

Easy Network Programming Support

An easy to follow for beginners to do an online support for RM.

 

Language Interpreter Drop-Down Support

Instead of buying an specific language RPG Maker, a drop down list of languages to use should be available, allowing users to jump in using English or Italian with ease, instead of buying both Italian and English versions for example, providing an RGSS dll for the language without getting it specifically.

 

Connect-Easy Workflow

Instead of the click-per-click eventing, future RPG Maker should follow the drag and drop connect string eventing like BlenderGame logic. This is to easily follow the event workflow and change the event without selecting the events again.

 

[TheoAllen]

Ah, regarding on editor itself. I would like to mention some modifications of current script editor features

Back button

Like in windows explorer or helpfile. Back button helps you to back on your recent place rather than scroll and scroll all over again to section the last time you in.

Autocomplete?

Not sure if it can be done in RGSS3 editor. Well, at least it may offer an autocomplete keywords based on RGSS library.

Syntax error recognition

Even it doesn't bother me so much, it's good if script editor has error recognition upon script that you make. You may toggle it to ON or OFF.

 

[shiori4me]

Is it unrealistic to ask for the engine to skip erroneous script calls and processes like it does with evented processes?

 

[Andar]

Is it unrealistic to ask for the engine to skip erroneous script calls and processes like it does with evented processes?

Yes, that is very unrealistic. I don't want to go into the technical details, but to do this you would either need to limit what a script call can do (disabling a large part of the engine's strong points and existing scripts) or you would need to enter an additional interpreter level into the engine, slowing it down massively.

 

[Tsukihime]

The engine doesn't skip erroneous event commands either.


At least with script calls you could potentially just wrap everything around a "rescue nil" or something I guess.

Level 4 Encryption System


To provide a secure and cheat-engine free game, future RPG Maker should impose a Level 4 or higher encryption system should be created, where Audio files should be encrypted by default and converted into files specific for the RM to read. This is often seen in many company produced games.

I am not sure how this would be secure and cheat-engine free.


I'm not too clear what "level 4 or higher encryption system" is either.

 

[Engr. Adiktuzmiko]

secure maybe, but cheat-engine free? IDK... I've seen CE used on a lot of AAA games...


Also, parts of maps can be copied via right clicking... you need to adjust the tileset on the new map but that's too easy to do anyways

 

[amerk]

The problem with forcing players to play the game your way (ie., cheat free) is that you begin to alienate certain players. That's perfectly fine, if your okay with that, and it's your intent to provide a challenging game regardless of the cost. Other developers wish to reach out to all players, and providing a way to cheat does just that. To make up for it, though, the developer may including challenging side quests that gives the more dedicated players better missions, more loot, extra mini quests, or expanded story content that cannot be had through means of cheating.

 

[Engr. Adiktuzmiko]

yeah, I always wondered why quite a number of games do ship with built-in cheating mechanisms... Now it all makes sense... XD

 

[whitesphere]

I'd love to see 3 features added which would be fairly easy to add:

1. More than 4 self-switches for Events, accessible through the GUI.  These are very handy.  Technically, the GUI just needs to go from 'A' to, say, 'Z' instead of up to 'D' since the back-end seems to support an arbitrary number of self-switches.

2. How about self-variables for Events, accessible through the GUI?  These could be fairly useful in some specialized cases.

3. It would be great if the editor itself supported Ruby plug-ins, so scripters could add, say, search and replace functions, or new ways to draw Region IDs, or custom levels, etc.

I know #1 and #2 are trivial to do with scripts, but having them smoothly integrated into the GUI makes them far easier to use on a large scale, than adding script calls every time they need to be used.

 

[Caustic]

Oh gawd. 

I don't know if this has been suggested yet or not, but...

Drag-and-drop functionality with pictures. And possibly paths for them to move on (such as arcs, swirls, etc).

The positioning system in place now is.. awkward. And requires a lot of poking around if you want a picture to appear in just a spot (and not, say, a parallax background/foreground object).