Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Sigh. I've been aware about games uses escape as quit for a while but that's the first engine I've seen make it mandatory. For me that'd be a deal-breaker right there just by what it says about the paradigms being used. You made the right call. That said, wouldn't it work to just change the condition from "WindowShouldClose()" to "WindowShouldClose && !IsKeyPressed(KEY_ESCAPE)"?

In theory? I don't think you could use it as a while loop condition the way it is by default because I had other problems in this project that suggest key capture granularity isn't that specific and would fail to have the intended effect, especially in long game loops, but there should be a way of doing it. Maybe you could do it with a boolean that checks if the escape key is currently held down and blocks a surrogate variable that a conditional checking WindowShouldClose() would otherwise set... To be honest, it may be another problem in my own code causing this, since the raylib devs' recommended examples on github issues specify unbinding Escape with SetExitKey(0) the way I've done with no further loss of functionality.

I might actually muck around and try fixing this problem specifically, because you've made it intrigue me and obviously any future raylib projects would have the same problem. I'll see what can be done.

Fixed it! Not Raylib's fault at all, my weird game loop structure was to blame. Update incoming.