Hello! The game freezes (no pun intended lol) if we walk for too much time. I suppose that it can be an issue with how you instantiate your audio player node, it looks like you're instantiating dozens of nodes and adding them each frame.
Viewing post in Robin "Xmas" Sweaters jam comments
How odd! I never encountered such problems during development, nor has any of my friends playtesting it. Not even my profiler flaired up when I’ve been moving for a while. If anything, physics calculations take up more CPU time than AudioStreamPlayers. What device are you using? Which browser? I’d be willing to get to the bottom of this if you have the time, since I can’t reproduce your problem myself. I’d at least be learning something about godot!
I’ve now narrowed down the problem to just one line of code! The audio stream player instantiations are not the problem, it’s the way I check for knights hearing footsteps. When walking for a while, there will be many footsteps in the scene at once, and they each have their own range in which they can be heard by knights. There’s 30 knights in the scene, and when walking for a while, probably upwards of 100 footsteps. Each knight checks every footstep for overlapping hearing range (except when one is found to overlap), which might be too many checks per frame on some browsers. I’m not quite sure what my lesson learned is here, since I playtested with some of my friends, my not the ones that ended up being able to reproduce this issue.
Oh, I see! Just throwing it out there but "Each knight checks every footstep for overlapping hearing range" seems weird to me, in a technical way. Are you using Area2D for this? Maybe this is what you have already, ignore if it is the case but I would try to have something like:
- Knights have an Area2D that only checks footstep's Area2Ds (selecting only the knight's mask layer)
- Footsteps have an Area2D that only checks for Knight's Area2D (selecting only footstep's mask layer) (if you really need to, check the item below)
- Footsteps don't need to check for Knights, so you can disable the "Monitoring" and keep only "Monitorable" for the Footstep's Area2D
- Knights are the ones who should check if they are overlapping with a Footstep's Area2D, so you can maybe disable "Monitorable" for it
If the knights are meant to chase you when they hear a footstep within their ranges, you could only call it one time when the Knight/$Area2D.area_entered signal is emitted.
Again, you can totally ignore this thought, I don't know exactly about your internal rules so it may not make sense, just wanted to share if it can help you in any case.
Nope! Works a lot simpler than that. No signals, no overlapping Area2Ds. A knight will find the distance to a footstep, and check if the distance is greater or not greater than the radius in which a footstep can be heard. I have an Area2D on the footstep but its only used to visually store the radius in a way I can play around with in editor. The Area2D has no collision layers or masks it listens to. I expect this calculation is a lot cheaper than 2 overlapping polygons (even if rectangle and circle are faily simple), but I suppose 30 knights * how ever many footsteps you can make in 15 seconds, is just too much for some browsers to handle. Once the Game Jam is over, my GF has pointed out to me it would be a lot better if its not the footsteps the knights will compare to, but just the player character himself (as long as he’s making footprints). Footprints should remain visual only