30 ms·

Why I Write Games in C (yes, C)

• adamnemecek 7y ago
  > "C is dangerous, but it is reliable. A very sharp knife that can cut fingers as well as veg, but so simple it's not too hard to learn to use it carefully." Cliche analogy.
• zabzonk 7y ago
  Write C code. Compile with C++ compiler. Catch lots of bugs at compile time.
  • xamuel 7y ago
    Or even better, compile with a C compiler with proper flags set (like -Wall). Catch lots of bugs and also enjoy blazing fast compile time!
    • zabzonk 7y ago
      Compilation speed for C++ is a function of the complexity of the code being compiled (particularly templates), otherwise a C++ compiler will typically compile C code (if it is compilable) at the same speed as a C compiler.
    • stevekemp 7y ago
      You'll probably find you're missing available warnings unless you add `-Wextra` too.
  • dkersten 7y ago
    Yeah use the few features that are beneficial, ignore the rest.
  • deleted 7y ago
    [deleted]
  • slacka 7y ago
    > Write C code. Compile with C++ compiler. What C only compiler were you thinking of? Most of the ones I can think of are toy compilers. If you're making a game, you're going to be using clang/MSVC/gcc. For catching bugs early, at least as important as the compiler are * Enabling additional compiler warnings and -Werror * Checking for memory leaks with valgrind * checking for Undefined Behavior with UBSan * Using mix of static code analysis tools such as Coverity, PVS-Studio, and the Clang Static Analyzer
    • ssalazar 7y ago
      All of those compiler families have separate C and C++ compilers. They’re saying to use g++ to compile your .c’s instead of gcc.
      • slacka 7y ago
        Assuming OP is correct, I learned something new today. I knew running g++ on .c would produce different results based on differences in the language like sizeof('x') and differences in extern. A quick google didn't turn up any differences between warnings between g++ and gcc. I'll have to look into this.
  • gray_-_wolf 7y ago
    C++ is not a superset of C. There is valid C code not compilable with C++ compiler.
    • kccqzy 7y ago
      The point is to eschew the use of C features not supported by C++ in order to catch bugs. Just read up on the incompatibilities deliberately introduced by the C++ committee and you'll likely agree that these are good things. Implicit conversions to void*? No thank you. Tentative definitions? I don't need that so give me an error.
      • gray_-_wolf 7y ago
        Yeah for example designated initializers. Such a useless feature... /s
• big_chungus 7y ago
  I get that this is not a popular opinion these days, but I like C. Quite a bit, actually. I can get stuff done reasonably quickly, don't have to futz around with multiple inheritance (C++) or where to call out to C anyway (python). There is so much more tooling behind C than Rust, or Go, or Zig (though I've been looking at Zig as a replacement). C isn't as bad as everyone makes it out to be, for personal stuff. I'd be a little more careful in group projects, but there's a reason it's still around. You do have to be careful and do a good design, but you should be doing a design anyway. Some day, C will be deposed. Something better will show up and gain traction. On that day, I will happily switch to the new better thing; but for now, C meets my requirements pretty well.
  • journalctl 7y ago
    It’s not unpopular to like C, and nobody ever said C is bad for personal stuff. Legitimate criticisms of a tool aren’t meant to be taken personally. I can say: “C happily lets you write off the end of arrays”, which is a valid concern, 100% true, and has no bearing on whether or not you should use the language.
  • non-entity 7y ago
    I didn't even realize C was so unpopular till recently. I kinda figured industry wise, C++ was much more common, but there seems to be a lot of stuff still written in C (i.e. many widely used kernels). I can understand was people would be apprehensive to C, but C++ just seems extremely bloated and I just haven't been able to get into it.
    • krapp 7y ago
      I can see the value in C, especially for API wrappers and such, but it's entirely possible to just use a minimal set of C++ and avoid bloat. Simple templates, a vector math library with operator overloads, function overloads and std::vector alone are most of what you'll probably want to use from C++. Maybe std::unordered_map as long as you preallocate space for it. It doesn't have to be hairy.
  • Keyframe 7y ago
• ChrisSD 7y ago
  So... essentially "I know and like C". Which is great! But as you say, that's not particularly useful for anybody else.
  • the_gipsy 7y ago
    The guy should try Rust and then explain why he prefers either, that would be interesting.
    • et2o 7y ago
      Interesting. I want to like rust but everytime I dive in it is getting more and more complicated and verbose.
      • sha666sum 7y ago
        My experience with Rust is that I have to fight the compiler a lot, but when the program compiles, it works. If it doesn't work, it means there's an error with my file/network paths or I did something in the wrong order, errors which no language can save me from. Rust also becomes a lot less verbose when you get better at it. The ? operator is especially useful.
        • TurboHaskal 7y ago
          > but when the program compiles, it works That's not even true for languages with dependent types, which Rust lacks.
          • oconnor663 7y ago
            And at the same time, I've heard people say "when it compiles, it works" about much weaker type systems, like Go's. It just seems to mean "this language catches more errors at compile time than the previous language I used."
            • 7y ago
• mkroman 7y ago
  There's one important question left out: what kind of games does the author make? I can see how 'vanilla' C can be more than sufficient for basic 2D games, but as soon as you grow in complexity it can quickly become an insurmountable task to grok.
  • astrophysics 7y ago
    Basic games like...Quake 3?
    • gmueckl 7y ago
      Yup. Quake 3 is basic. I remeber that the whole game had a "measly" 150.000 lines of code or so. It doesn't do a ton of things modern games do. The list of things expected from modern games these days in comparion is far too long to list here. These things have become elaborate world simulators. And all of these features add up. The Unreal Engine is around 4 million lines without dependencies (e.g. PhysX, a proper audio engine, etc). You could try to do all that in C (good luck finding a good physics library with a plain C interface, btw.). But you need to have proper software design throughout the project and you will likely end up replicating some kind of inheritance or polymorphism scheme somewhere.
      • gypsyharlot 7y ago
        Quake 3 has 230.000 lines of code. If Quake 3 is considered basic, then any studio with less than 100 developers can probably reach for C. The Unreal Engine is far more than a modern game. You wouldn't call Clang and editor just because Vi was compiled with it.
        • gmueckl 7y ago
          The Unreal Engine is less than a modern game. The actual game is obviously missing. Also, you need engine specific editing tools to make a 3d game that looks more advanced than minecraft. It is a mistake to exclude them just because the don't have to be shipped with the final product. And Quake 3 was made by a team of roughly 20 people. Id Software was quite small until they started to work on Rage.
• htk 7y ago
  Very interesting point of view. I wish I had projects (like games) that could benefit to craft meticulously with C. The feel of coding closer to the hardware is great.
  • krapp 7y ago
    I'm not sure C is that much closer to the hardware, nowadays.
    • kccqzy 7y ago
      C is closer to the hardware in the sense that with any given C code, I can pretty much predict what the generated assembly will look like. You cannot say the same for, say, Python.
      • Koshkin 7y ago
        > pretty much Not really... Not only the generated assembly code heavily depends on the compiler (LLVM, gcc, Intel, MSVC...) and the optimization settings, you cannot be completely sure what the machine code generated by the assembler even looks like these days.
        • someguydave 7y ago
          and you also won't be able to predict the timings of complex code as various "uncore" and on-core resource limitations bite
  • stephc_int13 7y ago
    The goal is not actually to write bare metal super optimized code, most of the time. The goal (at least mine and of some authors following this minority trend) is to write and read simpler, more straightforward code. Take a look at the code in the examples of the following url to see what I mean. https://www.raylib.com/examples.html https://www.raylib.com/examples.html
• xamuel 7y ago
  The author despises OOP, and I agree with him there. I would add that OOP can be particularly bad for games, because often times the OOP vocabulary clashes with the game's own vocabulary: the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. All support for OOP would vanish overnight if people realized you can do all the important OOP stuff using C structs.
  • zabzonk 7y ago
    > you can do all the important OOP stuff using C structs. Such as having a safe, leak-proof string type? I think not.
    • tlb 7y ago
      SDS is a safe, leak-proof C string implementation. Obviously you can misuse anything, but SDS is easy to use correctly. It's robust enough for Redis. https://github.com/antirez/sds https://github.com/antirez/sds
      • z_open 7y ago
        It's considered horrendous practice to typedef to a pointer of something. Not sure why this can be considered easy.
        • overgard 7y ago
          Citation needed on that, plenty of major libraries typedef pointers all the time.
          • bernawil 7y ago
            Yeah. Like I remember the win 32 API (not saying it's a good API though) to typedef every struct and it's pointer. I'm not sure if the Linux API are the same though.
• unnouinceput 7y ago
  Quote: "I want to produce less bugs, so I want strict typing, strong warning messages and static code analysis". Yeah, at strict typing you lost me buddy. Let's just go with somebody else reply, as in you like C and that's why you do your hobbies in. Nothing wrong with that in the end.
  • jchw 7y ago
    Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does prevent bugs, it does improve productivity. Tests do too when done correctly, but both together are better than either individually. When you go further, you can see that the core innovation of Rust is basically adding ownership to the type system and therefore making typing even stronger. Strong typing is a win for less bugs. Full stop.
    • eternalny1 7y ago
      I too do not understand how anyone can complain about typing if they have used a statically-typed language for any real projects. Your TypeScript versus JavaScript comparison is about as good as you can get. Many people I've met who think duck typing is the preferred way to go do so because they learned to program on JavaScript. That is more familiar to them, TypeScript is an extra burden to getting work done, and therefore is bad. I am working on a large project that uses TS (Angular) on the front-end and I can't possibly imagine doing that in plain JavaScript. The lost hours to simple, avoidable bugs would be too great.
    • kabes 7y ago
      I'm sure typing prevents some bugs. But if I'm looking at the bugs we find in the JS projects I work on, only a very few would have been avoided with typing. The vast majority of bugs are about unsound business logic, wrongly understood requirements, etc.
• stephc_int13 7y ago
  The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a few of other professional, experienced and talented developers doing the same, even full AA studios with up to 50 employees. Some of them are going back to procedural C after a few years of disappointment with OOP madness. I'll publish articles about this later, but for now, all I have to say is that it just works. Newbies are often afraid of manual memory management and pointers, but there are simple ways to avoid shooting yourself in the feet with those.
  • slacka 7y ago
    Writing game engines in C++ without using any OOP features, makes perfect sense to me. Other than the author likes C, he failed to show me why his approach is better than yours. I found it very light on details.
    • ncmncm 7y ago
      Writing game engines in C++ without using destructors is just foolish. If by OOP you mean virtual functions? Nobody uses that stuff much anymore, except Java refugees. (They use shared pointers, too.) But, anyplace you would use a function pointer in C, it's cleaner with a virtual function, and often faster.
      • skohan 7y ago
        > Writing game engines in C++ without using destructors is just foolish. Why? My understanding is that in modern game dev you're mostly traversing large arenas of structured memory, and you avoid freeing individual objects like the plague.
• maxharris 7y ago
  No mention of Rust?
  • maxharris 7y ago
    So I dug some more, and it turns out that while he does have something to say about Rust, I'm not sure I'm convinced by his conclusion about safety: "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would. I don’t care what language you rewrite it in." From https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl... (I think it's a bit mean to downvote me for not knowing that he addressed that point in a separate page of his. He didn't link to this Rust review at all!)
    • detaro 7y ago
      how do you know the article by Drew DeVault represents the opinion of the author of the article above? Did he link it somewhere?
      • maxharris 7y ago
        D'oh! Different person! whoops! So that really underscores my point, then. The "Why I Write Games in C" guy doesn't mention Rust anywhere!
    • mlindner 7y ago
      Holy... Believe nothing that guy says. I'll just wait until he releases his first game with network connection and instantly gets a buffer overflow and his game becomes an entry for worms into people's systems.
      • takeda 7y ago
        Most of network services are written in C, not to mention kernels.
• crystalsforme 7y ago
  Didn't even consider Rust...
  • sharpneli 7y ago
    I think it’s because ”Similarly I want to avoid tying myself to a particular OS, and ideally I'd like to have the option of developing for consoles. So it's important that my programming language is portable, and that it has good portable library support” Availability of Rust across platforms is nowhere near C or C++. It may, and I hope it will, change in the future but right now it is not so.
  • gypsyharlot 7y ago
    https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
    • Narishma 7y ago
      I don't think that's the same person.
• mumblemumble 7y ago
  I'm currently trying to decide if Nim is my C replacement. On the one hand, it isn't C++, and it has real type safety, and it interfaces with existing C libraries very easily. On the other hand, it is rapidly getting very complicated, and seems almost eager to become another C++ in terms of sheer volume of language features.
  • F-0X 7y ago
    >On the other hand, it is rapidly getting very complicated This seems to be the case for almost any "C replacement", and it will be (my prediction, at least) the reason they all fail. I feel I might be a bit of an outlier in this respect, but I have only ever enjoyed using languages which are small and simple - C, Go, Scheme. The times I've tried Rust, it's been nice to have code that cannot segfault, but I find it such a chore to deal with. Whenever I've read open-source projects in Rust it's always a readability disaster. Also the compiler emitted warnings because functions were not snake case, which I found obnoxious.
    • zem 7y ago
      you would probably like zig, if you haven't given it a look yet.
      • mrec 7y ago
        Zig is promising as a "better C" but is nowhere near a 1.0 release as far as I know.
      • PezzaDev 7y ago
        I feel zig is now experiencing feature creep now too sadly. Async and await and coroutines are being added to it, because it's the new-ish hotness I guess? Stopped paying attention to the language after that. I was hoping for a more streamlined language.
        • AndyKelley 7y ago
          it's been planned since the beginning: https://ziglang.org/download/0.3.0/release-notes.html#concurrency https://ziglang.org/download/0.3.0/release-notes.html#concur...
• mruts 7y ago
  C is one of my favorite languages but you know what be almost perfect for the author’s needs? OCaml! Almost as fast as C, no mandatory OOP, great performance, C FFI, nice FP, totally portable and native executables. Unfortunately OCaml is single-threaded, has a stop the world GC (though if it’s good enough for Jane Street it’s probably good enough for you), and sometimes has unfortunate syntax (though ReasonML fixes a lot of this). Also OCaml doesn’t have the greatest type system in the world. No higher kinder types and instead we get the parameterized “functor” module system. Which honestly, kind of sucks. A lot of OCaml is an artifact from the past, if it could be remade today it would really be something great. Even so, OCaml is a great language and doesn’t suffer from a lot of the dogma that Haskell succumbs to. I’ve always thought of and used OCaml as the functional programming equivalent of C. No unnecessary bullshit, just straight coding.
  • TurboHaskal 7y ago
    While OCaml boasts very low GC latency, I believe F# would be a better choice for writing games. It is an even more straight to the point OCaml; a Windows first class citizen; has a concurrent GC and I've heard C# is pretty popular for writing games due to Unity, so one might be able to leverage that (I don't know). A non CLOS heavy SBCL codebase would also be excellent.
• zemo 7y ago
  > The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage collector is doing work that doesn't need to be done. What latency budgets are you working with? How often do you do work to free resources? What are the latency requirements there? Even at 144 fps, that's 7ms per frame. If you have a garbage collector that runs in 200us, you could run a GC on every single frame and use less than 3% of your frame budget on the GC pause. I'm -not- suggesting that running a GC on every frame is a good idea or that it should be done, but what I find so deeply frustrating is that the argument that GC can't work in a game engine is never qualified. edit: wow for once the replies are actually good, very pleased with this discussion.
  • facorreia 7y ago
    Indeed, and also what about the effect of multiple cores? You could have 7 cores working on game logic and one doing GC.
    • detaro 7y ago
      That sounds like a massive synchronization nightmare and performance overhead that'll probably not be worth it.
    • zemo 7y ago
      not sure that cpu affinity is trivially solveable to avoid mutex contention here, since game entities can often mutate one another when they interact. how do you determine which entities are computed by which cores to minimize the cost of synchronizing the work between the cores?
      • yellowapple 7y ago
        One strategy might be to correlate CPU affinity with spatial proximity. That is: two entities that are close together are more likely to mutate one another than two entities far apart, so the two close together should be on the same CPU/core/thread and the other should be on a different thread (probably with other entities closer to it).
• hesdeadjim 7y ago
  He dismisses C# without even knowing what options he has. The latest stuff Unity has been doing is heavily biased towards data driven design where almost everything is a struct. There are very few classes to be found that use any kind of polymorphism, and it is actively discouraged. You could easily treat Unity as a cross platform rendering engine and asset loading system, and then build your own engine on top of it. I see very little reason to drop down to C or C++ at this point, especially if your goal is to ship your game to as many people as possible.
  • elabajaba 7y ago
    Blackbird Interactive did that for Homeworld Deserts of Kharak so they could have a deterministic simulation for multiplayer RTS and used Unity for the rendering. https://www.youtube.com/watch?v=wwLW6CjswxM https://www.youtube.com/watch?v=wwLW6CjswxM
  • jayd16 7y ago
    As a Unity dev this is really generous to Unity. After all it's extremely complex in a way the author would hate. That said, I'd love to see a pure C# engine on .NET core 3 that has access to Span<T>. C# is set up as a great high level language with low level features as long as you're willing to do the work you would have done in C or C++.
    • hesdeadjim 7y ago
      Any game engine evolves towards serious complexity as time goes on. The question is, do you want to waste time building systems that a million man hours have gone into to make them resilient across a thousand different permutations of hardware? Or do you want to ship your game? I've built a non-trivial engine active from around 2010 to 2015 that targeted all iOS and Android devices. Our test fleet of devices was enormous because we'd run into silly issues that were always device specific. My favorite, one particular phone with one particular driver version for the GPU did not correctly implement the ES 2.0 standard for constant defined variables. It caused our games to crash, and because of the scale of mobile this affected hundreds of thousands of users. At this point you could not pay me to build an engine, because for anything that isn't a toy you end up having to solve these problems yourself. Treating Unity as a rendering engine and asset loading system is not immediately "easy", but it's a very far cry from "hard". Dismissing it or other options simply because of unfamiliarity or a shallow distaste for OOP is ignorant at best and actively misleading otherwise.
• einpoklum 7y ago
  > [C++] is high performance, and it offers but features I don't want, and at a great complexity cost. 1. Complexity of implementation is not complexity of use. Example: Take std::array vs a plain C array. std::array is a few hundreds of lines of code. But - it's about as inutitive to use; has more convenience features; easier for the compiler to optimize; and doesn't let you should yourself in the foot that easily. 2. If Whiting don't want _any_ of the features of C++ - his software-writing skills are suspect. Now, few people need or want all of C++'s features - but C's are definitely insufficient, especially if you consider both the langauge and some of the standard library (or non-standard common libraries). 3. The complexity you have to tackle with C++ is lower than the complexity of non-standardized often-inconsistent idiosyncratic platforms and libraries for achieving the same things with C (or C + assembly). So I find Whiting's argument for C over C++ unconvincing. IMHO C++ would be the least-bad language for writing demanding games in.
  • seamyb88 7y ago
    Some people just like writing code. You can't say that C's features are insufficient, when you can implement the vast majority of C++ features in native C, and all of 'em with tooling. What's wrong with having direct control of only the features you need? What's wrong with code generation? Not to trample on C++, I like it (albeit less than C). I would definitely create C++ if it didn't exist.
    • einpoklum 7y ago
      > when you can implement the vast majority of C++ features in native C No, you absolutely cannot, even in principle. C++ is not "C with classes" and some syntactic sugar like it started out. That's not been the case for many years already. Also, even the features you can implement - you won't; you don't have the person-years for that. You will have to, need to, use libraries. For those you need to compare the libraries available for C and for C++, and C comes up quite short (not just because C libraries are also usable in C++...)
      • lightedman 7y ago
• Hokusai 7y ago
  Some points: > All my solo project games I've been making recently have been written in 'vanilla' C. The author is talking about solo projects, not big projects where dozens of teams may be collaborating. It is good that he makes the point at the beginning. > Nobody does this. This is just not true. There are solo projects developed in Python, Go, even Commodore 64 assembly. When you do something for fun, you can have as much fun with it as you want. > It would be nice to make things for the web, but it feels like a terrifyingly fast moving enviroment. The author should look into Emscripten. It is widely used in the games industry that aims for the web. > C++ ... It is also slow to compile compared to C. Probably an important point. You need very good practices to make C++ compile fast. Most people don't follow them as adds complexity to the project. > Haxe feels much more promising than most alternatives. Haxe is kind of Object-Oriented and like C++. So, I do not see the point after bashing C++'s OOP so badly. For me, the problem is that it transpiles to another languages. So, when something fails does it in code that you didn't write but the Haxe did. This makes debugging harder that it already is. > Some people just say screw it, I'll write my own language, the language I want to use. I admire this, and sometimes I toy with the idea of doing the same. Yep. Something possible for your own fun. Not a good idea when developing commercially. It makes sense for him to choose one language for commercial projects and another, or even create his own, in his spare time. > It can be made to run on just about anything. Usually this is relatively easy. It is hard to imagine a time when this won't be the case. This is the big advantage of C. If doesn't run C, probably it just doesn't run at all. > I absolutely DO NOT mean to say "hey, you should use C too" For solo projects is a giver that each developer should use the best-suited tools for the task and their abilities and preferences. I, personally, like C++. I have developed big and small projects in C++ and for me comes natural to write object oriented code. For big projects I see advantatges in being more rigid than C. The extra rigidity makes more difficult that there is unexpected funky stuff happening. So, it is easier to use for teams that maybe situated in different countries. For a solo project, you do not need that rigidity as you know how your own code works.
  • balaam 7y ago
    > You need very good practices to make C++ compile fast. I would reframe this as the design of C++ makes it hard to write code that compiles fast.
• relativeadv 7y ago
  "This is just an opinion but, it's also objective truth, you'll be a superior human in everyway to lesser mud-blood human's who never managed to release anything. Everyday they'll continue to toil away in the fields like Russia serfs, while you can skip past them like a wise and jolly Rasputin. (I've released exactly zero games independently, so I am too one of the serfs, with only homemade vodka and sweet dreams of a Bolshevik ruled future to keep me going.)" http://howtomakeanrpg.com/a/not-your-problem.html http://howtomakeanrpg.com/a/not-your-problem.html
  • dbtqgoat 7y ago
    That’s the exact tone I got from the first words in.
• crimsonalucard 7y ago
  He didn't talk about Rust. I feel rust bridges the gap, it's just library support still sucks.
  • newnewpdro 7y ago
    > and ideally I'd like to have the option of developing for consoles. So it's important that my programming language is portable, and that it has good portable library support. Every console will have a C toolchain out of the box, we can't say the same for rust.
    • crimsonalucard 7y ago
      Hopefully rust will eventually be the new standard.
  • stompl 7y ago
    Rust isn't the holy fucking spirit, dude. Jesus
• 0x0aff374668 7y ago
  Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only. MBED is C++, but I've never encountered or heard of an OEM or integrator using MBED in a real product.
  • busrf 7y ago
    Lots of folks use C++ on microcontrollers (including me!). I've definitely been working closer to the 32 bit processor, >= 128K flash world though. Certain things are very nice about C++ as compared to C, especially C++11 on: * type safety and expressiveness (aided by judicious use of templates) * The constexpr keyword for real compile-time constants (again, type safety) * RAII (often aided by statically allocated pools of memory from which one can then allocate objects from at runtime) What kind of issues with code size have you had (and using which compiler)?
    • 0x0aff374668 7y ago
      Which SDKs do you use that are C++? I use Keil, IAR, Renesas's compiler, XM8/16/32 from Microchip, and GCC. Which do you use? One of the main features of C++, its object-oriented stuff, is built on top of constructors and destructors -- aka dynamic memory allocation. This sort of thing is not desirable on deeply embedded systems due to resource constraints and the very real spectre of heap fragmentation -- embedded stuff tends to rely on static memory allocation done at compile time or system startup. C++ isn't quite as portable as C -- Not just the compilers which never quite supported the same combinations of features -- even if you just stuck with the ISO-ratified features -- but the language runtime, standard [template] library, and headers are far larger with various implementations including plenty of mis-features and quirks. All of this meant that it was quite common for C++ code to not even compile with a different toolchain -- especially when templates were used -- and even if it did compile, it might not actually function correctly. If you restricted yourself to avoid the problematic areas of C++ (eg not using templates or dynamic allocations) you'll end up with a language that is basically C. So why not just use C? :)
• billfruit 7y ago
  They didn't dwell on why they chose C over C++, in much detail. In my view the conveniences and quality of life features provided by c++ makes it a better choice than C for large programs. Also there are many kind of games that do not require a real time user interaction including many turn based games, card games, etc, so the type of game could be a factor in the selection of the tool. Some time s I guess game design can incorporate pauses and delays that might be required for technical reasons.
• makecheck 7y ago
  I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like. A lot of stuff in C++ is entirely avoidable. Protocol-oriented programming is extremely useful for games and I like Objective-C for that reason. (Objective-C doesn’t meet his mentioned goal of portability but this is an example where C++ could be used to gain “light” inheritance without having to opt in to the rest of the mess that C++ can be.)
  • kgabis 7y ago
    Compilation times even for simple C++ programs are far too long and it's not like you can reject this "feature" unless you basically write C code compiled with C++ compiler. For instance: simple hello world with iostreams takes 280ms to compile vs 40ms for C equivalent with stdio. And it only gets exponentially worse with bigger programs.
  • yellowapple 7y ago
    > Objective-C doesn’t meet his mentioned goal of portability Clang implements it, last I checked, meaning that it should be (at least in theory) portable to every platform Clang supports, no?
  • inimino 7y ago
    > I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like. The article mentions that: >> What I want from a language >> The strongest thing on my desired, but not required list is simplicity. I find looking up language features, and quirky 'clever' api's incredibly tiring. The ideal language would be one I can memorize, and then never have to look things up. (emphasis mine)
• gambiting 7y ago
  >>Nobody does this. I disagree - I work at a AAA games studio and we're currently building a little project made entirely in C. Not even a hint of C++. This is probably going to end up being just a little research thing in the end, but don't think that no one does this anymore.
• noncoml 7y ago
  Two things that I miss in C are smart pointers and closures.
• sgt 7y ago
  Just downloaded his game Mussel (it runs on macOS). Amazing fun - highly recommended. Crazy CRT like effects.
• melucasleite 7y ago
  I read your post as poetry. Where can I play your games? You gave me this "The beguiners guide" (a game about games) feeling.
• CameronBarre 7y ago
  If it works for you and acts as a means to your end, you've won the game!
• surfsvammel 7y ago
  Isn’t Rust an alternative? I don’t know Rust well enough, but wouldn’t that fit the bill?
  • pornel 7y ago
    It is if you're writing a game from scratch, without need to deeply integrate with something like Unreal Engine. I used to write games in plain C, and nowadays I'd definitely use Rust for them. There is a small Rust games community and a couple of engines/frameworks: https://lib.rs/game-engines https://lib.rs/game-engines One thing with Rust is that it pretty much requires use of entity-component-system. It's the best practice for real-world games anyway, but people who write their first game are surprised they can't just "wing it" with some ad-hoc OOP.
• Mountain_Skies 7y ago
  Wasn't Rollercoaster Tycoon also written in C?
  • corysama 7y ago
    It is considered one of the most complex hit games written primarily in assembly language. http://www.chrissawyergames.com/faq3.htm http://www.chrissawyergames.com/faq3.htm
• ufo 7y ago
  I think this discussion is incomplete without a mention to scripting. (Writing the core engine in a low-level language like C but implementing some or all game logic in a higher-level garbage-collected language such as Lua or Python)
• oscargrouch 7y ago
  One of my dream side-projects is to create something inspired by Ken Thompson's C (the plan9 compiler), with some ideas borrowed for Go, where this "almost C" language could be written in a valid C just like you can do it with C++. things like: (Composing structs) struct Parent {int number} struct Child {Parent; int another_number} // anonymous struct convention Child c; c.number = 10; c.another_number = 11; (Object notation, namespacing) int DoThis(Child* this, int input) {} Child* c ... c->DoThis(10) (Someway to define public/private in structs and methods, like Go do with convention of Lowercase/Uppercase components/function names) and Finally (Someway to define a interface and use vtables when needed just like Go´s Interface but in a more C compatible way like.. ) struct MyInterface { int (*Read)(int a, int b); int (*Write)(int a, int b); } or struct MyInterface { int Read(int); int Write(char); } struct X {} int Read(X* this, int n) {} int Write(X* this, char c) {} X x = X{}; x.Read(10); x.Write('b'); MyInterface* c = &x; (...) (templates) - C++ way is fine Thats it. With all this you would have "a better C", with compability with C codebase and still a language much simpler than C++, yet powerful.
• deleted 7y ago
  [deleted]
• e9 7y ago
  Have you tried D? It’s popular in game development world and very pleasant to work with. https://dlang.org/ https://dlang.org/
  • zerr 7y ago
    D doesn't seem to be popular in any field, unfortunately.
    • qznc 7y ago
      Not popular, but it was definitely used: http://dconf.org/2016/talks/watson.html http://dconf.org/2016/talks/watson.html > Can D be used to make games? Yes. Has it been used in a major game release? It has now. Remedy Entertainment have successfully shipped the first AAA game to use D code. And it’s in a fairly critical subsystem too. This talk will cover the usage of D in Quantum Break, problems encountered and solved, and where we want to take our usage of D in the future.
• CodeGlitch 7y ago
  Anyone who is interested in secure, plain, well-written C-code should checkout the OpenBSD project. I've just been browsing through the code to brush-up on my C as it's been a few years since I've had to use C in anger, and it's a joy to read.
  • ncmncm 7y ago
    Whenever I look at BSD code, it reminds me of how we did everything in the '80s. There's an esthetic to stone knives and bearskins (check out "Primitive Technology" series on YouTube) but performance suffers on modern hardware. Linux is irredeemably complex, and getting moreso all the time. My code nowadays bypasses it wherever possible -- O_DIRECT files, memory-mapped files, kernel-bypass NIC libraries that set up hardware ring buffers mapped into user address space.
• avodonosov 7y ago
  How old is this article? It says Haxe is new, but Haxe is a relatively old tool, first released in 2006.
• detaro 7y ago
  [2016] it seems
• bitwize 7y ago
  > The strongest thing on my desired, but not required list is simplicity. I find looking up language features, and quirky 'clever' api's incredibly tiring. Indeed. Clever apis are a disease endemic to the JavaScript community. expect(me).to.puke.when(i.see.shit.like.this()); > The ideal language would be one I can memorize, and then never have to look things up. You can't memorize C. The idea that you can "hold C in your head" is a myth, and propaganda repeated by C pushers. In reality, the gotchas surrounding undefined behavior are so numerous and subtle that you're much better off using something else, even if it means accepting the complexity that is C++. (In reality, what you want is a language such as Rust that has well-defined behavior.) > I need a platform that I am confident will be around for a while. Don't get your hopes up. The closest we've had is POSIX, but POSIX is showing its age, and in the modern era churn is the rule, rather than the exception. More than a decade old? Rewrite it! New framework came out? Rewrite it! Developer fell in love with some flashy new technique? Rewrite it! Not enough nonbinary PoCs on the dev team? Rewrite it!
  • aflag 7y ago
    I don't think C is as bad as you're making it out to be. It's a small language. There are some quirks, but I don't think it's any worse than c++. You can even easily become a standard zealot (just look any c forum). Rewriting software sucks. We usually don't like solving the same problem more than once.
• Bekwnn 7y ago
  I have similar frustrations using C++, but don't feel using C or even Rust would be an improvement, more of "side-grade" due to various tradeoffs those languages have for game development compared to C++. I am excited about the development of both Zig and Jai since they both are trying to fill what I believe is a much needed role of a C-like language with a few more nice language features like better compile-time code, better compiler error messages, better error handling that doesn't use exceptions, and build scripts written natively in the languages, all while sticking to fast compile times and simplicity. Games are a decently different domain than others, and there is a lot of valid complaining about C++. It's a known issue, we just need something that's clearly better, which so far I think those two languages are. I've chipped in a few dollars a month to support Zig and have been using it in my free time, but it still very much feels like the version 0.4.0 that it is. This wait will probably be a few more painful years.
  • adamrezich 7y ago
    imo it's worth pointing out that it's not called "Jai"
    • Bekwnn 7y ago
      What is it called? I've followed a bunch of videos and never heard it referred to in any other way
  • lone_haxx0r 7y ago
    The thing I hate about them is the backwards declaration syntax. var x:i32 = 5; ugh, it makes no sense.
    • FreeFull 7y ago
      Usually you wouldn't write the type, so `let x = 5;` In general, the C style type declarations complicate parsing quite a lot as well.
    • skohan 7y ago
      You'd be surprised how fast you get used to it.
• abetusk 7y ago
  I had never considered a "data-centric" approach to be anti OOP but from the article: > I am not an OOP convert. I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. I want to handle data as data and write the code that best fits a particular situation. I've come around to the idea much more that data should be the privileged structure and code should be considered transformations of the data. In some sense, code should be light and interchangeable and let the data is the first class citizen. Are OOP and "data-centric" approaches at odds with each other? Does OOP only have validity when the data is relatively "small" and can be abstracted away easily?
  • inimino 7y ago
    > Are OOP and "data-centric" approaches at odds with each other? Yes, because OOP Objects are data plus code (methods). If you don't have methods, but just pass data around, you don't have OOP. If you do have methods, you meet the "expression problem". If you have static types and well typed code you get pure data at runtime, and if you include unions and product or sum types at runtime, you end up with algebraic datatypes, and if you have RTTI and polymorphism and inheritance then you get classical OOP. If you have just data living in memory at runtime, and just transformations of the data (functions) sitting in your code, then you get FP.
• blunte 7y ago
  This is a surprisingly eloquent essay on the state of modern programming languages (and obviously why the author things that sticking with C is a better choice... and I'm fairly persuaded.)
• rootVIII 7y ago
  This line is pretty funny: "C++ is still the most common language for writing games, and not without reason. I still do almost all of my contract work in it. I dislike it intensely." hahaha poor guy
• blunte 7y ago
  We see articles not so different from this concept all the time on HN. Recently it's about ORM vs SQL. The core interfaces are really not terrible at all. They do have danger zones, but their complexities are relatively low. As the author of this article suggests, it's within the realm of something we can remember. That's a BIG deal. I haven't done C in a very long time. But with C, my recollection is that the biggest issue is to make sure you keep track of your memory allocation and releasing. Sure this is significant, but it's a direct concern. And if you abstract by one level your management of memory, it's a lot easier (especially if you include some testing). I think it's important to periodically evaluate if our efforts to simplify a situation have actually alleviated or simplified real issues that were hurting us.
• ulkesh 7y ago
  After I got past the horrible misspellings and atrocious grammar, I could appreciate what the author is saying. The author is privileged to be able to concentrate on and enjoy a particular language. That is great, for him. Most of the rest of us have to learn and use a wide swath of languages, features, and technologies to stay a leg up in this world. We seldom have the choice to pick what we work on. Sure, we can change jobs, but inevitably it requires conforming to someone else’s opinion. The author makes me want to go back and pick C up again. But like so many times in the past, I will probably find it needlessly painful and go right back to the more modern languages which already solved so much for me. I don’t mind standing on the shoulders of past C developers. I, for one, also do not mind learning the details of any particular modern language because, if anything, it makes me more marketable.
• Avamander 7y ago
  Yes, I do too love the remote code executions. We really should look at safer alternatives when making networked games.
• ltbarcly3 7y ago
  >>I am not an OOP convert. I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. He doesn't want to combine code and data rigidly, so he uses a language without any concept of generics. I think he doth protest too much, he can write code however he feels like, and Im not going to deny his personal opinions, but the justifications and reasons for those opinions are all just uniformly nonsense.
• seba_dos1 7y ago
  Nobody? I write my games in C as well :P The only other reasonable choice would be Rust, but never got past "have to write bindings to my framework" stage with it so far. Pretty much the only things I miss in C for gamedev are sensible string manipulation and lambdas/closures. Otherwise it works really well - I don't think I would be able to make my games so multiplatform (at the moment GNU/Linux, macOS, Windows, Android, Emscripten, Librem 5, Nokia N900, Pocket CHIP, Raspberry Pi, Steam Link, Nintendo Switch w/ devkitPro; more to come...) so easily with any other language.
• thrower123 7y ago
  I thought it was interesting that he highlighted Haxe as being a young language. I suppose it is compared to C, but I remember reading some tutorials about Haxe game development almost a decade and a half ago.
• anta40 7y ago
  What about Pascal, then?
• anta40 7y ago
  I wonder why the author didn't mention Pascal. Hmm...
• Uptrenda 7y ago
  I've been surprised and delighted by C recently myself; Being able to make a small change to a datatype, variable name, and so on, and then instantly seeing an IDE highlight errors relating to it is amazing for productivity. The language is incredibly simple. I mostly use structures to define my own 'types' and design functions to work on pointers to those types. That way you can control whether you want your data to live on the stack or heap and its fairly robust. I've rarely if ever had to use function pointers or macros, but they're there if you need more advanced features. I find just being able to manipulate memory and buffers as raw bytes with no bullshit wrappers helps you so much with actual programming (TM.) As far as data types go, I haven't used much more than linked lists and basic hash maps so far. For everything else I use fixed-sized arrays. It helps you precisely control how much memory the program is using without worrying that some higher-level magic garbage collector will overflow. Despite having that level of control, I haven't been frustrated by it yet. Yes, the standard library is very basic, but you can add the types you need very easily. There's some beautiful C code out there that will give you exactly what you want without having to include hundreds of obscure futures you'll never need. Overall, I've been very happy with it, and I look forwards to trying to run my code on all kinds of weird and wonderful platforms. I see huge competitive benefits for C code bases, to be honest.
• krzat 7y ago
  I hate that C is still a viable choice, it's basically a living fossil.
• blacklight86 7y ago
  It's quite curious that he didn't mention Rust as a possible alternative. Still fast compilation, still no forced OOP bloatware added, plus static memory management that prevents the issue with garbage collection that happens in Go.
• motles 7y ago
  ctrl+f rust <cr>
• jokoon 7y ago
  I still believe that C++ is great because you can "use the good parts". To me the STL containers are good enough. It's always a balance between how much time you save, and how much performance you lose. C++ is good enough with this. The only lacking thing would be an object pool. The author writes > but so simple it's not too hard to learn to use it carefully. I would really love a replacement to C++, or an subset of C, that have the best of both languages. I can't use C because it becomes hairy very quickly, since you don't have things like STL containers. I don't like Rust for the exact reason I quoted the author. The learning curve of Rust is too step, and its syntax if to distant from C. C is great because it's easy and fast, but it's also lacking many modern features that makes the programmer's life easier, without stomping down on performance or customization. It's true that C++ is very complex, but I still believes it's very very usable, and the standard is improving a lot.
  • skohan 7y ago
    Yeah I agree that there's still room for a "better C". Just C but with a few modernizations would go a long way. I think Rust has a different lane: Rust is for when safety is absolutely important. C is for when you want very little abstraction between you and the hardware, and you just want it to do what you tell it.
• Elrac 7y ago
  I'd like to voice my disagreement with the author about C having the shortest compile times. From my own experience and reports all over the Web, it seems that Go handily beats C at compilation speed. This is mostly down to a lot of design decisions in Go made with the goal of speeding up compilation. Elimination of header files, pre-compilation of Go modules, efficiently parseable syntax and more. From what I've seen, first-time compilation of Go programs competes well with C, while incremental compiles are practically instantaneous.
• jacobush 7y ago
  "when it comes to compilation I can't think of anything faster" FreePascal! :-D
• tutfbhuf 7y ago
  Rust!?
• KindOne 7y ago
  Needs (2016) added at the end. (Might be older, could not find anything on archive.org before Jan 2016) Previous discussion: https://news.ycombinator.com/item?id=10870488 https://news.ycombinator.com/item?id=10870488
• uvtc 7y ago
  > Haxe feels much more promising than most alternatives. If I do web stuff again I'll be diving in here. There is some good library support. I am a little concerned by its relative youth, will it last? Haxe has actually been around since 2005 or so. I'm really liking Haxe as a general-purpose compile-to-just-about-anything language.
• tripzilch 7y ago
  Can anyone explain me why this is on the front page? I mean it's basically someone bashing languages they've not worked with, not understand or in the case of C++ simply don't like. As in, he doesn't bring anything new or insightful to the table, just "this is my personal opinion". Which btw is a fine opinion, as far as personal ones go, not one that I share, but it's a perfect example of "great let's agree to disagree". Which IMHO basically amounts to trolling for HN comments if you post it here. Now people are just going to argue how wrong he is, against and for their favourite languages and nobody will learn anything new or useful. Is this guy well-known or something? Did he make any good games in C? Maybe I'm missing the point of this article (someone please explain), but it looks like it's worth as a post is only as a discussion starter and an inflammatory one at that. If there was any time a reason to flag a discussion thread for being useless, it's this one I think.
• thw0rted 7y ago
  > The ideal language would be one I can memorize, and then never have to look things up. If the language is so small I never have to look up anything when using it, it's also so small I'm going to have to spend ages re-re-re-implementing basic functionality that I get for free from a higher level language.
• ncmncm 7y ago
  If you are coding C++ and it is not super, super FUN, you are Doing It Wrong. Writing C code is also writing C++ code, but badly.