Game Development Reference
In-Depth Information
■
instead of typing in
module_function
, an alternative way to declare module functionality is by using
self
for each of the methods contained within. so, you would have
def self.value
, were you to apply it to the preceding
module. You do need to do one or the other, however, or your game will crash and return an error.
Note
Game Over by Incapacitation
By default, the only way that a player will receive a game over is if his/her entire party is dead. However, not every
role-playing game (RPG) throughout the years has followed such a system. Take the
Final Fantasy
games, for example.
If the entire party is unable to act, that will result in a game over, even if the party is otherwise still alive. Petrification
and Paralysis are two of the most common status effects that can cause this alternate game over. A look at the States
tab reveals that none of the default movement-blocking states has infinite duration. Perhaps it was something that the
designers thought of but decided against implementing. In any case, all we have to do is find the code that governs
game overs and work from there. Running a search in the Script Editor for “game over” returns a few results. The third
one (the only result that takes us to
Scene_Base
) is the one we're looking for. Take a look at the code below.
#--------------------------------------------------------------------------
# * Determine if Game Is Over
# Transition to the game over screen if the entire party is dead.
#--------------------------------------------------------------------------
def check_gameover
SceneManager.goto(Scene_Gameover) if $game_party.all_dead?
end
end
This method is where our rabbit hole starts. Our next step is to find the
all_dead?
method in
Game_Party
and see
what that entails. Running a search for that method turns up a rather curious result (see Figure
14-1
).
Figure 14-1.
A screenshot of the third and fourth results returned after running a search for
all_dead?
Namely,
all_dead?
is defined in two places. Actually, that's not strictly true, as I'll promptly explain. Clicking the
Game_Unit
result reveals the following method:
def all_dead?
alive_members.empty?
Now, let's take a look at the
Game_Party
equivalent.
def all_dead?
super && ($game_party.in_battle || members.size > 0)
Why are they different? If you look at how the two classes are expressed within the Script Editor, they should look
like this:
class Game_Unit
class Game_Party < Game_Unit
