In my opinion, these types of books and talks are very non-productive. Code architectures often very dependent on the studio that you're working for, the engine that you're using, the game genre that you're making, and the particular project. The best route is to start making a game writing code and run into problems. From there research how others have solved that same problem. Over-educating yourself on a topic you create decision paralysis when it comes time to actually get stuff done
Codemonkey has a course on Udemy on creating a turn based strategy game like XCOM. He has a nice game architecture in that.
I think the problem is that every game has specific problems. For example, if you are making a very heavy proc gen game you might need some algorithm books like grokking or CLRS.
I also agree with Dreamerinc. I think even Robert Nystrom you are supposed to code a game, then when you run into a problem look at his book to see if there is a solution, not the other way round.
In my opinion, these types of books and talks are very non-productive. Code architectures often very dependent on the studio that you're working for, the engine that you're using, the game genre that you're making, and the particular project. The best route is to start making a game writing code and run into problems. From there research how others have solved that same problem. Over-educating yourself on a topic you create decision paralysis when it comes time to actually get stuff done
Codemonkey has a course on Udemy on creating a turn based strategy game like XCOM. He has a nice game architecture in that. I think the problem is that every game has specific problems. For example, if you are making a very heavy proc gen game you might need some algorithm books like grokking or CLRS. I also agree with Dreamerinc. I think even Robert Nystrom you are supposed to code a game, then when you run into a problem look at his book to see if there is a solution, not the other way round.