Just mix C and C++ like a regular horrible person would do. An entire game in C sounds....tedious.
Why I Write Games in C
101–110 of 303 posts
Re: Why I Write Games in C
#102Re: Why I Write Games in C
#103You don't really get rid of complexity by using a simple language. You just move the complexity into your own code. Say if your language doesn't have dynamically sized containers, you will end up writing your own. You hack it so you can store different types in it. You have reinvented polymorphism. And then you need sort functions, and everything else that is missing from the language. And it wont be simple any more.…
> their own private code framework that is too complicated for anyone else to make use of
Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. The real sadness is when you get corporate websites, technology platforms, and the like that decide they need their own framework to make their own set of tradeoffs, and do a mediocre job of it, and end up with a slow buggy bastardization with 15% of the capabilities of a common well-understood framework. If I had a dollar for every minute I wasted on something like that... it'd be an accurate description of a nontrivial portion of my career :b
Bonus points for making this framework to optimize performance, without actually measuring the performance or setting explicit goals.
Re: Why I Write Games in C
#104How about Nim? [1] [2] To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more. 1: http://nim-lang.org 2: https://github.com/nim-lang/nim 3: http://nim-lang.org/docs/gc.html#realtime-support
Hi dom96,
I am a Nim fan too, but I doubt that Nim would fulfill the requirements of the author of this article.
At the very beginning of his post, the author says, "[the language] has to be reliable. I can't afford to spend my time dealing with bugs I didn't cause myself." One of the main reasons why I abandoned Nim after having used it more or less regularly for a couple of years is that so many things are still changing, and that compiler bugs pop too often. With every new Nim release I have got unexpected problems in recompiling my codes. This is the main reason why, despite still being a Nim lover, I have stopped using it for my projects. AFAIK, there is still no idea when Nim 1.0 will be released; there have been some optimistic announcements of its being imminent, but so far none of them has lead to such a release.
Later in the blogpost, the author adds another requirement: I do not want to spend my time porting old games to new platforms, I want to make new games. I need a platform that I am confident will be around for a while. Honestly, I think nobody can be sure where Nim will be a couple of years from now. There is practically just one coder (Araq) which understand the compiler internals, and by his own admission he suffers from a severe NIH syndrome which disperses Nim's scarce manpower. As an example, a tool so potentially useful as nimsuggest has been in a non working alpha stage for years because of the lack of people able to work on it (don't know if this is still true, though). IMO, this makes the future of Nim uncertain.
Don't misunderstand me, I still love the language and wish it can reach a state similar to Rust or Julia (which have a much larger and professional community of developers and are supported financially by a number of players). But I think that promoting it in this thread is a bit out of context: Nim is good when you want to toy with a nice language which gets so many things right (macros!), not when your primary objective is to have some language that just works and can be trusted in the mid-to-long term.
Re: Why I Write Games in C
#105>Even more than that I care about the speed of the compiler. I am not a zen master of focus, and waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone.
Quick suggestion, has really helped me: take that 10 or 20 seconds waiting for compilation, and stare out a window. This gives your eyes much needed break from focusing on a computer monitor, allows the muscles to refocus and breathe, and doing this regularly during a coding session can have important long-term benefits for your vision.
Re: Why I Write Games in C
#106You don't really get rid of complexity by using a simple language. You just move the complexity into your own code. Say if your language doesn't have dynamically sized containers, you will end up writing your own. You hack it so you can store different types in it. You have reinvented polymorphism. And then you need sort functions, and everything else that is missing from the language. And it wont be simple any more.…
I don't disagree with the spirit of your comment, only the primary example.
Most of the dynamically-sized containers I end up needing are one of vector, map, set, or list. For the latter three, there's and on most BSDs which provide intrusive macro-based implementations. Sure, they're a bit more clunky to use than e.g., std::map, but I'm neither concerned with their speed nor their reliability (insofar as their implementation).
Naturally, when you need to reach for a less-common data structure (e.g., a bloom filter or B+ tree) you'll have to look elsewhere, but feels like the same situation as if you were using C++'s STL.
Re: Why I Write Games in C
#107I understand the want for simplicity in C (and Go gets closer, but has its issues), however, it seems in the end it drags you down. Just having the C++ ability to have objects doing things is very helpful. But yeah, C++ has the ability to get very complicated But it's your choice to have "complicated C++". Limit yourself to some functionalities and it's much more manageable. Use basic STL and keep it simple (also C++…
There are some arguments to stick with C instead of a very C-like subset of C++. Off the top of my head: - Recompiling and reloading parts of your game at run-time is quite easy in C. In C++ you have to make sure (at least) that nobody has pointers to vtables of the dll at the time of reload. This can be a bit tricky if you're using things like std::function in your dll code. Yes, you could be using a scripting langu…
>Recompiling and reloading parts of your game at run-time is quite easy in C.
This is cool to hear. I've never done anything like this, but it almost sounds like REPL-driven development is a possibility in C?
Re: Why I Write Games in C
#108I understand the want for simplicity in C (and Go gets closer, but has its issues), however, it seems in the end it drags you down. Just having the C++ ability to have objects doing things is very helpful. But yeah, C++ has the ability to get very complicated But it's your choice to have "complicated C++". Limit yourself to some functionalities and it's much more manageable. Use basic STL and keep it simple (also C++…
I think that's what most engine developers do nowadays. Sticking to some part of C++ to a point that it looks like C with classes. Hey, some don't even use STL and go with their own libraries.
I've seen Justin Frankel write that he works this way, and it has most certainly served him very very well.
Re: Why I Write Games in C
#109How about Nim? [1] [2] To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more. 1: http://nim-lang.org 2: https://github.com/nim-lang/nim 3: http://nim-lang.org/docs/gc.html#realtime-support
If Nim compiles down to C and then you compile/link that.. How in the hell do you debug that?
Re: Why I Write Games in C
#110I wanted to program my game in C but then I took notice of how incredibly comfortable things like Vector and Map are. I never look back again. C is for plain libraries and OS where compatibility and performance are of utmost importance.