Why I Write Games in C

So, I believe it might be interesting to do something of a thought experiment, and imagine that C itself is just the language; and for a moment, imagine that it does have some modern standard library; only its modules are unfortunately somewhat scattered over "teh Internets", but probably just a quick googling away. And to see what comes out of that, and how "modern" one could actually make it feel.

Please bear in mind I'm not up to date with modern C. But this thread reminded me of some stuff I've glanced over here or there at some point, and made me wonder. Personally, I believe the result would not reach 100% high-level-ness of Go or the likes, but I have a feeling it might come uncomfortably near...

Dropbox is using Rust in production? Great news! But I'll wait when a thousand of organizations use Rust in production before advocating its use in my own organization. Also, judging by this comment: https://www.reddit.com/r/programming/comments/3w8dgn/announc... they had incredible rapport with the language core team. That is a luxury not every team using Rust is going to have.

Still, great news. I guess I must implement some kind of little personal project in Rust and in the process help iron out a few more quirks.

It is very frustrating to deal with bugs introduced by others, a product or engine changes that you aren't aware of. But you have to balance that with how much you can get done in your own engine/tech with the time wasted from bugs, and how much time you want to spend on tech vs games.

For 2D games, building your engine is probably doable with lots of small kits like physics libs (box2D, bullet, etc), libgdx, sdl etc but for 3D games and certain titles, a single person working on an engine is difficult, tons of work on the tech side. So the balance is key, whatever makes you able to ship more often is probably the best choice.

Unity is used by many people and does have very frustrating releases that aren't solid many times. Recently 5.3, 5.3.1 [1] all have issues. For a long time in 2015 the IL2CPP iOS versions were broken. But doing it alone you get caught in a tech swamp instead of making games if you aren't careful and limiting. There will be times where your engine product or team or yourself is wading tech changes that are needed and take time away from game making. During the period of IL2CPP and Unity bugs, games could still be developed in parallel and for other platforms, so this is a benefit even though there are bugs.

Even when we do engine or platform based games it is a good idea to keep it as platform agnostic as possible. In Unity this might be keeping all source assets, using less MonoBehaviours, storing/loading data in JSON/web formats rather than in serialize prefabs. Anything that locks your game into one engine too much one should be careful of to limit your surface area of exposure to bugs by the engine. For a long time other UI libraries ruled Unity before they made their new UI, it is still a bit buggy but better. For a long time Mecanim was not very solid and many still use legacy animation. The newer Shuriken particle systems are awesome but not as accessible in code and had scale limitations for a long time. You just have to see where areas are solid and not venture into areas prone to bugs in your own engines or existing engine platforms for shipping games like Unity/Unreal etc.

[1] http://forum.unity3d.com/threads/unity-5-3-1f1-particle-syst...

I think this is one of the biggest disadvantage of a mostly standards based, no particular organization in charge type of language like C, as opposed to, say, python.

I am fortunate that, at the moment, my needs are mostly casual and very rarely performance focused. If I needed C I would just STFU and use C, accumulating my own workarounds for the dispersed nature of its resources.