I'm a bit late, but I hope you'll see this comment....
When I saw you used ClojureScript and Quil, it inspired me to make my own game for Spring Lisp Game Jam 2024.
I took a look at your code, and there are some nice concepts I didn't know before, e.g. using multimethods for handling different screens — I'll be using them too.
----
Since you seem experienced with Quil, maybe you can help me with the problem I'm having, and it is a situation you didn't have in your own game. Is it possible to register multiple key-presses with one long press-and-hold of a key? Currently no matter how long I hold some key, it is the same as a single short press.
Hello, it's great to see I've inspired a game! I'm not super experienced with Quil, but I think I can help - I don't think Quil has the exact functionality you're looking for, but you can still make it work. For your use-case, I'd change the keypress function to modify the game state to record that the key is pressed, and add a key-released function to record that it is no longer pressed, and do the check-and-move code inside the game's update function using the info recorded in the game state. Does that make sense? Good luck with the game jam, and feel free to ask if you have any more questions!
Edit: actually if you only need the most recently pressed key, you could probably ignore the stuff I said about recording key presses in the state and just use q/key-pressed? and q/key-as-keyword inside the update function instead of inside the key-pressed function.
Thanks for the idea about "q/key-pressed? and q/key-as-keyword inside the update function" — I've just tried it and I can make it work!
The only problem I need to work-around is the frame rate. If the frame rate is too high (and even 30 fps is), then even a short key press will be counted multiple times. On the other hand, if the frame rate is too low (and even 10 fps can be), then a (very) short key press will not be recognized at all.
Quil doesn't give you very much of this out-of-the-box, it's up to you to find a way to make your player move how you want them to move. For example, I made a player that moves quite jerkily here, with some "long key press" functionality similar to how you were looking for: http://www.quil.info/sketches/show/926b90ca28f03e9511165d337bb7ed6089f07381d1264.... I did this by adding a :last-move-time key into the state to prevent it from moving after it has just moved, so you don't need to mess around with frame rate. I also added the moving functionality into both update and key-press functions, just in case a key press was very very short and didn't get picked up by the update function.
Or you could look at my sliding puzzle code to get some ideas about how to animate the motion - I add a key into the :animations map in the state, then draw piece positions using lerp (linear interpolation) and the current time to get the current position. I remove finished animations in the update function.
This was a very fun game. It even got me thinking about the math behind the solutions, but I didn't get too far, I don't know if there is a solution other than brute force (which can be reduced a bit by symmetries).
You could also introduce fixed obstacles (or just more balls), or dynamic obstacles that change state as balls move. I think it's hard to come up with good maps, you may want to write a computational tool that tries to solve the map for you so that you can find maps that have nice solutions. Are you interested in something like that to extend the game further?
Thanks for playing! That's an interesting thought - I feel like a non-brute-force algorithm is possible, and I have the outline of an aglorithm in my head (for the "get 1 of the 3 pieces into a given position" problem), but it has too many corner cases...
I like your map ideas, and I might take it further!
← Return to game
Comments
Log in with itch.io to leave a comment.
I'm a bit late, but I hope you'll see this comment....
When I saw you used ClojureScript and Quil, it inspired me to make my own game for Spring Lisp Game Jam 2024.
I took a look at your code, and there are some nice concepts I didn't know before, e.g. using multimethods for handling different screens — I'll be using them too.
----
Since you seem experienced with Quil, maybe you can help me with the problem I'm having, and it is a situation you didn't have in your own game. Is it possible to register multiple key-presses with one long press-and-hold of a key? Currently no matter how long I hold some key, it is the same as a single short press.
Here I tried to explain it in a bit more detail: https://github.com/quil/quil/issues/413
Thank you in advance!
Hello, it's great to see I've inspired a game! I'm not super experienced with Quil, but I think I can help - I don't think Quil has the exact functionality you're looking for, but you can still make it work. For your use-case, I'd change the keypress function to modify the game state to record that the key is pressed, and add a key-released function to record that it is no longer pressed, and do the check-and-move code inside the game's update function using the info recorded in the game state. Does that make sense? Good luck with the game jam, and feel free to ask if you have any more questions!
Edit: actually if you only need the most recently pressed key, you could probably ignore the stuff I said about recording key presses in the state and just use q/key-pressed? and q/key-as-keyword inside the update function instead of inside the key-pressed function.
Thanks for the idea about "q/key-pressed? and q/key-as-keyword inside the update function" — I've just tried it and I can make it work!
The only problem I need to work-around is the frame rate. If the frame rate is too high (and even 30 fps is), then even a short key press will be counted multiple times. On the other hand, if the frame rate is too low (and even 10 fps can be), then a (very) short key press will not be recognized at all.
Quil doesn't give you very much of this out-of-the-box, it's up to you to find a way to make your player move how you want them to move. For example, I made a player that moves quite jerkily here, with some "long key press" functionality similar to how you were looking for: http://www.quil.info/sketches/show/926b90ca28f03e9511165d337bb7ed6089f07381d1264.... I did this by adding a :last-move-time key into the state to prevent it from moving after it has just moved, so you don't need to mess around with frame rate. I also added the moving functionality into both update and key-press functions, just in case a key press was very very short and didn't get picked up by the update function.
Or you could look at my sliding puzzle code to get some ideas about how to animate the motion - I add a key into the :animations map in the state, then draw piece positions using lerp (linear interpolation) and the current time to get the current position. I remove finished animations in the update function.
This was a very fun game. It even got me thinking about the math behind the solutions, but I didn't get too far, I don't know if there is a solution other than brute force (which can be reduced a bit by symmetries).
You could also introduce fixed obstacles (or just more balls), or dynamic obstacles that change state as balls move. I think it's hard to come up with good maps, you may want to write a computational tool that tries to solve the map for you so that you can find maps that have nice solutions. Are you interested in something like that to extend the game further?
Thanks for playing! That's an interesting thought - I feel like a non-brute-force algorithm is possible, and I have the outline of an aglorithm in my head (for the "get 1 of the 3 pieces into a given position" problem), but it has too many corner cases...
I like your map ideas, and I might take it further!