Not the author, but I've implemented my own snake game and this bug is fairly easy to kill.
(1) - You can only change directions that will change your axis, if you're going left your possible changes are up and down, ....
(2) - You should be only able to consume one direction change per game tick, what is happening here is that rule (1) is working but you can change into the other axis, and then back to the other axis again before the game loop computes another frame. Direction change can be read asynchronously but the actual change should be tied by each tick.
I attended a two day Elm workshop a while back. There is a lot there to love, I just think it's Haskell inspired syntax is a major impediment to it's mainstream adoption. I however would love to be proven wrong as the webs reliability would be so remarkably improved.
Here's a challenge for you: what syntax would be better? I don't mean that in a derogatory way. I think you are right that the syntax (being very foreign to people) does provide an impediment, but puzzling out how to implement the same functionality with a more familiar syntax would be extremely difficult (though potentially very fun).
Elm has been personally an inspiration too. Nice set of decisions and tradeoffs for what they're trying to achieve, though yeah, mainstream syntax might not be one of them, but that's fine.
pgt|8 years ago
It would be fun to implement WebGL as a renderer.
DrPhish|8 years ago
Here is a snake in 4k (sn4ke) mapped onto a sphere instead of a 2d playsurface, which is one of my favourites. http://www.pouet.net/prod.php?which=61035 Here is an awesome music-driven one that modifies the songs based on level and "danger" http://www.pouet.net/prod.php?which=57518
But the best snake ever was the one from FastTracker 2 by Triton! http://www.pouet.net/prod.php?which=13350
dyarosla|8 years ago
Similar bug with RIGHT->DOWN->LEFT
And so on for all the other initial directions.
fb03|8 years ago
(1) - You can only change directions that will change your axis, if you're going left your possible changes are up and down, ....
(2) - You should be only able to consume one direction change per game tick, what is happening here is that rule (1) is working but you can change into the other axis, and then back to the other axis again before the game loop computes another frame. Direction change can be read asynchronously but the actual change should be tied by each tick.
KurtMueller|8 years ago
fareesh|8 years ago
Kiro|8 years ago
kornish|8 years ago
http://package.elm-lang.org/packages/elm-lang/html/latest/Ht...
donatj|8 years ago
mikekchar|8 years ago
chenglou|8 years ago
Elm has been personally an inspiration too. Nice set of decisions and tradeoffs for what they're trying to achieve, though yeah, mainstream syntax might not be one of them, but that's fine.
KurtMueller|8 years ago
lolc|8 years ago