What's good place to start learning code architecture

Hello, I'm trying to learn how to create good architecture, I want to write some core design, that could be used in following projects, so I'm searching for ways to learn about code architecture. What's best way to learn about it? apart from hardcore approach: writing 200 games in 10 years and learn from all of your mistakes.

I'm thinking of purchasing any complete project from unity assets store (or getting any open source one), that has good architecture. However there are too many of this projects and it's pretty hard to choose which project should I acquire. Does anyone has any suggestions maybe?

 

You can learn about all the different options that are available from books or tutorials. When to apply which is a grey area, but common sense limits which options are viable. Looking at one complete project probably doesn't reveal all of it and what you really need is experience. And experience is pretty hardcore, it takes a lot of time.

In the end, the things that count are:
- Does everything work as it should.
- If it doesn't work, is it easy to find the problem and fix it.
- Is it easy to change or expand the functionality.

In my opinion, this all comes down to proper reuse of code. So, never copy paste code, but try to reuse it instead. Inheritance, interfaces, generics, delegates, extension methods, they are all means to do this, but which to use where varies.

Edit: And top of those language options come the various design patterns like factories, singletons and many others. It really takes experience, but knowledge of the language and the design patterns is a good base. Without the experience you do tend to overlook the option that might work better in a specific case.

 

I'm with jvo3dc.

Experience is really what it takes. You could read all the theory you want, but until you actually have to exercise that theory in real development, it's not going to make total sense.

Every 'a-ha!' moment I've had reading theory was followed by "Wait... this isn't working the way I thought it would when I read it..." when I go to actually use it.

I will say though, it won't take 200 games over 10 years. Though it will take a while.

A big thing I do... and it's why you'll see me keep coming to these forums (and others) still after so many years. I find forums to be some of the best places to help understand a lot of concepts. There's an awesome mix of people with a lot of different concepts getting thrown around. I keep my ears/eyes open and read what everyone is doing, then go and do my own research on those topics, give them a try in my own code, keep what I like toss out what I don't.

Forums also come with the added benefit of being a great way to test yourself. When learning concepts it's hard to invent questions/hurdles to try and overcome when you don't even know the thing you're learning yet. On a forum people come in asking questions every day. A great quiz, in the wild, for you to test yourself with. Even to this day I do it for the exercise, keep myself thinking about the concepts, and applying it to conditions I myself may not have thought up in my 13 years of doing this.

There's also some pretty cool people around.

 

While I do agree with you generally, I'd think that there should be at least some good reads about this kind of staff. I'm sure that every decent game developer would face this issues, and would try to solve them, so I just think that somehow I failed searching for good resources. Only reliable good source I've found is gameprogrammingpatterns.com it is good, but I'm searching for more, and maybe something similar using Unity.

 

The game industry is young, the 3d game industry is even younger, and the ideas are changing regularly.

I've read various "game" specific books through out the past... and seldom did it really offer me much. 1000 pages, and maybe one concept of use. And a good deal of it is now useless considering it's often engine/framework specific (like I read the entire books on XNA, Torque3d, and others).

Just Unity alone over the years has introduced new concepts, which defunct older design concepts.

I seldom have ever found any one book, website, author, or anything to be much of use beyond being 1 more on the pile of concepts to compare to everything else I read. Especially if that book/author deals with a very niche topic like game design specifically, or a specific game engine/framework.

With all that said, of course Unity has a bunch in their "Learn" section. And you can learn quite a bit from it. But it's going to be very Unity specific of course.

...

If you want to expand outside of a niche topic though. Oh there's tons of stuff I advise you learn.

For example I thoroughly suggest "Concrete Mathematics", it covers some very interesting & useful concepts mathematically. Especially when dealing with continuous vs discrete mathematics (note that computers are inherently discrete due to their finite memory limitations).
https://www.amazon.com/Concrete-Mathematics-Foundation-Computer-Science/dp/0201558025

I've also enjoyed various books that deal with lower level stuff, like learning about how assembly/machine code works and writing some of my own. As well as general algorithmic theory. Donald Knuth's "Art of Programming" covers this rather well.
https://www.amazon.com/Computer-Programming-Volumes-1-4A-Boxed/dp/0321751043

I've also read various books about specific processor types. Like ARM-RISC, x86, etc.

But in the end, these aren't going to make games for you. They're more over-arching concepts.

 

Back when I learnt OOP, the "classic" GoF design patterns were a goto resource for me.
https://www.dofactory.com/net/design-patterns

Question for the full-time game coders (which I am not): Is this still considered good practice? I've read that Unity is shifting away from OOP to a more data driven approach with ECS. What does that mean for code architecture?

 

This means OOP is still in the business for a couple (5-10) years. Yes those patterns are nice to know and use.

DoD (Data-Oriented-Design) is good. It's really good for the performance and code architecture, but requires different thinking.

Classic approach is probably going to be here for a decade or more, depending on how fast UT will roll out their complete (non-experimental) ECS / Burst / Jobs stack. And even after that, legacy projects will probably going to stick with their architecture.

Also, not every project is easier / should be implemented in DoD. Some definitely are, some are not.