5) We outline which modules to complete first
a) Kernel <-- this is a module (it sits on our low level interface I guess) also loads and boots the script engine
b) Script Engine <-- runs scripts etc. basically it feeds the kernel things to do
c) Battle Engine <-- run from the field/script engine
d) menu Engine <-- runs all the menu 'stuff' this is run from the script engine
e) media Engine <-- plays sound movies etc. run by the script engine
You have the hierarchy wrong here... This is how the native FF7 is put togeather.
a) Kernel
+graphics
-------> 2D primitives (TIM)
-------> 3D primitives (PLY)
-------> Animation primitives (HRC, ANI)
-------> Texture cache system
-------> Double buffer manager
-------> Movie player(STR)
+audio
-------> Digital Audio primitives (VAG) <--- Also known as "Akao"
-------> Music primitives (SEQ)
+device
-------> Input primitives
-------> Drive access/sector access
-------> LZS/BZIP engine
-------> Memcard access
+misc
-------> Thread engine
-------> module banking (swap) system
-------> Window management (window.bin)
b) Menu System
-------> Plays opening/closing credits
-------> Initalizes savemap from kernel.bin
-------> Initalizes new game
-------> Saves/loads game (savegame access, hooks to kenel)
-------> Manages user changeable savemap data. (user savemap access)
c) field engine
-------> contains field script engine, low-level opcodes hook into kernel (animation, sound)
-------> Calls all other modules
d) battle engine
-------> This can, frankly, be done last ^_^
e) minigame engine
------> did you know that the chocobo race minigame, snowboard minigame, and rollor coaster minigame use the same engine?
f) worldmap engine
------> did you know that the worldmap also includes the "lost in the blizzard: seneriao where you stick staffs into the ground.
*******************
The kenel does not manage windows, but offers low functions to draw them with text inside. The Field window functions are more "fleshed out" than the kernel hooks. This allows battle to make the same windows as field as menu.
What distresses me is that the system is just renders on a doubled buffered display and has a logical texture cacheing system. There is no real reason to make an overly complex display subsystem as it's really just a painters algo that determines what goes on top of who. The cache is very key as there are bunches of textures that are banked in and out on the fly from the disk. We can't load the whole "magic" directory for the first battle. (The characters dissapear during a summon is because thier textures and animations are banked out) Look at gears, it explains the texture system as well as I can gleen.
These subsystems are very modular. This means that if we were to include FF8, we would just replace or expand the components needed.
So the first thing is to get the kernel going with enough hooks to get the *MENU* system up and running first. I know this seems bass-ackwards at first blush but we need to be able load the savemap though the proper module. It is from the act of loading a save game, be it the inital from kernel.bin, the newgame overwrite from kernel.bin, or the save frrom the savegame that actually kicks off the field file.
Does this make sense?