unnamed-snes-game

[KungFuFurby]

Yes... I had actually opened the first pull request for my music contributions on March 18th (so I had already jumped the gun on that one). The soundtrack itself evolved over time as the sound driver went from six channels to eight channels, in addition to feedback-related adjustments regarding volume balancing between music and SFX, so I've been keeping the soundtrack up to date as the sound driver evolves.

[SNES AYE]

Hey, UnDisbeliever, I'm not quite sure I understand what a sound driver is here. So, can I just ask, does this mean you've developed a tool that other people can use to create music for SNES? And if so, is this something new that allows them to do things with the SNES audio that they couldn't with other tools or maybe just get a better sound quality than other older tools, or is it simply an alternative option they can use if maybe there's something they prefer about the way you've designed this particular tool or something like that?

[UnDisbeliever]

Hey, UnDisbeliever, I'm not quite sure I understand what a sound driver is here. So, can I just ask, does this mean you've developed a tool that other people can use to create music for SNES? And if so, is this something new that allows them to do things with the SNES audio that they couldn't with other tools or maybe just get a better sound quality than other older tools, or is it simply an alternative option they can use if maybe there's something they prefer about the way you've designed this particular tool or something like that?

An audio-driver (also known as an audio-engine) is the code that runs on the spc700 processor. It is responsible for setting the S-DSP registers and communicating with the 65816 CPU to play music and sound effects.

I wrote the Terrific Audio Driver because I was dissatisfied with how the other open-source game-ready audio-drivers (snesmod, snesgss and qspc) handled sound effects. I wanted an audio driver that could hold ~100 sequenced sound effects. TAD was written to be sound-effect first, to the point where I implemented sound effects before my audio-driver could play music and before the the audio-compiler could parse MML (the music format I chose).

After about 6 months, I was happy with my audio-driver. It did everything I wanted and was at a point where I could make music and sound effects with. But I'm horrible at making music. So I made the decision to port the tooling to rust, build a GUI and make the driver easier for other people to use. This includes the decision to maintain the project and add requested features to the driver/GUI (provided they are not too outrageous).

The Terrific Audio Driver is an alternative option snesdevers can use in their games with the following features:

• Actively developed.
• The spc700 code is zlib licensed.
• Channel ducking. 8 Music channels and 2 sound effect channels.
• Songs written in a pmdmml inspired MML format.
• Sequenced sound effects, written in either bytecode assembly or MML.
• Configurable sound effect dropout behaviour:
  • High-priority sfx that will override the currently playing sfx. Intended for important sfx like player-hurt-low-health.
  • Interruptible sfx.
  • Uninterruptible sfx. Useful for vocal samples or item collected ditties.
  • One channel sfx that will play on a maximum 1 SFX channel. Intended for rapidly played sfx (ie, collect-coin) to prevent it from occupying both sfx channels.
  • Low-priority sfx that will not play if both sfx channels are occupied. Intended for background sfx like water droplets.
  See the sound-effect documentation for more details.
• Echo, portamento and vibrato support.
• An asynchronous API for ca65 and PvSnesLib that supports loading audio data over multiple frames. Useful for loading audio data in the middle of a level transition or fade-in.
• A GUI that:
  • Runs on Windows, MacOS and Linux
  • Plays MML songs at the cursor position or line start
  • Plays songs and sound effects at the same time (to assist in volume balancing sound effects and music)

[SNES AYE]

OK. Thank you for all the information there. That helps clarify a lot of things. Thanks again.

[UnDisbeliever]

I've finished the critical engine features I need for the next demo. There's still more features I want to to engine, mainly improving movement and collisions, but I'll do them later. I want to avoid falling into a rabbit-hole of endless engine changes for the sake of change.

I've improved MetaSprite palettes:

• Added palette swapped MetaSprite framesets
• The two bomb entities, player and boss, now have different colours.
• Added palette cycling using callbacks.
• Up to 3 MetaSprite palettes can be loaded at once.
• MetaSprite palettes can load child palettes, simplifying palette reuse.

I've rewritten the gamestate subsystem:

• u8 and u16 gamestate variables are now defined in a json file, so they can be referenced by the python and the 65816 wiz code.
• Split gamestate flags into global-flags and dungeon-flags. When I run out of dungeon-flags, I'll implement a dungeon banking system that switches the dungeon-flag bank when a dungeon is loaded.
• Added saving and loading gamestate from battery backed cartridge RAM.
  I'm saving multiple copies of each save slot to Cart-RAM. If one of the copies is corrupt, the save can hopefully be restored from remaining copies. I've got a ton of free cart-RAM space, there's currently four copies of each save slot (on a 4KiB save RAM).
• Added version and data size fields to gamestate. To prevent glitches, a save will only be loadable if the header (identifier, version, data-size) and checksums match.
• I've added a gamestate viewer/editor tab to my resources-over-usb2snes GUI. Allowing me to live-edit the gamestate flags while I develop and test the game. (Not critical, but it will make testing a lot easier and it can be used to warp the player to a specific room.)

File select screen (1chip Super Famicom screen capture)

Resources over usb2snes GUI screenshot

Finally, I've rearchitectured how the entity process/drawing functions are called to move the code to bank 0xc0 and increase the amount of free code space by 24KiB (4KiB of bank $c0 is used for the rodata segment).

Previously the process and drawing functions were stored as function tables in RAM and called with the JSR (addr,x) instruction (X = entity index), but required the code to be stored in bank $80 (so the Program Bank can access lowram).

Now the process and drawing functions are managed as byte-indexes to a function table. This is slightly slower but allowed me to move the Program Bank to a 64KiB ROM bank.


---


I'm going to wipe the old dungeon, start afresh and build a horizontal slice.

Instead on focusing on building a production-ready single dungeon slice of the game, I'm going to focus on a prototype slice of whole game. With bare bones tilesets, placeholders for enemies, NPCs, treasures, dungeons, etc. The goal is to map out the game's main path to get a feel of the demo's scope. This should (finger's crossed) give me a better understanding on the finished game and provide motivation to focus on the game over engine features.

Then, over the rest of the year, I will slowly develop and enhance the prototype placeholders and graphics until the game-demo feels complete.

Here's an 11 minute Youtube video by Timothy Cain explaining the concept better then I can.

[Kannagi]

It's interesting to see the solutions and difficulty for the engine and the game.
But I know what you write well, since I often tried to reconcile several things (engine, gameplay) etc., and that all this is not too long to do, otherwise we never finish!

Good luck "redoing" the level, I hope it will result in a more modular and easy code so that you can then continue to make an entire game

[UnDisbeliever]

I've decided to delay the game-demo to next year.

I feel like I've made negative progress over the last few weeks. Mostly because of indecision paralysis and because I forgot about bosses when I planned my rough 3 month schedule.

I took a break from the game to add more features to my audio-driver. With the upcoming SNESDEV game jam next year, I feel like my time will be better spent adding the final bytecode/MML features I want to the driver. Then I can removed the "this audio driver is still in development" notice and finally release a stable build of my audio driver. I do not know how long it will take, it will depend on feedback. I'm hoping to stabilize the bytecode/MML before the end of the year, leaving plenty of time for SNES musicians to learn the quirks of my driver before the game jam starts.

I'm planning on treating the next game-demo as a practice run for the SNESDEV game jam. I'll start in a similar position as I will for the upcoming jam (with tooling already setup and a partially completed engine) and build a small game over 3 months. If all goes well it will be excellent practice. If I run out of time it will be a learning experience. Either way, the practice will highlight potential issues before the game jam start.

[slidelljohn]

I just tested the alpha version 3 and it definitely has a lot of potential due to how fun it is to play. Any plans on adding a jump ability for the main character?

[UnDisbeliever]

I just tested the alpha version 3 and it definitely has a lot of potential due to how fun it is to play. Any plans on adding a jump ability for the main character?

I'm glad you had fun.
I'm planning on adding jumping and shielding to the game in the next release.


I've decided to delay the game a month. I need to focus on my audio driver at the moment.

I want to have the audio driver's MML and bytecode syntax stabilised by early January so people can practice with it before the 2025 SNESdev game jam starts. It's taking longer then I thought, mostly because I'm still finding and fixing bugs in the MML compiler.

I still want use unnamed-snes-game as practice for the SNESdev game jam. Here's the new plan:

• Finish the new audio instructions in December.
• January - March - Craft and release a second unnamed-snes-game demo.
• At the same time - Update audio driver documentation and declare the audio driver bytecode/MML stable. Completion date unknown, it depends on how many bugs I shake out of the code over the next few weeks.
• April - May. Refamiliarise myself with my untech-engine, add audio and rewrite a decent chunk of the MetaSprite code.
• 1st June - September 7th - SNESdev game jam

As you can see, I'm booked for the next 8½ months. I will publicly release the next demo, in whatever state it's in, on March 31st.