RGSS General Inquiry

[Alexander Morou]

Hi,

I'm trying to develop a language for games, and I thought that the easiest way to do so, would be to look into other languages used in games.  Everyone here probably knows something about The Ruby Game Scripting System (RGSS), since it's used in Enterbrain's RPG Maker XP/VX, so what I'm asking today is:

• What do you like about RGSS?
• Are there things you would change about RGSS?
• How well does RPG Maker XP/VX help you in coding, and keeping track of your methods, constants, and other game data?
• Is RGSS too confusing?

Thanks in advance,

PS:
Please keep in mind that I don't own RPG Maker XP or VX.  So if you mention something, if at all possible, please include a screen capture of some form.  If you need a place to put it, PM me and I'll send you my e-mail address so you can send me the image, and I'll upload it to my own web space, I'll send you a PM in response with the link to the image (if it's more than one, that's fine).

 

[Sarkilas]

RGSS is in general very clean code, considering it is Ruby with a premade library included.
The thing I like about RGSS is that I can work with everything inside RPG Maker easy as hell. This means using the data files, built-in modules and classes and such as that. This makes development really rapid and fun to do.

I don't feel like I want anything changed, especially not in the core language. If I feel the game is missing some methods, I just make it instead. I shouldn't really say "why didn't they include a method for this" when I can do it in a few minutes.

When it comes to helping, keeping track of data, this has a very good overview. You can easily check variables, and if you have very long scripts, you can just use Ctrl + Shift + F to find the variable in all scripts. It's easy to search through your scripts this way. The data from the database, map etc. is easily obtained using $data_*[index], which makes it easy to understand, and since there's also a complete manual of which attributes each data has, what it is and the full class/module displayed, you can easily go check up on stuff you don't know.

I'm sure many people find RGSS confusing, but I don't. If there was something I didn't know, I'd easily understand if it was explained properly. For instance, everything in the Help file is easy to understand for me at least. I've worked with RGSS in about 2 years now, and I want to call myself advanced, but hell knows if I truly am :tongue:

If you want any screenshots of blocks and stuff that I find "cozy", just give me a shout.

Hope this is of any use. Cheers!

 

[Cowlol]

Well, RGSS is pretty neat. I like how it's based on a popular existing language instead of inventing some new language. This gives us the power of a language that's been around for a long time and was designed carefully, as well as access to various learning and coding resources already available for Ruby.

The really neat thing about RGSS is the way RMXP uses it. Unlike some other user-friendly engines where the engine itself is hidden from the programmer and you could just build on top of it, RMXP's basically exposes most of the engine code for you (aside from the core classes for handling basic graphics, sound, etc.).You have the source code of a complete RPG and you could change it the way you like. You could even overwrite the few hidden core classes with your own or extend them with new functionality thanks to Ruby's open nature. While this might make it a bit complex for newcomers (having to go through all that code and wondering what it means), it's generally easy to start with the most basic classes and change things to see how the game differs. For example a player could try editing the default menu system code to change the layout a bit, and then slowly learn new skills and edit more complex parts.

I'm not sure if I'd change anything with the language itself. It's just Ruby with some extensions after all and I really don't mind Ruby (my personal preference would've been Python, though). I'd probably change the engine itself to make it more efficient (I hear they did that with RMVX, but I don't have that). For example, while RGSS does allow you to write and read screen pixels, it's generally too slow for real use, and while RGSS has no real limitations, the engine does (though there are ways to go around them). I'd have liked if RMXP's editor itself was more integrated with RGSS. Right now scripting is confined to the script editor and a few event commands that allow you to call scripts. It's probably this way to allow people to make games without having to use RGSS at all. However, it'd have been nice if you could use scripts in other places as well, like specifying a script to use when a weapon attacks a target or during an animation, all through the database. Now that's not really needed because you could easily code around it, but I wouldn't have minded closer integration of scripting into the editor, as seen in other game making programs out there (fury2 and RPG Toolkit come to mind).

RMXP's support for coding is pretty minimal. You could always use another editor and import the files or paste them into RMXP's editor. It does have basic features like syntax highlighting, find and replace (including searching through all script sections(files)), jumping to lines, and some more, but it's not that great. Tools to ease debugging (breakpoints, watches, etc.) would be nice. Game data that you change in RMXP (maps and database items) are in global variables that you could access while the game is running, which is a nice way to handle things.

RGSS isn't really confusing. Ruby could look a bit weird if you're coming from another language, but that's not a bad thing (it's still no Perl!). The huge amount of classes already there might confuse some people, but you don't have to go through them if you don't want to. The documentation is basic but covers everything. Some better getting started tutorials with the help file would've been nice.

Well, feel free to ask any more questions. Hope that helps!

 

[Alexander Morou]

From what I've read Ruby, the core language, is a dynamically typed language.  Do you know beforehand whether your code will, without a doubt, run, or do you have to wait until it crashes saying 'Method not found' or whatnot?

Would there be any advantage to a system that enables the scripts to be compiled directly into the program, omitting the usage of scripts in the final release version of the game?

Edit: While I agree that utilizing a preexisting language is advantageous in the realm of people who know how to use it, you also have to consider the fact that there are things you can't do with a language if you didn't write it.  The idea here is to write the language to cater to the task at hand, which means it'll be more game-oriented than general, which should, in theory, have some beneficial trade-offs.  Also, the core language structure will be based about C#, I'm still researching the viability of a dynamically typed version of it given the foundation on which it would sit (.NET).

 

[Sarkilas]

From what I've read Ruby, the core language, is a dynamically typed language.  Do you know beforehand whether your code will, without a doubt, run, or do you have to wait until it crashes saying 'Method not found' or whatnot?

Unless you typed something wrong, or remembered a method from an existing class to be something else than it really is, I usually know that it will without a doubt run. Though the main thing is: Will it run as I want it to? Are my values correct? That are the questions that remains before trying the code for the first time. Usually it runs perfectly fine, but there are always flaws.

Though exceptions are always there. For instance, if you write thousands of lines of code without testing it on the way, it's probably going to face a few minor errors. Not many, but a few, unless one is a beginner of course, which I doubt when creating such a long script.

Would there be any advantage to a system that enables the scripts to be compiled directly into the program, omitting the usage of scripts in the final release version of the game?

I don't see any advantage or disadvantage with this. What difference does it make? If you compile an encrypted RMXP game, the scripts can't be used outside the RGSS Player anyway, unless you manage to decrypt it. Not only that, but the compiling would actually take longer when building it all into the program. I might have misunderstood your question, but I hope not.

I hope this was of any use.

 

[Alexander Morou]

The reason I asked, about whether RGSS told you about errors ahead of time, is that is one advantage of compilation: your code is guaranteed to at least run.  The other is, generally, speed.  Compiled programs run faster, and while the target framework, CIL, is compiled into byte code (similar to java), it also compiles that byte code into Machine Code when it is ran on the user's machine.  This makes it even faster than Java; however, the issue with this is the first access of a method is slower (so it can be compiled).

 

[Sarkilas]

If you have a syntax error, you will be notified at the very start of the game, as it checks for all syntax errors before proceeding to the 'begin' statement. If the error lies within a script where methods are not defined and stuff like that, it will not display the error until this is run.

You are not guaranteed for it to run. The game won't even launch if you have a syntax error somewhere.
It's pretty much like other languages out there. I have been using C# for a while, and if I had a syntax error, it refused to run at all, asking me to run the last successful build. If the error was not a syntax error, it popped up the error and highlighted the error line once it reached it in the script.

 

[Zeriab]

You do not beforehand know whether a method is present or not. You can dynamically create new methods, classes and modules which is why the syntax checker won't check for existance of methods.
I believe the loose nature of Ruby makes it error checking a harder problem than on C#. (I am guessing)

Would there be any advantage to a system that enables the scripts to be compiled directly into the program, omitting the usage of scripts in the final release version of the game?

Naturally there will. My guess is the biggest advantage would be speed. I'm not really sure what disadvantages there are perhaps except restrictions on which scripting language you can choose.

A typical benefit on using scripting languages is that you are typically faster and easier writing small scripts. They are typically well-suited for rapid prototypic in small scale.

 

[Alexander Morou]

Can you show me a good example of where adding a method to a type at runtime is beneficial?

It might help my research on higher level functions.

Edit:
Additionally, how does Ruby handle accessibility?  Are there ever members of a type that are hidden from use based upon public/private/internal access?

Edit 2: To answer why I don't just perform a web search for these questions: People are smarter than even the best web search engine.  You can't really ask benefits of certain aspects of a language without ending up with 30000 pages that talk about something else.

Edit 3: As far as 'duck typing' and full 'dynamic typing' go (this gets a bit technical), altering the type structure at run-time wouldn't really change much.  I have a few ideas on how to structure the project so that compiling a project will evaluate the call tree of an application.  Based upon the call tree it would perform 'duck typing' (looks like a, behaves like a ... duck, must be one).  It would involve inferring what can be told from the types based upon the entry point of the program, and the static invokes of your code from the primary application (it would define what it calls, typically from a static language, it would be strictly typed).  Using this type information I could, in theory, build prototypes of the methods and the general typeless form of the method would still have the dynamic invoke functionality, it would do so by utilizing dynamic code emission from the .NET framework (since new calls to it would be running on top of a static core, the objects would have known types at this point).  As for altering a type at runtime and adding methods, that one's a bit trickier, but it would probably involve a similarly dynamic approach, and the information contained within the dynamic methods generated for a given type would be included within the dynamic method generation for a given signature. The only issue is it's unlikely that you'd be able to completely replace a method definition, but I'll look into it.

 

[Zeriab]

Sorry for the late reply.
Nearly all scripts in the Script Analysis section uses since you can just paste a script in a different section and have it modify the classes and methods needed.

You can declare methods to be public, private and protected. You can read more about how that works here: http://en.wikibooks.org/wiki/Ruby_Progr ... Visibility

*hugs*
- Zeriab

 

[poccil]

Many scripts rely on methods being redefined or added to at runtime.  Ruby's  "alias" statement stores a copy of a method, and code elsewhere in the script can redefine that method and call the "aliased" method.  In that sense, the technique is similar to inheritance in C#, Java, and other compiled languages.