3 ms·

> There's also almost nothing pragmatic about C++. Huh? We’re talking about game dev. C or C++ is the primary language for just about every game engine ever. E

> There's also almost nothing pragmatic about C++. Huh? We’re talking about game dev. C or C++ is the primary language for just about every game engine ever. Even Unity is written C++. I can’t say functional languages haven’t ever shipped a game. I’m sure there’s an example or three. But yeah when it comes to shipping games C++ is the definition of pragmatic.

bmitc 4y ago
The word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C. Just because C++ ships games doesn't make it pragmatic. Aren't many game codebases considered to be absolute hell? And none of that says anything about the pragmatism of functional-first languages.
- FartyMcFarter 4y ago
  What language would you suggest game developers should have used throughout all these years? It needs to be performant and portable, and it needs to have existed for quite a long time.
  - JonChesterfield 4y ago
    C99 with code generators written in python or lua for the engine. Implementing templates in the C preprocessor goes pretty badly, but implementing them as a normal language that writes valid C to #include various places works just fine.
    - otabdeveloper4 4y ago
      > C99 with code generators written in python or lua for the engine. Nice fantasy, but the real-life codebases that do this make even the most hellish C++ code look like future space-age magic technology. You're not speaking from real-world pragmatic (heh) experience here, you're just complaining that C++ is hard and that you'd rather go shopping.
      - JonChesterfield 4y ago
        I've been coding like that since at least 2016[1]. The trick is to make adding code generators as easy as adding source code. Not a game engine in my case, though there's a CppCon talk from 2014 which makes a passing reference to using code generators with C++ instead of templates for one. Assume source is src/foo.c and compiled to obj/foo.o, then introduce a third directory called gen. Change the makefile rule to copy .c from src to gen, and compile from gen to obj. Then add a makefile rule that says gen/foo.c can be built from src/foo.c.py by calling python on the source and redirecting stout. That means a C source file can be turned into a python program that generates the same source by wrapping it in a string literal, calling print and renaming the source file. No build system change. Then change the python as you see fit to work around the limitations of C. Works really well for a solo developer. Repo using this scheme is ~100 generated files (mostly lua, some python) vs ~600 C files. Plus ~20 C++ and one D, just getting started with that language. [1] https://github.com/JonChesterfield/boring-makefile/blob/master/src/makefile https://github.com/JonChesterfield/boring-makefile/blob/mast... $(GEN_PY_SOURCE): $(GEN_ROOT_DIR)%.c: $(SRC_ROOT_DIR)%.c.py $(PYTHON) $^ > $@
- simplotek 4y ago
  > The word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C. C++ is indeed not C. C++ is a considerable improvement over C. You can stick with your C-style code and get the same result you'd get if you had used C, but you still have access to features that simplify a great deal your life and don't have a performance impact, like templates. With C++ you can have your C cake and eat the C++ cake too. The only drawback is compilation times, but any caching system takes care of that.
pjmlp 4y ago
Unity is partially written in C++, and since HPC# introduction they have been slowly migrating code from C++ into it. Unity is one of the reasons why Microsoft started to take Midori lessons into regular C#. Ultimately if we want to be pedantic, all game engines are written in C and C++, as that is the only way current OSes expose their graphics APIs, no alternative implementation can change that unless they also write an OS in the process.

bmitc 4y ago

The word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C. Just because C++ ships games doesn't make it pragmatic. Aren't many game codebases considered to be absolute hell? And none of that says anything about the pragmatism of functional-first languages.

FartyMcFarter 4y ago
What language would you suggest game developers should have used throughout all these years? It needs to be performant and portable, and it needs to have existed for quite a long time.
- JonChesterfield 4y ago
  C99 with code generators written in python or lua for the engine. Implementing templates in the C preprocessor goes pretty badly, but implementing them as a normal language that writes valid C to #include various places works just fine.
  - otabdeveloper4 4y ago
    > C99 with code generators written in python or lua for the engine. Nice fantasy, but the real-life codebases that do this make even the most hellish C++ code look like future space-age magic technology. You're not speaking from real-world pragmatic (heh) experience here, you're just complaining that C++ is hard and that you'd rather go shopping.
    - JonChesterfield 4y ago
      I've been coding like that since at least 2016[1]. The trick is to make adding code generators as easy as adding source code. Not a game engine in my case, though there's a CppCon talk from 2014 which makes a passing reference to using code generators with C++ instead of templates for one. Assume source is src/foo.c and compiled to obj/foo.o, then introduce a third directory called gen. Change the makefile rule to copy .c from src to gen, and compile from gen to obj. Then add a makefile rule that says gen/foo.c can be built from src/foo.c.py by calling python on the source and redirecting stout. That means a C source file can be turned into a python program that generates the same source by wrapping it in a string literal, calling print and renaming the source file. No build system change. Then change the python as you see fit to work around the limitations of C. Works really well for a solo developer. Repo using this scheme is ~100 generated files (mostly lua, some python) vs ~600 C files. Plus ~20 C++ and one D, just getting started with that language. [1] https://github.com/JonChesterfield/boring-makefile/blob/master/src/makefile https://github.com/JonChesterfield/boring-makefile/blob/mast... $(GEN_PY_SOURCE): $(GEN_ROOT_DIR)%.c: $(SRC_ROOT_DIR)%.c.py $(PYTHON) $^ > $@
simplotek 4y ago
> The word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C. C++ is indeed not C. C++ is a considerable improvement over C. You can stick with your C-style code and get the same result you'd get if you had used C, but you still have access to features that simplify a great deal your life and don't have a performance impact, like templates. With C++ you can have your C cake and eat the C++ cake too. The only drawback is compilation times, but any caching system takes care of that.

pjmlp 4y ago

Unity is partially written in C++, and since HPC# introduction they have been slowly migrating code from C++ into it. Unity is one of the reasons why Microsoft started to take Midori lessons into regular C#. Ultimately if we want to be pedantic, all game engines are written in C and C++, as that is the only way current OSes expose their graphics APIs, no alternative implementation can change that unless they also write an OS in the process.