daniel:
You're totally rigth. You need to update onfly the Main Character's definitions. It is mandatory if you want nice animations.
I do this for our MC, while we use two SPT's stored in VRAM (swapped each 8 vblank)  for NPCs (this allows up to 128-4 definitions).

My sprite management actually is far more complex than this, but the main ideas are here.
I use also a double SAT and I do the SPT update for the MC in multiple steps in order to spread the CPU load on many vblanks.

Currently it isn't very portable, sorry... The sprite engine is (almost) the code of th game itself.
Anyway we (Huey and me) will try to do separate C modules for each parts of core of the game
in order to allow the willing people to reuse the sprite engine or part of it.

The main issue with the AI is that the key part of the code is in encoded tables that describe the NPC AI and animation,
thus it is essential to release the PC tools that allows to design the NPC, encode the state machines, the transition tables,
the animation tables etc. etc. giving as output tables directly usable by the NPC engine.

The PC tools, like the NPC code, are in the middle of the development, at the moment, I do not think we
can release something very soon.

http://retrodevelopment.wordpress.com/

In any case, if this can help your development of G&G, we could try to :
1) publish some snippets of the AI core as it is now (unstable and undocumented, even now if Huey agrees)
2) publish the full source at the end of the development (stable and documented)

In CoT I faced the same problem and the solution was a fast horizontal mirroring routine of the main character's sprites. Being fast is hardly noticed and in GnG, as it always comes with a background scroll direction change it would be even harder to see the possible speed glitches.

So he must be using a similar routine, I'm only dumping the data from three sprites with this piece of code:


Unrolling could speed even more the routine...

In Parachuteless Joe (and Tam Tam Twins too), I used  to copy only the pattern of the required frame from ROM to VRAM, so I can have more than 64 sprites in Rom and just make a dump of 3x32 bytes (in PJ), on every frame, copying the 3 patterns on the 3 main sprite layers. I think it's an acceptable amount of bytes, and you can have more sprites. But it takes a big space in the Rom But it that way, you can have a lot of patterns, in Rom, and the rest of vram sprite data, free for use for other sprites at the usual mode, (enemies, etc...)

Voto a brios!  Ghost and Goblins forever. Si alguien consigue currarse una version maja me corro 
Por cierto yo hace años pensaba que habia una version, en el ultimo numero de msx-club lo decian en el coleccionable creo,era un articulo que comparaba juegos de msx salidos otras plataformas creo. Se decia que los graficos, coño! voy a buscarlo:
Pues vaya, no he tenido suerte, el cd recopilatorio de Martos no me funciona, pero si alguien lo tiene a mano puede comprobar que hablan de Ghost&Goblins y dan a entender que existe par MSX, aunque seguro es solo una fantasia. De todas formas hasta hace muy pocos años no llego la rom de Capcom Comando que tampoco se sabia seguro de su existencia.

El COMMANDO oficial de Capcom / ASCII para MSX es bastante patético, pero bueno, es un producto oficial y tiene muchos colorines... Me quedo de lejos con el WHO DARES WINS II de Alligata. Puede ser sencillote, pero es un gran juego, muy digno y muy divertido. En una palabra: muy logrado. Y, además, ocupa bien poco: creo que es compatible incluso con MSX con 16 KB de RAM, pero no estoy seguro de esto (haré mis averiguaciones).