5 ms·

And your point is? Shipping garbage is better than not shipping anything?

azemetre 9mo ago
Probably a nuanced point in what's the purpose for espousing the virtues of performance if you don't have the output to show it is worth it? If you want advice about making games would you rather learn from the person that routinely ships games or a person that shipped a game once 10 years ago? Is that a trade off worth chasing? "Potential perfection" with nothing to show for it?
- jackling 9mo ago
  More like, shipped 2 hit games, which were both technological and artistic feats for their time. And developed a blazingly fast compiler. Casey also was a developer in RAD game tools developing animation tools. Their output is probably better than most industry developers. I understand if you don't like their attitudes and the way they attempt to teach/preach to other engineers, but IMO their work speaks for itself. I take their advice and try to apply it to my own work, because it seems to have work for them.
  - azemetre 9mo ago
    I'm not saying I don't like their attitudes but it's a viewpoint I am struggling with myself. I'm starting to realize caring about all these minutia of details that don't really matter for my professional goals. I know my software isn't special, caring about pumping out as much performance as possible when I just sling JS professionally feels a tad myopic? What is the point of it just continues the pattern of procrastination towards the actual goals I want to achieve? Does this also apply to them? What is the point of espousing all these supposed virtues when the output isn't that special? I mean Braid is still good, but let's not act like greener devs haven't put out good games too without all the jackassery baggage.
    - jackling 9mo ago
      Yea I largely agree with you on that point. I think when discussing Jon, Casey (and to add another, Mike Acton), there's actually a series of advice that they give that get lumped into a whole, and people don't really see the parts of what they're saying and instead focus on the part that sounds most critical to their work. I do agree that if you take from their "teachings" that every dev needs to optimize every thing, and never use any other language than system languages, that advice is myopic for most devs. However, I don't really see them arguing for that, at least not entirely. From following their teaching for a while, they mostly preech about the following things which I agree with, even when talking about higher-level languages, technologies. - Get the clowns out of the car: Don't make things needlessly expensive. Write simple procedural code that maps cleanly to what the hardware is doing. This is essentially stating OOP, large message passing, and other paradigms that abstract the problem away from the simple computations that are happening on your computer is actually adding complexity that isn't needed. This isn't about tuning your program to get the highest amount of performance, but rather, just write basic code, that is easy to follow and debug, that acts as a data-pipeline as much as possible. Using simple constructs to do the things you want, e.g. an if-statement versus inheritence for dynamic dispatch. - Understand your problem domain, including the hardware, so you can reason about it. Don't abstract away the hardware your code is actually running on too much where you lose vital information on how to make it work well. I've seen this many times in my professional career, where devs don't know what hardware the code will be running on, and this inevitably makes their code slower, less responsive to the user and often drives up cost. There are many times in my early career (backend engineering), that just simplifying the code, designing the code so it works well for the hardware we expect, greatly lowered cost. The hardware is the platform and it shouldn't be ignored. Similarly, limitations that are imposed by your solution should be documented and understood. If you don't expect a TPS greater than some value, write that down, check for it, profile and make sure you know what your specturm of hardware can handle, and how much software utilization of that hardware you're getting. - Focus on writing code, and don't get bogged down my fad methodologies (TDD, OPP, etc). Writing simple code, understanding the problem more deeply as you write, and not placing artifical constraints on yourself. Now each of these points can be debated, but their harder to argue against IMO then the strawmany idea of them proposing that you must optimize as much as possible. And they argue that you will actually be more productive this way, and produce better software. FWIW, you may have some datapoints showing that they do propose what I called a strawmany version of their ideas, but I have seen them advocating for the above points more so than anything else. --- I do want to add, for Jon Blow, I don't think he has a problem with people using engines. From what I've seen he's played, and loved games that used engines in the past, and had no problem with their output in terms of gameplay or performance. From his talk about civilization ending relating to game dev, he's more concern that if no one tries to develop without an engine, we as a civilization will lose that ability.
rcxdude 9mo ago
Fact of the matter is that code quality is a pretty small part of whether a game is good or not. It can be notable when it's good and it can sink a game when it's really bad, but there's a huge gap in the middle where it doesn't really matter that much (especially to the player).
AndriyKunitsyn 9mo ago
Some people actually have mouths to feed. Some people don't have the luxury of preaching for whatever ideals they have without a need to release anything in 10 years; that doesn't make their products "garbage".
- Johanx64 9mo ago
  > Some people don't have the luxury of preaching for whatever ideals they have without a need to release anything in 10 years Wait, how did they gain this "luxury"? Are they trust fund babies or something? Or did they earn their big stash of money by producing "garbage" and now retroactively are preaching ideals that they themselves didn't follow or what? This line of "criticism" doesn't make any sense whatsoever. After all both in question live off money they've made and/or are making from their (arguably) uncompromised quality work. That is to say their uncompromised quality work has directly resulted in them being able to not release anything for close to 10 years, and practice their ideals in software they ship even if the "shipping" takes 10 years to do. It would be more fair to say, that most people don't have the craftmanship and skill (and not the luxury) to be able to produce high quality work and software that enables them the so called "luxury".
  - Capricorn2481 9mo ago
    Just to be clear, your comments are implying everyone who doesn't write everything from scratch is shipping garbage. Ignoring how misinformed that opinion is, I would say The Witness is a very compromised game. Maybe if less focus went into the technical aspect, it could've been better.
    - Johanx64 9mo ago
      You are implying that my comment is implying something about "writing everything from scratch", it is not implying anything of the sort. > Ignoring how misinformed that opinion is You are making up some random opinion (that I supposedly have, but that are nowhere to be found in what I wrote).
  - AndriyKunitsyn 9mo ago
cwyers 9mo ago
If you have bills to pay, it really is.

Probably a nuanced point in what's the purpose for espousing the virtues of performance if you don't have the output to show it is worth it? If you want advice about making games would you rather learn from the person that routinely ships games or a person that shipped a game once 10 years ago? Is that a trade off worth chasing? "Potential perfection" with nothing to show for it?

jackling 9mo ago
More like, shipped 2 hit games, which were both technological and artistic feats for their time. And developed a blazingly fast compiler. Casey also was a developer in RAD game tools developing animation tools. Their output is probably better than most industry developers. I understand if you don't like their attitudes and the way they attempt to teach/preach to other engineers, but IMO their work speaks for itself. I take their advice and try to apply it to my own work, because it seems to have work for them.
- azemetre 9mo ago
  I'm not saying I don't like their attitudes but it's a viewpoint I am struggling with myself. I'm starting to realize caring about all these minutia of details that don't really matter for my professional goals. I know my software isn't special, caring about pumping out as much performance as possible when I just sling JS professionally feels a tad myopic? What is the point of it just continues the pattern of procrastination towards the actual goals I want to achieve? Does this also apply to them? What is the point of espousing all these supposed virtues when the output isn't that special? I mean Braid is still good, but let's not act like greener devs haven't put out good games too without all the jackassery baggage.
  - jackling 9mo ago
    Yea I largely agree with you on that point. I think when discussing Jon, Casey (and to add another, Mike Acton), there's actually a series of advice that they give that get lumped into a whole, and people don't really see the parts of what they're saying and instead focus on the part that sounds most critical to their work. I do agree that if you take from their "teachings" that every dev needs to optimize every thing, and never use any other language than system languages, that advice is myopic for most devs. However, I don't really see them arguing for that, at least not entirely. From following their teaching for a while, they mostly preech about the following things which I agree with, even when talking about higher-level languages, technologies. - Get the clowns out of the car: Don't make things needlessly expensive. Write simple procedural code that maps cleanly to what the hardware is doing. This is essentially stating OOP, large message passing, and other paradigms that abstract the problem away from the simple computations that are happening on your computer is actually adding complexity that isn't needed. This isn't about tuning your program to get the highest amount of performance, but rather, just write basic code, that is easy to follow and debug, that acts as a data-pipeline as much as possible. Using simple constructs to do the things you want, e.g. an if-statement versus inheritence for dynamic dispatch. - Understand your problem domain, including the hardware, so you can reason about it. Don't abstract away the hardware your code is actually running on too much where you lose vital information on how to make it work well. I've seen this many times in my professional career, where devs don't know what hardware the code will be running on, and this inevitably makes their code slower, less responsive to the user and often drives up cost. There are many times in my early career (backend engineering), that just simplifying the code, designing the code so it works well for the hardware we expect, greatly lowered cost. The hardware is the platform and it shouldn't be ignored. Similarly, limitations that are imposed by your solution should be documented and understood. If you don't expect a TPS greater than some value, write that down, check for it, profile and make sure you know what your specturm of hardware can handle, and how much software utilization of that hardware you're getting. - Focus on writing code, and don't get bogged down my fad methodologies (TDD, OPP, etc). Writing simple code, understanding the problem more deeply as you write, and not placing artifical constraints on yourself. Now each of these points can be debated, but their harder to argue against IMO then the strawmany idea of them proposing that you must optimize as much as possible. And they argue that you will actually be more productive this way, and produce better software. FWIW, you may have some datapoints showing that they do propose what I called a strawmany version of their ideas, but I have seen them advocating for the above points more so than anything else. --- I do want to add, for Jon Blow, I don't think he has a problem with people using engines. From what I've seen he's played, and loved games that used engines in the past, and had no problem with their output in terms of gameplay or performance. From his talk about civilization ending relating to game dev, he's more concern that if no one tries to develop without an engine, we as a civilization will lose that ability.

rcxdude 9mo ago

Fact of the matter is that code quality is a pretty small part of whether a game is good or not. It can be notable when it's good and it can sink a game when it's really bad, but there's a huge gap in the middle where it doesn't really matter that much (especially to the player).

AndriyKunitsyn 9mo ago

Some people actually have mouths to feed. Some people don't have the luxury of preaching for whatever ideals they have without a need to release anything in 10 years; that doesn't make their products "garbage".

Johanx64 9mo ago
> Some people don't have the luxury of preaching for whatever ideals they have without a need to release anything in 10 years Wait, how did they gain this "luxury"? Are they trust fund babies or something? Or did they earn their big stash of money by producing "garbage" and now retroactively are preaching ideals that they themselves didn't follow or what? This line of "criticism" doesn't make any sense whatsoever. After all both in question live off money they've made and/or are making from their (arguably) uncompromised quality work. That is to say their uncompromised quality work has directly resulted in them being able to not release anything for close to 10 years, and practice their ideals in software they ship even if the "shipping" takes 10 years to do. It would be more fair to say, that most people don't have the craftmanship and skill (and not the luxury) to be able to produce high quality work and software that enables them the so called "luxury".
- Capricorn2481 9mo ago
  Just to be clear, your comments are implying everyone who doesn't write everything from scratch is shipping garbage. Ignoring how misinformed that opinion is, I would say The Witness is a very compromised game. Maybe if less focus went into the technical aspect, it could've been better.
  - Johanx64 9mo ago
    You are implying that my comment is implying something about "writing everything from scratch", it is not implying anything of the sort. > Ignoring how misinformed that opinion is You are making up some random opinion (that I supposedly have, but that are nowhere to be found in what I wrote).
- AndriyKunitsyn 9mo ago

cwyers 9mo ago

If you have bills to pay, it really is.