I read through this entire thing, and it seems like you've learned quite a lot. I'd like to give you some of my thoughts in terms of a purely game design standpoint, if you'd like. If not, feel free to stop reading here.
Anyways:
I first want to commend you for custom building a game without much reliance on the Godot engine. I am still fairly new to game dev and I don't think I would have wanted to undergo something like this to be honest. I also empathize with you about the job search. I got laid off last November and I still haven't been able to find a software engineering job, so try not to beat yourself up over that. The market sucks, and to be honest, if you put your game dev stuff on your resume it will absolutely attract companies.
Here's where I'd like to give you feedback (and yes I know you went through all of the other stuff. Don't take this as me saying you should have done all of this for the game jam, just take this as if you hypothetically made a game to release in full):
- The color scheme is pretty cool, but I was frankly quite blinded with what I assume was the lighthouse beam. I was unable to see where I was going for the most part and spent a good amount of time trying to climb the house you spawn in to just try to see where to go in the first place.
- I also noted the lack of a pause menu. While accessibility is not as important in my personal opinion for a game jam, the ability to pause with a rudimentary menu is still pretty important. I have no idea how you'd do it if you used custom and experimental plugins / unstable features since from my understanding you wanted to avoid using the Godot engine for development altogether, but it usually isn't difficult at all.
- In a similar vein, the text to read the controls were too small. Consider increasing size and potentially introducing a small tutorial, whether it's a couple signs (like the UI is real wildcard comes to mind) or a dedicated level showing the player how to take advantage of the mechanics.
- In a couple Valve dev commentaries I've seen, they talk about 90% of the time, players get extremely confused as to where to move towards in a game unless there's a giant yellow arrow pointing to the location / map. I don't think you need to use something so obtrusive, but having indicators as to where to go will help players get past the initial hurdle of your game.
- The sound design could be better - I was frankly annoyed with the drone and quite confused as to what it was supposed to represent. Again, take this with a grain of salt because I just read through your post mortem and I understand what you went through, but this is just a general critique.
- Regarding collisions, I believe you need to set the collision shapes to ConcavePolygons both to reduce weird collision behavior and also to have it conform to the shape you are creating. It might be less performant due to more calculations but I think it's a good tradeoff for saving on player frustration.
- What was the reason for you wanting to make this in C#? If it is generally easier for you to make stuff in C# (i.e. Unity refugee) I get it, but seriously, give GDScript a try. It's Pythonic and you can still strongly type to avoid dynamic interpretation. If it's a performance standpoint I can't really argue with you there, but I would still say to try and use GDScript.
- For scoping, I have a design document that I'll share 3M Design Document Explanation. I'll also link the blank document at the end of this comment. Read through this and consider using it for your next jam!
- Personally, in my experience with jams, people don't have the 10 minutes or so to fully immerse themselves in your game. And I'm not saying just your game specifically. Everybody wants others to look at THEIR game and play THEIR game, they don't want to look at others'. People who do take the time to give ratings and comments likely look at your game for maybe 1 minute if they're being generous, and if there's ANY friction between their gaming experience and the experience you are trying to deliver, they're not gonna bother to explore the hidden intricacies. I have generally tried to stick to simple but (hopefully) more captivating games with simple mechanics that can be explained easily. If you want to make a complex game like Intuition, that's great! But for the purpose of being seen in a game jam, I personally would not recommend going all-out on something like this unless you're working with a more substantial team.
- To get more people to rate higher, it's plain and simple: get a hook, keep mechanics simple, and sfx & art are way more impactful than you think. Remember: assume that everybody is going to try your game for 30 seconds tops. If they aren't interested by then, they're not gonna keep playing.
Overall, the game's bones are there. I can see it being very stylized and intuitive. Pun intended! It's definitely a Herculean task to try and bring a grand concept to life when things will inevitably get in the way. It's also great that you are introspective of your abilities as a developer and are able to see some of the flaws that you encountered. I love that you are actively working to improve, and with that it will propel you to colossal heights.
Here's the 3M Design Document Template. I hope you find it useful! Cheers and good luck on the Pirate Software Jam.