Post by Colin EUMP in The Long Hole comments

Viewing post in The Long Hole comments

The x button at the top of the window doesn't work. I would recommend learning how to fix that if you use RayLib again. The "basic window" example on the site shows a way to do it, though I don't know if there's any complications that would come up in an actual game.

For the game itself, the movement is good and the difference between obstacle and good thing is clear. I would recommend trying to have more contrast between background and obstacles though. Also, if you design a game that goes on forever, it's a good idea to include some quick mechanism for increasing difficulty. For example, in this case having the obstacles spawn more often if the player has a higher score would've worked.

CleverCrumbish3 years ago (1 edit)

Hi Colin!

All good suggestions, though I'm afraid in each case the reason for the problem is "I ran out of time in the jam".

The X button not working was actually a deliberate call I made based on what I have to presume is a bug in raylib. The "WindowShouldClose()" function in the basic window example on the site is actually in the game code, but captures the escape key without ever passing it to developer code and uses it to quit the application. There is a function you can use to remap or disable this behaviour, but (unexpectedly and I think incorrectly) it also disables WSC()'s ability to capture the X button. If, as in my case, you don't have time remaining to reimplement WSC()'s X button behaviour from scratch, you must then make a decision as to whether it is more problematic for the close button not to work or for a single no-feedback keypress to terminate the entire program. I chose the latter, but I agree it isn't ideal.

I agree that having a mechanism for increasing difficulty would be good, and I even considered the one you suggest during the jam, however it would require the way the game spawns obstacles and collectables to be completely reworked - currently, each 32px row can only have one item (wall or DBloon) on it - this is to prevent object generation having to take into account where other objects spawning at the same time are, but also more importantly to prevent the game generating a scenario where progression is completely blocked off by obstacles (technically this can still happen, but the chances of it happening, at least at game start, are (0.0125^24)%, which I considered acceptable odds). I could do this, but not in the time allotted, as it would require a more complex system for managing row spawns, and one that would probably need to be abstracted into a game state structure of the kind I spent the entire day on Wednesday implementing before ripping it out on Thursday morning when I realised I wouldn't be able to fix the circular inheritance issues it introduced in time.

In theory you could keep the current system by simply changing the probabilities of each encountered object on a row as the game progresses, but this would cause a weird difficulty deceleration behaviour if, as you suggest, progression were tied to score, as DBloons spawned less often. In that case I would probably tie it instead to total distance fallen.

Ultimately I don't think I will be returning to this project. Most of my associations with it are frustration and lack of sleep, and I don't think it's anywhere near as strong an offering as my game from last year. I have thought about rewriting that game in raylib or another C++ library, however, so I will take your criticisms on board for that potential project.

Colin EUMP3 years ago

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)"?

CleverCrumbish3 years ago

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.

CleverCrumbish3 years ago

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

itch.io

Viewing post in The Long Hole comments