Snake in Elm with WebGL(github.com)
github.com
Snake in Elm with WebGL
https://github.com/tibastral/elm-snake
5 comments
I'm going to make this the "Other awesome snake implementations" sub-conversation
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
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
Bug: Create snake of length two. Move RIGHT. Quickly press UP LEFT in quick succession. Lose.
Similar bug with RIGHT->DOWN->LEFT
And so on for all the other initial directions.
Similar bug with RIGHT->DOWN->LEFT
And so on for all the other initial directions.
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.
(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.
Maybe it makes it too easy, but I would enjoy the mechanic that quickly pressing UP LEFT when moving right would make the snake head move one square up then turn left and continue left. I suppose that would require some special casing, and you wouldn't want to support longer queued direction changes. Maybe a nice implementation would be that for inputs queued within a single game tick, execute the first input for one square of movement, then the last input for the next tick.
Yeah happened to me too, thought it was my mistake but now I blame the bug :D
How is the actual game loop executed? I don't know Elm but I only find update, not how it's run.
The function `Html.program`, in `main`, takes an update function which handles (among other things) ticking the game loop.
http://package.elm-lang.org/packages/elm-lang/html/latest/Ht...
http://package.elm-lang.org/packages/elm-lang/html/latest/Ht...
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).
Redux follows the same pattern with your more "familiar" syntax.
Typed functional programming offers wins that forces more safety and modularity onto the code. These are all long term wins. Ultimately I would argue that elm's syntax is better suited for extremely complex projects that have low tolerance for bugs.
Typed functional programming offers wins that forces more safety and modularity onto the code. These are all long term wins. Ultimately I would argue that elm's syntax is better suited for extremely complex projects that have low tolerance for bugs.
Redux is a javascript library. It shares some idioms with correct Elm code, but is a very different beast.
Right but the underlying design pattern is the same. This is all I'm saying. Redux can almost be thought of as an Elm pattern implementation with "familiar" imperative syntax.
Well, something like C-like, for maximum familiarity.
What functionality is difficult to render in C-like syntax?
What functionality is difficult to render in C-like syntax?
Currying
I can get the same effect as currying with C syntax by deliberating invoking a special function:
functools.partial(old_function, my_new_argument)
You can do it in Python as you have, but it becomes second nature with Haskell (I can't speak to Elm directly). You might not even realize you're doing it.
Add 5 to each num in a list (using a pretend function called `add` in both languages to be fair):
Add 5 to each num in a list (using a pretend function called `add` in both languages to be fair):
map(functools.partial(add, 5), nums)
map (add 5) nums
map(functools.partial(map, functools.partial(add, 5)), nums)
map (map (add 5)) numsI suppose it would make more sense to write these as lambdas in a c style syntax
nums.map(|sublist| sublist.map(|num| add(num, 5))
Sorry, but there is nothing more explicit about using lambdas as you have done, it's simply redundant (notice the repetition of sublist and num arguments).
Yes
[deleted]
I work on Reason, which is something you might like: http://facebook.github.io/reason/
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.
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.
sorry, what are these decisions and tradeoffs? why not just use ocaml(for anyone who doesn't mind not C-like syntax)?
Imho, Elm's syntax is more akin to OCaml than to Haskell. Besides OCaml, it reminds me a lot of F#.
Or any other strict language in ML family like SML. Still it tells something about language popularity when is Elm is only compared with Haskell.
Cool demo. And I learn there was an Elm conference close to where I live and I missed it.
It would be fun to implement WebGL as a renderer.