Making a Game with Go: Interlude
In this short post you can read about why I switched from raylib-go to Pixel for this tutorial series. If you don't mind you can safely skip this issue. Did I fall into the trap of needlessly starting over with another library instead of sticking to what I have? I think I made the right choice after reconsidering my requirements.
Why ditch raylib-go?
First let me say that I still think raylib is a great library. And if you write your game in C/C++ I still recommend it very much. But I want to write my game in Go and therefore have to use bindings. It's great that someone provides these bindings and they seem to be good quality code. However certain problems arise from the fact that raylib is C first.
API changes
raylib moves pretty fast and its API has not really settled. That means there is a lot of work for the maintainer of the bindings to keep up with those changes and thus the bindings are rarely up-to-date with the newest updates.
Bugs & improvements
If you find a bug or want to improve on some functionality in raylib you can do that. But you have to do it in C first and then write the bindings in Go. That's a lot of work if you want to make a game at the same time.
I e.g. had the following problem with raylib.
If you look at the movement of the planets you will recognize that it is a little jumpy. That comes from the fact that internally raylib casted floats to ints before drawing a sprite. I opened an issue about it and it was resolved pretty quickly. However when it is updated in the Go bindings is unknown.
Feels like C
This one is a little subjective but you can still smell the C in the Go bindings. For example all of raylib's floats are translated with float32. This is very cumbersome because most parts of Go's standard library expect float64 and you just have to cast values everywhere.
Why Pixel?
Last time I wrote that Pixel was a little to beta-ish and doesn't support mobile and web targets. Now I was right about the targets but to be honest for this project I don't really need them. And after re-evaluation of its capabilities and the code and submitting a pull request to Pixel I think I was a little wrong about the beta-ish. It's well thought out and seems solid so far.
Contributing something to the library was also a very smooth experience. And even if I want features that will not go into the official library I still can use them in my private fork.
Conclusion
In the end it's all about how easy it is for me to change things in the library. Therefore a library that is primarily written in / for Go is just a better choice. Ideally it should build on top of GLFW or SDL. They both are mature and have solid Go bindings.
I will give raylib another shot when the API has settled, maybe with the next major release.
If you want to see how far the game got before I stopped have a look here. This project will now be discontinued and Gonk will take its place. More on that in the next issue.
I already had written a large chunk of part 1 but rewriting it for Pixel should be pretty straightforward, so it shouldn't take to long for the first real tutorial issue. See you soon.