10 ms·

You 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 dynamical

by petke 11y ago

You 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. Probably slow and buggy too. But you are not alone. Everyone has their own private code framework that is too complicated for anyone else to make use of. If only there was some way to avoid this mess ...

fennecfoxen 11y ago
> 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.
- chii 11y ago
  > Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. i feel like this is somehow perpetuated like folklore, but there shouldn't be any reason why game code should be inherently less reusable than other areas of software development. For example, code that deal with geometry data shouldn't really be any different for games, or code that deal with setting up a rendering environment ought to be the same for most, if not all games (i can't imagine initializing directx or opengl would be different for different games). Game logic is one area that is going to change a lot between games. However, if you partitioned your game logic well, wouldn't it make the next game easier since you're "just" swapping game logic?
  - loup-vaillant 11y ago
    > code that deal with geometry data shouldn't really be any different for games Counter-example: http://jonathanwhiting.com/games/knossu/ http://jonathanwhiting.com/games/knossu/ (Highly recommended if you have 20 minutes to spare.) The geometry of this game is unlike any I have seen so far. There is common logic with that of a Doom-like ray caster, but I'd argue not much. The time spent rewriting the generic parts of a ray caster probably pales in comparison to the specific parts of his graphics engine. (Of course, your point stands in general. But for Jonathan Whiting in particular, I have the feeling that it may not.)
    - deleted 11y ago
      [deleted]
      - loup-vaillant 11y ago
        Ah, now you've spoiled it! Somehow I have the feeling this game is even more effective when you think of it as a retro game, until you discover by yourself that this world is… not right.
        phyllostachys 11y ago
        Fixed. :)
    - Ace17 11y ago
      Great game, thank you!
  - Rusky 11y ago
    That sort of code does get reused a lot, when games are built on third-party (or in-house) engines. But I don't think it would make sense to just consolidate all of it- engines make different tradeoffs on how geometry data is formatted, laid out, and processed, and that continues to be an area of optimization and innovation. As far as initializing the hardware, that's a relatively small, one-off piece of code that's different for every platform (including consoles) anyway.
- chongli 11y ago
  Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. Huh? I don't know what the numbers are but I'd hazard a guess that the majority of games out there (at least those written by more than one person) use a 3rd party commercial game engine.
- ArkyBeagle 11y ago
  I am relatively sure that we've lost the code reuse wars outright. The problem isn't Yet Another Framework. the problem is mediocrity itself.
lcampbell 11y ago
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 <sys/tree.h> and <sys/queue.h> 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.
crafn 11y ago
That's partly true. However, you do get rid of the complexity you never wanted in the first place. For me this is OOP, RAII, C++ allocators, exceptions, references, vtables (see my post about runtime recompiling), templates (mostly), C++ standard library (I'd have to write my own vector for fast compilation. I'd have to write my own hash map to get contiguous storage (IIRC)) C is by no means optimal, but it's still one of the least bad languages to write games with.
- hellofunk 11y ago
  I really like this idea of using C as a main language, but when you mention writing your own vector and hash map implementations (and undoubtedly many other fundamental tools that are otherwise provided for you by STL), doesn't that get quite time-consuming to re-invent the wheel in those areas that it's great to have a wheel already there for you?
  - nautical 11y ago
    Generally speaking , people tend to re-use the code . I have a complete folder filled with tons of reusable snippets which I keep optimizing there and there if some new idea comes up , otherwise they are good .
    - hellofunk 11y ago
      Put those puppies up on github for the rest of us to enjoy! or, if not, can you recommend some good repos that showcase great C snippets that help in a lot of situations?
  - crafn 11y ago
    When you drop the semantic silliness of C++, like having the container to take care of constructing, copying, moving, and destructing, not to mention exception safety, a basic implementation of a "templated" dynamic array implementation in C comes down to like 100 lines. Hash map will be a bit more, and is not so trivial to write. It's true that there should be no need to write these things yourself. The alternative C++ gives is not really tempting. A language designed for demanding game development doesn't exist (yet), so one evaluates which is the least worse option.
akavel 11y ago
I believe that there are actually some third-party libraries for C, which evolved in the open-source ecosystem since K&R, which potentially provide quite much interesting stuff. At some point I've stumbled upon some string library for example, I believe it might have been http://bstring.sourceforge.net/ http://bstring.sourceforge.net/. To respond e.g. to your specific concern about containers - some quick googling for "C containers library" seems to give e.g. https://code.google.com/p/ccl/ https://code.google.com/p/ccl/. 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...
ArkyBeagle 11y ago
Yep. Then you can control the complexity. It's not for everybody. "Containers" are actually quite easy without bespoke libraries in 'C'. And sorting is built-in. A simple example: http://www.codeproject.com/Articles/108830/Inheritance-and-Polymorphism-in-C http://www.codeproject.com/Articles/108830/Inheritance-and-P... Throwing languages at problems is in itself a Tower of Babel problem. We need to emphasize mechanism and not tools. But people gain reputation not by producing correct implementation but by leading revolutions against the status quo.

by petke 11y ago

fennecfoxen 11y ago

> 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.

chii 11y ago
> Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. i feel like this is somehow perpetuated like folklore, but there shouldn't be any reason why game code should be inherently less reusable than other areas of software development. For example, code that deal with geometry data shouldn't really be any different for games, or code that deal with setting up a rendering environment ought to be the same for most, if not all games (i can't imagine initializing directx or opengl would be different for different games). Game logic is one area that is going to change a lot between games. However, if you partitioned your game logic well, wouldn't it make the next game easier since you're "just" swapping game logic?
- loup-vaillant 11y ago
  > code that deal with geometry data shouldn't really be any different for games Counter-example: http://jonathanwhiting.com/games/knossu/ http://jonathanwhiting.com/games/knossu/ (Highly recommended if you have 20 minutes to spare.) The geometry of this game is unlike any I have seen so far. There is common logic with that of a Doom-like ray caster, but I'd argue not much. The time spent rewriting the generic parts of a ray caster probably pales in comparison to the specific parts of his graphics engine. (Of course, your point stands in general. But for Jonathan Whiting in particular, I have the feeling that it may not.)
  - deleted 11y ago
    [deleted]
    - loup-vaillant 11y ago
      Ah, now you've spoiled it! Somehow I have the feeling this game is even more effective when you think of it as a retro game, until you discover by yourself that this world is… not right.
      - phyllostachys 11y ago
        Fixed. :)
  - Ace17 11y ago
    Great game, thank you!
- Rusky 11y ago
  That sort of code does get reused a lot, when games are built on third-party (or in-house) engines. But I don't think it would make sense to just consolidate all of it- engines make different tradeoffs on how geometry data is formatted, laid out, and processed, and that continues to be an area of optimization and innovation. As far as initializing the hardware, that's a relatively small, one-off piece of code that's different for every platform (including consoles) anyway.
chongli 11y ago
Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. Huh? I don't know what the numbers are but I'd hazard a guess that the majority of games out there (at least those written by more than one person) use a 3rd party commercial game engine.
ArkyBeagle 11y ago
I am relatively sure that we've lost the code reuse wars outright. The problem isn't Yet Another Framework. the problem is mediocrity itself.

lcampbell 11y ago

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 <sys/tree.h> and <sys/queue.h> 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.

crafn 11y ago

That's partly true. However, you do get rid of the complexity you never wanted in the first place. For me this is OOP, RAII, C++ allocators, exceptions, references, vtables (see my post about runtime recompiling), templates (mostly), C++ standard library (I'd have to write my own vector for fast compilation. I'd have to write my own hash map to get contiguous storage (IIRC)) C is by no means optimal, but it's still one of the least bad languages to write games with.

hellofunk 11y ago
I really like this idea of using C as a main language, but when you mention writing your own vector and hash map implementations (and undoubtedly many other fundamental tools that are otherwise provided for you by STL), doesn't that get quite time-consuming to re-invent the wheel in those areas that it's great to have a wheel already there for you?
- nautical 11y ago
  Generally speaking , people tend to re-use the code . I have a complete folder filled with tons of reusable snippets which I keep optimizing there and there if some new idea comes up , otherwise they are good .
  - hellofunk 11y ago
    Put those puppies up on github for the rest of us to enjoy! or, if not, can you recommend some good repos that showcase great C snippets that help in a lot of situations?
- crafn 11y ago
  When you drop the semantic silliness of C++, like having the container to take care of constructing, copying, moving, and destructing, not to mention exception safety, a basic implementation of a "templated" dynamic array implementation in C comes down to like 100 lines. Hash map will be a bit more, and is not so trivial to write. It's true that there should be no need to write these things yourself. The alternative C++ gives is not really tempting. A language designed for demanding game development doesn't exist (yet), so one evaluates which is the least worse option.

akavel 11y ago

I believe that there are actually some third-party libraries for C, which evolved in the open-source ecosystem since K&R, which potentially provide quite much interesting stuff. At some point I've stumbled upon some string library for example, I believe it might have been http://bstring.sourceforge.net/ http://bstring.sourceforge.net/. To respond e.g. to your specific concern about containers - some quick googling for "C containers library" seems to give e.g. https://code.google.com/p/ccl/ https://code.google.com/p/ccl/. 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...

ArkyBeagle 11y ago

Yep. Then you can control the complexity. It's not for everybody. "Containers" are actually quite easy without bespoke libraries in 'C'. And sorting is built-in. A simple example: http://www.codeproject.com/Articles/108830/Inheritance-and-Polymorphism-in-C http://www.codeproject.com/Articles/108830/Inheritance-and-P... Throwing languages at problems is in itself a Tower of Babel problem. We need to emphasize mechanism and not tools. But people gain reputation not by producing correct implementation but by leading revolutions against the status quo.