Serialized Field Vs Public properties | Unity Game Dev Tutorial

[@LostRelicGames]

I really hope you find the info in this video useful, if you do consider giving it a like! Also come chat we me on discord yo :) discord.gg/yeTuU53

[@salvatorealexander997]

I guess Im pretty randomly asking but do anybody know a good website to stream newly released tv shows online?

[@rogeliovalentino3826]

@Salvatore Alexander i would suggest Flixzone. You can find it on google =)

[@abdielernesto9051]

@Rogelio Valentino Definitely, been using Flixzone for since march myself :)

[@kendalljavion3533]

@Rogelio Valentino Thanks, I signed up and it seems like a nice service =) I really appreciate it!!

[@jaysonderek8314]

@Salvatore Alexander No problem xD

[@IanSRutter]

WOW! Great explanation and clear as glass to me. I've been following some tutorials from Learn Unity and the tutorials they have created have been teaching me to show within the Inspector by adding public to everything within the Script. Then I started to also follow Gamedev Complete C# Unity Game Developer 3D by Rick Davidson and he has made learning Unity very enjoyable, but watching him, he's using [Serialized] which got me confused. Immediately I just thought that the two commands do the same. I asked on Discord and the answer was half answered to why?, BUT your video cleared up the reasons why we would use [Serialized]. Thanks for taking the time to make this video it really does help a lot.

[@TheSerphmx]

I think it is important to point out that with Serialize Fields you can use de 'Header' and 'Tooltip' to keep things organized. In my personal experience it has helped a lot to use those. Other than that, great video again John! Thanks!

[@LostRelicGames]

Great idea, I don't use them enough myself actually, though I am aware, might make for a good vid topic! Thanks for the comment man!

[@yobeenocreative6984]

Hey Cheers, John. I just started using Serialized Field, as you mentioned 'via a tutorial', and your vid makes it very clear, benefits in using it. As a artist/coder, making stuff that works, but now wanting to make cleaner stuff that works - I've often wondered about limiting information exposed between systems, to ensure only information that is necessary is shared, and this looks like a big part of the solution. Thanks man.

[@JimmyKadesch]

thanks for the info dude, your videos are always super helpful! *tips hat

[@LostRelicGames]

And a thanks from me to you for supporting my channel with views and positive comments!

[@khalidzoz4186]

In summary, when you limit access of variables, it's easier to debug and focus on certain problems in certain areas. For example if a certain func is not working properly in a certain class, you know exactly where to look and debug because that func only has access to certain fields. In other words you only have to be worried about whatever that func sees as public(because it can actually use it). That's why I think it's better to limit access whenever possible.

[@chaosmastermind]

Oh, it's like having a separate phone for your other girlfriends. And when you get a random text from one of them, you won't be confused as to who it came from or send one to the wrong person. Kinda makes sense now. It really doesn't matter at all.. until you mess up.

[@cordeirokord]

Genius

[@ultim8sceptile584]

lmao you're a programmer, do you really think we believe you?

[@chaosmastermind]

@@ultim8sceptile584 About what?

[@bradleysmith9924]

Thank you so much, very clear breakdown. One step at a time I'm understanding more and more about programming. :)

[@andrespascal116]

After 100 Unity videos where "programmers" break encapsulation, finally I found one that knows about Object Orientation. Good Job!

[@rohit-bq6ox]

I m just beginning my solo game Dev journey...n I find ur explanation is quite goood.......keep up the good work....ur awesome...ur an awesome asset tovus

[@LostRelicGames]

Very kind words, wishing you the best

[@antalaai]

that's great infos. I remember when I started and made everything public "just in case I need it"

[@daichi_devs]

I'm taking a Java course after work and the prof. told us that fields should always be private and use getters and setters to access them from other classes. So you are bang on! I'd definitely would love a more in-depth video about this!! Thanks always

[@saito853]

This video is actually full of misinformation, in C# the getters and setters are called Properties, while a field, public or not, is still a field (he called it property).

[@urasha6692]

Thanks a lot for this video! I've tried to find some information, when we need to use serialize fields or public fields, for a long time... and I did it. P.S. hello from Russia :)

[@sifsif2725]

Thanks, I never really understood why some used public and other used SerializeField

[@scottisitt]

You can also use public getter methods to make your private variable/property accessible to other classes.

[@array8265]

Thanks so much for this is exactly the question im concerning about while didnt find an answer in other place

[@maximeumbra7235]

If you need exposed fields but you also want the safety of a private setter AND you still want to set the value in the inspector what you can do is an autoproperty with auto backingfield. [field: SerializeField] public Type Propname { get; private set; } you can also assign default value in it as you would a field by appending = defaultValue;

[@nightlifekid7843]

love that nice bit sense of humor in that video

[@معرفية]

Great information So happy i found your channel

[@LostRelicGames]

Hey thanks! :)

[@randallN-sw6ee]

Lost Relic Games, thank you very much for this highly excellent tutorial! You explained what serialize field does, why we use it, what microsoft documentation says, why violating encapsulation is bad, you gave very short and simple code examples, etc.. highly underrated channel and more programmers online should teach like you do.

[@BulletsToBrainRatio]

6:26 Bold of you to assume web developers follow best practices.

[@Dreyko5893]

Totally agree

[@serkan.bircan]

They called attributes. 4:16

[@yadav-r]

Very helpful, thank you.

[@lawh1ify]

Thanks man! Love your videos 👌👌

[@FISS007]

In C#, the default modifier is internal and not private. Just to clarify. Internal is public within the current assembly. Private is private everywhere. Also, i doubt that a private field would've been accessible through the inspector though.

[@Nowfen]

I've been trying to know about how to develop games and if I wanna make a project that I want to really finish then I need not just blind determination but how to really optimize the game so I can put more mechanics with smooth fps. so thx for the tutorial 👍

[@cosmotect]

Thank you very much!

[@Muhammadfaisal-ex8ip]

Your so amazing man 😣 thanks for your tutorial

[@LostRelicGames]

Kind words bro. Thanks for your comments and support

[@abdulkadirdursn]

Great video. Thank you

[@TheIronHeadRat]

Thanks for sharing 👍

[@mehmedcavas3069]

they should make it so that if you want it visible in the editor you have to write serialized field. Or they made it so that it is easier to learn because most new developers use all variables and functions public

[@LostRelicGames]

I agree, having it mandatory would push new developers onto better habits. Having everything public is a big no no, and this inspector reveal utility has been a big cause of spreading it.

[@JohnSmith-ox3gy]

Everything is private on default for a reason.

[@valeriopavan]

Hello, good tutorial man! 😊. I perfectly understand the field serialization in order to encapsulate classes... but I keep not understanding the different way the serialized fields behaves with data. For example, what is the difference between using a public variable and a public (serialized) variable? AI tells me when I save a scene, values changed in inspector persist only if they are serialized... but that's not true, because both values (serialized and not) are reloaded when I reload the scene... I'm very confused...

[@jeffmccloud905]

quote from .NET Class Design Guidelines (this has been there since 2001): "❌ DO NOT provide instance fields that are public or protected." followed by "You should provide properties for accessing fields instead of making them public or protected."

[@skelettman]

Fantastic explanation :)

[@sohankaushik7]

Helpful tutorial!!👍

[@v1n3ss]

Great video. I wonder why you have no warnings in the console, because your private field is never set (only through the inspector, which the compiler doesnt know). This really annoys me. I dont want to have useless warnings spamming my console, but initializing the fields to 0 or null feels also not right.

[@xellart]

The serialized field tag just marks a field to also be serialized by unity when it's serializing the object that has this field. Class visibility has nothing to do with this. Unity just happens to automatically serialise public fields.

[@zyrha]

Having too many public variables might affect a game's performance?

[@waynewestlake8120]

I had been taught when learning Java that you pretty much keep properties private however if something needs to access a property to change it then you create a public method that can be called. That way at least it's not an accidental access when doing as you showed, auto-complete in the editor.

[@billmularski1865]

In C# though instead of getters and setters you should just use: public int MyProperty { get; set; }

[@mateuszpatua3016]

[@tubertmorti8282]

THIS: is why I use public to show fields in the inspector. Sure this makes them unnecessarily accessible by all other classes, but I don't get spammed with this warning while I'm debugging. And this value was used in many code blocks and the value is never 0. Maybe [SerializeFeild] is an old Unity thing. I never use it. And using private or public in front of voids is seemingly okay too, I mean Unity's built in functions like Update and Start, automatically paste it in as private if not declared public. But that may just be Visual Studio. I'd switch to Rider if I could afford it. Assets\PlayerController.cs(14,28): warning CS0649: Field 'PlayerController.gravity' is never assigned to, and will always have its default value 0

[@crit_cannon1090]

quick question. if i used a serialized field, would i still be able to access the property if i made it into a "namespace"? as in when im making my character controller and separate the jump from the weapon firing but wanted to have my jump referenced in the jetpack (for instance), would i be able to access properties?

[@lenecrogaming]

I got a question, how may I serialize an instance of GameObject because i just get an error on unity interface?

[@kodaloid]

Auto properties are useful because you can control weather you can read or write to them using the get and set. The idea is that your real properties remain private, and auto properties act as the gateway to accessing them (if they grant access). It should be mentioned though that the act of exposing properties to the outside world is not necessarily evil, and in-fact is a vital tool for many situations, which is why auto properties exist. For example if you are building a C# program using a desktop framework like WPF or WinForms, controls (like TextBox, ListView etc...) expose properties to allow you to customise their look and behaviour. Just trying to enhance and clarify what John meant in this video.

[@jr8209]

sweet. thx bud

[@JKGAMES01]

Thank you

[@LostRelicGames]

You got it!

[@nunnyu]

thx 🙂

[@LennoxParsec]

So if i don't need any other script to deal with my variables, i should always go with [Serialized Field] instead of public?

[@lgtwzrd]

I some times wonder if this "encapsulation" thingy is the reason why I run into so many weird to find bugs on my code. I have yet to make use of serialized Field, but I'll try to use it in the near future and see if it helps me from a lot of headache. Thanks.

[@tlgt]

Good overview. Unfortunately, you mix up fields and properties, which may be confusing for beginners. Apart from the end of the video, you show serialized and public fields, but call them properties. Two related, but different concepts.

[@pixies64]

Is it bad practise to have a load of serialised fields? I tend to use it to tweek variables and sometimes hard code them afterwards but not always

[@Bjarkediedrage]

I also learned from school that Properties was the way to go, but this whole OOP mindset leads super bad and unnecessarily encapsulated, low performance code. It more often than not, create more problems than it solves. If you want to see a good example of OOP, go check out the source-code for the Unity Animator class, by coincidence, it is also one of the the worst API's I've ever come across - you can't do ANYTHING it wasn't designed to do. And so people start using reflection, hacking workarounds in there constantly... Which leads to hard-to-maintain, read, and slow performant code. Which is exactly what happens to codebases made with an OOP mindset in general... I'm now in a completely different mindset, and only rarely use properties, I think much more in terms of data, and data structures - That means, lots of structs and lots of public fields! (very rarely private data), as.. It's just data.. Nothing to be afraid of. It's nice for performance, it's makes your functions super simple and easy to understand, as you are doing computing on data, and not doing work on some abstract level, that has nothing to do with computing. You are writing instructions for the CPU, thinking about memory and data. Properties are bad for so many reasons - whenever I see a property I also go: oh no, yet another peace of data, I can't access without calling a method to get the field.. Who knows what's going on between that layer. Even Unity has introduced countless bugs in their own code-base, because they didn't know, that getting the data of some property would actually go an do other unexpected work behind the scenes. Who knew! Camera.main is super slow - now people post gifs and tips and blogposts about, how not to use camera.main. But Unity had made it a method instead - (Which properties actually are) and called it GetMainCameraByTagName() then people would likely think twice about using it runtime every time they called the freaking thing. I could go on.. Luckily, Unity has also learned this lesson, and you'll see more and more public fields throughout 2020 and 2021 in Unity's code-base as they adapt more and more data oriented design principles. I would highly encourage people to check out Mike Acton's data oriented design video, and also check out what Jonathan Blow and Casey Muritori is up to! You'll learn so much more meaningful things.

[@outlander234]

I am still amateur game dev looking to make it some day. Never went to school, self thought, read a few books about computer architecture, C and assembly language. I always felt alot of stuff in oop was over the top. Its all just data and functions and pointers to data and functions. Regarding prpoerties you talking about get and set? Yeah I find them annoying and just adding to confusion. Its nice for restricting access to fields in an API like Unity but as you said it adds level of abstraction that its not needed. Surely if you use an API you must know what you are doing. Alot of the stuff, even to me an amateur, seems like just syntactic sugar just to appeal to beginners but it doesnt help in long run. You seem to know alot so I have a question about C# events of you dont mind answering.I have read conflicting stuff about their performance. They are nice to use but I wonder whats their performance compared to just having public boolean fields and keeping track of those? Like say I want to keep track when my character finished jumping. Is it better to have that in event system or just keep track of bunch of flags?

[@yoavraman8919]

are private better then Serialized?

[@heyyounotyouyou3761]

Wow! Found John Wick

[@harsht4345]

who dislikes the video? it’s bloody free information and knowledge...

[@outlander234]

Because he may have not explained it properly.

[@saito853]

It's because the video is full of misinformations.

[@SaudBako]

public fields, getters, and setters are forbidden. Sometimes I have to, though, but that's because I have a bad design. If use them, it means I was in a hurry, and I'll have to get back to them.

[@rattyredemption]

is it ok to use a serialized private field in unity's inspector, and then expose that private field via a public property so other classes or scripts can assess it?

[@mrcallum1995]

100%!

[@rattyredemption]

@@mrcallum1995 thanks.

[@DerClaudius]

They're called Attributes in C#... Also, it doesn't make any difference if you write public fields as a simple variable or with default getter/setter. You can even change it later. Having getter/setter only makes sense if you're really using it architecturally to implement something that works differently from the default.

[@jeffmccloud905]

it makes a huge difference. public fields in C# are considered a bad practice and that's been the recommendation in the C# / .NET Class Design Guidelines since 2001 (it has nothing to do with Unity)

[@DerClaudius]

@@jeffmccloud905 Yes, but a public field with the default setter/getter is just a normal public field and bad practice where the simple public field is considered a bad practice

[@jeffmccloud905]

@@DerClaudius quote from .NET Class Design Guidelines (this has been there since 2001): "❌ DO NOT provide instance fields that are public or protected." followed by "You should provide properties for accessing fields instead of making them public or protected."

[@DerClaudius]

@@jeffmccloud905 mate, this is about why design-wise public fields are considered a bad practice... because outside code can influence your inner state without you noticing. This leads to badly maintainable code. Public properties are no difference here

[@jeffmccloud905]

@@DerClaudius yes, there's no difference in accessibility, but that doesn't mean public fields are OK. They are not the same, they are not binary compatible with a public property. An object compiled into a DLL with a public field that gets converted into a property will need to have any callers of that DLL to be recompiled and redeployed, even though the calling syntax didn't change (the syntax is actually different in the IL). All I'm saying is the public fields are an anti-pattern that MS has discouraged since Day 1 of .NET

[@siddharthjain1745]

But serialized field throws a warning :(

[@flaviokonti5522]

Just set it up to be dafault; and it will stop throwing warning in unity

[@David-bj6gw]

Do you know your second name sounds like quite common second name from Czech Republic?

[@LostRelicGames]

I am Czech ;) (but born in Australia)

[@David-bj6gw]

@@LostRelicGames Cool, I was just curious cause Im from Czech. Btw I really liked your video "Path to gamedev Glory" it really helped me to think more sober about me and game development

[@coco5843]

Hello, could you make a video on how you handle enemy, trap, ect despawning when the camera is far away, or performance issue. Thank great videos ;)

[@LostRelicGames]

Good topics, added to my list! :)

[@im_cloudy]

Good video, but it would be better to use correct code conventions, just to teach other the correct. This is not Java, but C#. Public fields are PascalCase, method names are PascalCase, private fields camelCase or _camelCase.

[@rrlosabio7190]

Yoww you like brackeys big brother no offense, hope more people found your channel for game dev community

[@butterfinger4393]

I public everything expected the things that i know i don't want have access to. Im probably doing it wrong. I haven't had any issues because i know what all variables are. 😅

[@KillerGameDev]

So im getting the feeling that this has no bearing on performance. Would that be a correct statement? In web dev, global variables(basically public) can lead to things like a memory leak, which in cleaner modern projects you wont see as much, but to my understanding(keywords are my understanding) this is when the ram/memory is filled with variables and this causes you to not be able to properly load everything later on down the line, because it never deletes crap. I dont think this is as much of an issue in modern projects because web dev has gotten more efficient and computers have gotten more tech-advanced with larger ram and junk. Im still not sure if this is similar in c# using unity or not. I could care less about how my coding practices bother others in a personal indie game but rather if it will affect the user in performance - having trouble finding info on this.

[@rattyredemption]

some expects say fields are faster than properties and methods, i don't really understand why but it's discussed in this topic: forum.unity.com/threads/field-vs-property-vs-method-performance.688546/

[@GuyFromNet]

why did you put "script" in the name of the file... 😦

[@foncode101]

its so you wont accidentally call another scripts public variable, function, etc.. so you could have similar name in different scripts...

[@emanueltejadacoste2250]

The Brackeyss brother ? XD

[@MarkWaner]

But those are not properties. What you call properties are actually public fields... Properties have to have get and set accessors. The problem with properties is that you have to jump through hoops to get them in the inspector

[@MarkWaner]

You could actually see this info when you opened Microsoft documentation

[@See_Sharp]

Game Devs are more concerned about performance.

[@paranormalgamesstudios]

Good vid cheers, but If it doesn't affect performance or security then it doesn't really matter in the grand scheme of actually getting the game finished. And if you think it does then Id like to see some more info regarding those factors.

[@danielstewart4221]

Using public in games really does not matter. It depends more on how you get the information. You can still use public PlayerName if you're using a function to access it. Really only needs to be private for security reasons, which don't matter in a game

[@nTu4Ka]

Please call it "incapSulation" instead of "incapTulation". Thank you. :)

[@aaronwinter7911]

there is only one true answer, and it is `onready var`.

[@saito853]

WARNING: this video is full of misinformations. If you want to learn actual C# practices DO NOT REFERENCE THIS VIDEO.

[@I2EF]

care to explain why? serious question, I'm working on a project and I use different scripts for the different actions of the player, for example I have a jump handler, a dash handler, a movement handler, etc. and some of these scripts need to reference one another so I need to make the needed fields public, if that's generally wrong, how should approach this situation?

[@saito853]

@LuisAR Because he can't tell the difference between fields and properties. public string _value; is a field public string Value { get; set; } is a property The way a property works is: private string _value; public string GetValue => return _value; Therefore not exposing the field to other scripts. OOP practices is to never expose a field, but you can expose a property. In your case you need to make sure what and why each field need to be exposed. Do you need to read and write the value? Then expose a property: public Type Value { get; set; } Does the other scripts only want to read this value? Use public Type Value { get; private set; } Do you want to set the value with a certain logic inside, one example I could think of is if you want the player to only airdash once and set the count back to normal (inside the jump script) once the jump is finished? Generally we use methods like: public void ResetCount => _dashCount = _maxDashCount, this way you expose one method instead of 2 private fields. Also I would like to mention the main reasons for exposing properties rather than fields: - Easier to debug, every time you get or set a value, it's considered a method/function call. Search for stack trace for more info on this. - If you're using Visual Studio, the properties will also show references when or where it was get or set, fields won't. - Data encapsulation. - Properties can also expose conditions without exposing the value. For example you can have an inventory: private List _inventory; and a property exposing its count: public int ItemCount => return _inventory.Count() without exposing the entire list.

[@I2EF]

@@saito853 Thank you so much for your detailed answer! It really helped me get a better understanding to improve my code, I was kinda lost after his video on where to go next but your explanation cleared things up!.

[@FiksIIanzO]

That was not a property. Intellisense literally labels it as a field in your video. Microsoft documentation in your video labels them as fields. Properties have accessors. Come on, man. You can't know everything, but do some research before you make a literal tutorial. This isn't an "um ackshually" moment either; I came here looking for _property_ usage in Unity, and the word "property" is literally in the title of the video.

[@khoavo1175]

thank you