Video

Damn. Sage programming advice from a young programmer. This guy is going places.

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.

On the Action class for your event, why did you not use the event keyword?

I feel like you can generate a navMesh with colliders. Its somewhere in the navMesh settings

What's great about this video is many of these tips apply to almost all software. I wish some of my coworkers would watch this lmao

For my project to come to a grinding halt first it needs to come to a grinding start.

Good stuff

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 😊

you have no idea how helpful this is

4:36 this is something I'm definitely planning to start implementing in future projects.

This video makes me feel like a freaking senior developer at my 17

this is just the video that i needed that you so much

This would be too advanced for a lot of beginners, but this is peak Intermediate advice. Heavily recommend following these tips.

Great advice

Man what happened to you.. I found the video and it is soo good. but you have only 5 videos.. years ago.. is everything fine?

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

Very Nice

Love the video

12 seconds in and I feel personally attacked

As someone with decade of experience with unity: Dont use unity for big projects. Ull suffer terribly and it will be too late to change engine later. Its closed black box and ull hit wall after wall of unity limitations and very closed software approach it have

Please Keep this series going, This video is pure gold

Its funnier that some guy is called "god dev", now is going to godot and did not have this impact full that you did. Thank you ❤

Okay, you didn't have to call me out that hard at the beginning of the video...

The only one I disagree with is the notion that you should completely isolate your scripts from one another. Setting that rule for yourself makes it hard if you need to coordinate different actions, like pushing the player back when you fire a weapon.

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

This is something I had to learn the hard way with my first game. It wasn’t huge or anything but I was still very new and oh boy was the backend the biggest piece of garbage 😂

Nice viedo but it's defenetly not ADVANCED!

Any progress?

dislike just because you are using the youtube name "Tesseract". you are not worthy of that name.

Will my experience from roblox studio help me

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!

Amazing video... Dahm I have to learn so much QQ I feel like a deer in headlights after looking at this lol

That's good~ thanks

Perfect video! Thank you so much!

Can you speak in English bro?

Advanced? Hmm 😂

wont unity events break when u change scene? lose reference? *question*

Really great content, keep it up man 😊

Extremely helpful video that introduced me to a few new concepts I had not encountered before. Great job!

Working on my first game and yea its slowly starting to turn into spaghetti code Its very early though and thus fixable still but yea its tough 😅

most of these are just basic c# tips that everyone should know considering working on a "big" unity project lol

That was the most useless video for "advanced" guidance...

This is sick! I am currently making a video similar to this one :)

Beware the pitfall of Singletons. Overuse them and you have a giant bowl of spaghetti soon. Mostly only a manager should ever be a singleton. Think like this: - I am a component, I receive orders, I return results and notify my observers. I have one job function and I do not know about anything that is not directly related to doing my job. I do not use Singletons, I do not send messages to other parts of the system. Any subcomponents I require to do my job I am solely in control of, everything goes through me. - I am a controller, my job is to control flow of logic and information and order things to be done. I still only control things within my job function, but this could be a wider set of things that are related. I am a controller, I do not micromanage; I expect my components to do their job, I expect my fellow controllers to do their jobs. I can use singletons(managers), but I do it wisely. Orders travel down the hierarchy (never horizontal), notifications and results travel up. Some will say this is rigid to work with, and it is ... however, it WILL save the project from failing with spaghetti syndrome, it WILL prevent lazy programmers to do shortcuts that come back to bite you in the ass later, and it WILL make it possible for a new programmer on the project to have a chance to take over and change the code base without huge side effects (we can not have a project fall apart or get severely limited because a programmer left the project leaving incomprehensible spaghetti behind). ed. Communications with components should happen through interfaces as much as possible, to prevent lazy programmers from messing with internals of components. Yes it can feel like unnecessary bureaucracy, and in small projects it is, but already at 2 programmers or code reuse between projects it pays off instantly.

You are officially the best

Watching this video has made me realise how terribly spaghettified my most recent Unity project is

Make more videos please

Suggestion for a sniper class perhaps when holding the shoot stick the cam can zoom in and the closer it gets to full zoom the more accurate the shot will be.

Here's my unofficial advice when you struggle with something like color palettes or other dev related things, just research what a successful game does and press ctrl c, ctrl v. Then just change it a bit.