Here's a couple of notes/corrections that people have pointed out in the comments: 🔵 The tip I called "getters and setters" should've been referred to as C# properties 🔵 Use Invoke(nameof(yourFunction)) instead of using a string parameter. Also coroutines are normally the better option because they don't use reflection. 🔵 Call a coroutine with StartCoroutine(myFunction()) instead of using a string. Also look into async methods as an alternative. 🔵 Use the event keyword when you declare an action variable 🔵 Singletons are a contentious topic and are probably better suited for small to medium size games. Use them carefully or look into dependency injection as an alternative. 🔵 I made a mistake in the code for implementing a singleton. Don't destroy the original instance, destroy the new class. It should be if (Instance != null && Instance != this) { Destroy(this); return; } Instance = this; 🔵 Scriptable objects are not recently released… oops
I highly recommend using async/await instead of coroutines for a few reasons: - Async functions can return values - You can catch exceptions both outside and inside an async function - Debugging experience is much better, the call stacks will make much more sense. - It is easier to compose and combine async functions - Use UniTask (free) for additional support such as WebGL support for some APIs and tracking long running leaked tasks. Use the standard IProgress interface for reporting progress of long running tasks.
@@marinamaged962 You just, like, separate scripts into domains or modules that do some specific stuff, put them into a folder and then you create an AssemblyDefinition file in this folder. Unity won't reload scripts from this folder anymore unless they were changed.
@@marinamaged962look it up in the documentation for Unity, they have a pretty lengthy piece. Although it’s a bit dense if you’ve never done assemblies in C#, so I suggest to use a YT tutorial first. Simply put, anything that isn’t covered by a specific assembly, is put in the global one. That’s why any minor change triggers a recompile of all the project code (not packages though, those use their own definitions). So you can put an assembly definition file (same way as you create a script) in any folder. That definition will cover every script in that folder and all in every subfolder. So if there is a folder with multiple big folders, it might be better to put one assembly in each subfolder, so changes to that folder only affect scripts there. However, if you’re depending on packages or other assemblies of yours, you have to declare those in the definition file, so that’s why I recommend watching a tutorial.
8:00 for Invoking a method, it's better to use nameof(MethodName) instead of literal string so the name will be updated when you change the method name, as well as being able to view it with the method references, and the best of all, auto completion
Didn't know that existed, that rules. I've always felt weird about using strings for method names since there's a decent chance I'll change them during refactoring
this is "stuff i heard about but didnt quite understand fully and i havent looked it up yet" THE VIDEO at least for me it is. i will probably come back to this a dozen of times. great work!
As a developer with 5+ years of experiece who recently started to learn Unity and C# I would like to state that this is the best, most informative and well structured "tips" video I have ever seen. Great job!
Same, I worked with C++ for 6 years, and moving to Unity and C#, it's something easier (due to C# being globally easier to use) but at the same time really different, C# has stuff that C++ do not have or do differently. For example Interfaces Class and Unity Scriptable Objects is something new that I didn't knew about.
Something slightly more advanced, but that will help immensely once you get into the habit is unit testing. This is probably easiest to do through the Unity Test Framework, this allows you to write code that tests a single function, and by keeping it around you'll be sure the feature isn't broken in a future update. Say for instance you want to add recoil to your weapons, pushing the player back a bit whenever they fire. By writing a unit test you can ensure that the push is always opposite the direction fired. That way if you later add a weapon that fires in random directions you might discover that the random vector added to the aiming direction didn't get transferred to the recoil. It's not just useful for catching errors in the future, but it also helps you write good code. If you want to test something but it's hard to do then it's often a sign that you did something wrong in the first place. For instance, let's say you can't test the cover mechanic because it requires the map to be loaded, and the timer to be running, and the network code to be loaded. That means your cover mechanic is dependent on all those other systems and is simply doing too much. One nice way to ensure you test your code is to write the test first, so instead of adding the recoil to all the weapons *first* you add the test to make sure the recoil is pushing the character back first. Then you run your tests, this will give you a red flag for this feature. Then you add the feature and test again, now you get a green flag. Then finally you clean up by refactoring things before moving on. In short: red-green-refactor. The benefit of this is that you are sure you wrote your test properly. If for instance you check for the recoil that you don't have in the game yet, and the test says it's working then you know you have a bug in your test code. Same with running the test after adding the feature, now you're sure it can tell that the feature *is* working properly. That way you can be sure the test will alert you in the future if a bug creeps in. It's a part of agile programming, if you want to look it up for more details. By using that I could handle a 300k+ lines of code project just fine on my own. Before adding unit tests there was always the concern that I forgot some edge case or broke existing functionality, and it was simply too much to manually test. Finally, singletons can be hard to unit test, but you can make them work by adding extra code for swapping out the instance with a test one. Usually by changing it from a specific class to an interface instead. Then you can replace the singleton with a test version that just says okay to things you're not interested in testing at the moment. At that point it might be easier to simply give the class the interface implementation directly through a property, which is basically what "inversion of control" is about. Having external code provide the dependency your code requires instead of having it get the dependency itself.
You should use the C# "event" keyword in order to protect the event's delegate (Action) from being invoked from outside the class in which it is declared. Without the "event" keyword, you risk the event being triggered at the wrong time.
@@TesseractDev sebastian lague has a series where he goes into more detail with events and delegates and their usecases in unity if you wanna check it out
Actually, use a public event _accessor_ with the _add_ and _remove_ blocks and keep the underlying event delegate protected or private. Event accessors cannot be invoked, they're only a gateway to subscribe/unsubscribe to events. In real life it's also good practice to have a private object like "objectLock" and use a lock(lockedObject) { ... } block inside of the add and remove blocks to prevent anything whacky ever happening if more than one threads tries to get at the event. Don't sit there and say "But I don't use threads, Jimmy!" lol, write correct/robust code because if you ever work with a team or publish some code you have no control over what people do ... they might create 20 threads and try to make them all subscribe and unsubscribe to the event in a tight loop lol, don't let that blood be on your hands ... nothing more embarrassing than finally having a real job and the software fails in some code _you_ wrote, because you thought following the advice of the language designers and senior engineers wasn't important ... so get in the habit of writing it correctly. There's an example of this whole pattern on Microsoft Learn for C#, just Google "C# event accessors" and learn the correct, modern way to use and expose events in C# .... Also, most people don't know that Action and EventHandler are _not_ anything special, they're just regular-ass ol' delegates. You can make your own, too, with whatever parameters your heart desires. Then you can make them events with the event keyword, expose them with an event accessor and protect them from harm by an object lock. 🔐 However, using System.Action in an event pattern is really _not_ the appropriate design even though it works. An Action is kind of useless beyond simply triggering something with absolutely _no information_ whatsoever. That might seem cool in beginner projects where you have one thing that fires one kind of event, but in real-life software and games that would be rather useless and silly for anything that's important. The "proper" convention is that all events are generally supposed to take two parameters: (object sender, EventArgs e) ... but you can _specialize_ this for custom events. Make a small class that inherits from EventArgs and has some special event data it like "InputEventArgs" with key/control input data in it. The "sender" parameter is just whatever object is triggering and dispatching the event, most likely the class that contains/exposes it, so it just passes "this" into the sender parameter. That way, subscribers can know _which_ dispatcher fired the event in situations where you may have more than one instance of a thing exposing the same kinds of events. Also, define your own special delegates with a special name describing the kind of event it's for, and use those specific delegate types with the event keyword ... that way, another programmer can simply read the event signature and gather _all_ they need to know about it in one glance! Take this one for an example: // custom delegate: public delegate DamageHandler( object sender, DamageEventArgs dmg ); // custom event data: public class DamageEventArgs: EventArgs { // constructor omitted for space //♤ Define your constructor here // properties here: public ICreature Victim { get; set; } public IAgent Attacker { get; set; } public bool WasAttacked => this.Attacker is not null; public DmgType DmgFlags { get; set; } // you get the idea ... } // ------------------------------------------------- // Now you actually use this stuff inside // of a class that exposes events: object objectLock = new(); event DamageHandler _creatureKilled; public event DamageHandler CreatureKilled { add { lock(objectLock) { _creatureKilled += value; } } remove { lock(objectLock) { _creatureKilled -= value; } } } I bet that after reading that bit of code you're like "Whoa, I understand _exactly_ what that event represents!" even if you're not familiar with the proper usage of event patterns in C# ... you can clearly tell what the event is talking about and what its purpose is, and that's how you implement events properly, not with System.Action lol ... think about all the stuff you can do with the simple pattern I just showed you. This is really basic/intermediate C# stuff and it's the reason I urge people to read a complete C# book that has _nothing_ to do with Unity or anything library/framework/engine specific whatsoever, just learn proper C# and thank yourself later for that best month or two you ever spent ...
@@GameDevNerd this is extremely unnecessary. Explicit event accessors have virtually no mainstream use case except for maybe storing the delegates in a dictionary instead of the automatic delegate field. Adding/removing handlers is thread safe so there is no need for a lock. Invoking with the null coalescing operator avoids the need for a null check. In other words, ignore the entire previous comment.
Really wish a video like this was around back when I started Unity development six years ago, these really are some of the top priorties that new beginners should learn. Great video!
I have been working in Unity for many many years now, and these are some perfect examples of paradigms and patterns that I have learned over time after coding myself into a corner. One of the better unity tip or even coding tip video I have seen in a long time. I'm gonna save a link to this video in the root of my unity project as I develop so I can watch it from time to time as a reminder to not write silly code anymore. Great work, keep it up! =)
I have to admit, that when I saw 22 minutes long video, I thought this is us yet another artificially stretched video about Unity basics... and it frankly is, to some extend. You managed to cover the basics but I'm such pace, that I had to pause it several times and in the end I wished this would be bit longer. To cover these basics, you would otherwise spent hours of searching for other fragmented pieces of such important basics. This is very well done my friend... Keep up!
ENUMS and Serialization: Be very careful when adding new enum values/options to an existing enum definition if you have already started using it in your project and you have that enum serialized anywhere (scene or prefab). Unity serializes enums as numbers by default, starting at 0, if you add a new option to the enum make sure that you at it at the END of the definition list because otherwise you may be 'redefining' what already serialized enum data will be deserialized back to.
Hey man! Normally i dont comment on videos, but… ive been doing software development (outside of gamedev) for 20+ years and only recently got into Unity. This video is very well thought out and full of good stuff. Really rare to find such a well structured set of tips. Thanks a lot and keep up the great work
@@TesseractDev As a software developer myself, I really can confirm that you not only did a great job structuring the most important tips, but also show some real-world examples why and how you can use them. This video should be an essential education source, for anyone that wants to develop in unity. Thank you very much for your afford in this video.
Yup.. also a 20+ years dev coming into the gaming world and wanting to tear my eyes out over some of the approaches that people take in these tutorials! Nice to know I'm not the only one trying to do this, though I have to ask, if you were going into the field as a senior dev, would you expect to get in as a senior dev, or do you think things are sufficiently different that not all your skills apply and you may have to take a mid-level dev position in a game manufacturer? With it being such a crowded market for devs, it's why I feel this is going to be more a hobby than a career!
Version Control is huge, but being a "backup" is just the beginning. The true value is how it empowers development by being able to see the difference between what the before and after states, how it enables or disallows multiple members to make changes to the same file at the same time, and being able to go back in time to previous states of code or even the whole project. Great video =)
Kid, this video is exactly what everyone needs to hear. Incredible work, one tiny bit of feedback would have been to add a data oriented section for people who want the kind of performance that OOP cant provide.
i really like this vid, he really helped me get into the mindset of developing a big project and even made it seem a little less daunting by splitting things up and haveing your code correlate with itself, thanks
This is the video that i longed to have for years. I only tangentially got into programming and only ever learned what was needed to get the job done. This video made so many of the concepts that i kinda knew about but never fully grasped, trivially easy to understand. Stellar work on this video and many many thanks
This was the ultimate "how to less likely to drop yet another project unfinished" video for me. It contains so much information that I knew existed but never knew where to look for it. It was so useful thank you! Also, nowadays I don't really finish any videos because I get bored of them. But yours was so entertaining to watch and I even learned from it. Thanks again!
Most importantly: LINK THINGS UP IN CODE! I think this is an often-overlooked issue with projects that become bigger. The Unity UI is great for novices and small projects, but in the end you want a debuggable and searchable dependency overview. The ironic thing is that it’s not a full item on your list, but a side comment about your preference. Anyway: some more tips: - return an IEnumerable on the public get of a list or array, so callers can’t change it that easily (except for casting and other reflection utils) - end multi-line enums and list initializers with a comma, so it’s easy to add, delete or reorder the items. - coroutines run on the component so make sure to not disable it. Better yet, have a “coroutine” instance that you can address at any point. - use the nameof(Function) variation of Invoke to get compile-time checks on your function name. - scripts should destroy themselves, not the other Instance (whoops) - don’t go overboard with inheritance and interfaces when s nice _type enum and case statement will do. This will often create less messy code, especially when they do similar things with different values (easier to compare the implementation differences at first glance) - if you have lists of content (levels, weapons, avatars, spells) consider going for a data-driven method and loading stuff like textures and scriptable objects through addressables and a parameterized path. Instead of hard-linking it in Unity UI. Your loading time will thank you as well.
For the last tip, do you mean that - for example; I have 300 upgrades in my game as scriptable objects. And I have one scriptable object for a database. I have a function that finds the resources folder with my upgrades and attatches them to the database? Rather than drag clicking them in
So, this video basically summarizes like 80% of what I learned getting a degree in Software Engineering/Real Time Systems. Obviously lacks depth (how could you in a 22 min video) but is an amazing resource.
Honestly there is only 2 important tips to remember, whatever the level of programming you have (Beginner or Experienced) you always need to take extra time to re-check your code in general, and fix/improve stuff regularly and also always backups your projects everyday ! But honestly it's still more like a thing of a mid/experienced programmer to make a game, I do not recommend to a beginner to start by making a game, start by something simpler, like a simple software and learn from it.
Creating a calculator is not the most exciting way to start coding. I say start with a game, it all depends about the scope. You don't start with a GTA7 project :)
Thank you! I’ve been trying to use car to simple of techniques to solve complex problems. It’s annoying how few unity tutorials teach more advanced methods. So again thank you for this it has been hugely helpful.
Really good video! One additional thing that I like to have as a standard when using strings for Invoking or Coroutines is to use the built-in "nameof()" function so the editor can identify the references.
These are great tips. I recently cleaned up a project significantly just by drawing a box for each script in my project on a piece of paper and drawing an arrow from each box to each box it referenced. I realized i had tons of messy and unnecessary references all over the place and was able to delete almost half of all the code I had written as well as delete an entire class that turned out to be unnecessary.
I am really impressed on how the video is structured and how many actual good tips of good clean code are here. Will be very helpful to many software engineers, thank you for your input
I’ve only made two unity games and I’m already writing smart code and organizing my scripts and game objects… it’s probably my second favorite part of making a game next to actually programming it 😊
Great video :) Another random tip, if you want to serialize a field, but have an "auto property" (like public foo {get; private set;}, you add the attribute like [field: serializeField], to expose it in the editor. This turns the "auto generated backing field" from that property into a serialized field on the objects. This helps to prevent the need for the [SerializeField] private _field; public field {get; private set;}
Another thing that I prefer doing is explicitly numbering my enums, like enum Foo { bar = 0, baz = 1, ... }, this lets you re-arrange them later or add/remove them if you change the enum. As an advanced topic, you can also turn enums into bitflags (via the [Flags] attribute) for making your own masks like the layermask stuff, but that can be confusing, so it's good to be a little sparing with it, but it can save a ton of memory in some cases (i.e. a 32bit int can store 32 bools/flags, while a single bool is a whole byte).
As someone who's just getting into more game development, this video is super helpful! Ngl may need to watch it again and take some notes for reference 😅
This seems really useful and you explain things well. I would love to see some more basic-building-blocks and more in depth videos from you especially revolving around Unity. Thanks so much for this video!
I'm a senior developer and I approve of these advice ;) I'm currently learning C# (transitioning for a while from Web-Dev) and I found them helpful. Thank you very much ;)
@@Johan-rm6ecWhy can't I approve? I mean, if I as a specialist can add to the credibility of the video, is that a bad thing? Some people will see this and will have faith in the video more. So overall it's a positive message, even if the advices are common, I know too many developers that don't follow even common advices or even enough good practices.
Even though I already knew all of these tricks, I found this video to be a nicr refresher of possibilities you have to structure and improve code as well as show me that even though there's a lot left to learn, I've also already come a long way :)
Lots of good advice here. The main omission from my perspective is unit tests. Increase stability and make changes quickly and safely by covering your code with tests :)
Great video! There’s tonnes of stuff in there that can take new unity devs a long time to get to. I would have liked to see mention of using non-monobehaviour classes, the biggest change i noticed moving from hobby to professional was how often is write things like static service classes for manipulating objects/data, makes for reusable code and saves you a lot of hassle
Not just showing the tips but explaining and showing the mechanics behind it and examples. Great video to help with these things. Never knew about InvokeRepeating and it's practical use like that.
Very good tips for the begginers. 06:25 - About the coroutines, I highly recommend to use a async Tasks instead. When you try to do more advanced things with coroutines it quickly becomes really messy, you not able to return a value for example.
I read this recently in the Unity docs: ''The Unity API isn’t thread safe and therefore, you should only use async and await tasks from inside the UnitySynchronizationContext. Async tasks often allocate objects when invoked, which might cause performance issues if you overuse them.'' and "Unity doesn’t automatically stop async tasks that run on managed threads when you exit Play mode. To listen for enter and exit Play mode events to stop the tasks manually, use EditorApplication.playModeStateChanged. If you take this approach, most of the Unity scripting APIs aren’t available to use unless you migrate the context back to the UnitySynchronizationContext."
Which is true, it's strange, but if you just try using async Task await in your code in edit mode and stop the editor, unless you implement it in a certain way, it keeps playing it forever even when you stop play mode. There's also an Editor Coroutine plugin you can download for editor coroutines, but last I used it it was in beta form.
Aren't they require manual cancelation and can continue running in editor? I'm not saying they shouldn't be used, but I wouldn't replace all coroutines with tasks and vice versa.
@@astrahcat1212 It basically means avoid creating your own threads and interacting with Unity APIs e.g. GameObjects there. UniTask is a great library that reduces the garbage generated and also provides utilities to use async/await in Unity 'safely'.
The pit of despair... when your learning and suddenly realise... there's very little material to teach you the advance stuff these kind of vids really help XD ty
@@Mel-mu8ox Maybe I don't, enlighten me Cuz as far as I know there are tons of advanced stuff on the internet. Most of it is in blogs not youtube though
Another tip for the #6 could be [field: serializedfield] public {get; private set} to be able to change the property in the inpector but still private set. For the #7 I totally agree, decoupling is a great thing to learn and the observer pattern help a lot for that.
Thank fuck. Someone who actually knows what he's talking about. I've been a developer for over 20 years (I'm 46) and I agree with all of this. You should talk about about access modifiers, such as Internal, Private and Protected. You can also use directives like [assembly: InternalsVisibleTo: "A.Different.Assembly"] to allow access across layers.
The good news is this is incredibly helpful and is changing the way I write code. The bad news is I'm realizing my entire game is built on a foundation of jello and I have a LOT of rewriting to do
ScriptableObjects were introduced in Unity 3.5, which was released in 2012. This feature has since become a powerful tool for managing data and creating modular systems in Unity, allowing developers to store data outside of scene files and reduce dependencies between game components.
Gave the like after the dream game description. Doesn't matter if any of the content is any good "Fantasy, mmo, RPG, Sandbox, battle royale, powered by a block chain economy" for the win.
Just starting game making and programming. This is invaluable to getting a lay of the land. I might be trying to run before I walk, but all these seem to make sense even if most of it is going over my head. Thank you!
Hi there, I just started last week. Do you feel or are you any closer to making your first game? I feel like this goal is years away for me and it's all overwhelming
I did a bad thing and took a break. Life got busy and such. Id say just start on small projects and keep building up. I did a flappy bird tutorial and it made me hopeful. I might redo it because there are so many add-ons that can be used to learn. @@FenrirFinance
myself, programming only in simple basic, certainly not to the level of C++ or even C#, i came across so many problems like that, that i kind of start making my program way ''cleaner''... Especially when you have more then 2000 lines of codes, it is beginning the required a lot of 'convention' in your variable naming habits and you also learn to use 'include' so to get rid of code you really don't need to see. I also implemented the idea of encapsulation as much as i can and make a real effort to have part of my code to do a single thing and get that result CLEAR WHAT IT RETURNS. So important, i also always explain what a section of code do and also explain what the variable really hold as value, meaning i explain what the value is from and what it should become. When you return to your code many weeks later, you need to read it all to get back 'into it' again.
Just one thing I want to add from my experience. As I like C# events more than those from Unity, there is a big advantage for the unity ones. When you're working in a team with designers, it's much more productive if they can change what happens on an event, than asking a programmer to change it. It's not always the case, of course, but it's something worth considering :)
Mostly good :D Couple of things Singleton is anti-patter that affect the SOLID principles mainly SRP and DIP for that reason you should never use singleton Inherence section, you can here check the liskov sustitution, and mostly of the things that you mention your guns class should have, can be added later as a external components like ammo, attachments, recoil, spawn properties, etc I'm learning C# and unity and I saw a lot of horrible code even in AAA games like Rust. I will say that stick to SOLID principle and the first chapters of your video will make a greater architecture that what I can see right now. I imagine this is happening because making a game requires so much knowledge about so many things that sometimes they cannot be great on everything. Keep up with the work!
I gotta be brutally honest, when I began watching this video and I saw how young you look, I was thinking, dude ... what's this guy gonna be able to teach me? It turns out ... quite a lot. Thanks dude. Power to you. Appreciate the content.
I was so glad I started a Git repository in one of my projects before trying to migrate it to Universal Render Pipeline... it costed almost nothing to put it in a back branch and go back to BiRP that worked much better with the assets I had hahaha
10:00 regarding singletons: Just don't make the error that your managers end up in circular references. This just makes it harder to take something out / replace it. In our game I try to organize them in layers. (managers only have access to the layers below them) 18:00 scriptable objects are _not_ a recent feature... they are mentioned already in the docs to unity 4.6 ALSO ... those are beginner tips. You should know all that before starting any project that's larger than a game jam project.
There is definitely a major lack of people talking about advanced coding practices in gamedev, especially when it often becomes the biggest barrier for people trying to make games as their projects inevitably devolve into an unworkable pile of spaghetti. Hope to see more similar content
Singletons are fast to build, good to use, confortable to have... and easy to mess! I have used it too much, but now I prefer to use something more related to ScriptableObjects whenever possible. It is easier to maintain in Unity. Now, that's for small hobby projects. For a larger project, I have had really bad experiences with singletons =/
Note on Invoke/InvokeRepeating or similar functions: Always use nameof(yourFunction) rather than "yourFunction" so that you don't risk forgetting to rename the strings if you rename the function later down the line.
Also the code snippet at 9:14 is incorrect. The else should be Destroy(this) or Destroy(gameObject), as you want to destroy the new one and keep the original rather than destroying the original and leaving a hanging reference.
paused the video just to comment, thanks a lot! i learned a lot from this video. its very well put together and i hope someday you elaborate on each of these topics and other more advanced programing principles. p.s you should really enable donations on your channel😋, i would donate to you if i could, you brought me value
Here's a couple of notes/corrections that people have pointed out in the comments:
🔵 The tip I called "getters and setters" should've been referred to as C# properties
🔵 Use Invoke(nameof(yourFunction)) instead of using a string parameter. Also coroutines are normally the better option because they don't use reflection.
🔵 Call a coroutine with StartCoroutine(myFunction()) instead of using a string. Also look into async methods as an alternative.
🔵 Use the event keyword when you declare an action variable
🔵 Singletons are a contentious topic and are probably better suited for small to medium size games. Use them carefully or look into dependency injection as an alternative.
🔵 I made a mistake in the code for implementing a singleton. Don't destroy the original instance, destroy the new class. It should be
if (Instance != null && Instance != this) {
Destroy(this);
return;
}
Instance = this;
🔵 Scriptable objects are not recently released… oops
Does it exist example project with the code?
@@toroddlnning6806 No sorry. I'm planning on releasing the game so I don't think I can do that.
@@TesseractDev ok, maybe later, in a few years!
I highly recommend using async/await instead of coroutines for a few reasons:
- Async functions can return values
- You can catch exceptions both outside and inside an async function
- Debugging experience is much better, the call stacks will make much more sense.
- It is easier to compose and combine async functions
- Use UniTask (free) for additional support such as WebGL support for some APIs and tracking long running leaked tasks.
Use the standard IProgress interface for reporting progress of long running tasks.
@@Sindrijo Coroutines are still better for when you need an action to happen on each frame, since you can only specify a time delay when using async.
Great video! It's awesome to see someone so young already so focused with writing good clean code!
Heyo code monkey
Of course code monkey is here this guy never misses anything about unity
Even Code Monkey approve! Good job my dude.
What I came here to say exactly, dude's amazing
yeah, Code Monkey, it is 🤨
Me: Moves hand for a sec
Unity: *Reloading Domain*
you can actually make this a lot faster by making assembly definitions :)
@@yolocat-dev True, but then your VSCode takes 20 minutes to start
It's worth it though
@@yolocat-dev can you elaborate? how do i do this
@@marinamaged962 You just, like, separate scripts into domains or modules that do some specific stuff, put them into a folder and then you create an AssemblyDefinition file in this folder. Unity won't reload scripts from this folder anymore unless they were changed.
@@marinamaged962look it up in the documentation for Unity, they have a pretty lengthy piece. Although it’s a bit dense if you’ve never done assemblies in C#, so I suggest to use a YT tutorial first.
Simply put, anything that isn’t covered by a specific assembly, is put in the global one. That’s why any minor change triggers a recompile of all the project code (not packages though, those use their own definitions). So you can put an assembly definition file (same way as you create a script) in any folder. That definition will cover every script in that folder and all in every subfolder. So if there is a folder with multiple big folders, it might be better to put one assembly in each subfolder, so changes to that folder only affect scripts there.
However, if you’re depending on packages or other assemblies of yours, you have to declare those in the definition file, so that’s why I recommend watching a tutorial.
8:00
for Invoking a method, it's better to use nameof(MethodName) instead of literal string so the name will be updated when you change the method name, as well as being able to view it with the method references, and the best of all, auto completion
I'm doing it only for the auto-completion :)
Most important: compile time spelling check.
I came for this comment, lol
Didn't know that existed, that rules. I've always felt weird about using strings for method names since there's a decent chance I'll change them during refactoring
this is "stuff i heard about but didnt quite understand fully and i havent looked it up yet" THE VIDEO at least for me it is. i will probably come back to this a dozen of times. great work!
As a developer with 5+ years of experiece who recently started to learn Unity and C# I would like to state that this is the best, most informative and well structured "tips" video I have ever seen. Great job!
Same, I worked with C++ for 6 years, and moving to Unity and C#, it's something easier (due to C# being globally easier to use) but at the same time really different, C# has stuff that C++ do not have or do differently. For example Interfaces Class and Unity Scriptable Objects is something new that I didn't knew about.
Something slightly more advanced, but that will help immensely once you get into the habit is unit testing.
This is probably easiest to do through the Unity Test Framework, this allows you to write code that tests a single function, and by keeping it around you'll be sure the feature isn't broken in a future update.
Say for instance you want to add recoil to your weapons, pushing the player back a bit whenever they fire. By writing a unit test you can ensure that the push is always opposite the direction fired. That way if you later add a weapon that fires in random directions you might discover that the random vector added to the aiming direction didn't get transferred to the recoil.
It's not just useful for catching errors in the future, but it also helps you write good code. If you want to test something but it's hard to do then it's often a sign that you did something wrong in the first place. For instance, let's say you can't test the cover mechanic because it requires the map to be loaded, and the timer to be running, and the network code to be loaded. That means your cover mechanic is dependent on all those other systems and is simply doing too much.
One nice way to ensure you test your code is to write the test first, so instead of adding the recoil to all the weapons *first* you add the test to make sure the recoil is pushing the character back first. Then you run your tests, this will give you a red flag for this feature. Then you add the feature and test again, now you get a green flag. Then finally you clean up by refactoring things before moving on.
In short: red-green-refactor.
The benefit of this is that you are sure you wrote your test properly. If for instance you check for the recoil that you don't have in the game yet, and the test says it's working then you know you have a bug in your test code. Same with running the test after adding the feature, now you're sure it can tell that the feature *is* working properly. That way you can be sure the test will alert you in the future if a bug creeps in.
It's a part of agile programming, if you want to look it up for more details. By using that I could handle a 300k+ lines of code project just fine on my own. Before adding unit tests there was always the concern that I forgot some edge case or broke existing functionality, and it was simply too much to manually test.
Finally, singletons can be hard to unit test, but you can make them work by adding extra code for swapping out the instance with a test one. Usually by changing it from a specific class to an interface instead. Then you can replace the singleton with a test version that just says okay to things you're not interested in testing at the moment. At that point it might be easier to simply give the class the interface implementation directly through a property, which is basically what "inversion of control" is about. Having external code provide the dependency your code requires instead of having it get the dependency itself.
You should use the C# "event" keyword in order to protect the event's delegate (Action) from being invoked from outside the class in which it is declared. Without the "event" keyword, you risk the event being triggered at the wrong time.
Without the "event" keyword, it also becomes possible to accidentally overwrite the subscribers if you use = instead of +=
I didn't know that thanks!
@@TesseractDev sebastian lague has a series where he goes into more detail with events and delegates and their usecases in unity if you wanna check it out
Actually, use a public event _accessor_ with the _add_ and _remove_ blocks and keep the underlying event delegate protected or private. Event accessors cannot be invoked, they're only a gateway to subscribe/unsubscribe to events. In real life it's also good practice to have a private object like "objectLock" and use a lock(lockedObject) { ... } block inside of the add and remove blocks to prevent anything whacky ever happening if more than one threads tries to get at the event. Don't sit there and say "But I don't use threads, Jimmy!" lol, write correct/robust code because if you ever work with a team or publish some code you have no control over what people do ... they might create 20 threads and try to make them all subscribe and unsubscribe to the event in a tight loop lol, don't let that blood be on your hands ... nothing more embarrassing than finally having a real job and the software fails in some code _you_ wrote, because you thought following the advice of the language designers and senior engineers wasn't important ... so get in the habit of writing it correctly. There's an example of this whole pattern on Microsoft Learn for C#, just Google "C# event accessors" and learn the correct, modern way to use and expose events in C# ....
Also, most people don't know that Action and EventHandler are _not_ anything special, they're just regular-ass ol' delegates. You can make your own, too, with whatever parameters your heart desires. Then you can make them events with the event keyword, expose them with an event accessor and protect them from harm by an object lock. 🔐
However, using System.Action in an event pattern is really _not_ the appropriate design even though it works. An Action is kind of useless beyond simply triggering something with absolutely _no information_ whatsoever. That might seem cool in beginner projects where you have one thing that fires one kind of event, but in real-life software and games that would be rather useless and silly for anything that's important. The "proper" convention is that all events are generally supposed to take two parameters: (object sender, EventArgs e) ... but you can _specialize_ this for custom events. Make a small class that inherits from EventArgs and has some special event data it like "InputEventArgs" with key/control input data in it. The "sender" parameter is just whatever object is triggering and dispatching the event, most likely the class that contains/exposes it, so it just passes "this" into the sender parameter. That way, subscribers can know _which_ dispatcher fired the event in situations where you may have more than one instance of a thing exposing the same kinds of events. Also, define your own special delegates with a special name describing the kind of event it's for, and use those specific delegate types with the event keyword ... that way, another programmer can simply read the event signature and gather _all_ they need to know about it in one glance! Take this one for an example:
// custom delegate:
public delegate DamageHandler( object sender, DamageEventArgs dmg );
// custom event data:
public class DamageEventArgs: EventArgs {
// constructor omitted for space
//♤ Define your constructor here
// properties here:
public ICreature Victim { get; set; }
public IAgent Attacker { get; set; }
public bool WasAttacked =>
this.Attacker is not null;
public DmgType DmgFlags { get; set; }
// you get the idea ...
}
// -------------------------------------------------
// Now you actually use this stuff inside
// of a class that exposes events:
object objectLock = new();
event DamageHandler _creatureKilled;
public event DamageHandler CreatureKilled {
add {
lock(objectLock) {
_creatureKilled += value;
}
}
remove {
lock(objectLock) {
_creatureKilled -= value;
}
}
}
I bet that after reading that bit of code you're like "Whoa, I understand _exactly_ what that event represents!" even if you're not familiar with the proper usage of event patterns in C# ... you can clearly tell what the event is talking about and what its purpose is, and that's how you implement events properly, not with System.Action lol ... think about all the stuff you can do with the simple pattern I just showed you. This is really basic/intermediate C# stuff and it's the reason I urge people to read a complete C# book that has _nothing_ to do with Unity or anything library/framework/engine specific whatsoever, just learn proper C# and thank yourself later for that best month or two you ever spent ...
@@GameDevNerd this is extremely unnecessary. Explicit event accessors have virtually no mainstream use case except for maybe storing the delegates in a dictionary instead of the automatic delegate field.
Adding/removing handlers is thread safe so there is no need for a lock. Invoking with the null coalescing operator avoids the need for a null check. In other words, ignore the entire previous comment.
Your video made me realize, that I am no longer a beginner. I understood all your tips and will be using them asap. Thank you so much for this video,
Really wish a video like this was around back when I started Unity development six years ago, these really are some of the top priorties that new beginners should learn. Great video!
I have been working in Unity for many many years now, and these are some perfect examples of paradigms and patterns that I have learned over time after coding myself into a corner. One of the better unity tip or even coding tip video I have seen in a long time. I'm gonna save a link to this video in the root of my unity project as I develop so I can watch it from time to time as a reminder to not write silly code anymore. Great work, keep it up! =)
I have to admit, that when I saw 22 minutes long video, I thought this is us yet another artificially stretched video about Unity basics... and it frankly is, to some extend. You managed to cover the basics but I'm such pace, that I had to pause it several times and in the end I wished this would be bit longer. To cover these basics, you would otherwise spent hours of searching for other fragmented pieces of such important basics.
This is very well done my friend... Keep up!
You came out of nowhere and your channel blew up! Glad I ran across this gem. Great work on this. I've learn alot in the pass 22 minutes.
ENUMS and Serialization:
Be very careful when adding new enum values/options to an existing enum definition if you have already started using it in your project and you have that enum serialized anywhere (scene or prefab). Unity serializes enums as numbers by default, starting at 0, if you add a new option to the enum make sure that you at it at the END of the definition list because otherwise you may be 'redefining' what already serialized enum data will be deserialized back to.
You can also as an alternative, manually define the underlying value of each enum value, to have a concrete persistence regardless of additions
@@joshuacadebarber8992 this is what’s called a “pro move”
@@lucbloompro what?
I'm not actively using Unity at the moment, but a lot of these are solid pieces of advice for programming in general.
Hey man! Normally i dont comment on videos, but… ive been doing software development (outside of gamedev) for 20+ years and only recently got into Unity. This video is very well thought out and full of good stuff. Really rare to find such a well structured set of tips. Thanks a lot and keep up the great work
Awesome! It's good to get approval from developers who have more experience than me.
@@TesseractDev As a software developer myself, I really can confirm that you not only did a great job structuring the most important tips, but also show some real-world examples why and how you can use them. This video should be an essential education source, for anyone that wants to develop in unity. Thank you very much for your afford in this video.
Yup.. also a 20+ years dev coming into the gaming world and wanting to tear my eyes out over some of the approaches that people take in these tutorials! Nice to know I'm not the only one trying to do this, though I have to ask, if you were going into the field as a senior dev, would you expect to get in as a senior dev, or do you think things are sufficiently different that not all your skills apply and you may have to take a mid-level dev position in a game manufacturer? With it being such a crowded market for devs, it's why I feel this is going to be more a hobby than a career!
Version Control is huge, but being a "backup" is just the beginning. The true value is how it empowers development by being able to see the difference between what the before and after states, how it enables or disallows multiple members to make changes to the same file at the same time, and being able to go back in time to previous states of code or even the whole project. Great video =)
This is about 5 years of head-butting, condensed in 20 minutes. Great contribution.
Events and interface makes the code modular and decoupled alot that once you start using it, u will appreciate it alot
Exactly! Modular and decouple are good words that I probably should've used.
Kid, this video is exactly what everyone needs to hear. Incredible work, one tiny bit of feedback would have been to add a data oriented section for people who want the kind of performance that OOP cant provide.
i really like this vid, he really helped me get into the mindset of developing a big project and even made it seem a little less daunting by splitting things up and haveing your code correlate with itself, thanks
This is the video that i longed to have for years. I only tangentially got into programming and only ever learned what was needed to get the job done. This video made so many of the concepts that i kinda knew about but never fully grasped, trivially easy to understand. Stellar work on this video and many many thanks
Rarely wish a video was longer but this is one. Well done.
This was the ultimate "how to less likely to drop yet another project unfinished" video for me. It contains so much information that I knew existed but never knew where to look for it.
It was so useful thank you!
Also, nowadays I don't really finish any videos because I get bored of them. But yours was so entertaining to watch and I even learned from it. Thanks again!
Great to hear!
Going back into Unity development from other engines, and man this is the BEST refresher course I've ever seen. You just earned a new sub!
Most importantly: LINK THINGS UP IN CODE!
I think this is an often-overlooked issue with projects that become bigger. The Unity UI is great for novices and small projects, but in the end you want a debuggable and searchable dependency overview.
The ironic thing is that it’s not a full item on your list, but a side comment about your preference.
Anyway: some more tips:
- return an IEnumerable on the public get of a list or array, so callers can’t change it that easily (except for casting and other reflection utils)
- end multi-line enums and list initializers with a comma, so it’s easy to add, delete or reorder the items.
- coroutines run on the component so make sure to not disable it. Better yet, have a “coroutine” instance that you can address at any point.
- use the nameof(Function) variation of Invoke to get compile-time checks on your function name.
- scripts should destroy themselves, not the other Instance (whoops)
- don’t go overboard with inheritance and interfaces when s nice _type enum and case statement will do. This will often create less messy code, especially when they do similar things with different values (easier to compare the implementation differences at first glance)
- if you have lists of content (levels, weapons, avatars, spells) consider going for a data-driven method and loading stuff like textures and scriptable objects through addressables and a parameterized path. Instead of hard-linking it in Unity UI. Your loading time will thank you as well.
For the last tip, do you mean that - for example; I have 300 upgrades in my game as scriptable objects. And I have one scriptable object for a database. I have a function that finds the resources folder with my upgrades and attatches them to the database? Rather than drag clicking them in
The intro is just speaks so much facts, Amazing video.
Thanks!
This video made me feel so much better about the things I have been confused about at school, thank you so much for putting this together.
So, this video basically summarizes like 80% of what I learned getting a degree in Software Engineering/Real Time Systems. Obviously lacks depth (how could you in a 22 min video) but is an amazing resource.
Great video! Just a tip, do not use == to compare null as it can be overloaded. Use "is null" or "is not null"
Please Keep this series going, This video is pure gold
Honestly there is only 2 important tips to remember, whatever the level of programming you have (Beginner or Experienced) you always need to take extra time to re-check your code in general, and fix/improve stuff regularly and also always backups your projects everyday !
But honestly it's still more like a thing of a mid/experienced programmer to make a game, I do not recommend to a beginner to start by making a game, start by something simpler, like a simple software and learn from it.
Creating a calculator is not the most exciting way to start coding. I say start with a game, it all depends about the scope. You don't start with a GTA7 project :)
this is by far the most useful unity coding video i've come across on youtube. you have been sent by god himself, thank you angel boy
Thank you! I’ve been trying to use car to simple of techniques to solve complex problems. It’s annoying how few unity tutorials teach more advanced methods. So again thank you for this it has been hugely helpful.
Really good video! One additional thing that I like to have as a standard when using strings for Invoking or Coroutines is to use the built-in "nameof()" function so the editor can identify the references.
Solid tips for beginner trying to get more serious with coding in unity. Great video!
great video i use those tips in my big unity project
These are great tips. I recently cleaned up a project significantly just by drawing a box for each script in my project on a piece of paper and drawing an arrow from each box to each box it referenced. I realized i had tons of messy and unnecessary references all over the place and was able to delete almost half of all the code I had written as well as delete an entire class that turned out to be unnecessary.
Great video! A brilliant shallow dive into a lot of concepts that was well delivered and very well edited. Kudos!
I am really impressed on how the video is structured and how many actual good tips of good clean code are here. Will be very helpful to many software engineers, thank you for your input
Glad you found it helpful!
I’ve only made two unity games and I’m already writing smart code and organizing my scripts and game objects… it’s probably my second favorite part of making a game next to actually programming it 😊
This would be too advanced for a lot of beginners, but this is peak Intermediate advice. Heavily recommend following these tips.
Hey man, thank you for this video! This video will save so much resource for so many people and i think you should be awarded by Unity!
Nice work! A lot of hidden gems that make it easier working with Unity.
Not even what I was looking for, but the advice given was so good that I watched all the way through.
Great video :)
Another random tip, if you want to serialize a field, but have an "auto property" (like public foo {get; private set;}, you add the attribute like [field: serializeField], to expose it in the editor.
This turns the "auto generated backing field" from that property into a serialized field on the objects.
This helps to prevent the need for the [SerializeField] private _field; public field {get; private set;}
Another thing that I prefer doing is explicitly numbering my enums, like
enum Foo { bar = 0, baz = 1, ... }, this lets you re-arrange them later or add/remove them if you change the enum.
As an advanced topic, you can also turn enums into bitflags (via the [Flags] attribute) for making your own masks like the layermask stuff, but that can be confusing, so it's good to be a little sparing with it, but it can save a ton of memory in some cases (i.e. a 32bit int can store 32 bools/flags, while a single bool is a whole byte).
Thank you for making a video on how to make games, instead of just how to make features. I really appreciate the help!
As someone who's just getting into more game development, this video is super helpful! Ngl may need to watch it again and take some notes for reference 😅
That's good to hear!
This seems really useful and you explain things well. I would love to see some more basic-building-blocks and more in depth videos from you especially revolving around Unity. Thanks so much for this video!
I'm a senior developer and I approve of these advice ;) I'm currently learning C# (transitioning for a while from Web-Dev) and I found them helpful. Thank you very much ;)
No offence but you can't approve any of this otherwise than it seems as common sense practices. I do applaud your transition though.
@@Johan-rm6ecWhy can't I approve? I mean, if I as a specialist can add to the credibility of the video, is that a bad thing? Some people will see this and will have faith in the video more. So overall it's a positive message, even if the advices are common, I know too many developers that don't follow even common advices or even enough good practices.
Damn. Sage programming advice from a young programmer. This guy is going places.
This is EXACTLY what I was looking for!!! Thank you for taking the time to make this.
Even though I already knew all of these tricks, I found this video to be a nicr refresher of possibilities you have to structure and improve code as well as show me that even though there's a lot left to learn, I've also already come a long way :)
Nice, it’s also helpful for non game programmers :) Great explaining.
I’m glad!
Lots of good advice here. The main omission from my perspective is unit tests. Increase stability and make changes quickly and safely by covering your code with tests :)
Creating assembly definition is really helpful to speed up compiling, I wish I knew it years ago, it would have saved me a lot of time.
Great video! There’s tonnes of stuff in there that can take new unity devs a long time to get to.
I would have liked to see mention of using non-monobehaviour classes, the biggest change i noticed moving from hobby to professional was how often is write things like static service classes for manipulating objects/data, makes for reusable code and saves you a lot of hassle
Usually I prefer more in depth tutorials, but this was surprisingly a good style for this specific topic. Nice work!
Thank you for the valuable tips!
you have no idea how helpful this is
You did great explaining things in an easy to digest manner. I hope you post more in the future. Good luck with your game as well.
Such a relief I'm already doing most of these!! These are excellent tips, thanks a lot!
Not just showing the tips but explaining and showing the mechanics behind it and examples.
Great video to help with these things. Never knew about InvokeRepeating and it's practical use like that.
Very good tips for the begginers. 06:25 - About the coroutines, I highly recommend to use a async Tasks instead. When you try to do more advanced things with coroutines it quickly becomes really messy, you not able to return a value for example.
I read this recently in the Unity docs: ''The Unity API isn’t thread safe and therefore, you should only use async and await tasks from inside the UnitySynchronizationContext. Async tasks often allocate objects when invoked, which might cause performance issues if you overuse them.''
and
"Unity doesn’t automatically stop async tasks that run on managed threads when you exit Play mode. To listen for enter and exit Play mode events to stop the tasks manually, use EditorApplication.playModeStateChanged. If you take this approach, most of the Unity scripting APIs aren’t available to use unless you migrate the context back to the UnitySynchronizationContext."
Which is true, it's strange, but if you just try using async Task await in your code in edit mode and stop the editor, unless you implement it in a certain way, it keeps playing it forever even when you stop play mode.
There's also an Editor Coroutine plugin you can download for editor coroutines, but last I used it it was in beta form.
Aren't they require manual cancelation and can continue running in editor? I'm not saying they shouldn't be used, but I wouldn't replace all coroutines with tasks and vice versa.
@@astrahcat1212 It basically means avoid creating your own threads and interacting with Unity APIs e.g. GameObjects there. UniTask is a great library that reduces the garbage generated and also provides utilities to use async/await in Unity 'safely'.
Thanks for the tips! I agree, it’s nice to have us young guys care about clean code! This was great help for my game!
The pit of despair...
when your learning and suddenly realise... there's very little material to teach you the advance stuff
these kind of vids really help XD ty
Are you serious?
@@saniel2748 XD yes its actually a thing.
I only found out about it when I began learning to code.
I was warned XD
@@Mel-mu8ox Dude none of stuff in this video is advanced
@@saniel2748 I think you miss the point.
and yes, of cause its not advanced. pit of despair XD
@@Mel-mu8ox Maybe I don't, enlighten me
Cuz as far as I know there are tons of advanced stuff on the internet. Most of it is in blogs not youtube though
4:55 Hold alt in your IDE to select multiple lines of code at a time. Very useful!
Another tip for the #6 could be [field: serializedfield] public {get; private set} to be able to change the property in the inpector but still private set. For the #7 I totally agree, decoupling is a great thing to learn and the observer pattern help a lot for that.
The best tutorial I've found on clean code... Great work
Glad it helped!
Thank fuck. Someone who actually knows what he's talking about. I've been a developer for over 20 years (I'm 46) and I agree with all of this. You should talk about about access modifiers, such as Internal, Private and Protected. You can also use directives like [assembly: InternalsVisibleTo: "A.Different.Assembly"] to allow access across layers.
good job my friend. I'm a self-taught game developer too and this video was really really helpful to me. Thanks a lot 🙏 . be strong and continue 💪
You can use Invoke with the actual function itself, not just the string name. This helps prevent typos and lets you refactor more easily
Extremely helpful video that introduced me to a few new concepts I had not encountered before. Great job!
The good news is this is incredibly helpful and is changing the way I write code. The bad news is I'm realizing my entire game is built on a foundation of jello and I have a LOT of rewriting to do
Yeah that happens a lot 😂
Glad it helped!
I'm planning to watch this video every month so I can include all the tips in my work. Thanks for this, i'ts really helpfull.
4:36 this is something I'm definitely planning to start implementing in future projects.
I see that you’re using fusion. What a wonderful framework!
ScriptableObjects were introduced in Unity 3.5, which was released in 2012. This feature has since become a powerful tool for managing data and creating modular systems in Unity, allowing developers to store data outside of scene files and reduce dependencies between game components.
Good Job!! The amount of skill you have at a young age is very impressive. Keep Going!
Exactly the video I’ve been looking for. Great stuff
This tips are awesome and is for all levels in my opinion either if you are a beginner, intermediate or advance developer
Gave the like after the dream game description. Doesn't matter if any of the content is any good "Fantasy, mmo, RPG, Sandbox, battle royale, powered by a block chain economy" for the win.
note: content is also good.
Just starting game making and programming. This is invaluable to getting a lay of the land. I might be trying to run before I walk, but all these seem to make sense even if most of it is going over my head. Thank you!
Hi there, I just started last week. Do you feel or are you any closer to making your first game? I feel like this goal is years away for me and it's all overwhelming
I did a bad thing and took a break. Life got busy and such. Id say just start on small projects and keep building up. I did a flappy bird tutorial and it made me hopeful. I might redo it because there are so many add-ons that can be used to learn. @@FenrirFinance
myself, programming only in simple basic, certainly not to the level of C++ or even C#, i came across so many problems like that, that i kind of start making my program way ''cleaner''... Especially when you have more then 2000 lines of codes, it is beginning the required a lot of 'convention' in your variable naming habits and you also learn to use 'include' so to get rid of code you really don't need to see.
I also implemented the idea of encapsulation as much as i can and make a real effort to have part of my code to do a single thing and get that result CLEAR WHAT IT RETURNS. So important, i also always explain what a section of code do and also explain what the variable really hold as value, meaning i explain what the value is from and what it should become. When you return to your code many weeks later, you need to read it all to get back 'into it' again.
Just one thing I want to add from my experience. As I like C# events more than those from Unity, there is a big advantage for the unity ones. When you're working in a team with designers, it's much more productive if they can change what happens on an event, than asking a programmer to change it. It's not always the case, of course, but it's something worth considering :)
Great video, thank you for these points, it is not very often to see more advanced architecture advise specifcally for Unity
Mostly good :D
Couple of things
Singleton is anti-patter that affect the SOLID principles mainly SRP and DIP for that reason you should never use singleton
Inherence section, you can here check the liskov sustitution, and mostly of the things that you mention your guns class should have, can be added later as a external components like ammo, attachments, recoil, spawn properties, etc
I'm learning C# and unity and I saw a lot of horrible code even in AAA games like Rust. I will say that stick to SOLID principle and the first chapters of your video will make a greater architecture that what I can see right now.
I imagine this is happening because making a game requires so much knowledge about so many things that sometimes they cannot be great on everything.
Keep up with the work!
Very satisfying content brother. Loved it.
That's literally what i inversio understood during developing my last game. Really good kickstart to good code, like it.
For Unity, I would recommend having a spare scene for when you want to sandbox or just make prefabs without cluttering you game scenes.
Great video, I’m sure you’ve noticed this now as it’s a year since you posted this, but usually methods have a capital letter at the start!
I gotta be brutally honest, when I began watching this video and I saw how young you look, I was thinking, dude ... what's this guy gonna be able to teach me?
It turns out ... quite a lot. Thanks dude. Power to you. Appreciate the content.
Haha I'm glad you found the video helpful
Agreed. I wonder if you plan to go to college/university what they'd be able to teach you. You seem to have no trouble learning so much already.
I was so glad I started a Git repository in one of my projects before trying to migrate it to Universal Render Pipeline... it costed almost nothing to put it in a back branch and go back to BiRP that worked much better with the assets I had hahaha
10:00 regarding singletons: Just don't make the error that your managers end up in circular references. This just makes it harder to take something out / replace it.
In our game I try to organize them in layers. (managers only have access to the layers below them)
18:00 scriptable objects are _not_ a recent feature... they are mentioned already in the docs to unity 4.6
ALSO ... those are beginner tips. You should know all that before starting any project that's larger than a game jam project.
There is definitely a major lack of people talking about advanced coding practices in gamedev, especially when it often becomes the biggest barrier for people trying to make games as their projects inevitably devolve into an unworkable pile of spaghetti. Hope to see more similar content
Singletons are fast to build, good to use, confortable to have... and easy to mess! I have used it too much, but now I prefer to use something more related to ScriptableObjects whenever possible. It is easier to maintain in Unity. Now, that's for small hobby projects. For a larger project, I have had really bad experiences with singletons =/
This is sooooo awesome! My God this is great. Keep up the good work.
Hey, you just answered to the many questions I was looking for.. especially the events and coroutines.. ... Thank you , cheers.
Yay!
Note on Invoke/InvokeRepeating or similar functions: Always use nameof(yourFunction) rather than "yourFunction" so that you don't risk forgetting to rename the strings if you rename the function later down the line.
Also the code snippet at 9:14 is incorrect. The else should be Destroy(this) or Destroy(gameObject), as you want to destroy the new one and keep the original rather than destroying the original and leaving a hanging reference.
Thanks for the corrections!
Great job. It’s a good refresh of important ideals. I would have added state machines in their but I mean that’s alot to cover so elegantly.
paused the video just to comment, thanks a lot! i learned a lot from this video. its very well put together and i hope someday you elaborate on each of these topics and other more advanced programing principles.
p.s you should really enable donations on your channel😋, i would donate to you if i could, you brought me value