If I was to give a noticeable suggestion, it would be to write more comments. I generally try to make sure I have at least 1 line of comment for every 5-8 lines of code. But even in cases of obvious code, I usually write something simple as a comment. I also do the same for every method and class I write, even if it's fairly obvious what is going on. The terminate method might have a comment which simply says "disposes windows".
I do like that you have commented the "end" keyword with what code/line the "end" relates to. However, I'd suggest using better words than "outer" and "inner". If I had 5 nested if/unless/while statements, it might be hard to know which is which. What I tend to do is write part of the line the if/unless/while etc says:
if apple_pie
if four_serves
else six_serves
end #if four_serves
end #if apple_pie
Another thing that jumps out:
$result
One thing you should try to avoid is the use of $ to create global variables. There's only one case in RGSS where creating a global variable is acceptable - and even that is barely acceptable, and could be done better, in my opinion.
If you look at the default scripts you'll notice that only Game containers and the RM Data objects are accessible like this, like $game_party to access the instance of Game_Party, or $data_items to access the database version of an Item. This isn't necessary, but it allows scripters to access important game data easily. Note that word, "easily". Your $result variable is just as "easily" accessed, which is not a good thing for anything.
General rule of thumb: avoid the temptation to create global variables.
Instead, look to encapsulate it inside a class. You could use one of the Game containers (even though those are accessed through global themselves) like Game_Temp (the instance being accessed by $game_temp). The difference, however, is that these variables are references to a class instance, not just a value. This means you can protect the data a little better because we can add methods to Game_Temp.
class Game_Temp
attr_reader :question_result
def question_result=(result)
@question_result = result if ( result.is_a?(TrueClass) || result.is_a?(FalseClass) )
end
end
As a globally accessed variable, we can do:
$result = true
$result = false
$result = 5
This is the problem with it. It's a global variable which means it can reassigned at any time, which could cause issues.
By having to go through Game_Temp, we can ensure that result (in the example, @question_result) has to be a TrueClass (true) or FalseClass (false) object. If we tried to do:
$game_temp.question_result = 5
It wouldn't change question_result to 5. It can only be changed if we assign true or false.
The same applies to other global variables you have, like $gamestate.
Finally for the moment: whilst there aren't any official coding standards as far as I'm aware, there are some common conventions that can be followed. One of them is with regards to default method parameters. For example:
def default_param(default_value=5)
#some method code
end
Notice that the default parameter assignment contains no spaces between the parameter name, the equals sign and the default value. That would be the common way to see it written, rather than:
def default_param(default_value = 5)
end
Its not a real issue with how the code works, but I thought I'd mention it anyway. On the same note, it's always good to try follow existing convention if you can.
For example, the class names for your custom windows.
WinPicture, WinQuestion, WindowConfirm.
Try to write them consistently. Instead, you should write these as:
Window_Picture, Window_Question, Window_Confirm
Of course, you might run into problems by using common looking names that other scripts may likely use. Instead, you could use:
Window_BANKPicture, Window_BANKQuestion, Window_BANKConfirm
It does mean you have to type a few more letters, but by writing the names like this it will reduce the chance of conflicting names.