fgaaldal

Whatever happened to the popular 9front?

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.

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.

It is funny that just after I wrote this, I spotted another article on the frontpage: https://sourcegraph.com/blog/live/gophercon2015/123574706480

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.

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.

This is an interesting question and depends on your domain. However if we want to optimize "get stuff done across the most domains", I would go with:

Python: proof-of-concept, web-dev backend, scientific exploration

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

Haskell: expressive, performance (through-put), reliability

Scheme (e.g. Chicken): expressive, simplicity, explorative computing

Additionally one might consider Java (and later Clojure, which should be easier if you already know Scheme and Java) to interface with the JVM world.