"in this scenario optimisation is not a big deal" As a game dev community, we should be very careful about not fostering this sentiment. Its so important especially in the more mobile moving development world (by this I mean the eventual return to hand held gaming and VR not just mobile) Things like pushing to use Sqr Distance over distance, understanding the cost of list and hash etc... and especially linq vs foreach vs for. Teaching optimisation second leads to worse developers
But it's also important to understand the improvements over time. Recent C# (not in unity yet) has massive improvements for linq which are very important to know
As an old school game developer from the late 90s through the late 00s I embrace these concepts. I wrote early BREW titles on handsets with less capability than your toaster. We had to do some serious wizardy tricks to get some of that stuff to fit and be usable. That was all C++ on old school BREW handsets. Before that I wrote games for DOS, so yeah :D One thing to caution though - as Knuth said, Premature Optimization Is the Root of All Evil. Don't optimize something that doesn't need to be optimize and don't think you already know what needs to be optimized before you start stress testing. Optimization is important, but it should be your second thought. Your very next thought that is - after you have completed your game design. Obviously follow good design principles, but that should go without saying. Don't look at a function though and say, "hmm, that can be optimized" and start refactoring. That's the source of so many bugs, and frankly, it's something I see juniors do ALL the time. I have one guy on my team who is a junior, but he happens to have a PhD in physics. He constantly wants to optimize and refactor. He has caused more bugs than he has solved with that.
Absolutely, I'm still relatively new to programming - 4ish but more and more recently I've been trying to step away from "okay I need this optimized as I can on the first go" that also includes systems, sometimes I dont need them to be as complex as they are but I think "it'll be easier to extend in the future if I make this super customizable and designer friendly" - I am the sole programmer on this project and the only one who does the stuff in Unity. I end up not needing it and instead its just wasted time and thinking power that could have been used elsewhere. As I improve in my skillset I have been trying more and more to step away from that "it has to run the best it can" mentality - unless it's absolutely needed or asked for, it's not really needed to be optimized. You seem a bit more experienced, if I could ask a quick question. In your opinion what do you think separates Intermediate Developers from Seniors? I'd love some suggestions in taking that next step!@@BitwiseMobile
LINQ is a fabulous tool in many aspects. I use it in my work frequently, so it's nice to see this being a tool in game dev! Works great for many aspects and helps learn even more into various data operation tasks.
I *really* like LINQ! It reduces a lot of the madness that goes into writing endless for loops. Lately I started coding my own LINQ extensions, although my main complaint is that C# doesn't really have interfaces for types that can be "added", "multiplied", etc (IAddable? IMultiplicable?). The quickest workaround is just to create multiple variants of the same extension method for different types, which is really bad. 😬 If I'm not incorrect, interfaces for arithemtic operations are coming soon to C#, so I think that will really make writing LINQ extensions waaay easier!
Sine a few folks have expressed concern over performance with LINQ they may have inadvertently given you a topic for a video (profiling, refactoring, optimizing) these queries:)
The type hints and parameter name hints make it extremely hard to read the code and understand your explanation because they are not standard C# constructs. If I try to type what I am looking at it won't work. I also don't understand what is the point of using var if you are going to use type hints, it would be much better to use explicit types in these cases IMO.
It comes in hand for refactoring. Let's say you decided to go with a double return value on a function instead of an int, for whatever reason. Now all those places you explicitly typed it as int have to be changed. Sure, you could do a find and replace, but then you have to deal with valid int statements. If I use var it's a no brainer. int foo = Bar() vs var foo = Bar() If Bar changes from say int Bar() to double Bar(), now you don't have to worry about changing the explicit type. Since it's implicit it will compile just fine. Of course if you are calling int functions on foo that will break, but you would expect that regardless.
It would be good idea to also explain closures, because they are closely related to problems with linq queries. I think a lot of beginners do not know about them
@@PixelBlight If you need to do a get component, then you would have a script on that object that would cache that for you, then all you would do is then access the cached variable on that object. As for the LinQ, then you would leave it as an IEnumerable, but if it is not in an update then you could ignore creating a list. Using an IEunemrable also has issues, if one is not aware of how they work.
Just don't use it in a render loop. Use it for menu items, settings, reacting to a menu or button click, or in game startup or shutdown, things like that.
Yes and it creates garbage by allocating memory. Because its easy and fast you can use it while developing ( I simply avoid to use it in core loops) . If you do an optimization pass its quite easy to replace ( probably ai assistant can even do it for you)
Recent C# has MASSIVE improvements for linq. It is extremely vital to understand when it is appropriate and when it is definitely not appropriate for linq
It's not "extremely" inneficient. The vast majority of use cases are scenarios where performance doesn't matter. It only matters when you have hundreds to thousands plus elements doing complicated logic every frame, and even then you can use parallel link if your objects are not unity ones and it will likely end up even faster than you would be able to implement manually without spending a lot of time on it.
How did you assume that MOST of the developers don't use linq? I used to watch you a lot but recent videos are just pure click baits, sadly but unsubbing
Most of the ones I've talked to recently (especially at the beginner level) are still surprised by it. You dont' see many linq statements in gamedev tutorials (at least I don't). In web/enterprise it's beyond common, but for the game only devs I've seen that more than half of them either have never seen linq statements or don't understand what they are enough to try writing one :)
@@nopepsi206 I mean you can be pedantic if you want, but he did say gamedev, and yes, developers, senior and junior alike, use LINQ often in business logic production code. I'm a Senior Architect with over 25 years experience. I've seen it all. I even wrote my own LINQ before it existed back in C# 1.1 around 2005. I called it ObjectQuery and I still have it in my GitHub. I wrote an SQL compiler to generate reflection based on an SQL-like language for querying objects. I've actually been using C# since it was beta. I worked for a company that was a Qualcomm/Microsoft joint venture and Microsoft allowed us to be beta testers for .Net. We rewrote our entire C++ ISAPI layer with C# and it went from tens of thousands of lines of complex C++ code to a thousand lines of C# :D
Not sure why my comment never got posted, but here it is again. ServerCharacter mostExperiencedCleric = ( from t in charactersInRange where t.Shared.Class.Value == CharacterClass.Cleric orderby t.Shared.Experience.Value descending select t ).FirstOrDefault(); I don't recommend using LINQ this way, just because it's confusing to look at, but it's wild seeing the IDE be cool with it.
I agree, it's readable for people familiar with SQL and relational databases in general. But, when you're working with other developers in a professional setting, it might not be appreciated. If you're a one-person team, though, go nuts and have fun :)
I prefer the method syntax. It's much more readable. var mostExperiencedCleric = charactersInRange .Where(t => t.SharedClass.Value == CharacterClass.Cleric) .OrderByDescending(t => t.Shared.Experience.Value) .FirstOrDefault(); Also, the IDE has been "cool" with it since 2007. :D
@@BitwiseMobile I prefer that syntax too. I've never used the SQL-style syntax in a serious project, I just stumbled across it once and it blew my mind that it worked. I only shared for amusement value.
Wow, you've really been putting out a lot of videos this week. Awesome!
"in this scenario optimisation is not a big deal"
As a game dev community, we should be very careful about not fostering this sentiment.
Its so important especially in the more mobile moving development world (by this I mean the eventual return to hand held gaming and VR not just mobile)
Things like pushing to use Sqr Distance over distance, understanding the cost of list and hash etc... and especially linq vs foreach vs for.
Teaching optimisation second leads to worse developers
But it's also important to understand the improvements over time.
Recent C# (not in unity yet) has massive improvements for linq which are very important to know
I very much appreciate being proactive in pushing for profiling.
True but you also have to watch for premature optimization. That ones a killer of time and potential productivity - theres a nice middleground.
As an old school game developer from the late 90s through the late 00s I embrace these concepts. I wrote early BREW titles on handsets with less capability than your toaster. We had to do some serious wizardy tricks to get some of that stuff to fit and be usable. That was all C++ on old school BREW handsets. Before that I wrote games for DOS, so yeah :D One thing to caution though - as Knuth said, Premature Optimization Is the Root of All Evil. Don't optimize something that doesn't need to be optimize and don't think you already know what needs to be optimized before you start stress testing. Optimization is important, but it should be your second thought. Your very next thought that is - after you have completed your game design. Obviously follow good design principles, but that should go without saying. Don't look at a function though and say, "hmm, that can be optimized" and start refactoring. That's the source of so many bugs, and frankly, it's something I see juniors do ALL the time. I have one guy on my team who is a junior, but he happens to have a PhD in physics. He constantly wants to optimize and refactor. He has caused more bugs than he has solved with that.
Absolutely, I'm still relatively new to programming - 4ish but more and more recently I've been trying to step away from "okay I need this optimized as I can on the first go" that also includes systems, sometimes I dont need them to be as complex as they are but I think "it'll be easier to extend in the future if I make this super customizable and designer friendly" - I am the sole programmer on this project and the only one who does the stuff in Unity. I end up not needing it and instead its just wasted time and thinking power that could have been used elsewhere. As I improve in my skillset I have been trying more and more to step away from that "it has to run the best it can" mentality - unless it's absolutely needed or asked for, it's not really needed to be optimized.
You seem a bit more experienced, if I could ask a quick question. In your opinion what do you think separates Intermediate Developers from Seniors? I'd love some suggestions in taking that next step!@@BitwiseMobile
I love these deeper, advanced tutorials.
Love your work, man. Thanks for the insight.
minor correction: the .ForEach at 4:25 is not Linq but actually a default List method
And, aggravatingly, does not exist for IEnumerable! Argh!
@@manzellit's easy to write a decorator.
LINQ is a fabulous tool in many aspects. I use it in my work frequently, so it's nice to see this being a tool in game dev! Works great for many aspects and helps learn even more into various data operation tasks.
I use it all the time as well. I use Find and Any here and there, and ToList now and then. It's handy.
I *really* like LINQ! It reduces a lot of the madness that goes into writing endless for loops.
Lately I started coding my own LINQ extensions, although my main complaint is that C# doesn't really have interfaces for types that can be "added", "multiplied", etc (IAddable? IMultiplicable?). The quickest workaround is just to create multiple variants of the same extension method for different types, which is really bad. 😬 If I'm not incorrect, interfaces for arithemtic operations are coming soon to C#, so I think that will really make writing LINQ extensions waaay easier!
Maybe not quite what you mean, but the .Sum is very useful imo!
Sine a few folks have expressed concern over performance with LINQ they may have inadvertently given you a topic for a video (profiling, refactoring, optimizing) these queries:)
Linq, is super nice for going through lists arrays dic ect. for keeping code nice and clean.
I'm thinking about units to be self registering to some collection service you write. Would it help on perfomarnce?
Definitely the way to go with any collection that's being used regularly like units, spawned items, etc
The type hints and parameter name hints make it extremely hard to read the code and understand your explanation because they are not standard C# constructs. If I try to type what I am looking at it won't work.
I also don't understand what is the point of using var if you are going to use type hints, it would be much better to use explicit types in these cases IMO.
It comes in hand for refactoring. Let's say you decided to go with a double return value on a function instead of an int, for whatever reason. Now all those places you explicitly typed it as int have to be changed. Sure, you could do a find and replace, but then you have to deal with valid int statements. If I use var it's a no brainer.
int foo = Bar()
vs
var foo = Bar()
If Bar changes from say int Bar() to double Bar(), now you don't have to worry about changing the explicit type. Since it's implicit it will compile just fine. Of course if you are calling int functions on foo that will break, but you would expect that regardless.
sadly for me, i'm not used to lambdas and i have hard times reading this kind of code :(
probably in 2024 most of new programmers , we must to focus more on C# and .Net before advance in Unity .
I absolutely love LINQ
It would be good idea to also explain closures, because they are closely related to problems with linq queries. I think a lot of beginners do not know about them
Use Linq on irregular events. Are we at the point of Unity being totally event-driven? Do coroutines count?!
a loop that does a GetComponent and then converts to a list, OMG that screams bad code right off the bat.
One could argue that. How would you go around solving it though?
@@PixelBlight If you need to do a get component, then you would have a script on that object that would cache that for you, then all you would do is then access the cached variable on that object. As for the LinQ, then you would leave it as an IEnumerable, but if it is not in an update then you could ignore creating a list. Using an IEunemrable also has issues, if one is not aware of how they work.
I heard Linq is extremely inefficient
He addresses that at 7:30-9:10
Just don't use it in a render loop. Use it for menu items, settings, reacting to a menu or button click, or in game startup or shutdown, things like that.
Yes and it creates garbage by allocating memory. Because its easy and fast you can use it while developing ( I simply avoid to use it in core loops) . If you do an optimization pass its quite easy to replace ( probably ai assistant can even do it for you)
Recent C# has MASSIVE improvements for linq.
It is extremely vital to understand when it is appropriate and when it is definitely not appropriate for linq
It's not "extremely" inneficient. The vast majority of use cases are scenarios where performance doesn't matter. It only matters when you have hundreds to thousands plus elements doing complicated logic every frame, and even then you can use parallel link if your objects are not unity ones and it will likely end up even faster than you would be able to implement manually without spending a lot of time on it.
How did you assume that MOST of the developers don't use linq? I used to watch you a lot but recent videos are just pure click baits, sadly but unsubbing
Most of the ones I've talked to recently (especially at the beginner level) are still surprised by it. You dont' see many linq statements in gamedev tutorials (at least I don't). In web/enterprise it's beyond common, but for the game only devs I've seen that more than half of them either have never seen linq statements or don't understand what they are enough to try writing one :)
most of the ones i've talked to != most gamedevs lol@@Unity3dCollege
@@nopepsi206 I mean you can be pedantic if you want, but he did say gamedev, and yes, developers, senior and junior alike, use LINQ often in business logic production code. I'm a Senior Architect with over 25 years experience. I've seen it all. I even wrote my own LINQ before it existed back in C# 1.1 around 2005. I called it ObjectQuery and I still have it in my GitHub. I wrote an SQL compiler to generate reflection based on an SQL-like language for querying objects. I've actually been using C# since it was beta. I worked for a company that was a Qualcomm/Microsoft joint venture and Microsoft allowed us to be beta testers for .Net. We rewrote our entire C++ ISAPI layer with C# and it went from tens of thousands of lines of complex C++ code to a thousand lines of C# :D
Not sure why my comment never got posted, but here it is again.
ServerCharacter mostExperiencedCleric = (
from t in charactersInRange
where t.Shared.Class.Value == CharacterClass.Cleric
orderby t.Shared.Experience.Value descending
select t
).FirstOrDefault();
I don't recommend using LINQ this way, just because it's confusing to look at, but it's wild seeing the IDE be cool with it.
I learned SQL before C#, totally readable to me!
I agree, it's readable for people familiar with SQL and relational databases in general. But, when you're working with other developers in a professional setting, it might not be appreciated. If you're a one-person team, though, go nuts and have fun :)
I prefer the method syntax. It's much more readable.
var mostExperiencedCleric =
charactersInRange
.Where(t => t.SharedClass.Value == CharacterClass.Cleric)
.OrderByDescending(t => t.Shared.Experience.Value)
.FirstOrDefault();
Also, the IDE has been "cool" with it since 2007. :D
@@BitwiseMobile I prefer that syntax too. I've never used the SQL-style syntax in a serious project, I just stumbled across it once and it blew my mind that it worked. I only shared for amusement value.