Hey, thanks for the feedback. All the issuse you mentioned I'm pretty much aware of, however, my focus was to get a finished thing out the door first.
But yeah, the code really got ugly towards the end, since I was running out of time and was scrambling to get things done.
In hindsight, considering I had not amde a game before, and not worked much with the library I made it in, I should have gone with something more simplistic but make it more polished.
For example, the spinning attack caused a lot of trouble, since the sprites in the Python arcade lib all rotate around their center. So I messed around with transforming coordinates and making the sprite move while turning such that it would seem to stay in place, but I never got it to work. That ate up a good 3.5 hours. In the end I just made the sprite be a square picture, so it would rotate properly.
The collision detection was a major headache aswell, especially since the collision check between the player and and the obstacle sprites caused the collision detection between the attacks and the creatures to break. For whatever reason. Well, really the reason is terrible spaghetti code :D
And the bugs not resetting after going to the menu was something I thought I fixed, and that was working before. I must have broken in the last few hours, but never noticed while I was testing it. I noticed right after I submitted the game, which annoyed me quite a bit, since the fix should be fairly simple; a line or two at most. But I wasn't sure if the rules allowed me to go back and fix it after the deadline, so I left it how it is.
Overall, I've learned a bunch over the last two days. Since I'm a hobbyist, I never really have time constraints when making anything, so that was a new type of development for me. Main things I took away from this:
* Proper, clean code / good architecture takes time. More than 48 hours anyway. This probably get's easier to do under pressure with more experience, but for me, in the end the only thing I cared about was to get it working.
* Don't fret scrapping features if they don't work out. I spend more than 2 hours on a health bar that never worked, wich is about 10% of the total time I effectively spend working. I should have scrapped it earlier and got on with other things.
* Taking breaks is important. Even when you don't have time. Everytime I took a break longer than 20 mins, the hour or two after, I got more done than the last 3 to 4 before that
* Make a plan. Write it down. Anything and everything, every thought on how to do things. Order in by priority, then start working. Don't be like me and jump straight into writing code, it's way less efficient.
* Quality over quantity. I should have made something more simple, with less features but more polished, both in terms of the game itself, aswell as the way the code looks.
* Rotating things is difficult and causes all sorts of issues :D
Anyway, I will definetly make a more polished version of this game. I am proud of the fact that it works, and that it was made is such short time, but I'm very aware that I did many things the wrong way, some intentionally to save time, others unintentionally because of lacking experience.
As said before though, overall this was quite a lot of fun, but also quite the challange. I would have love to take it further, and there were many more features I would have liked to have, so I will upload a V2 to my GitHub in the coming days and weeks and improve it until I'm happy with it.
Thanks again for the feedback, and for pointing me to this competition, I'm already looking forward to the next one :D