itch.io

Delightful! Answers to some questions:
- Moving off-beat is not explicitly punished, but if you get too far off the rhythm the game advances whether you're ready or not. So the main danger is that enemies get a free hit. The timing is actually quite generous, meant to help the game work properly on emulators and televisions with a lot of display lag
- The compo version ends after stage 1-4, so you were pretty close to completing the demo content. I wanted it to end with a proper boss fight, but ran out of time to implement it
- You guessed correctly: gameplay is heavily inspired by Crypt of the Necrodancer and Cadence of Hyrule. The NES isn't fast enough to process the updates in the same way as those games, so Tactus will necessarily diverge in terms of behavior, and that's fine

- The final version is planned to have much more content, especially music tracks. Many of the current limitations were due to the time and space constraints for the compo

This was strongly considered for the compo, and I just didn't have time! It wouldn't be very hard to add. I'm planning a bugfix round, hopefully before the compilation is compiled, so I might sneak it into the demo for that.

This game is difficult :D Thrust mechanics were never my thing, but it's hard to complain with so many mechanics to explore and great polish to boot. 10/10, would explode trying to find the home base again.

Gah, the art style is so cute, I love it.

It took me a long time to figure out which team I was supposed to be supporting; I guess the color of my cursor is the biggest clue? Other than that no real issues. This is a clever idea, well executed and fun to mess around with.

Oooh, I need to write up a mini tutorial don't I? You damage enemies by moving towards them. It's a D-pad only game :)

More progress! The battle system is basically complete, it has physical attacks, magic spells, and a type advantage system:

https://workshop.reploid.cafe/images/magic_types_battle.mp4

The defender's type advantage is determined by the equipment and spells they are carrying, and this affects the player too. If you equip a lot of FIRE spells, you'll have an easy time with ICE type enemies (enemies who, themselves, have equipped ICE spells or frost-aligned equipment) but you'll be weaker to AQUA in return. These water-ice slimes won't exist in the final game, but their spell assortment demonstrates the concept well. The player can easily lose this fight by managing their spells poorly, even with such a large health pool.

The player, and enemies, can hold one weapon with an optional type alignment, one armor with base defense and optional type alignment, and three spells, which always have a type alignment and have varying power from 1-3 (technically 255, practically 3). At the highest attunement, one *absorbs* damage, which is the only way to heal during battle.

Your weapon always attacks a single target, and refills your energy by 1. Magic always hits the entire field, but costs energy according to its base power.

2273 bytes! Worryingly large at this point, as there's just the one enemy coded. I need to squeeze in room for a proper encounter table, additional enemy sprites, and the dungeon-exploring scaffolding that will actually contain these battles. This may require some dirty tricks after all...

Huzzah! Loop closed!! Here's my poor brave adventurer, taking on a party of helpless slimes, and ... wait, what are these slimes eating!?

https://rusticnes.reploid.cafe/images/overpowered_slimes.mp4

Much progress today. Text systems are *fiddly*. I ended up writing a basic string concatenation routine, as otherwise erasing the full line of text when it's built out of so many small parts was a state tracking nightmare.

I want to generalize the player / enemy structures a bit so that attacks can swing in either direction, and therefore share most of their code. Then enemies can respond with attacks of their own, and that should close the interaction loop for battles. Then onward to magic!

I'm making a minimal RPG, squeezed into VIP memory constraints. Today's progress: working health and energy display, and a rudimentary text system with a 5x3 font. Up to 574 bytes already, which is just a bit worrying. We'll see!

I'm weirdly interested in targeting the original CHIP8 implementation, with the goal being to ensure the game at least runs playably (if not particularly quickly) on the old hardware. It'll be a turn based game, so speed isn't critical. I of course lack the original hardware to test with. Questions about the "VIP" compatability mode:

- Sprite drawing trigger vblank: does this mean no more than roughly 60 sprite calls per second, but other instructions have more leeway?
- Is 15 cycles/frame a reasonable approximation of the original hardware?

And a more general question: have I missed something, or is the only way to update I with a runtime value really to use self-modifying code? The resulting code structures feel quite awkward.