Game design decisions - limits on frames of animation

By megatron-uk

Resident (51)

megatron-uk's picture

12-12-2022, 12:22

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:

  1. Stamp down bg saveunder bitmap
  2. Stamp down animation frame 1
  3. Stamp down bg saveunder bitmap
  4. 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?

Login or register to post comments

By aoineko

Paragon (1136)

aoineko's picture

12-12-2022, 13:24

For animations, it's hard to answer in theory. I would say that there are two slightly opposite options:
- Put more frames on the animations you see most on the screen (probably the Idle anims)
- Put more frames on the animations that are most important for the gameplay (probably the Attack anims).
I know, it doesn't help much ^^

Are you sure you want to use the 256 colors mode?
If you look at the VRAM as a bitmap, you have 256x300 pixels off screen let to put your data in that mode.
If you switch to 16 color mode (you can change the palette for different screen strips) you would have a space of 256x812 pixels off screen to put your data. Even if you keep a double screen-buffer to draw invisibly, it allows you to put a lot of animation frames. Smile

And then, nothing prevents you to change the VRAM content at each frame. Not all the content, but if you spread your update over the different characters to be displayed, you may be able to update them fast enough to play the animation (e.g. at 10 fps, you have 5 frames to update your data).

By megatron-uk

Resident (51)

megatron-uk's picture

12-12-2022, 13:42

Yes, indeed, there are always compromises to be made Smile

I had forgotten that in 256x212 there are the unused regions outside the displayable area. That will actually give me enough space to completely free up all of the 32x32 portrait images (4 party + 6 enemy + several more for npc head in dialogue, shop vendors, etc) I was intended to load into a bank of RAM.

I suspect that the 2 idle frame + 1 attack + 1 magic route is the least-worst compromise if I stick to 256c mode. 16 colour could be an option and it would free up both VRAM and main-memory....

By max_iwamoto

Paladin (673)

max_iwamoto's picture

12-12-2022, 14:21

I think using screen 5 with 16 colors is better option as you will have extra VRAM space. Also, I would change visible area to 192 pixels to gain even more extra space off screen. And it should be more compatible with Spectrum screen size. I would also use VRAM pages 0 and 1 as double buffer so animations are smoother. Similar can be done on Spectrum 128. Also data transfer in screen 5 is way faster compare to screen 8. And I would also store more data in Rom so you don't have to use 256KB of RAM since most msx computers are 128kb and 64kb. I would aim at 64kb if possible to have even better compatibility. You can transfer data from ROM to VRAM without issues. So you will have 256 x 512 area for animations, etc. And 2 off screen areas of 256x64 of VRAM pages 0/1 to store fonts and other GFX that always used during the game.

By PingPong

Enlighted (4155)

PingPong's picture

12-12-2022, 20:05

Maybe if you do not need hw sprites, you can disable them, and use an extra little area to store gfx data with the additional bonus of having a little faster command engine. OR maybe you can combine this hint with a 16 color mode...
Even reducing to 192 px the y size could give you a little vram space...
another advantage of 4bit pp is that if you use byte oriented vdp command there is half memory to manage speeding up the execution. even transfer between RAM->VRAM will be faster