Making some progress on my game, figured I'd post the screenshots of the current prototype.
Quick explanation of what's going on: So I didn't want to keep using the Littleroot town map for testing purposes, and it didn't really have enough variety of terrain anyhow. I pretty much threw it out and started focusing first on sprite animations(because I don't like Unity2D's animation system) and from there on making overworld entities. This involved creating a wrapper which would contain simpler functions that could be chained to get more complex behaviors (Think RMXP's system of commands for an event). The sprite of Red and the Biker dude off in the distance in the final screenshot are really there as placeholder NPCs so that my team can see all the different functions for overworld entities present in the current prototype build.
At this point, sprite animations are working decently well - I've made a system where a spritesheet's animations can be named and then referred to by name ("Walk Left", "Idle", etc), have its number of frames defined(for example, a Pokemon game doesn't have idle animations for normal characters, so their idle animation could be set to 1 frame), and it can also be defined how long (in seconds) an animation takes to complete. Animations can be switched on the fly(for instance, if I need a character to suddenly face a different direction), and at this point, the only limitation is a deliberate design choice - the function to set which frame is currently visible is a private one, meaning that the only way to access a frame from the middle of an animation is to be playing that animation. If I needed it to freeze on a frame(for instance, if you're crossing a patch of ice in Pokemon), there is a pause function which freezes the frame counter until the animation is unpaused. Fun stuff.
As for what's going on with overworld entities: So at this point, each character on-screen has the same functionality as an overworld entity. All overworld entities can do the same stuff: Jump, Face a direction(4-directional now. My artist Joey and I have talked about 8-directional but haven't made a concrete decision. It's doable, but it'd double the amount of art he has to produce), Move a direction, Jump(given a height), move forward(just whatever direction the entity is currently facing), and face a given point.
What's the use of breaking these functions up so much instead of whipping up a whole script for whatever individual purpose? This modular system is mainly to prevent code reuse, which, let me tell you, is prone to a LOT of errors. Let's say I wanted caterpillar-style movement(picture the Pokemon following you in HG/SS). In order to make that happen, all I have to do is create a new script which attaches to the overworld entity's game object. The script asks what game object it's supposed to follow, and then moves forward every frame. Every so often, it checks what direction the target object is in, and if necessary changes the direction. Additionally, it doesn't have to be a moving object. I've also used this for waypoint-based movement for NPCs, in which I define the corners of a polygonal trail for the character to walk in, and then they follow that trail indefinitely, and also have considered using it for cutscene purposes. Another good use for this modular functionality? I can have a character consistently face the player(like a Pokemon trainer encounter in the overworld when you're trying to run past).
