I've been doing a lot of thinking about Thwimbly over the last couple days, and have come to the realization that I definitely need to pivot in some direction.
The game is closing in on being "feature complete" in the sense that most of the underlying mechanics are done, it's just pixelart, level design, and music that need to be completed. Realistically, I can probably get the rest of the game done in 100-200 hours of solid work, but with working full-time and trying to balance my other creative outlets and responsibilities, that could still be a year off.
This game is closing in on being in development for four years (sometime in June 2021 was when I started working on it). While I haven't been working consistently on it over that whole time, it's really been a part of me. it feels wrong to put it out in a subpar state after how much of my time and energy I've spent on it.
That brings me to the current problems, most of which are caused by the engine.
It's a fantasy console, so it's trying to lock you into a set of limitations that mimic retro consoles (16 colors, limited code size, 256 tiles, 256 sprites, limited map memory, etc). This can be good, and helped a lot in the early days: having code/sprite/map editors built in was excellent for prototyping. The problem now is that the game can't be all that I want it to be because of the limitations.
Problem 1:
The audio engine in TIC-80 is too limiting. I'm limited to four channels, each monophonic. It's slightly less limiting than the original gameboy, as each channel can be any waveform including noise, but you're still effectively limited to gameboy sound. While there are a lot of phenomenal albums and tracks made on the gameboy (Spectra by Chipzel is an incredible achievement), those don't have to contend with sound effects.
If you've played the demo and picked up a bunch of coins in quick succession, you might have noticed that it sounded glitchy, that's because the sfx for coin collection is overwriting the sound on channel 3. I tried to mask it by making channel 3 the drum channel, but I think it's still noticeable.
Besides just chopping the music down to three channels and leaving one for SFX, I can't see an easy path forwards living within the engine. Music is one of my favorite parts of games, and I would like Thwimbly to have some bangers without getting overwritten by the .
Problem 2:
The map limitations are pretty rough. I'm currently limited to 28 levels of exactly the same length as those in the demo. I can make them shorter, but they can't be any longer because that's where the map size ends. I actually don't think that the levels are too short, I like how long they are, but it would be nice to have more of them. I really wanted to have a sort of "Master Quest" "Kaizo" mode that was super ultra difficult after the main game was complete, but I just won't have room for that without making a fully new executable or trying to encode level data in text and pull it in at runtime.
I'd like the game to be longer than 1.5 hours, but even if I make the levels pretty difficult, I don't think it'll take an average player much longer than that for a first playthrough.
Problem 3:
TIC-80 does not support Steamworks. I would like achievements for one, as I really enjoy hunting for them. This basically requires modifying the engine to overcome.
Big Solution 1:
Port the game to Löve2D. TIC-80 is Lua based, Löve2D is as well. Graphics calls and map data would be more complex, as primitives like lines, circles, triangles etc would need to be recreated, but this would effectively solve all of my problems in one swoop.
Löve2D also already has a library to integrate Steamworks, and is running LuaJIT, which is a much faster version of Lua that would help me squeeze more performance out of the current code without rewriting much of anything.
I won't be able to have a web app anymore, but the current web app is way too resource intensive anyways.
Big Solution 2:
Fork TIC-80 and compile a custom version that breaks some of the restrictions. If it's simple to just add on a couple more channels that I can route SFX to, even if I can't use or edit them for music, that would be great. Similarly, if I can't already just paste extra banks of sprites/maps at the end of the .lua file, breaking that restriction so I can would be great. Even if I can't edit those sprites in the engine, being able to copy them from a different project would be fine. Steamworks will have to manually be grafted on later.
Big Solution 3:
Just deal with it and stay true to the fantasy console limitations. I'm confident in saying that Thwimbly is one of the frontrunners in terms of high-effort games made with TIC-80.
Emuurom is the other high effort game I'm aware of, and it would be cool to push the engine to the limits. Emuurom does have a Steam page, but does not take advantage of Steamworks or any of that stuff.
If I take this road, I'll have to trim back my musical compositions to allow an extra channel for the SFX, which could leave things feeling a bit empty (even fewer chords than I can do with 4 channels). I'll also have to lock in to 28 levels and just accept that.
The Road Ahead:
If any of y'all have any input, I'd love to hear it. Solutions 1 and 2 are probably going to require me commissioning or hiring someone to help with that process, so if you or anyone you know is interested in helping or can maybe even just give me an estimate of how long / expensive that might be, I'm all ears.
I'm reaching the desperation stage of this project. I need it to be done so I can clear out all of the brain RAM it's taking up. But I also don't want to release something I'm not proud of. The current web export performance problems and general audio problems are not something I'm proud of.
I also really should refactor my collision code, but the engine decision should really be made first. 
