Game Development Reference
In-Depth Information
There is our answer.
Game_Party
is a subclass of
Game_Unit
. For an analogy, think of it as a parent and a child.
Game_Unit
is the parent of
Game_Party
. The
super
in
Game_Party
's version of the method is a call to the parent method
of the same name in
Game_Unit
. Execution-wise, this is technically what the
Game_Party
version actually says:
alive_members.empty? && ($game_party.in_battle || members.size > 0)
■
super
can also accept parameters to limit what is called from the parent method. however, in rMVxa, you'll
mostly be seeing
super
used without any parameters passed. in that case, it passes all of the method's arguments up to
the superclass' method.
Note
You may be wondering what the double “
and”
marks (ampersands) are for. They're one of Ruby's various
operator expressions. You can find a full list of operators on RMVXA's Operator Expressions reference page. The two
I'm personally interested in within the context of the basics are the
&&
and
||
operators.
&&
is another way to express
and
, while
||
is the equivalent of
or
. The difference between using the symbol operators and the word operators is
essentially summarized on the cited reference page. Here's a relevant screenshot (Figure
14-2
).
Figure 14-2.
A comparison of how Ruby handles a trio of variables, depending on where the operators are located
&&
has a greater priority than
||
. So, if you have an expression that you can count on executing in a certain order,
it may be preferable to use
and/or
instead. Our next task is to find
alive_members
. As we want the method definition,
what we're looking for is on line 28 of
Game_Unit
.
def alive_members
members.select {|member| member.alive? }
The expression contained within
alive_members
contains a new method, as it were.
.select
is part of Ruby's
Enumerable
module. This particular method accepts an object (in this case,
|member|
) that will be analyzed, based on
the block
(member.alive?)
criteria. This method returns an array containing every object within the list (
members
) for
which the block returns true. In other words, the
alive_members
array will contain a list of every party member that is
alive. Being alive is defined by the
alive?
method, which can be found in line 565 of
Game_BattlerBase
.
def alive?
exist? && !death_state?
This method contains another new Ruby idiom. Notice that
death_state?
has an exclamation mark to its left.
That mark declares a state of opposition. In other words, the
alive?
method checks for
death_state?
to be false
rather than true. We have nearly reached the bottom of this rabbit hole.
exist?
is only used to determine whether
a certain battler is hidden or not (and, thus, only really applies to enemies, as Actors in battle always exist). So, let's
just search for
death_state?
(note the absence of the exclamation mark). The very first result is what we have been
looking for. As the comment box directly above the method notes,
death_state?
is used to check for the KO state.
def death_state?
state?(death_state_id)
