You can generalize to deal with items being restricted based on switches being turned on and off.
I know this is not completely the same, but you can have an Enable Save and a Disable Save common event which also turns a switch on and off. I'd recommend such a structure anyway since it gives you more freedom for later changes.
Here is a quick'n'dirty script illustrating the concept:
[ruby]# Item switches stuff
module ItemSwitches
@@items = {}
module_function
def add(item_switch)
@@items[item_switch.item_id] = item_switch
end
def usable?(item)
if item.is_a?(RPG::Item)
return true if @@items[item.id].nil?
@@items[item.id].usable?
else
return true if @@items[item].nil?
@@items[item].usable?
end
end
end
##
# All switches must be ON for the item to be usable
#
class ItemSwitch < Struct.new
item_id, :switches)
def initialize(item_id, *args)
if args.size == 0
raise ArgumentError.new("No switches given")
end
super(item_id, args.flatten)
ItemSwitches.add(self)
end
def usable?
return false if $game_switches.nil?
for switch in switches
if switch.is_a?(ItemSwitch)
return false unless switch.usable?
elsif !$game_switches[switch]
return false
end
end
true
end
end
##
# At least one switch must be OFF for the item to be usable
#
class ItemNotSwitch < ItemSwitch
def usable?
!super
end
end
##
# The item is usable if one or more switch is ON.
# All switches must OFF for the item to be unusable.
# (Unless something else causes it)
#
class ItemOrSwitch < ItemSwitch
def usable?
return false if $game_switches.nil?
for switch in switches
if switch.is_a?(ItemSwitch)
return true if switch.usable?
elsif $game_switches[switch]
return true
end
end
false
end
end
##
# No switches must be ON for the item to be usable
#
class ItemNotOrSwitch < ItemOrSwitch
def usable?
!super
end
end
##
# Integration
#
class Game_Party < Game_Unit
alias zer_switch_item_can_use item_can_use?
def item_can_use?(item)
# Just to make sure we are deaing with an RPG::Item
return false unless item.is_a?(RPG::Item)
# Check that it is usable according to the switches
return false unless ItemSwitches.usable?(item)
# Return normal result
zer_switch_item_can_use(item)
end
end
#################
# CUSTOMIZATION #
#################
ItemSwitch.new(21,1,2)
ItemNotSwitch.new(12,1)
ItemOrSwitch.new(2,1,2)
[/ruby]
Working demo:
http://www.mediafire.com/?bkvep7nmscef2nu
Note that ItemOrSwitch and item ItemNotOrSwitch are not necessary, but they do make life easier.
@blue:
There is a prevalence of aspect oriented design for modular scripts in the rm communities.
Consider problem of you wanting to change the behavior of a method where you want to use the old method for something. A solution is create an alias for the old method so you can refer to it while outside calls refer to the new method.
This introduces the problem of creating a proper alias. It should tell you that it is the old version of the method. As you say the most common naming scheme is
GUID_
aspect_
method. Some also include class name, but more often than not I find that being clear from the context. (GUID is an acrynom for global unique identifier, which typically is an acronym for the scripter)
For this purpose alone the
GUID is superfluous. The
aspect tells you which script has overwritten it and the
method which method was overridden.
The picture changes if you consider the problem of compatibility. The convention of each scripter having their own unique identifier is nice because it is more reasonable to assume that a scripter is aware of his or her own work than the work of all scripters. It is possible that two scripters name the aspect the same even if they are not trying to do the same thing which could happen due to the ambiguity of the chosen word. What they did could be independent and not attaching their GUID could be the only reason for the two scripts not being compatible.
It increases compatibility at the price of readability.
I do not think you should add the GUID if you are working on your own game, but for modular scripts which you publish for everyone? I think that adding the GUID is better than the alternative.
*hugs*
