RetroDotCards dev log (alt account)

Eridin is like Fire Emblem combined with Magic the Gathering. Having "cards" alter the rules of a game is now a pretty common mechanic, but I do think the e-reader and Eridin's approach to this will make it unique and interesting.

To do this, GBA Eridin will scan cards, have an API cards can use, a z80 emulator, resources, etc. In other words, it's going to act a lot like the e-reader itself. If I build the API out well, cards should be able to alter almost anything in the game. First step, a z80 emulator...

Super basic, but these energy meters get the job done for now.

I did it similarly to how I'd have done it on the Neo Geo, using a background layer. I created 8 tiles from 1 to 8, and render in as many 8 tiles as needed, throw in one partial tile (so if their health is 22, that's two 8s and one 6), and then fill the remaining space with black tiles.

I threw in an attack range indicator, just like Fire Emblem. Today's goal is functioning energy bars. Usually how a system handles graphics influences how to accomplish something, but in this case you can do energy bars in several different ways on the GBA and they are all valid approaches.

If I could just plot tile indexes like on the Neo Geo, or draw directly into a bitmap, then energy bars would be a sinch. But the GBA is kinda stuck in the middle here. Anyway, once they are done, I'll be juuuust about to my first milestone goal of a very basic Fire Emblem clone.

In Pixel Pup, all memory is static. When the game starts, everything in the entire game that needs RAM, grabs it. The entire game is in RAM at all times (the puzzles don't need to be in RAM, they are read from ROM). I know that won't cut it for Eridin, so I created a very simple memory allocator.

Resting back to zero means I never have to worry about memory leaks or freeing. There is a small amount of global memory that keeps track of things that shouldn't reset. Ex: When attacking, the game goes from battle phase to attack phase. Global memory is used to keep track of who is in the fight.

In Pixel Pup, all memory is static. When the game starts, everything in the entire game that needs RAM, grabs it. The entire game is in RAM at all times (the puzzles don't need to be in RAM, they are read from ROM). I know that won't cut it for Eridin, so I created a very simple memory allocator.

Today I'm tackling action points. Each character has a set amount per turn, and can use them how they please to move/attack/etc. At least in early Fire Emblem games, I was never a fan that characters can or can't move depending on what they've done so far. This is my attempt to clarify that.

See how the 2nd 1 icon has a green corner? That is the goblin sprite down below, the menu itself is a background. The clear corner of the 1 icon is allowing the goblin pixel to push through the bg. The GBA's method for deciding how sprites/bgs combine to form the final pixel is a little primitive.

Currently playing around with a title screen.

Very early days so all of this is WIP and will change a lot. But hey, it's starting to kinda look like a game! I'll take it. And the goblin is just a placeholder :)

Taking a break from coding, back to art. I'm going to take a stab at Tril's attack animation. For starters, I got a decent idle pose going. And what better place to get reference and inspiration on pixel art sword attack animations than Samurai Shodown?

The last video had a tiny hack in it. The goblin's attack sprite is wider than its idle sprite, so actually the video should have looked like this.

So today's goal is to resolve this by using aseprite tagged animations and a MultiSprite component that understands different animations will have different widths.

To do sprite animation in Pixel Pup, I loaded all of the tiles of all of the frames into video ram at once. Then to animate the sprites update which tiles are their current one.

But most commercial games did it differently. They keep the sprite using the same tiles, and copy frames into that tile location over time to accomplish the animation. This uses fewer tiles, but the game needs to copy the tile data into vram fast enough to get smooth animation without any tearing.

To do sprite animation in Pixel Pup, I loaded all of the tiles of all of the frames into video ram at once. Then to animate the sprites update which tiles are their current one.

I decided to switch over to graphics for the starting work on the fight scene. I'm planning to have them take place on scenes that kinda look like a 2D fighting game. How realistic is this decision? Maybe too ambitious. One way I'll judge that is how long it takes for me to draw this village.

Now that I have a functional menu system, it's time to start tackling a basic 1-on-1 fight system. My goal is to have a basic, but complete, battle/fight system in place for the Detroit Retro Gaming Show on November 7th. A lofty goal, but I think it's doable.

Finally getting somewhere with the ui on the GBA. This is gnarly stuff, and game devs of the past did things like this in their sleep. "Attack" wraps incorrectly, so there's the first of many bugs...