Hi folks,
So, some time ago I said I would keep in touch regarding what I'm doing at the moment. So here I am. :D I also said I had my mind off RPG Maker, and today I'm going to tell you why. Actually, as a programmer, I like to do things my way. I mean, it's just like a spriter lookingfor graphical resources and unable to find anything satisfaying, you're just gonna say "let me do the whole stuff on my own anyways, since I can do it". Same goes for me as far as scripting is concerned. I can't refrain from seeing flaws and limitations everywhere, and just think "I absolutely need to reprogram that from scratch someday". For instance, you might think the reason why I made the Animated Custom Menu System in the first place was because I felt some artistic urge arousing in me and I couldn't resist it - but actually it's just that I was fed up with all existing custom menus, either for being so ugly or for offering so few customization options (or for both). Not to sound self-important or anything, I'm merely sharing some insight as to what motivates me. And mediocrity is a powerful motivation catalyst to me.
The reason why I'm telling you all this is because RPG Maker itself is quite mediocre in my opinion. You might be surprised to hear me say so, and then wonder why I've bothered to write scripts for it in that case - and I suppose it's for that very reason, since I felt there was so much to improve in it. Then you might wonder why I don't move on to another maker/language. Well, the fact is, I'm not the hard-working type for one, and it's not like game-making earns me anything but personal satisfaction (and nice comments from time to time, too) anyways. I'm not ready to spend a lot of time and energy learning how to use new tools - besides, it so happens that I have grown to like Ruby a lot and it fits my style of thinking prefectly. In other words, I can't decide between sticking to RPG Maker and its stupid limitations, and trying my hands at something new.
So, the "doing things my style" reasoning led me to the following conclusion - since I can program in Ruby, why not reprogram RPG Maker itself? I mean, not the maker in itself, but rather the game engine. Since I'm aware this concept might sound a little foggy to my everyday reader, let me come up with a cool diagram to illustrate my point.
The important part of it is that, while scripts featured in the script editor do power your RPG Maker project, they are in turn powered by something called RGSS, of which contents is not directly accessible because it's compiled (that is, already transformed to machine-understandable code). This is what I called the game engine, that is the stuff that makes it possible for Ruby scripts to run a video game in the first place. Scripters may have noticed there are limitations you can't override, unless you use some dirty, heavy workaround when it's even possible. For example, it's the game engine's fault if we can't have a window larger than 640x480. Or if we can't have the game run at more than 40 FPS. Or if the game tends to lag with big maps. It's all because it was programmed by Enterbrain in a certain way - and there's nothing we can do about it, since the code responsible for it is already compiled in the .DLL and Game.exe files.
So my thinking is: if we could replace the game engine parts (RGSS####.dll and Game.exe) with Ruby scripts, then we get ourselves a 100% customizable game engine, since as scripters we can program in Ruby anyways. Eventually, such a game engine should be able to run RPG Maker projects, instead of its own game engine. And this is exactly what I'm trying to do right now - program a suitable replacement for what runs RPG Maker projects. I call this project OpenRGSS since it's still RGSS, technically speaking (RGSS being the name for the programming language on top of Ruby rather than the game engine) and its main purpose is to be open-source, somewhat like OpenOffice is to Micro$oft Office.
Okay, great! But why go through the trouble again?
- Natively bypass RGSS's limitations (screen resolution, FPS limit, inability to use the mouse or the entire keyboard, lack of support for some file formats...)
- Offer better performances than RGSS
- Pure Ruby, thus entirely customizable and reprogrammable as long as you can script in Ruby
- Ideally entirely compatible with any versions of RGSS-using RPG Maker, past, present and future, and all custom scripts available on communities
- Uses a more recent version of Ruby (2.0.0 as of 4/2013 against 1.8.1 for RMXP) and thus benefits of all the improvements made to it - and can be rebuilt with any future versions of Ruby as well to keep up-to-date)
So, more about the progress report itself. I'm currently dealing with the engine's most basic functions, that is loading images and displaying them on-screen. There's nothing very exciting to be seen so far as it essentially involves a lot of work behind the stages. However I decided to make an interesting experiment to compare the performances of OpenRGSS with RPG Maker XP's built-in RGSS. This also served to show that the exact same piece of code can run in both environments with no difference in the output.
The following tests were run on a ASUS EEEPC 1005HA laptop (Intel Atom N280 @ 1.66GHz, 1.00 Go DDR2 @ 271MHz, Mobile Intel 945 Express Chipset Family), which is far from the cutting edge of technology, but I thought that was the best condition to try since it would show how easily both engines could run out of reliability on slower machines. All tests were run in the same conditions, save the running environment, in a 640x480 window, using the exact same script. Mean FPS ratings were recorded and rounded-up each time. Since the original RGSS has a FPS limit of 40, the >40 mention denotes a perfect 40 FPS all along the running process, with no slowdown, while ~40 means that the program oscillated around 40 FPS but slowed down from time to time. Also, scripts were run on OpenRGSS with either a 40 FPS limit, or no limit at all, to see how fast it was able to go. All screenshots were taken from the OpenRGSS application using its built-in screenshot function. :)
Moving sprites
In this test, a number of 32x32 sprites were randomly placed on the screen and moved in any of the four directions, vertically or horizontally, at each frame. We can see a neat improvement in OpenRGSS as compared to RGSS - when the latter's performances start to waver and drop under 40 FPS, it's still running at 92 FPS, and it's still playable, though not smooth, at 4000 sprites, while RGSS is already unbearable at 2000 sprites.
| Sprites | 250 | 500 | 1000 | 2000 | 4000 |
| RGSS | >40 | ~40 | ~17 | ~7 | ~3 |
| OpenRGSS (40 FPS limit) | >40 | >40 | >40 | ~28 | ~15 |
| OpenRGSS (unrestrained) | ~155 | ~92 | ~52 | ~28 | ~15 |
Rotating sprites
In this test, a number of 32x32 sprites were randomly placed on the screen and rotated at various speeds. The rotating process is very costly, hence the loss of performances for both engines compared to the moving sprites condition, however once again OpenRGSS fares pretty well against its counterpart.
| Sprites | 250 | 500 | 1000 |
| RGSS | ~10 | ~5 | ~3 |
| OpenRGSS | ~35 | ~20 | ~10 |
Scaling sprites
In this test, a number of 32x32 sprites were randomly placed on the screen and scaled up and down at various speeds. This time, RGSS wins over OpenRGSS, but this is because OpenRGSS uses the same method for scaling and rotating - thus, its performances are just the same as in the rotating condition.
| Sprites | 250 | 500 | 1000 |
| RGSS | ~35 | ~35 | ~20 |
| OpenRGSS | ~35 | ~20 | ~10 |
Scaling & rotating sprites
A combination of the two previous conditions, in which sprites were rotated and scaled-up/down at the same time. As stated above, since OpenRGSS uses the same method for both transformations, it sticks to the same performances whether just one is applied, or both. RGSS's performances, however, drop dramatically, as the very costly rotation process stacks with the scaling.
| Sprites | 250 | 500 | 1000 |
| RGSS | ~6 | ~4 | >2 |
| OpenRGSS | ~35 | ~20 | ~10 |
There might still be room for optimization, but so far things are going pretty well, so I'm satisfied with my work. Also, since I'm going quite fast, I think there might be additional progress reports very soon to keep you informed of my advancement with this project. Don't hesitate to let me know what you think. Cheers and stay safe in the meantime.
