4 ms·

I've been programming in the games industry, first at indie scale and now at AAA, and I use almost all of the patterns described in the book in some way. This i

by Kapura 6y ago

I've been programming in the games industry, first at indie scale and now at AAA, and I use almost all of the patterns described in the book in some way. This is an invaluable resource for people to learn not only the sorts of programming patterns used in games, but also the sorts of problems that game developers are challenged to solve. I've found that google and stack overflow are now worthless for anything outside of checking syntax for a C++ lambda. Everything else I work on is essentially a novel problem set.

erikbye 6y ago
> novel problem set Examples?
- Kapura 6y ago
  Well, I've spent the past week tuning our boss fight camera algorithms so that the camera does its best to track the boss if they dash across the room or leap into the air. Nobody can really tell me how to do this outside of our company, because nobody else is dealing with a boss that moves like ours, nobody else has the same camera language constraints, and frankly dealing with algorithmic camera motion is not something most programmers ever have to do. I can look at our other code, I can look at other cameras in game & film, but ultimately it's just me down there in the code deciding whether the pull the camera in or pitch down or lengthen the lens or how to handle blends or whatever.
  - vvanders 6y ago
    Oh man camera systems. We had one dev and an animator spend months getting our camera system to the point where it felt natural. Definitely one of those things that takes a ton of work and only gets noticed when it goes wrong.
mmoll 6y ago
> Everything else I work on is essentially a novel problem set. It‘s a rotate! ;-)
robmaister 6y ago
I 100% agree and I also work in AAA. On the subject of StackOverflow being worthless... I've been working for 4 years now and I have learned pretty consistently over that time that the best way to solve a problem is to just keep digging deeper into the system with the issue. You will eventually figure out that either the system has a bug or you used it wrong. And along the way you will familiarize yourself more with the system. (and debugging tools!) The learning effect of this snowballs the more you do it. I'm a year and a half into a UE4 project and am now the "engine person" who people come to with questions or odd crashes. I have seen every single pattern this book describes used somewhere within Unreal. They are all super valuable to know especially within game programming where problems are novel and often open ended.
- Kapura 6y ago
  >I have learned pretty consistently over that time that the best way to solve a problem is to just keep digging deeper into the system with the issue. >You will eventually figure out that either the system has a bug or you used it wrong. And along the way you will familiarize yourself more with the system. (and debugging tools!) I identify with this so much. It's a different kind of programming, where you're finding the source of the bleeding instead of trying to just bandage the wound, which is much more what I encountered in the tech industry.
- mcv 6y ago
  10 years ago, Stackoverflow was fantastic. I feel a bit like its usefulness has dwindled. But it's never been about debugging deep problems. Nobody can look at what's happening in your debugger. It's mostly useful for how to use specific libraries and frameworks or basic language features.

by Kapura 6y ago

erikbye 6y ago

> novel problem set Examples?

Kapura 6y ago
Well, I've spent the past week tuning our boss fight camera algorithms so that the camera does its best to track the boss if they dash across the room or leap into the air. Nobody can really tell me how to do this outside of our company, because nobody else is dealing with a boss that moves like ours, nobody else has the same camera language constraints, and frankly dealing with algorithmic camera motion is not something most programmers ever have to do. I can look at our other code, I can look at other cameras in game & film, but ultimately it's just me down there in the code deciding whether the pull the camera in or pitch down or lengthen the lens or how to handle blends or whatever.
- vvanders 6y ago
  Oh man camera systems. We had one dev and an animator spend months getting our camera system to the point where it felt natural. Definitely one of those things that takes a ton of work and only gets noticed when it goes wrong.

mmoll 6y ago

> Everything else I work on is essentially a novel problem set. It‘s a rotate! ;-)

robmaister 6y ago

I 100% agree and I also work in AAA. On the subject of StackOverflow being worthless... I've been working for 4 years now and I have learned pretty consistently over that time that the best way to solve a problem is to just keep digging deeper into the system with the issue. You will eventually figure out that either the system has a bug or you used it wrong. And along the way you will familiarize yourself more with the system. (and debugging tools!) The learning effect of this snowballs the more you do it. I'm a year and a half into a UE4 project and am now the "engine person" who people come to with questions or odd crashes. I have seen every single pattern this book describes used somewhere within Unreal. They are all super valuable to know especially within game programming where problems are novel and often open ended.

Kapura 6y ago
>I have learned pretty consistently over that time that the best way to solve a problem is to just keep digging deeper into the system with the issue. >You will eventually figure out that either the system has a bug or you used it wrong. And along the way you will familiarize yourself more with the system. (and debugging tools!) I identify with this so much. It's a different kind of programming, where you're finding the source of the bleeding instead of trying to just bandage the wound, which is much more what I encountered in the tech industry.
mcv 6y ago
10 years ago, Stackoverflow was fantastic. I feel a bit like its usefulness has dwindled. But it's never been about debugging deep problems. Nobody can look at what's happening in your debugger. It's mostly useful for how to use specific libraries and frameworks or basic language features.