A few questions have come to mind as I've read through the way RMXP is scripted, and I was wondering what the rest of you guys might think about them.
First: Items, Weapons, Armors, and States are loaded as databases, and those applied to a battler are simply an array of ID numbers which point to where in $data_items, $data_weapons, etc. the scripts should look for information. I find this to be incredibly limiting. The question comes in this: how much benefit could be gained by instancing these per application? For example, what if that sword Arches had equipped was an instance of its own instead of a pointer to the database, allowing it alone to be modified without changing ALL swords with its ID number? What if that Poison status effect could be stacked, and each copy of it on the enemy could be told on application who put it there (thus allowing the damage ticks to drain toward the actor, or generate Hate)?
What would be the overall gain vs. cost ratio, when you factor in what could be done with it against how difficult it would be to re-engineer, how much more load you put on RAM and processor, etc? Would it be worth it?
Second: Again, a question of gain vs. cost. I've hammered what appears to be a workable method for adding variables to items in the data structure after it's been loaded. Unfortunately, it requires splitting two methods in Scene_Title to add a Load_Database method, which can then be modified to add in other things between the load and the initialization of Game Objects. It also requires running a loop for each type of object to be added: want to add 2 stats to all battlers? $data_actors and $data_enemies both need a .each do now. Worse, after setting defaults with that loop, you have to go back and set individual ones that you don't want at that default with a scripted-in database.
It could work, but it would require a lot of effort, and it would be pretty hefty on the game's loading time and (probably worst of all) it would be quite incompatible with a lot of scripts. Is it worth it to modify the database in this way, or should changes just be made to the Game Objects themselves?
Third: Enemies could (using the above method) be redesigned to scale with level in much the same way that actors do, with tables defining their stats at every level (most likely populated with default equations, like the Actors' standard 50+5*level). They could even be given inventories from which their drops are loaded, but to which they would have access in combat as well. It could be rather cool if that Soldier didn't drop a Potion because he used it in round 4. Is the coolness factor worth the pain?
(Here, insert a break in the train of thought, which today is sponsored by Amtrac.)
When it comes right down to it, making RMXP behave in the way I think would be cool would be a lot of work, and would break a ton of scripts because it would be a redesign of some major portions of the system. As I am unlikely to ever complete my own game (I just enjoy tinkering with the system), is there really a point to building such a bulky system from the ground up despite knowing that users would then be forced to choose between my creation and virtually every CBS, CMS, and half the side-systems out there?
Should I do it anyway and release it when I'm done, even if nobody's likely to pick my work over everything else available?