Snake game made in Go
github.com
github.com
- does timers
- does sleeping and/or threads
- handles user input
- gets some kind of output to screen
- provides basic data structures
- writes and loads files for high scores
- There is a delay right before you hit the wall.
If you are playing at the fastest speed and barrel towards the wall,
it slows down to the slowest speed when you are on the final square
before game over.
I always loved this because the it made the most deadly obstacle the
snake body which is the one that you yourself created.
- When it polled input it stored one of each press.
If you pressed up then left, and the next tick the snake would turn
up, and the next tick the snake would turn left.
- There are only four parts of the screen max that are updated each
tick, the new snake head is drawn, the previous snake head is drawn as
a body, the previous snake butt is cleared, and maybe a new egg is
drawn.
Very common to see a snake game draw the entire screen, or redraw the
entire snake on each tick. Super frustrating to have a game get start
to stutter more and more as your snake gets longer.
- You could play using two buttons instead of four.
The game could be played by using buttons 2=up 8=down 4=left 6=right.
But it could also be played using buttons 1=up-or-left and
9=down-or-right because you can only change from your current
direction to two other directions since you can't have a button to go
the opposite direction, and you don't need a button to go the same
direction.
It was never super intuitive though, a "right turn" or "left turn"
button would make more sense.
The problem i have with the snake is that one cell in a termloop is not a square but a rectangle. for example a cell could be 1 width and 2 height, so if the snake would move 1 cell up, it would actually move 2 up.
Also, I always wondered what it would be like if you mixed a snake game with Conway's Game of Life. Watching a snake go around the screen blasting through automata would be interesting ( or maybe not).
Like what would your 50th project be, ideally?
Also made something similar, although with much less features and in a single file: http://github.com/hoffa/snake
I am currently evaluating 2 tiny frameworks; ebiten and oak. Oak is super interesting as it doent uses sdl/glfw etc in its core. But has a rougher api. Ebiten on the other hand feels very frinctionless.
Oops.
And frustrated that I'm not hearing anything from Golang programmers about how it enables a larger class of software.
"We're writing the same software, just better" isn't a reason to come up with a new language.
If you thought using a new language would give you better runtime character, you were wrong. Languages are transpiled and cross-compiled on the reg, and it really makes no difference to the runtime what language you used to get your bytecodez into the scheduler.
Newcomers don't need connectors anyway, they need the room to experiment with syntax and such, get their head around ASCII symbols. It's great, good luck.
In my teens I wrote Snake and Dig-Dug and Chinese Checkers and whatnot. I was learning to write anything at all. But twenty years on, distributed systems are applications. Writing Golang as though it changes the paradigm is fucking silly. But learn however you want to learn.
Newbies of every stripe are encouraged to think that language is the entry point for software development, but it's a teaching moment that most teachers fail. The language is not important.
The runtime is important.
Define better.
Also, Go isn't really an all purpose programming language. It's application is fairly specific even if it's something a lot of people would use. It's good for fast, simple concurrent applications especially for web related projects. Bonus points for easy binary distribution. Microservices are a big deal, and golang is really well suited to build one.
On the other hand, it's never going to be the cool kid on the block like python where there are a tonne of clever libraries that are a lot slower but easier to build with.
I think that you're underestimating Go and its community. The static type system of Go allows to catch many errors while Python has to rely on unit tests to even catch typos in variable names.
Building Go libraries and distributing them is much easier than Python/JavaScript/Perl/Ruby/Java/R now that Go has modules...
The go community is part of the problem. And I mean that in a good way. So much of golang is about writing your own code. Like if you want a web framework, a lot of people will tel you to just write bare metal code. And it works. It's refreshing to have a simple language without all the crud. It's a wonderful feeling. Which is why people fight tooth and nail against any slightest bit of additional complexity in the language. Complexity that's sometimes needed to make it easier to write code fast.
There are so many options for statically typed languages that for low level projects, it's not worth it for go to try to get into that race.