5 ms·

>if anything it might be faster in C89. You're underestimating the role played by good abstractions in developer productivity.

by fooker 7y ago

manfredo 7y ago
I don't think the increase in productivity in re-implementing old games lies in ease or programming. It's the fact that all the art assets already exist and all the game design is already done. And not to mention, marketing, HR, etc. are totally out of the picture. For most games, programming is far from the biggest labor cost.
- fooker 7y ago
  You have contradicted yourself. >For most games, programming is far from the biggest labor cost. And as you say, the other bigger costs are out of the picture when re-implementing old games. So, programming is the largest remaining part, almost by definition of 're-implement'.
  - manfredo 7y ago
    I'm pretty confused as to why you think I contradicted myself, and your last couple sentences don't really make sense to me. When making a game from scratch, you need to produce art assets (often 50-70% of the cost of the game is art assets alone), design gameplay mechanics, market the game, test the game, and distribute the game (which, in the old days, often meant making physical cartridges or disks). Let's say that 10% of the labor in making a game from scratch went to programming. When you're re-implementing a game, all you need recreate is that 10%. So if re-implementing a game is an order of magnitude easier than making a game from scratch, there's no reason to think that programming games has gotten any easier.
Crinus 7y ago
I am not, but C++ does not provide any abstractions that would be helpful for a DOS-like game that "someone who has enough knowledge to make a project in C++17 like a game" cannot do (also remember the context in the original message was about stuff made decades ago being made today, not modern AAA engines). Even if you take out the possibility of grabbing something like SGLIB, the two most common data structures in a game you'll need are lists and dynamic arrays and you can create a generic header for both in an hour. What sort of abstractions does C++17 enable that you think are useful for creating a 2D sidescrolling platformer (or anything other decades old game) that are so empowering compared to C to sidestep C++17's deficiencies?
- blub 7y ago
  C doesn't provide any abstractions period... there is no such thing as a list or dynamic array in C, at best one can build a leaky abstraction based on structs and pointers with almost zero type safety. Case in point, the SGLIB you mentioned, which uses the same old macro tricks from decades ago. Anything is better than C at providing abstractions for building games, because any language offers more than procedures, crude arrays and structs. C++, Rust, C#, Python, Java, Swift, etc. All of these would run circles around C for almost any kind of possible project.
  - Crinus 7y ago
    > there is no such thing as a list or dynamic array in C, at best one can build a leaky abstraction based on structs and pointers with almost zero type safety First of all, type safety is not necessary to create something fast which is what the original comment was all about and everything i'm writing is in the context of mmoez writing how modern tools enable individuals to do work that decades ago would need entire teams and my reply to that was that this applies to some types of tools and someone who knows C++17 enough to make such a game like those made decades ago wont gain implementation speed from the language itself as opposed using something like C89. I repeat this context because i have a feeling from your replies that you are taking my comments out of it. Second, you can use the preprocessor to create type safe lists, dynamic arrays, etc. In fact SGLIB does exactly that, this is why you pass a type to the macros that declares your list types and functions. But outside of SGLIB's approach you can also use include files as templates with parameters passed outside of it. Here is an example i wrote some weeks ago: https://news.ycombinator.com/item?id=19879059 https://news.ycombinator.com/item?id=19879059 This creates types and functions based on the parameters you give to the header. > Anything is better than C at providing abstractions for building games, because any language offers more than procedures, crude arrays and structs. Also a somewhat decent macro system, but so does C++. However i never argued that C is good at providing abstractions (as i show above you can, but it can be a PITA). C++ and some other languages are better than that, sure. What i argued about is that those abstractions will not cause someone who has enough knowledge to write a game like the one submitted here in C++17 to make it "that would need teams decades ago" faster than if he'd used something like C89. In other words, considering the type of project we're discussing about, even if he gains any speed, it'd be minimal.

>if anything it might be faster in C89. You're underestimating the role played by good abstractions in developer productivity.

by fooker 7y ago

>if anything it might be faster in C89. You're underestimating the role played by good abstractions in developer productivity.

manfredo 7y ago

I don't think the increase in productivity in re-implementing old games lies in ease or programming. It's the fact that all the art assets already exist and all the game design is already done. And not to mention, marketing, HR, etc. are totally out of the picture. For most games, programming is far from the biggest labor cost.

fooker 7y ago
You have contradicted yourself. >For most games, programming is far from the biggest labor cost. And as you say, the other bigger costs are out of the picture when re-implementing old games. So, programming is the largest remaining part, almost by definition of 're-implement'.
- manfredo 7y ago
  I'm pretty confused as to why you think I contradicted myself, and your last couple sentences don't really make sense to me. When making a game from scratch, you need to produce art assets (often 50-70% of the cost of the game is art assets alone), design gameplay mechanics, market the game, test the game, and distribute the game (which, in the old days, often meant making physical cartridges or disks). Let's say that 10% of the labor in making a game from scratch went to programming. When you're re-implementing a game, all you need recreate is that 10%. So if re-implementing a game is an order of magnitude easier than making a game from scratch, there's no reason to think that programming games has gotten any easier.

Crinus 7y ago

I am not, but C++ does not provide any abstractions that would be helpful for a DOS-like game that "someone who has enough knowledge to make a project in C++17 like a game" cannot do (also remember the context in the original message was about stuff made decades ago being made today, not modern AAA engines). Even if you take out the possibility of grabbing something like SGLIB, the two most common data structures in a game you'll need are lists and dynamic arrays and you can create a generic header for both in an hour. What sort of abstractions does C++17 enable that you think are useful for creating a 2D sidescrolling platformer (or anything other decades old game) that are so empowering compared to C to sidestep C++17's deficiencies?

blub 7y ago
C doesn't provide any abstractions period... there is no such thing as a list or dynamic array in C, at best one can build a leaky abstraction based on structs and pointers with almost zero type safety. Case in point, the SGLIB you mentioned, which uses the same old macro tricks from decades ago. Anything is better than C at providing abstractions for building games, because any language offers more than procedures, crude arrays and structs. C++, Rust, C#, Python, Java, Swift, etc. All of these would run circles around C for almost any kind of possible project.
- Crinus 7y ago
  > there is no such thing as a list or dynamic array in C, at best one can build a leaky abstraction based on structs and pointers with almost zero type safety First of all, type safety is not necessary to create something fast which is what the original comment was all about and everything i'm writing is in the context of mmoez writing how modern tools enable individuals to do work that decades ago would need entire teams and my reply to that was that this applies to some types of tools and someone who knows C++17 enough to make such a game like those made decades ago wont gain implementation speed from the language itself as opposed using something like C89. I repeat this context because i have a feeling from your replies that you are taking my comments out of it. Second, you can use the preprocessor to create type safe lists, dynamic arrays, etc. In fact SGLIB does exactly that, this is why you pass a type to the macros that declares your list types and functions. But outside of SGLIB's approach you can also use include files as templates with parameters passed outside of it. Here is an example i wrote some weeks ago: https://news.ycombinator.com/item?id=19879059 https://news.ycombinator.com/item?id=19879059 This creates types and functions based on the parameters you give to the header. > Anything is better than C at providing abstractions for building games, because any language offers more than procedures, crude arrays and structs. Also a somewhat decent macro system, but so does C++. However i never argued that C is good at providing abstractions (as i show above you can, but it can be a PITA). C++ and some other languages are better than that, sure. What i argued about is that those abstractions will not cause someone who has enough knowledge to write a game like the one submitted here in C++17 to make it "that would need teams decades ago" faster than if he'd used something like C89. In other words, considering the type of project we're discussing about, even if he gains any speed, it'd be minimal.