The way I've been doing it as least with my current project.

I work on a batch of features at a time. Could be a bunch of small things or a more full release with two or three major implementations like a camera system or new usable items. I keep a txt log where I document changes, and go from build to build like 'pre-alpha build 0.3'. Keep building said builds until you feel you're ready for a stable release, whether for real or get people to help squash bugs you've found in the current build.

Thanks for the clarification and further ideas on how to improve the mechanic in theory. Yep, I'm utilizing solid behavior and eight-direction too. Also, since you posted again, thank you for an actual working example. Kudos for going out of your way to show me, man.

I think I initially visualized this wrong though. I assumed sides even if he was facing forward, but it turns out technically the feeler helpers would be actually both in front and behind him. They get get rotated if he faces left or right, I suppose. I had drawn up a really simple diagram replicating it on paper.

I've modified an old capx I found to create a grid system for my gamekit. I feel I've gotten it pretty close to how A Link to the Past runs, if you compare this gif below. I've recorded the below gif with bsnes and licecap, so the example below runs at near 100% accuracy in terms of simulating the SNES. (without accounting for the slight slowdown caused by recording the gif, so it probably runs slightly faster)

How would I go about getting the smooth movement as seen in this next gif? The gif demonstrates Link smoothly moving into a one-tile wide space, for clarity. The original Legend of Zelda did not have this, as it had clipping issues with attempting to move into a one-tile wide space. As some of you know, you had to be exactly pixel perfect to not clip with things in the NES LoZ.

From some googling and article research, my guess is to create two feelers on the side of the player's hitbox. One on their left and one on their right, about four pixels away from their own hitbox edges. If there's no collision for both, no position adjustment is needed but if both get collision detections, it'll stop the player's forward progress but if only one feeler has a collision detected, the player will get nudged into the opposite direction until they're aligned with the grid and then continue forward motion.

I have a method that may work for you, but it uses an entire animation (player, sword, and all) instead of pinning a sword sprite to the player and uses a player line of sight as replacement for collision boxes, just so you know.

Get a cheap SSD or a flashdrive (they now have them for beyond 100 GB), as flash memory is pretty much nearly guaranteed to last for ages.

Although there probably won't be a video to showcase this (unless I can record a video with me using the 360 USB gamepad in tandem like a picture in picture mode), Zelda Gamekit is now in pre-alpha version 0.9!

This marks the introduction of rebindable keyboard controls and full gamepad support.

You know, this pretty much seems like major copyright infringement to me.

Paint.net also works. It's free and is often touted as a program on the level of complexity between MS Paint and Photoshop. It's a bit simpler than GIMP but has Photoshop features like layers.

New build for my Zelda Gamekit, now with working savedata!

A new build, with working savedata!

You can buy Construct 2 either on here (on the website), or Steam but either one will only run on the platform it was purchased for you. You can, however, link non-steam games into your library.