I am working up the basic framework for the MSX(2) target for my D&D rpg engine (already working well on the SDL2, DOS and Sinclair/QL targets [yes, really!]).
On the MSX I of course have the added complications of fitting everything in to individual available RAM banks (the engine will definitely have a minimum 256kb memory requirement) and am at the point of needing to make some design decisions on how the game looks.
For the most part, it is a text based RPG, somewhat like the Bards Tale, or early SSI adventures. With branching text, NPC dialogue, shops, taverns etc. However the combat is much more similar to the JRPG turn-based style of the early Final Fantasy games. A little bit of an odd combination, I know!
Anyway, the combat screen plays out in an inset window that is some 3/4-ish of the full screen (I'm using 256x212 256c bitmap mode of the MSX2). Normal player character and enemy 'sprites' are 32x32. Boss monsters are a fairly huge 96x96.
In addition to the player party of 4, you can encounter up to 6 normal enemies or 1 boss and up to 3 normal enemies. There are a maximum of 4 different types of enemy on screen at any time (so of the possible 6 enemy sprites on screen, at least 2 would be duplicates).
I aim to have one entire 16k bank of RAM for the player party:
- 4x players, each with 4 frames of animation
- 4 x 4 x (32x32) = 16384 bytes
- Uses one entire 16k RAM bank
The same for the enemy party, which can be up to 6 characters, but only up to 4 types (hence the same memory use as the 4 unique player party characters):
- 4x enemy types, each with 4 frames of animation
- 4 x 4 x (32x32) = 16384 bytes
- Uses one entire 16k RAM bank
Because of their size, I intend to load boss sprites to the second page of VRAM, along with sprite saveunder areas for each of the (possible) 10 on-screen sprites:
- 1x Boss type, with 4 frames of animation:
- 1 x 4 x (96x96) = 36864
- 1x Boss saveunder area for saving bg bitmap:
- 1 x (96x96) = 9216
- 10x Sprite saveunder areas for saving party + enemy bg bitmaps:
- 10 x (32x32) = 10240
- Total page 2 use 56320 bytes
Due to 'soft' sprites, the animation sequence will obviously be:
- Stamp down bg saveunder bitmap
- Stamp down animation frame 1
- Stamp down bg saveunder bitmap
- Stamp down animation frame 2
My question is not really a technical one, but more of an aesthetic/gameplay one: since there are only a limited number of frames of sprite animation available, what would you use them for?
On the other targets (e.g. DOS and SDL2), memory is (usually) not an issue, and I've designed the data structures/display logic to use (up to) 4 frames of animation for each of:
- Resting animation (in normal idle loop, staggered, so all on-screen characters don't all have to animate each loop), cycling 1-2-3-4-3-2-1 etc.
- Melee attack animation
- Magic attack animation
- Wounded animation (when receiving an attack, then reverts to resting)
- Killed animation (with the 4th frame remaining until end of combat)
Without cutting down the player party size and the enemy party size, it's just not an option to have animation frames for all of those on the MSX. So my initial thoughts are 2x resting animation frames, with a 1x static sprite frame for melee attack and 1x for magic attack. Wounded animation can be simulated by flashing the initial resting animation red, or similar. Also no death animation/sprite, so on the MSX the character would die (via some overlaid pixel effect) and then just be removed from the screen.
However... based on that 4-frame limit, what would your preference be if playing such a game? Would you prefer a smoother resting animation sequence (i.e 3 or 4 frames), but no dedicated attack/magic sprite?