{%hackmd @themes/dracula %}
# backdrop³
A re-write of Project Backdrop using SolidJS and the SolidStart framework. The main focus of `backdrop³` is speed. The app will be using SSR. Loading things from a CDN is on the table, but with CloudFlare it might not be necessary.

The entire UI will also be re-done from scratch for the first time.

## Milestone 1
Have a working prototype of the UI, minus the Checkpoint.

Make three songs function as they should:
- Zeal
- Sticker (variations)
- Bobonga (404)

Once this is done, send it up to Railway and let people test the UI and get input.

## The UI
The current UI is old. While I did replace things with MUI in the last re-write, it still looks the same like it always has - which means that it is still very much inspired by the old Materialize.css look. Things are very spread out; the top-left is the settings menu. The top-right is the about modal. To the right we have the SongInfo prompt, and on the bottom there's the Checkpoint button that opens a large drawer. It looks simultanously very spaced out while also looking a bit bloated on smaller screens. Especially the settings menu and the Checkpoint, as they show so many things. Point is to make it more compact and cleaner.

Will use NextUI and TailwindCSS rather than MUI. The menu will be the CommandCenter, listed as a Card on the bottom of the screen that can be hidden out of view. Buttons will either be button icons or normal text. They should be separated by vertical Dividers.

## CommandCenter
Current idea:

                 ___________________
                | GAME - SONG NAME |
< SONG | VARIATION | CHECKPOINT | CONTROLS | ETC >
              | COMPOSER - DEVELOPER |
              -----------------------

It appears towards the bottom of the screen and can be hidden.
Each button should open a Popover with the current menu.

1. Song: Opens up a scrollable / searchable list of songs.
2. Variation: Is disabled unless the song has a variation. Is always shown unlike currently.
3. Checkpoint: Opens up the Checkpoint menu.
4. Volume, Brightness, UI color, and UI fade sliders.
5. About, Changelog, Language, maybe a link to aravix.dev.

The Game/song name and composer/developer fields "pop out" in a neat way.

## Layout
The Layout.tsx file in current Backdrop handles a lot of things. It somewhat works like this:

- Keeps track of the current song, and puts it in a CurrentSong object which has both the song info, as well as variation info.
- Handles the switching of songs and secrets.
- Sends the extra functions required for variations and secrets to the router.

We can keep some of this, but it might be due a re-write.

## Song object
Current Backdrop makes use of a JSON file to list all the song data, since it's static. Keep this.

{
    "name": "Zeal",
    "song": "Corridors of Time",
    "game": "Chrono Trigger",
    "franchise": "Chrono Trigger",
    "developer": "Square",
    "composer": "Yasunori Mitsuda",
    "hasVariation": false,
    "debug": true,
    "new": false,
    "interactable": true, //NEW!
    "random": false, //NEW!
}

### New fields:
`interactable`: Used to indicate in the UI that there is possible human interaction.
`random`: Has features that are randomized when the page loads.

## The megafiles
BackdropCore has 3 megafiles: PixiHelper, HowlHelper, and ImportHell. Need to come up with a good way of handling these.

### HowlHelper
The hardest one. HowlHelper is currently used to control *everything* related to playing sounds. Muting, volume, playing any kind of sound. It has huge functions inside of it that assemble the tracks depending on what was sent in. We want to avoid this in specific.

Volume and muting can simply be handled on its own in the ConfigMenu.tsx.

When it comes to playing audio we have a different problem, however. The thing that this megafile allowed us to do is to make use of the CurrentSong and play audio without having to call that manually in each song file. Since a lot of songs have an intro that shouldn't repeat, they make use of two Howls that call each other in a chain.

So what are our options? Well... we can't really reproduce this functionally perfectly without some manual work. However, that might not be a bad thing, necessarily.

#### Song-specific hooks
i.e: `useZeal`. These hooks have already been planned to be used for things that need event listeners, but with this we can have a useEffect on load that unloads sounds as well as creates and plays the new one.

#### useHowler
`useHowler` will be a a hook that takes an array of howls and plays them. We'll do as we wrote above and make a hook for each song that handles logic for the songs as well as starting the music. `useHowler` should have functionality for swapping music (for songs such as Majin) as well as playing sound effects that don't interrupt the playing music.

### PixiHelper
Easiest way here is probably to use ReactPixi and build things in a React way instead. PixiHelper itself is completely ambigous and isn't a big deal to keep if we have to.

### ImportHell
The file that has every single image used in the songs are exported from. Easiest solution here is probably to just import everything directly in the song files themselves.

### The Checkpoint
The Checkpoint has historically always been a bit off on mobile devices. Come up with a design that makes sense.