Some nice patterns, though the unrestrained screenspace and the wild movements sometimes makes bullets overlap in a way that makes them nearly impossible to macrododge (which you're able to for quite a long time), not sure if that's my lack of planning, or it's intentional in order to make you micrododge. Would be more fun if there was more stuff to do other than just dodging, getting hit doesn't feel like a big enough penalty either.
Props for getting this to work (mostly) fine on browser, my game worked terribly on it which is why I took down that version as soon as I tested it. Wondering if you used any special optimization techniques with that taken in mind or you just coded it right from the beginning and it just worked.
Viewing post in Heartbeat jam comments
Thank you for the detailed feedback! I did somewhat design the game to kill you with some patterns. There is one enemy mode that has some randomness which can become "kill mode" if you are unlucky with rng. The other 4 patterns are manually designed with a set pattern that can be 100% avoided with careful dodging.
Re: performance I played your game and saw you also used Godot. First is the longstanding issue of audio stuttering with HTML5 exports (which is being addressed with "Threads" mode in export) Another issue I've read about is Godot's performance with rendering many 2DNode sprites on screen. However I didn't encounter major performance issues in my game until I hit 3000+ bullets on screen at once. I did my own hit detection with simple distance formula checking. You might want to look into the 2D Bullet Shower Demo with godot and research Optimizing with servers for rendering sprites (I did not implement this in my game, but it is a topic I recently learned about that could definitely help with bullet hell games in the future!). What was your method of collision detection? Did your HTML5 version play at a low frame rate or did the audio just sound bad/glitchy? I find that when the audio is glitchy it tricks you into thinking the game itself is stuttering when it's actually running smoothly
But other than using the distance checking vs. 2D areas and built-in hit detection signals, I didn't do anything special for optimization
We also used simple distance checking to detect bullet collision, and we didn’t even have many bullets on screen at once, but still the Godot HTML5 export was a bit laggy and had audio stutter (it was more severe depending on the computer). We’ll take a look at the reddit thread you linked, it brings up some interesting things to try, thanks for sharing!
Thank you for the reply. The distance checking might be important, I've only used simple collisions (Area2D on bullets and CollisionArea2Ds on the KinematicBodies that are the player and the enemies). Though I do wonder whether distance checking is actually more optimal, considering Godot's own collisions are probably optimized in a similar way.
I can't recall right now how it worked on itch. Playing the project from the editor into HTML5 works mostly fine, though it definitely has some FPS drops that I don't see in the Windows export version. I do remember that when uploaded on itch, it worked so much more terribly worse than how I had tested it locally that it just wasn't worth leaving it up since it would leave a bad impression of the game.
I don't think I hit even 1000 bullets at any point in the game right now, though the bullet deletion is definitely a very quickly put together hack with VisibilityNotifiers on the bullets + a bunch of rectangular collision boxes outside the play area just in case, so maybe there are times when bullets aren't getting deleted as quickly as they should; I should change that to be done manually as soon as they exit the visible area of the game.
I'll check those links and keep that info in mind for next time, thank you.