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: 124
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: 188
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: 310
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: 32
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: 124
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: 32
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: 201
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: 891
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: 124
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.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: unnamed-snes-game

Post by SNES AYE »

That all sound great to me.

Looking forward to seeing your progress.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: unnamed-snes-game

Post by SNES AYE »

One other thing: I know you're project isn't near final yet, but one thing I would strongly recommend once you feel it's at the right stage of development, is to contact all the SNES artists out there and see if you can get one of them to do a pass on all your visuals and really take the pixel art to the next level. I think that will make all the difference and give it that final SNES release-quality look to go along with all the great code and gameplay design. It's like the difference between two games that play quite similar to each other under the surface with one looking like say Yo-Yo Shuriken and the other Smash TV. And if you can get someone who's great at that Link to the Past/Final Fantasy VI/Chrono Trigger style pixel art or even anywhere close to that working on your game with you, it really could turn into something special. :)
UnDisbeliever
Posts: 124
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: unnamed-snes-game

Post by UnDisbeliever »

I have added prototype sound effects to my game and have released a build for your enjoyment. Gameplay, dungeon layout and enemy behaviour remain unchanged.

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

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


I created my own audio driver. It's a 8 channel bytecode interpreter (link to the bytecode spec), dedicating 6 channels to music and 2 channels to sound effects. Each sound effect is limited to a single channel, and only 1 sound effect can be played per frame. If multiple sound effects are queued in a single frame, the lower sound effect integer id takes priority.

The sound effects are assembled (from sound_effects.txt) into bytecode using a python script. I also created a python GUI that can assemble sound effect bytecode, transfer it to my sd2snes and play the sound effect on my SNES console (old twitter video of the GUI in action). I doubt I would have had the patience or motivation to be able to create these sound effects without the quick code-test-adjust-repeat loop that my resources-over-usb2snes subsystem offers me.

The sound effects in this build are rough prototypes, created from simple samples (sine, square, sawtooth, triangle, noise). I am going need to coordinate with someone who is more musically inclined then myself for the sound effects and music in the future. I can not make heads or tails of sample creation or music theory.



The next two features I'm going to add to the game are music (I am still in the middle of writing an MML compiler) and a dynamic sprite system. I think I'll work on both features in parallel this time.
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: unnamed-snes-game

Post by Nikku4211 »

UnDisbeliever wrote: Sat May 06, 2023 2:53 am I am going need to coordinate with someone who is more musically inclined then myself for the sound effects and music in the future. I can not make heads or tails of sample creation or music theory.

The next two features I'm going to add to the game are music (I am still in the middle of writing an MML compiler) and a dynamic sprite system. I think I'll work on both features in parallel this time.
For music, hit me up. I've got a whole collection of tunes in ModArchive, and I have some experience with writing MML from my short run of recreating my music for Super Mario World hacks.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
UnDisbeliever
Posts: 124
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: unnamed-snes-game

Post by UnDisbeliever »

Nikku4211 wrote: Thu May 11, 2023 11:04 pm For music, hit me up. I've got a whole collection of tunes in ModArchive, and I have some experience with writing MML from my short run of recreating my music for Super Mario World hacks.
Thank you for the offer of help, I will take you up on that.

At the moment I am splitting the game code in two; the core-engine and the tech-demo. The plan is for the engine and tech-demo to be completely open-source, while the full game (whenever I get around to naming it) will be a mix of open-source and proprietary code/assets.

After that, I'll prioritise the MML music compiler. No idea how long that will take. I should have it done by the end of the month (but I make no promises).

I'm also planning integrating the MML compiler (written in python) with my resources-over-usb2snes GUI. The goal is to have a GUI textbox where MML can be edited. With the click of a button the compiled song data would be sent to a QUsb2Snes compatible emulator/device and the user can quickly listen to the song at (hopefully) any point in the MML file.

I realise that setting up makefiles, a C++ compiler, python packages and QUsb2Snes might be too complicated for everyone, so I will eventually convert the MML compiler to a executable program (and combining it with bsnes's S-SMP emulator for live music playback). No idea when I'll do that. For now I'll stick with python for the prototyping phase of the audio engine.
Post Reply