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.

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 🤨

I'm doing it only for the auto-completion :)

Most important: compile time spelling check.

I came for this comment, lol

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.

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.

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!

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”

Fair enough. Everyone has different definitions of “advanced”. This was just a collection of programming devices that aren’t normally covered in beginner tutorials and that I myself didn’t learn for many years. Maybe I’ll make a part 2 when I am more advanced lol.

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 :)

Glad you found it helpful!

That's good to hear!

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

Exactly! Modular and decouple are good words that I probably should've used.

Great to hear!

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

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).

Thanks!

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.

Yay!

Glad it helped!

Good luck!

Yeah that happens a lot 😂 Glad it helped!

I'll consider it