Script Compatibility Talk: Object Composition

[Tsukihime]

As a scripter, I write scripts with the goal of being plugged into any project and suddenly a developer has just solved a problem.


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 compatibility between scripts. Or Maybe I just don't look at enough scripts.


Object Composition


In software engineering, there is a concept called Object Composition. You can read about it on Wikipedia but basically you have an object that contains another object. Wikipedia uses the analogy of a car being composed of an engine, wheels, and all of the other parts that you may expect from a fantasy automobile, such as laser turret or warp drives. 


Where would I use it?


In RPG Maker, you can see examples of object composition. A battler sprite holds a reference to the battler object that it represents. Similarly, a character sprite holds a reference to the character object that it represents.


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 picture), 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 but that's a different topic.


Revisiting Alias


Aliasing is a common technique 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.


For example, let's say you are writing a battle system that provides a number of mechanics such as battler positions on the battlefield as well as limiting your skills to the equips that you are currently holding. If you don't know what those mean, that's ok. Basically, you are going to have to add new logic to classes like `Game_Battler` and `Game_Unit`. 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.


Everyone shares everything


This is a consequence behind 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.


This starts to become a problem when you have two or more scripts want 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.


Going with the example of battle skills, the default system makes it so that you can use basically any skill you want as long as the 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).


There are many ways to come up with a situation where two 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 effective, but what could we do?


...


Read the rest at Hime Works!

 

[Engr. Adiktuzmiko]

back then on wc3 modding, I've always made my own classes (class-like objects actually) when making scripts... Never thought of doing that in RM until you posted this.

 

[TheoAllen]

A new completely different class for custom battle system seems interesting. I might try this on next RPG Maker if there is any. For now, my battle system is overly complex and I don't want to renovate it once again lol.

Thanks for share

 

[Engr. Adiktuzmiko]

Though it might be only useful for larger systems, especially those that involves a totally new scene. For smaller ones it might actually not be a good idea, especially for small modifications of existing mechanics..


If I think about it, if two battle oriented systems would both use their own classes, how would they interact with other now? They would still need to have a common method where they can interchange their data someway or another, wouldn't they?


Like what if I use your battle system but I want to have my own filter mechanism for the skills (assuming your script won't allow me to define my own custom filters), if we both use a customized Actor class, how would the scripts share that information? Since your system uses a custom actor class, and my filter was made to work using a custom actor class too, your system wouldn't read my filter.

 

[Tsukihime]

Though it might be only useful for larger systems, especially those that involves a totally new scene. For smaller ones it might actually not be a good idea, especially for small modifications of existing mechanics..


If I think about it, if two battle oriented systems would both use their own classes, how would they interact with other now? They would still need to have a common method where they can interchange their data someway or another, wouldn't they?

This is where the composition comes in.


The custom battle actor class is a wrapper for the game_actor object which holds all of the information about the actor in your game.


We're still using $game_actors[1] to access the first actor everywhere else in the game. If you just plug that into a custom battle actor and you design your wrapper class so that it operates on that actor, then you can read and modify properties about that actor that would affect other parts of the game as well.


Two battle systems with distinctly different logic? No problem, just design the appropriate wrapper classes for each, and then plug your actor in. This is not much different from plugging your battler into a Sprite_Battler object and the sprite simply reads the battler's name and index.

Like what if I use your battle system but I want to have my own filter mechanism for the skills (assuming your script won't allow me to define my own custom filters), if we both use a customized Actor class, how would the scripts share that information? Since your system uses a custom actor class, and my filter was made to work using a custom actor class too, your system wouldn't read my filter.

If you didn't like my custom filter but instead want to use your own, you would have to overwrite the way I wrote the filter. This is no different from how RM scripting is usually done: if something doesn't work for you, you would just change it.


If a method returns all odd numbers but you needed all even numbers, you would simply overwrite the method to return even numbers.