If you are interested in gamedev and Golang, a while back I did a video series teaching programming via game projects in Go. Starts out with text games, then 2d, then some opengl 3d stuff at the end. Jump in wherever you like! All free.
Snake games are my go-to when I learn new languages, it's always under 1000
lines of code and can usually be done without libraries. In not a lot of
time you can learn how the language:
- 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 are a lot of things that I like about the original Snake that most
people don't put into their hobby projects:
- 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 only critique I have for this is your snake almost doubles speed when
you move up or down which is pretty jarring.
thank you for the very detailed and useful reply! i will definitely think about adding some, if not most of your suggestions.
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).
http://www.asahi-net.or.jp/~cs8k-cyu/flash/la2/index.html. LA-2 is close to what you're describing although it's a shmup instead of a snake game. It's old so unfortunately it's a Java applet that might be hard to run now :(. Google has been very successful in killing all old interactive content on the web.
I am actually trying to get my project out there, as this is actually my first big project.So every star would be appreciated(maybe we can even reach trending)
This is a bit off topic but since there might be some Go folks in here, does anyone know of a Go equivalent of WebGoat (an intentionally insecure code base for testing vulnerability scanners)? Doesn't need to be a WebGoat clone, just an insecure code base written in Go.
Quick question;
Whats been the performance like, specially with Go's GC. I know snake is probably not a project to push the language run time to its limit but still would love someone to chime in. I may be wrong here but i assume that GO's GC is more geared towards concurrent data access tasks like web servers.
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.
Congratulations! It may not seem like a big accomplishment, but it is. It's one thing to toy around with a language, but creating a fully realized product is a big deal. There's nothing that compares to that feeling when you load up your project and it just works as you expect it should. You should definitely walk around the next few days with a big grin on your face :).
I have an idea: there are a couple of these already, pretty fun to play. There could be a service, in which you can SSH into then play these games! with scoreboards, forum, discoverability and stuff. It would be a pretty niche product/service, but would be fun to build and play!
It could be the steam of modern terminal games :D
> "We're writing the same software, just better" isn't a reason to come up with a new language.
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.
> 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...
> I think that you're underestimating Go and its community.
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.
It's a great reason to write a new runtime. JVM is still okay.
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.
It really feels as though someone has done career JVM professionals a huge favor, sending all the upcomers to Python and PHP and Golang. Let them learn in their sandboxes, right?
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.
Nobody writes C# except for the sake of fitting into the .NET ecosystem. Java is the original dorky reference-oriented language with underlying bytecode, and after 20 years of runtime optimization it's still the best.
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.
https://gameswithgo.org/