{"id":3373,"date":"2014-09-29T00:35:10","date_gmt":"2014-09-29T05:35:10","guid":{"rendered":"http:\/\/www.himeworks.com\/?p=3373"},"modified":"2014-09-29T13:55:15","modified_gmt":"2014-09-29T18:55:15","slug":"script-compatibility-talk-object-composition","status":"publish","type":"post","link":"https:\/\/himeworks.com\/2014\/09\/script-compatibility-talk-object-composition\/","title":{"rendered":"Script Compatibility Talk: Object Composition"},"content":{"rendered":"

As a scripter, I write scripts with the\u00a0goal of being\u00a0plugged into any project and suddenly a developer has just solved a problem.<\/p>\n

In this article I discuss a certain technique that I personally have not seen being used very often in RPG Maker scripts, though it is something I feel is extremely important for\u00a0compatibility between scripts. Or Maybe I just don’t look at enough scripts.<\/p>\n

Object Composition<\/h2>\n

In software engineering. there is a concept\u00a0called Object Composition<\/a>. You can read about it\u00a0on Wikipedia but basically you have\u00a0an object that contains another object. Wikipedia uses the analogy of a car being composed of an engine, wheels,\u00a0and all of the other parts that\u00a0you may expect from a fantasy automobile, such as laser turret or warp drives.<\/p>\n

Where would I use it?<\/h2>\n

In RPG Maker, you can see examples of object composition.\u00a0A battler sprite holds a reference to the battler object that it represents.<\/p>\n

class Sprite_Battler < Sprite_Base\n\u00a0 def initialize(viewport, battler = nil)\n\u00a0   super(viewport)\n  \u00a0 @battler = battler # <---\n  \u00a0 @battler_visible = false\n    # ...<\/pre>\n
Similarly, a character sprite holds a reference to the character object that it represents.<\/p>\n
class Sprite_Character < Sprite_Base\n  #--------------------------------------------------------------------------\n  # * Object Initialization\n  # character : Game_Character\n  #--------------------------------------------------------------------------\n  def initialize(viewport, character = nil)\n    super(viewport)\n    @character = character # <---\n    @balloon_duration = 0<\/pre>\n
Rather than creating a single object that handles both the logic (moving around, keeping track of HP and skills) as well as the presentation (updating animations, drawing the\u00a0picture), we logically separate the two sets of responsibilities into their own classes, and use object composition to link them together. There is also something called MVC which appears to be useful\u00a0but that’s a different topic.<\/p>\n
Revisiting Alias<\/h2>\n
Aliasing is a common\u00a0technique that is used to increase compatibility between scripts. It is usually quite effective as well, since you are simply adding extra logic on top of existing code. However, there are times when aliasing is not the best solution.<\/p>\n
For example, let’s say you are writing a battle system that provides a number of mechanics such as\u00a0battler positions on the\u00a0battlefield as well as limiting your skills to the equips that you are currently holding. If you don’t know what those\u00a0mean, that’s ok. Basically, you\u00a0are going to have to add new logic to classes like Game_Battler<\/code> and Game_Unit<\/code>. Adding new attributes and changing the way skills are determined can be done using aliases, while allowing you to preserve existing logic that may have been added by other scripts.<\/p>\n
Everyone shares everything<\/h2>\n
This is a\u00a0consequence\u00a0behind aliasing methods. When you add more logic to a method, everyone else now has to cope with it, even if you didn’t intend it yourself.<\/p>\n
This starts to become a problem when you have two or more scripts\u00a0want to use the same method, but they will conflict with each other because the logic they’re adding is not what the other scripts want.<\/p>\n
Going with the example of battle\u00a0skills, the default system makes it so that you can use basically any skill you want as long as\u00a0the requirements are met. If I added logic to only limit it to skills that are associated with certain equips, this change may be incompatible with the default battle system (or even outside of battle, such as in the menu screen).<\/p>\n
There are many ways to come up with a situation where\u00a0two scripts aliasing the same method causes problems, and for sufficiently complex scripts such as battle systems, you will very likely have many conflicting methods. Aliasing in these situations is\u00a0effective, but what could we do?<\/p>\n
Introducing composition<\/h2>\n
Imagine\u00a0you have your basic Game_Actor<\/code>\u00a0object, and you want to use it in a custom battle system. You can alias all of the methods that you need like before, or you can consider\u00a0“wrapping” or “decorating” it with a custom actor object that is specifically made for that battle system.<\/p>\n
It might look something like this<\/p>\n
class Custom_Battle_Actor\n\n  attr_reader :x\n  attr_reader :y\n  attr_reader :atb\n  \n  #----------------------------------------------------\n  # Pass in an actor that you want to decorate\n  #----------------------------------------------------\n  def initialize(game_actor)\n    @actor = game_actor\n    @atb = 0\n    @x = 0   \n    @y = 0\n  end\n  \n  #-----------------------------------------------------\n  # Custom skill filters. Calls the actor's skills method\n  # and then filters on that\n  #-----------------------------------------------------\n  def skills\n    @actor.skills.select do |skill|\n      # some filter criteria for your skills\n    end\n  end\n\n  #-----------------------------------------------------\n  # All of the other methods you need...\n  #-----------------------------------------------------\nend\n<\/pre>\n
Notice a few things with this design:<\/p>\n