So I ran into an issue that bugs me with my attempt at making animated battles more dynamic.
I wanted to have more dynamic views by randomizing the BEM view, as well as the positions of the characters by using variables and character switches before a fight actually begins.
Not only can the view and positions be randomized, but I can break the tradition of having every battler standing in a straight, neat, boring line (this would help to give the AOE targeting options of BEM more weight as well).
I've also created (and am in the process of creating more) large, human proportioned animated battlers. Of course, I see why squishy sprites are normally preferable: Those little guys don't create and discrepancies when they move about on the battlefield, but once you've got large sprites, it becomes obvious that they don't have any perspective to them. They just walk along the screen as is hovering above it. To look right, they'd have to get smaller if they were to approach an enemy that is further away from the camera, or get larger when approaching an ally/enemy that is closer.
I'm devising a way to make this possible with minimal scripting. Basically, I can create if/then scenarios within the melodies, and track enemies based on their index (the order they are placed within the battle party screen).
So, basically, enemy 1 is always an enemy that is closer. Enemy 2 is always an enemy that is further away. The melody will select an attack animation graphic which is merely the same animation resized for the appropriate distance. For actors, I would simply use a state to identify them within the melody.
The approach part is the only thing that would require some scripting. The character would need to shrink or grow as they approach the target or ally. I've already been able to create branching paths for some of the automatic animations in the script (enemies and actors can be knocked to the ground or launched into the air, so that requires damage animations that are appropriate for each position), so I believe I should be able to do the same within the script for approach animations based off of variables or states.
Doing this would also allow me to better represent characters that are up in the air or flying, and differentiate them from characters that have just moved further away from the "camera".
So, I'm pretty confident this will work. I'm posting here to see if anyone has any immediate thought on how this could NOT work, just so if there's something I'm missing (which is possible) I can just not waste my time finding it out the hard way.
My scripting talent is pretty minimal, and I'm using a lot of scripts with permission to make this game. So that my work would be worthy to stand up along side the work of more talented scripters, and because I just want the game to look the way I want it to look, I feel the presentation needs to be top notch. This is just one of the many ways I'm hoping to enhance the visual aspects (not that I'm skimping on gameplay, as I feel that the graphics are needed to represent the gameplay itself properly).
EDIT: As for lighting, I figure I might have to cheat and just make one single light source constantly beaming from the same place no matter what the setting.