unnamed-snes-game

A place where you can keep others updated about your SNES-related projects through screenshots, videos or information in general.

Moderator: Moderators

Post Reply
UnDisbeliever
Posts: 102
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

unnamed-snes-game

Post by UnDisbeliever »

It's taken a lot longer then I expected, but I have finally released a tech-demo for my unnamed-snes-game.

It's a simple demo, a single dungeon. Sadly, there is no sound. I wanted to release this demo by year's end and I ran out of time.
20230101a-screenshot-ac-scaled.jpeg

Download Link: https://github.com/undisbeliever/unname ... o-alpha-v1

Source code is available on github (MIT licensed): https://github.com/undisbeliever/unnamed-snes-engine/


I'm looking for feedback, especially regarding the dungeon layout and enemy behaviour.

I hope you enjoy the demo.
User avatar
olddb
Posts: 176
Joined: Thu Oct 26, 2017 12:29 pm
Contact:

Re: unnamed-snes-game

Post by olddb »

Nice :D

This is one of best SNES homebrews demos I've seen. Right up my alley.

Things I most liked:
-Fast and fluid character movement
-Enemy AI
-Transition scrolling
-Overall game design/flow

Things that need improvement:
-A better indicator when taking damage. Maybe flash the main character red or white? A hitspask of some sort would help. Also, bump the character farther and disable controls for a bit longer.
-Attack at Y Button. I would prefer it being on the B Button.
-Sword length needs to be longer. :D Also, the hitbox for the sword is not ideal.

Will continue playing...

EDIT:
Finished the demo.

Really liked this! :beer:

-Boss was fun! It took me a while to figure out you need to first strike bombs in order to pick them up.
-It wasn't apparent to me that the water actually heals, instead of reduce damage. Maybe an unique heal animation would help.
-Would love to see this more fleshed out.
Last edited by olddb on Mon Jan 02, 2023 11:21 pm, edited 6 times in total.
...
User avatar
Individualised
Posts: 157
Joined: Mon Sep 05, 2022 6:46 am

Re: unnamed-snes-game

Post by Individualised »

Always good to see more SNES homebrew releases!
regiscaelus
Posts: 19
Joined: Thu Jan 24, 2019 1:35 am

Re: unnamed-snes-game

Post by regiscaelus »

Enemy movement is very clever and is very distinct based on enemy type. The strong bow men are too strong at the moment. Perhaps a slower version should be encountered first to understand their pattern.
UnDisbeliever
Posts: 102
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: unnamed-snes-game

Post by UnDisbeliever »

Thank you for the feedback. I'm glad you all enjoyed my game.

The next two features I'm going to add to the game are sound effects and dynamic sprite tiles. If I don't add sound effects now, it will be months before I get around to it.
Afterwards I will add more player MetaSprite frames (player hurt frames), more particle effects (healing sparkles) and start tweaking player/enemy behaviour.

regiscaelus wrote: Tue Jan 03, 2023 2:16 pm Enemy movement is very clever and is very distinct based on enemy type. The strong bow men are too strong at the moment. Perhaps a slower version should be encountered first to understand their pattern.
When increased the attack delay of the crossbow men (the time between them spotting the player and firing the bolt) they became a lot easier to defeat (wait for them to start firing, walk around them, attack them from the side). Your idea of a trainee crossbow man, perhaps behind a monster door to force the player to learn how to defeat them, is an excellent solution to this problem.

As a bonus I could add an expert crossbow man, who has better reaction time, in a future dodge the crossbow bolts room.
regiscaelus
Posts: 19
Joined: Thu Jan 24, 2019 1:35 am

Re: unnamed-snes-game

Post by regiscaelus »

I can't believe I wrote strong bow instead of crossbow as I don't ever drink cider.
SNES AYE
Posts: 18
Joined: Mon Nov 07, 2022 11:28 am

Re: unnamed-snes-game

Post by SNES AYE »

OK, some feedback:

1. I would make the swipe cover 180 degrees based on the direction you are facing rather than 90. I think this would make attacking less finicky, and just feel more satisfying in general.

2. I would let player interrupt the current swipe if they press attack again while swiping. This way they can very easily and quickly correct themselves if they've started an attack and either need to quickly attack some enemy coming from another direction and/or they just attacked in the wrong direction in the first place and want to change where they are attacking quickly. Although, might need to tinker with this if it just results in the player never actually making an attack if you keep spamming the button.

3. Possibly speeding up the animations of the swipe might help with the two things above anyway, presuming you're currently holding each frame of the swipe for a few frames. Maybe adjust this lower to see what feels the best, but basically faster and more responsive should be better.

4. You have a thing right now where moving diagonally makes the player move faster than moving in any of the four other directions, so might need to do something so the diagonal speed is reduced slightly to seem the same as moving straight.

5. Not sure if you're planning on doing this, but adding in diagonal animation frames when the player is walking in those directions will really help with reading where he's likely to attack. Obviously, you're pushing in the direction anyway, but I think it also needs to visually reflect this so it's always patently clear to the player.

6. I think the floating skull enemies move a little fast. But that might be fixed if the various attacking stuff above is implemented, as you will far more easily be able to adjust you're attack on the fly and make sure you're swiping that sword exactly as planned and with great responsiveness.

7. It seems like you're using separate sprites for the shadows, but I would bake them into the sprite graphics where possible just to make sure you're not approaching any sprites per scanline limits unnecessarily.

8. The dungeon stuff is all fine. I'd have to see much more of the final game to know if there's anything there I'd want to feed back on, presuming they're going to get more complex later on and have levels and switches and other stuff like that to interact with possibly.

9. I like that I can just run past soom rooms of enemies, so I don't always have to kill every baddie just to progress.

10. I'm not a huge fan of enemies that randomly change their movement patterns, like the green slugs seem to do. If you want to keep that, I might think about some way to make it more difficult for the player to accidentally get caught off guard and take unfair damage when they are just trying to move into the enemies path based on where they're currently going but suddenly the enemy randomly changes direction and the player bang into them before they had a chance to know what was happening.

11. I've just noticed the diagonal swipe starting position differs for the same diagonal direction depending on which direction the player was facing before moving diagonally. This means that sometimes the sword isn't actually swiping across the diagonal position you are moving in. For example, if you're moving left and then push diagonally down and left, the sword only swipes from above the player's head down to the left, never properly attacking in the down and left position clearly, at least not as I would expect it to. So, I would try to keep that consistent and really visually reflect what the player expects to see. If you're pushing diagonal in whatever direction, the main point of the attack should clearly be in that direction. If you do what I say above regarding the 180 degree attack range, that would always be during the middle of the attack animation ark.

12. Personal preference: I wouldn't reset enemies if you've cleared the room of them, leaven the room, and then go back into the room. But, one I thing I do think would be cool, if you can maybe do it via background tiles or whatever, is to have the bones or whatever of defeated enemies resting in the place where you killed them, much like you see in Doom. That way you could wander through rooms you've already completed and see the remains of the enemies you've killed. And it also acts as a nice marker of rooms you've already been to, which can often help guide you back through dungeons a bit easier if you have to background through certain parts.

13. I would drop bombs with the primary action/attack button, which is currently Y. It doesn't make sense to me currently that I have to press X to drop a bomb. Unless there's some reason you can't assign it to the same primary action/attack button? And I might also make the player have to press the same primary action/attack button to pick them up too, but I'm not too fussed about it if you stick with automatically picking them up. I would maybe even let the player throw them forward in the direction the are facing if they are currently holding down a direction when they press to drop the bomb. I think that would feel satisfying as an action.
Last edited by SNES AYE on Sun Feb 05, 2023 1:25 pm, edited 5 times in total.
Fiskbit
Posts: 623
Joined: Sat Nov 18, 2017 9:15 pm

Re: unnamed-snes-game

Post by Fiskbit »

I moved the button mapping conversation here so this thread can focus on UnDisbeliever's game.
UnDisbeliever
Posts: 102
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: unnamed-snes-game

Post by UnDisbeliever »

Over the last month (and a bit) I have been working on creating a simple audio driver for the game. None of the existing open-source drivers met my needs when it came to sound effects, so I'm trying my hand at it. So far I have a bytecode interpreter and a basic sound-effect instruction assembler (Twitter video playing 3 sound effects).

I'm currently working on improving my tooling. I want to add a GUI to resources-over-usb2snes that will allow me send song/SFX data (as I'm editing it) to my console and have the console play it ASAP.

SNES AYE wrote: Sun Feb 05, 2023 12:54 pm OK, some feedback:
1. I would make the swipe cover 180 degrees based on the direction you are facing rather than 90. I think this would make attacking less finicky, and just feel more satisfying in general.
I agree with you that the sword mechanics needs a lot of work and tweaking. Half the reason I'm using 90 degree swings was to reduce the sprite-tile count (the other half was that I didn't want to completely copy Zelda 3's sword mechanics). After I've got this audio engine working, I'm going add dynamic player sprite tiles.

I'm thinking of using a compositional sprite system for the player; where the weapon, torso, head, feet are separate sprites. This should give me enough flexibility to improve the sword mechanics while also adding new weapons to the game.

This is still in the design phase, I have not figured out a good data-structure or workflow for compositional sprites yet.

Once the sprite-tile count is no longer a problem, I'm going to overhaul and rewrite player-movement and player-attacks.

SNES AYE wrote: Sun Feb 05, 2023 12:54 pm 7. It seems like you're using separate sprites for the shadows, but I would bake them into the sprite graphics where possible just to make sure you're not approaching any sprites per scanline limits unnecessarily.
I'm using separate sprites for the shadows because I was originally envisioning jumping enemies and a player jump mechanic.

I haven't noticed any sprite-clipping in the demo, having more than 6 enemies in a room gets unwieldy anyway.

I should probably check the STAT77 register every frame and log any sprite overflows, just to be safe.

SNES AYE wrote: Sun Feb 05, 2023 12:54 pm 12. Personal preference: I wouldn't reset enemies if you've cleared the room of them, leaven the room, and then go back into the room. But, one I thing I do think would be cool, if you can maybe do it via background tiles or whatever, is to have the bones or whatever of defeated enemies resting in the place where you killed them, much like you see in Doom. That way you could wander through rooms you've already completed and see the remains of the enemies you've killed. And it also acts as a nice marker of rooms you've already been to, which can often help guide you back through dungeons a bit easier if you have to background through certain parts.
Something like this has been on my low-priority todo list for a while now. I was thinking of keeping track of the last 16 (or so) rooms the player has been in and which enemies in those rooms have been defeated. Enter a room on this list and the defeated enemies won't be spawned.

I'm not sure if entering a room to see the remains of defeated enemies fits the theme of my game. It's something to think about.

SNES AYE wrote: Sun Feb 05, 2023 12:54 pm 13. I would drop bombs with the primary action/attack button, which is currently Y. It doesn't make sense to me currently that I have to press X to drop a bomb. Unless there's some reason you can't assign it to the same primary action/attack button? And I might also make the player have to press the same primary action/attack button to pick them up too, but I'm not too fussed about it if you stick with automatically picking them up. I would maybe even let the player throw them forward in the direction the are facing if they are currently holding down a direction when they press to drop the bomb. I think that would feel satisfying as an action.
The player dropped the bomb because I was working on time crunch. However, it did inspire an interesting idea. I'm thinking of having two types of bombs in the game; small bombs the player can throw and large bombs that the player drops (which the player has to find and are required to kill the rooks).

I can't remember why I chose X for dropping the bomb. I'll switch it to the attack button when I overhaul the player subsystem.

As for why I chose Y for attack. I was thinking of using B for jumping or dashing.
Post Reply