It would be nice to see some examples, otherwise this is "yet another game engine that will be deprecated in 1 year". I consider this very important as games are so different that it is hard to find common parts to put into a library that are not trivial and could be reimplemented. In particular have at least 3 slightly involved examples, otherwise it is unclear what one would gain over simply using SDL/OpenGL.
This goes also the other way. If I hack for fun, I often think about how to abstract stuff that is not specific to my current problem and put it into a library (I think we all have been there). Fact is, I often rush, so my abstraction only works for the current situation and so does not belong into a library. Until I did not reimplement the stuff at least 3 times I try to avoid making a library.
Yes, and so few people write actual games, just game engines.
My game is pretty crappy but I overcame a bunch of (mostly boring) technical issues to get it running on both Android and iOS. Here is a repo that sets up an Android development environment.
Obviously it depends on the game. However if you do not plan to make a straight-forward game or do not have to be fast, I highly recommend the combination SDL2 + OpenGL. It just works.
- you find tons of documentation
- you will run anywhere (that is obviously not trivial)
In particular if you are going 2D you can skip OpenGL if speed is not a problem (yet).
You then just write a small C-kernel which provides the main functionality and explore Haskell's FFI.
Why the down-votes, I think this is a valid point. In case of real-time, e.g. video games, you want to render every ~15ms and doing that with a GC is really NOT trivial. I do not say, GC-languages perform bad, they actually are great for throughput, but doing low-latency stuff is still hard.
The new GC reduces pauses to the single-digit milliseconds. Rendering every ~15ms seems reasonable under those constraints. Plus I don't think a game engine will typically put a lot of pressure on the garbage collector.
I don't think the new GC precludes Go from being suitable for writing games. On the contrary, I think it is now more suitable, and look forward to using Go for writing games myself.
So I admire their goal to reduce latency (it's probably a latency-throuhput tradeoff) and I always get told that real-time (which in my opinion requires low-latency) is possible in GC-languages, I just do not know how to do that reliable. But I hope I am wrong and it is possible to go real-time with a GC as it is often a prerequisite for high-level language features.
ISTR that producing a clean sign wave on a scope requires a real-time operating system, and it was one of the first tests for seeing if your real time linux patches worked.
C: performance (low-latency), system (interface to most kernels), game-dev
JavaScript: UIs
Remark that I would not consider these languages my personal favourites, but in fact, you do not have much choice. C is enforced as it is tight to *nix which is the most spread OS, JavaScript as it allows you to build cross-platform UI's (that do not require user-installation) and Python because of its huge library diversity (in particular in the applied sciences).
If you speak them sufficient you can tackle most problems. If you then want to go further I suggest
