For me KOF 91 (and Mugen) are an engine with severals
states. I'll use 'engine' term for both of them. This mean the engine must react
different way in each state. For exemple processing the char select screen state
use no function of the battle process state (except common functions to the
whole engine, of course).
So, I think developing each state of this engine is
possible as long as the main structure is flexible enough to make changes compatible
for others developers.
Basically, I think main functions of the engine need
three parameters : game variables , player_variables, time of the game (well,
time is not necessary).
Game variables includes all configurations vars and
global vars.
player_variables includes all player vars (include sff,
snd and stuff like that if needed).
I use this axiom to develop the whole project (I knwo
it's false but it help simplify things). And as an ancestor, KOF 91 must work
like Mugen but with default values that looks much more restrictive than Mugen's
one. And as an ancestor all that is working with KOF 91 must work on Mugen's
engine (retrocompatibility).
This mean there's a function called 'auto_conf' wich run at
the beginning of the engine and test the environnement to know if the engine
must work like KOF 91, Mugen's or a mix of the two.
It's an engine... This mean the project must include all debug stuffes that Mugen include: debug mode (of course), args in line... and all vars.
By thinking the whole project as states this mean each state is independant of the others, included coding. Now, you could take a look to Engine states view to check them, directly to the documented sources or see what's done and what's left.
I don't have time by myself, and I'm working on KOF 91 sources that are not really clean. This mean the retro-compatibility constraint is heavy, not like if i were starting from scratch.