Why does the FPSSample codebase look so foreign?

I downloaded the FPSSample to get some ideas of what a well designed game code base in unity looks like and good lord it appears so foreign to any of the code ive seen in any unity related tutorial I've watched or codebase I've worked with Why is this the case? Is it because the whole game is built on top of this network infrastructure? Almost all the classes implement IComponentData or CharDataFactory or BaseComponentDataSystem... etc. I've been developing games professionally for 2-3 years and looking at this code base makes me feel like john snow.

If anyone knows any open-source unity projects with really clean code bases (Non-networked), please do show :,D

 

Well, it kinda is foreign tech... it is written as a hybrid classic Unity (what you've seen) and the new and evolving ECS/DOTS system, which you can google/read about.

One man's clean is another man's nightmare. Your best bet is to just dive into any project and root through until you understand what's going on a little bit.

I actually gave a talk a year or two ago about one of the best ways to get familiar with any arbitrary project is to look around and use it, then say "I want to change X!" and steadily make X get more and more complicated. Start with trivial, such as "Change the name of the title page!" and move onto the more complex. Take your time, use lots of googling, and if you do that for some breadth of projects over some period of time, you will find suddenly your skill stack has become really flexible.

And you don't have to be on a really recent project either. I took the FPS Rogue game and during my talk made significant changes to it, like enlarged the playfield, made the camera track the player, I forget what all. Another key is, if you get stuck trying to do something, google and ask around (including here), and if you can't "get" it, move onto try something else.

 

If you want to dive in into the new Data oriented design principle read this free e-book. This handles the principle and thought concepts, but not Unity's implementation of it. It just helps to understand why DOD is in many cases better than OOP. And how structuring your program in DOD and "thinking" in those concepts improves your programs in regards to performance and structure (reusability, changeability). If you want to make the transition (which can be hard), read it or even buy the more detailed paperback version. But since Unity's DOTS is still evolving there are just a few example projects and tutorials out there for using DOD specifically in Unity.

 

Thanks for the link @exiguous ... it's also important for 99.9% of developers here to realize that the types of bottlenecks that ECS/DOTS will address are not going to be helpful, mostly.

For instance, if you're doing mobile development, you're almost certainly fill rate bound, and DOTS doesn't change any of that. You just need to send less pixels to the GPU, end of story.

That said, there are plenty of places ECS/DOTS will help, but for the average "I wanna make a flappy bird clone!" developer, that ain't one of the places.

 

Don't want to derail the thread or go offtopic. But the book explains why it is also easier to develop in a DOD manner than with the "regular" OOP aproach. OOP is pretty strict and rigid with its type hierarchies. And when you want/need to change something (pretty common in gamedev) you often have to da a major refactoring, potentially introducing new bugs and issues. Whereas (in theory) DOD allows for easier changes and thus faster development and prototyping. It's initially harder to get into (especially when you have been "indoctrinized" with OOP) but once you get it it changes the way you think. But I'm also not certain wether I can make the transition. But I like the concept and think it is the future and it never hurts to have another tool in your belt.

If you can do calculations more efficient with less random memory access you also save on electricity which extends users battery life.