The Long Hole
A downloadable game
Long have you, a yellow-cloaked person, heard the tales of the mythical 'Long Hole' out in the desert, and its treasure of silver DBloons! You travel out into the dirt on a creaking, left-swerving bus devoid of other passengers. It seems an eternity before the bus finally stops and the doors open. You eagerly step out, and that is when you discover (to your dismay) that the Long Hole is right under the bus stop, just under your feet as you stepped off! The wind whistles past your head as you plummet down the hole.
In the event that you survive the fall, you think, you will have a very large hospital bill. Better collect the silver DBloons on the way down, to pay for your expenses! Twist and turn yourself in the air to collect the DBloons and avoid the protruding blocks. How long can you survive falling down... The Long Hole?
Made in under a week for the Desert Bus 2021 Game Jam, as an experiment in making a game in C++ using Raylib, and deliberately mishearing the game jam prompt "long haul".
Controls
Left and Right arrow keys - Navigate (Menus); Turn in the air (In-game). The more horizontal you are, the slower you fall.
Spacebar - Start game (Main Menu); Return to menu (From game over screen).
Escape - Exit to menu (In-game); Exit to desktop (Menus).
Download
Install instructions
Download and extract the zip file somewhere, then run TheLongHole.exe.
Development log
- The Long Hole 1.1Nov 26, 2021
Comments
Log in with itch.io to leave a comment.
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.
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.
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.