itch.io

There... shouldn't be a coin stuck in the lower corner of the map? I'm not sure what you're seeing, though I wouldn't discount some sort of entity spawning bug. No, the coin you're missing is most likely a secret area in the pink forest. Hint: the balloon is required!

Oh, yes! Press as you're landing and keep it held. Once you release to jump you should maintain that momentum. You'll even keep your faster momentum after bonking into a wall, which can help with setting up a few of the leaps more consistently. But if you fall off a platform without jumping, you lose your dash speed.

I can tell this mechanics really needs coyote time. I'll do a quick revision pass later (I need to fix a few errors and frustrations I didn't catch during my own testing) and I might try to sneak that in when I do.

To those of you having trouble with the speed shoes, there's a trick to them: You can press a little bit before landing and they'll activate every time. If you don't want them to activate, get in the habit of holding A right after you jump and keeping it held the whole time you're in the air. No press near landing == normal speed.

This is certainly a frustrating control scheme to internalize, but exploring it was the entire point of this project. :P

I'm getting reports that some browsers are adding a ton of input latency. There's not much I can do about that, and it'll make this game a loooot more finnicky to control. Try a different browser or the native player if you're getting lag. There is no input buffering; the game should be responding to your inputs basically instantly.

The dash is the solution! The timing here is a little tight. I was battling small screen size and "the player can't ninja their way across this without the necessary upgrade" considerations. Try to release your dash-jump right on the corner of the yellow triangles.

Right now it should work in the newest builds of Mesen, which can be found here: https://github.com/SourMesen/Mesen2

Rainbow is still fairly new, so there may be some bugs we haven't squashed just yet, but it should at least boot and run. I use Mesen2 for development, as it has an excellent debugger. The older Mesen project on github is no longer being maintained, as far as I'm aware.

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.