ฝัง
- เผยแพร่เมื่อ 31 พ.ค. 2024
- Architecture Principles apply to Unity Game Dev just like any other Software Development. Let's dive into practical application of one of the most foundational principles in Object Oriented Programming - Favoring Composition over Inheritance (of course, there will be a bit of both) and a few Game Dev tips along the way!
The Advanced Dissolve shader you see in the video is at the top of the list of Assets below. In the video it is integrated with two Shader Graph shaders as it's own node for the leaves and the trunk of the trees which required a very easy integration. It uses a geometric shape to hide things between the player and the camera. It is well documented, and on sale right now. Check it out!
A few things about Tuples! The word "Tuple" comes from the field of mathematics, particularly from the concept of a tuple in set theory. In mathematics, a tuple is an ordered list of elements. The term has been adopted in computer programming to refer to a data structure that contains multiple fields, usually of varied types, grouped together. "Tuple" is pronounced similar to the word "couple" rather than rhyming with "quadruple," even though the latter shares the same "-uple" suffix.
🔔 Subscribe for more Unity Tutorials / @git-amend
#unity3d #gamedev #indiedev
▬ Contents of this video ▬▬▬▬▬▬▬▬▬▬
0:00 Composition vs Inheritance
8:20 Tuples
12:10 Generating UML
Assets Shown In This Video (Affiliate Links)
Advanced Dissolve: assetstore.unity.com/packages...
Aquarius Max Stylized Trees: assetstore.unity.com/packages...
Eole Foliage Shader: assetstore.unity.com/packages...
Dungeon Mason Tiny Hero Duo: (FREE): assetstore.unity.com/packages...
Dmitriy Dryzhak Models: assetstore.unity.com/publishe...
Chromisu: Handpainted Forest MEGA Pack assetstore.unity.com/packages...
VFX Trees: assetstore.unity.com/packages...
Kronnect Beautify: assetstore.unity.com/packages...
Follow me!
linktr.ee/gitamend - เกม
Hi everyone! I hope you are all set to reach a few goals in 2024 - I know I am! Let's "G" + new string('O', 5)! 👍
I enjoyed this video. It helped sort some things in my mind. I made a small game a couple of years ago. I used every worst coding practice ever. I'm getting back on the horse to make another game and it's difficult to architect a robust system. I'm learning a lot.
@@elijah-jones-inboxGlad to hear it!
Your videos are hidden gem - way better than anything other on youtube - way better than people with hundred thousands subs and to do unity guides.
Thank you, I really appreciate that! Too kind.
Documentation Documentation Documentation. Throwing summary blocks everywhere helps a lot. Especially that tuple at 9:40. I throw them above classes/getters/methods. This works really well for ScriptableObjects, where you can just highlight the class name and it goes "Oh, this scriptable object is for storing audioclips and has functionality to easily grab a random one." Now you don't have to go rabbit-holing opening/peaking scripts to find what a function/class/getter does.
Yes, that's a great point. I tend to document extension methods as well for this reason. Thanks for the comment!
But then again, if your naming conventions were good enough, you shouldn't have to tell people what your classes or methods do.
There are exceptions, of course, but documentation is more often than not a symptom of bad naming conventions or structure.
@@Hersatz Completely agree. Documentation should be implicit in the structure of your code itself. Naming being the big main thing to watch out for.
I do imagine large language models coming in to provide documentation as well though.
How much documentation?
From my experience, one can easily overdo it with tons of redundant documentation, effectively wasting time and energy on something that's either of not much use or will eventually change.
I am not a fan of internal documentation. Although highlight does tell you what the class is, it likely won't tell you how to use it, where to use it, nor what's the context of the class (whether it has dependencies on something else, etc.). Certainly the last thing you want is someone else (or even you) doing local changes that are not consistent with the rest of the project, or might cause bugs or technical issues. For example, when you do make a unit spawner class, but make the mistake of not knowing that every unit needs to be registered in the unit manager, as other mechanics do need a quick access to all the units.
@@TehAntares That's a good point as well. It can be challenging to decide what to document inside of a class. Often times comments add no additional value and are just visual clutter. Generally speaking, internal comments should only serve to explain code that actually requires explanation. I think this article has some very good points:
stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/
I absolutely love this channel lately. I really appreciate how you actually help people solve complex problems. Most other youtubers just give surface-level begginer if statement code instead, and try to sell me their overpriced course on top of that. Really appreciate your videos man, keep it up!
Thanks for the kind words!
I almost exited the video when you started the lecture on favoring composition over inheritance. I'm glad I stayed because I enjoyed your examples on tuples and your trick for easily creating UML diagrams. Thank you.
Great! Glad to hear it!
Wow, that's actually an insanely useful video. I'm happy I stumbled upon your channel. Immediately subscribed. Your tip with tuples as a return type is sick. Will use it!
Awesome, thank you! Welcome!
Happy New Year :)
I really enjoy following your channel. One of the things I have experienced as the biggest challenge for most gamedevs is to keep a tidy architecture in their code. I have come across many developers over the years that give up (or delete all code and started over) due to major techincal debt and code complexity. Your channel is amazing at illustrating good practices without overselling the benefits/challenges. Your channel is a true gem!!
Happy new year! Thanks for the wonderful comment!
Like everyone else has reiterated before, your videos are excellent! Please continue banging out some fire videos in the coming year. Happy New Year! Keep up the great work!
Thanks, will do!
your channel is amazing!! I'm still beginner/low-intermediate level so a lot of your vids are over my head, but I can't count how many times I've had eureka moments while watching your stuff
Awesome! Thank you!
Happy new year brother!!! You are nailing it with these videos. There’s going to be a whole lot more skilled devs out there because of you. Thanks again!
Happy new year! Thank you!
Thanks for making videos during the holidays. Great video. Going to review some of my code and apply this.
Thank you and you're welcome! All the best in '24!
Eye opener. Really love your hands on approach.
Glad to hear it! Thank you!
The moment I saw "Composition vs Inheritance" I followed you! what a great video. Keep it up!!!💯
Sweet! Welcome!
Great video, as always :) still looking forward to a video about what you do for work and any tips sometime! But all your videos are a blessing, thank you!
Thank you! Happy New Year!
Happy New Year! @@git-amend
Its really interesting how much of this becomes second nature after years of developing
Yes, I agree - I had to sit down and think for a bit before attempting to explain it!
Op do you have any other tricks such as the “Is A” and “Has A”?
Great video. Easy to listen to voice.
@@corgalie I have a few more :) There will be more architecture videos coming up soon!
@@corgalie there's a lot of resources online about architecting code. But honestly best way to learn is to try something, see the issues, and refactor it.
And then just read or watch videos about architecture. There isn't one glove fits all, it's all about the problem you are trying to solve.
For example, a lot of people say singletons are bad, but they are fine. Many enterprise codebases have them. Its using them badly that makes them well bad.
But at the end of the day, we are here to make games. This is just to make the lives of your future self and team easier. But the player isn't going to see the code so game design is always more important.
Code is just a laying the bricks, and architecting is making it structurally sound. But it won't tell you how to build a house that people want to buy.
This video is literally a 'SpecialResource'! It helped my understanding a lot! Please keep on posting architecture/pattern videos, I'm more than happy to support!
Glad it was helpful!
Wohoo I'm so happy I found your channel, it's a hidden gold mine ! Thank you for your high quality work !
Glad you found it! Welcome aboard!
Really helpful! Thanks as always and happy new year!
Happy new year! Thank you!
WOW! This was an amazingly structured video! Loved that you took the perspective of a new learner at the beginning and showed the progression from easy/messy to advanced/structured with tips along the way. Awesome stuff and these type of tutorials just encourage me to keep on coding! HNY 2024!
Thanks so much! Happy New Year!
I would love to see how you would make a simple inventory system using just a hotbar like in lethal company. The way you explain and structure things is incredible
Interesting, have not tried Lethal Company yet. Will check it out!
@@git-amend Its a fun game. Not asking for a 1 for 1 but just the concept and proper structure. Much like the examples in this video I tend to over complicate things when it comes to an inventory system. So learning how to get the base down for a strong structure will be amazing. Im sure a lot of other people will enjoy it as well.
just found your channel. This video convinced me to subscribe! Really good work!
Awesome! Glad to hear that, welcome!
Fantastic as always, and interestingly something I'd just been contemplating in relation to a process my controller is using
Awesome!
This is, this is, i always wonder why no tutorial ever teach about tuple, i personally think it's usefull, many of them use "out" keyword when needed to deal with more than one returning value, this is great keep it up man
Hey thanks! Yeah, I agree, tuples are an under appreciated feature!
To be honest when it comes to value of your videos - you are top 1 above people with hundred thousands of subs.
Thank you!
Thanks for your awesome resources! 👌
Glad you like them!
Hi, just want to say thank you so much for this video and other amazing contents. I struggled a lot when refactoring part of my game code, but your tips are truly helpful as it make me feel clearer what I need to do!
Great to hear!
Thank you for sharing, and happy New Year to you! :)))
Same to you!
This is a fantastic video, thank you!
You're very welcome!
Amazing! I have two years of experience and I didn't need tuples. But I think I might have needed them but didn't know it xD Thanks for the info and happy new year
Right on! Thank you!
I love this subject, it'd be awesome to have more practical examples like this one or for more complex topics
Absolutely, I plan to make quite a few more on this subject - seems to be not too much practical advice about it on YT.
Exactly ! That's nice 👍
I organically started building everything "standalone". I have a "Core" folder of scripts that I bring into every new game and am always improving. My Player class uses inheritance but very minimally.
Nice when it comes naturally! Sounds similar to what I tend to do, my library is always slowly growing. Cheers!
@@git-amend I'd say it was "naturally" in the sense Pain is natural :D The pain of refactoring led me to it. Thank you for the video. I want to get better at Composition.
Yippee 🥳 - Another amazing video from one of the best Unity tutors out there.
Thank you! Happy New Year!
@@git-amend Likewise
Hey, great video as always. I love the little touch-ups you do, just those little refactorings. That's where my question comes from. I kinda expected the ResourceType enum to be deleted once the ResourceConfig was in place. Do you or would you handle your types like this e/g defining type in code, choosing it in ScriptableObjects? Or was it just the cut for the video?
Cheers and happy new year!
Thanks! That's a good question. For me - I usually keep them in an Enum format so I can easily have a drop down menu in my scriptable object definitions and not do any extra work. However, you might want to approach that differently if you want to be able to define types from inside Unity - or somewhere else, like say Google Sheets. In that case I would probably have a ScriptableObject that just represents the list of types aka a ScriptableList. This works great for any kind of data that needs to change in the Editor or at Runtime.
Great video again! You could also return a list of gathered resources instead of a tuple. That way you don't have any limit on how many resources a node can contain. What do you think?
Great job and I can't wait for another video!
Thank you! Yes, a List or another Collection type would work if you didn't need to distinguish one Resource from another, also great if you wanted to iterate over them with LINQ. The only downside (in this example) would be that you wouldn't be able to tell which one was the 'special' one if the consumer wanted to treat it differently somehow. Also, most collections in C# are reference type whereas a Tuple is an immutable value type, something I didn't mention explicitly, but might be something to consider. Cheers!
Agree with the sentiment of the video. However, I'm a bit surprised you don't bring up in your video that unity itself is component based. To me, the best advice is to embrace that. So often you see a Player class that has the functionality. Whereas in 95% of cases you'd want a health component, attack component, player input component, etc
god dammit you're finally gonna be the guy that makes me give a shit about dependency injection, aren't you?
subbed. humbled and subbed. good shit homie. I usually get all claws out when I see people trying to apply a lot of software engineering paradigms that Unity's community has long since kinda overlooked (generally), but your approach is solid. no platitudes, no generalizations, just teaching approaches and respecting the language. shit rules man.
Welcome aboard!
Wow, great video. Subbed!
Awesome, thank you!
awesome video. thanks!
Glad you liked it!
When preferring composition over inheritance in my project, I've found that I still use inheritance frequently - just in my prefab variants instead of my code. For example, I have an Actor prefab (not a MonoBehaviour) that has all the functionality for moving around the world, taking damage, and holding an inventory (separated nicely into components), and then I have Player and Enemy prefab variants that I can conceptually think about as "Actors" since they are variants of the same prefab. For me it really feels like a best of both worlds way of doing things.
That's a great approach! It's all about finding what works best for your project and adapting as needed. Cheers!
Really interesting to see this concept being brought up in Unity. As a Godot hobbyist (who hasn't really touched Unity in 4 years or so) it's something that gets talked about a lot in the Godot ecosystem because, unlike Unity, there's no ECS it's all just "nodes" so an entire scene is one big composition tree and it's therefore super important to structure your code that way to work within the systems provided and super easy to do so.
One example would be in the project I'm currently working on where I'm currently making, for it, a finite state machine in nodes rather than all in code. This works super well for this because, yes, you do have some inheritance with a base state class for instance, but since you're designing every state just based off of a few boilerplate methods in the base class and then placing that as a child object of the state machine that therefore just composes that particular state machine. The equivalent in Unity would either be making a state machine game object with a bunch of child game ibjects for the states or making one game object with a bunch of scripts for both the state machine and every individual state neither of which fits super nicely into the ECS of Unity which is probably why this isn't as core of a discussion within Unity development since it's just about how you structure your code not how you structure your entire game. I do find it really interesting to see how the same concepts do then show up in different ways in how you guys actually then write code though which is obviously quite different to the ideal Godot workflow since you have much more monolithic objects so while you wanna keep components you intend to reuse nice and small, generally it's ok to pack lots of features into one script and handle all the different logic and conposition within that which, while it absolutely can be done that way in Godot, generally isn't our ideal workflow with Godot generally preferring much smaller scripts (only one of which can be attached to any node) and then setting up their interactions through the node hierarchy and seperating out objects from each other using the scene system which is essentially like prefabs except used for pretty much everything from an enemy you wanna re-use loads to a gun you wanna have the player use to the main protagonist themselves or the game world and up to whole game scenes (hence the name). It's a very different structure where the game is just inherently a bunch of classes each composing greater and greater parts if the overall world and it's up to you to plan out how you intend to divide it up whereas Unity has everything already split up into neat objects but it's up to you to turn them from amorphous, a-hierarchical lumps of code into well order and structured units that are easy to work with through how you plan out and structure your code. It's really interesting to see how that shifts the way in which particular coding principles, such as inheritance vs composition, then get adapted and applied in different ways to fit the differences in workflow between the two engine.
It's fascinating to see how different game engines approach code structure! Thanks for sharing your insights from the Godot perspective.
Hey supreme leader, hope you have great holidays! Need advice please, sorry for asking here, quite desperate (I'm skipping holidays just to work/learn), you're the best unity dev right now at youtube by far.
Let's say you know how to code a specific game, closed scope, solo dev. In a terrible/spaghetti/unoptimized way, but you just know how to do it. Would you rather code it now, even it being a total mess or would you rather hold/study and then start from good architecture before putting any line at rider?
I'm not sure if I just go for it and then refactor once I get the skills (not sure how much work it takes) or if I should study a lot before writing any code at all (aiming at production-level quality). My skill level: I coded a clone of Slay the Spire by myself, in the worst possible way (breaking every principle of SOLID, using tons of FindGameObjectsWithTag, having 500+ lines monoliths as scriptable objects, its fucking scary), but it works perfectly. Gonna code a 2d turn-based game by myself, would love your advice.
Thanks a ton!!
Thanks for the comment! In my opinion, you don't need to put your next project on pause - instead of halting everything to learn, integrate learning into your development process. As you learn new concepts, apply them to refactor parts of your code. You've successfully built a game, which is a significant achievement. This experience is invaluable. Start by leveraging what you already know.
Build a small part of your new game, refine it, learn from it, and then move to the next part. This way, you’ll progressively improve both your game and your skills. While aiming for better quality is important, beware of the trap of perfectionism. It's okay if not every part of your code is exemplary. Sometimes, progress is about moving forward, even if it's not perfect.
I think you saw my post about suggested books from the last video. I think these two might be good for you:
Agile Software Development: Principles, Patterns, and Practices - Robert C. Martin
Clean Architecture - Robert C. Martin
Read a bit every day as part of your routine and start applying some of the concepts as you write code for your new project. Remember, every developer has written code they’re not proud of. What makes you a better developer is the willingness to learn from past experiences and continuously improve. Your journey from a spaghetti codebase to a more structured one will be a valuable learning experience.
@@git-amend wow thanks for the effort of coming with such a detailed reply, you rock, gonna follow that 100%!! I won't forget this lesson
mermaid markup can also be used to visualize code in varying different ways.
Interesting. Looks like it has some VS Code integration too.
Well done video sir, commenting for the algorithm!!!
Much appreciated!
really useful tutorial
Glad to hear that
Amazing video.
Thanks! Glad you enjoyed it
Question - I noticed you have some tasty plugins for Unity. I see Console Pro - which is nice, but also your Unity windows (the dropdowns inside of Unity) are black, what are you using for this (this doesn't come with with the standard dark-theme)? Also, your inspector looks different as well - are you using something for this too?
The difference in the Editor (black backgrounds) is probably because I'm using Unity 2023. It has some nice features like scrollable context menus as well, among many other things. I have several additional Assets running in all projects, and there will be a video about my setup at some point since it's been requested many times. For the inspector, I use Better Transform from Tiny Giant Studio:
assetstore.unity.com/packages/tools/utilities/better-transform-real-size-global-local-switch-and-child-parent--258314?aid=1101lw3sv
@@git-amend Thanks for the response - take care!
Interesting about the tuples, didn't know about them... but I think I would've used an array unless I really needed to know that the 2nd harvested item was a specific type of harvest, in which case it would likely be a different class anyway! Is there a particular reason you wanted that separation?
In the scenario shown in the video, using a ValueTuple is preferable over an array for several reasons. Firstly, ValueTuples allow for clear, named properties, enhancing code readability and making it explicit what each element represents. This clarity is especially beneficial when returning a regular harvested item and an occasional special item, as it avoids the ambiguity of array indices. Additionally, they offer the flexibility to hold different data types, if that was something you chose to do, providing a structured way to return multiple values without creating a custom class or struct.
I might choose an array over a tuple if I were unsure how many items would be returned or if I wanted to use the result in a loop or LINQ.
Hey, awesome informative video.
I am wondering, what code conventions are you used to, because I worked mostly with rules by Microsoft code conventions
Thanks for your comment! My code conventions fall in line with what I do at work - which actually involves several programming languages other than C# - Java would probably be the biggest influence in that area. Additionally we also use automated tools like Prettier to format our code when making commits so that it is always consistent - it has built in rules, so as a team we never have to argue about these kinds of things - we just use the tool: prettier.io/
Thanks for your response. Interesting, I am a c# developer and I am sticking to Microsoft conventions and finding your code a little hard to read for myself.
Thank you for the exclusive advanced tutorials on C#+Unity
This is the first architecture video I've watched where I said "aaaaah, OK. I get this" without going and looking for six other videos like it. Any chance you understand dots enough to explain it like this?
Is it messed up that I can't wait for family time today to end so I can watch everything on your channel? (posted at 4pm, new years eve 😂)
Haha great! Maybe start with the Programming Patterns playlist! No DOTS videos on the channel yet, but you aren't the first to ask so maybe one of these days.
i favor composition over inheritance, but i still sometimes use inheritance.
for example: both a door and a resource node are Interactables, but each of them has very different interaction.
in the character controller i check if what i am looking at, is an interactable, and if so i call interact().
having a class that will composite both of these is not the best.
This was a great video! Do you have another one that applies Composition to create different character types? Each character would have different abilities or stats. Like for an action game, have a Goblin, Dragon, Boss, and so on. Each character would "have a" melee attack, ranged attack, defensive tactic, maneuver tactic, special ability, perform task behaviour, and so on. On that note, what if you have a special character like a Boss that has finishing moves that regular enemies do not. Would you create a different base class for that? Or keep the same base class of perhaps "NPC" and just leave certain fields blank for those missing features? Curious to hear your insight on this. Thanks, great channel!
I do not have a video specific to that context. However, you are on the right tack with your description. I would start splitting the character/enemies into specific domains - combat, movement, abilities, etc. Those would likely be further reduced. The amount of coupling and extent of the inheritance hierarchy really depends on the project though. We'll have more videos on this in the future, but you might want to watch the videos on Strategy pattern and the Dependency Inversion principle. Cheers!
@@git-amend Another question I had is about the architecture of components for a character. Right now I have a ton such as a NavMeshAgent, Rigidbody, AnimationHandler, Health, SquadHandler, Inventory, FieldOfViewHandler, and so on. Currently all these components are gathered in the NPC class, then passed into the NPCController. The NPCController is then passed into concrete abilities such as dash, melee, and so on. The abilities then can use Controller.Inventory or Controller.FieldOfViewHandler and so on. This architecture feels dirty but I'm unsure the cleaner approach?? I'm still fairly new to programming so I'm not sure if I'm phrasing this correctly but I guess what I'm trying to achieve is the idea that concrete classes (the specific ability) can access the components in the high-level classes to cause an effect. Or should I be more thinking of it in a completely different way?? A specific example is when an enemy enters the AttackState, it needs to Add itself in as an attacker - so SquadHandler.AddMember(). So the AttackState requires access to the SquadHandler. In the same vein, StateParameters needs to be passed into AttackState so it can affect the Animator, plus the Agent so can use things like Agent.isStopped = true, plus the FieldOfViewHandler so the AttackState can determine if the target is still in view, and so on...I think you get the idea. A lot of things are getting passed around into different states as well as different abilities. Sorry for the long description but being a noob means it's hard to describe these problems. Appreciate any direction to cleaning this up for the long term. Thanks once again! You are amazing!
@@inkofthedragon It seems like you need to reference various services from multiple locations, possibly even static classes or classes instantiated at runtime. If that's the case, then there is nothing wrong with passing in an object that exposes references to the specific services you need. A cleaner approach is to just pass in a Strategy or Command to be executed, so that your states for example are not tightly coupled to behaviour. The strategy can be created at runtime and contain the references and logic to be executed. This is more in line with the single responsibility principle and allows you to change behaviour in each state if you need to.
Try not to let perfection get in the way of progress. Just keep building things and applying knowledge that you acquire. As you continue to learn more, and are exposed to new ideas and concepts, your skill level will naturally increase as you apply that new knowledge to your project. Remember, all senior developers were juniors once!
I love youtube recomendations :D
Welcome!
How come your create menu has a scrollbar? Is that part of Unity 2023? Or maybe a Windows feature? I'm stuck in the LTS versions for reasons and use a Mac.
Yeah, it's a feature of 2023. To be honest, it's taking me a while to get used to the new menus, but that is one feature that is pretty nice.
What’s going on with that transparency shader on the tree? The one that’s letting you see your character when it’s occluded.
Is there a video about it? :D looks super useful
No video on that one (yet), I just started using it this week. It's the Advanced Dissolve shader made by Amazing Assets. I've taken that shader and used it as a node in several Shader Graphs used by my environment assets (made by Aquarius Max). It was surprisingly easy to use and has really good demos and documentation. It's on sale right now 50% off. Link in the description if you want to check it out! So far, I really like it.
So as a beginner my code tends to get messy when I start implementing the visual side of things. Say with your code near the end, when interacting with the rock to get a resource, how would I impliment visual change? Such as the rock breaking. Or how do I update the UI? I'm not wondering how to do it as I know of ways to do it but structurally how do I keep my code clean and add all these other elements that are part of every game.
That's a great question. I was going to use the tree as an example, because I was working on the visual effects for chopping it down already but decided that was going a bit far for one video. In most resource gathering systems, you might need to remember some state - like how many times the node can be hit before it's exhausted, and what particle effects to play each time, and how long until it is ready for harvest again. As it gets more complex, if you feel that your list of exposed fields is becoming repetitive (or too many) consider extracting your visual effects and sounds into one or more strategies. So you could have a strategy that plays some sounds and vfx during harvest and another one when it's exhausted. Then you just use different strategies for trees and rocks, and you only have to change those in one place in the future.
@@git-amend Ahh great! I’ll look in to that :)
hi, do you have an information about how you did your trees slowly disappear when its abstracting the camera? id like to know the technique thanks
is it like a shader? hmmmmmmmm
A few others have asked so I added some detail to the description of the video. I'm using a shader called Advanced Dissolve from Amazing Assets - there is a link in the description. My trees use several Shader Graph shaders, and I've integrated that dissolve shader as a node in the graph. It uses a geometric shape to determine which area to hide. It's very powerful, well documented and easy to use. Link in description. Also - it's on sale right now 50% off during the New Year sale.
@@git-amend make a tutorial video perhaps? would be a cool content 😍
Great guide as always, I am in minute 5, and asking the question before i finish, So what if our some of our base nodes has no special resource? Wouldnt it be a reduntant methods in some of derived classes, for example a Gold Node without special, wouldnt it break Liskov's substition principle? I always like the idea of "Composition over inheritance" but while applying it in a medium scale project, i find myself duplicating a lot. writing the same thing.
Btw, the PlantUML tips is extremely useful!
Thanks for the comment. LSP states that objects of a superclass shall be replaceable with objects of its subclasses without affecting the correctness of the program. If some base nodes lack special resources, it doesn't inherently break Liskov's Substitution Principle as long as derived classes still fulfill their base class contracts, even with some methods becoming redundant. In fact, the Null Object pattern is very useful in these scenarios - but I want that to be a separate video so I didn't get into it here... stay tuned!
In regard to duplication - this is almost always indicates that you should consider Inversion of Control / Dependency Inversion. Duplicate logic can almost always be injected one way or another as a service or strategy.
@@git-amend Great explanation. I would love to see some examples about Liskov substition later on if you have time!
@@TheKr0ckeR Quite a few people have requested a good SOLID video, so I'll plan one for early 2024.
@@TheKr0ckeR consider this method: void Gather(BaseNode node), and this class BigGoldNode : GoldNode (which inherits BaseNode). LSP basically means that if you pass in BigGoldNode instead of GoldNode, the program should still work.
Hiya, bit late to the party, but for class diagram generation you can also look into automated documentation generation. I hooked my project onto Doxygen and am able to generate UML diagrams without the chatGPT intermediary step.
Still though, this is a great video, I'll be binging your channel when I find the time :)
Thanks for the tip!
Ur vid is so great. Im just curious the way u set up camera so that the tree does not obscure the character, can u help me?
Thank you! I'm trying out the Advanced Dissolve shader made by Amazing Assets. I've taken that shader and used it as a node in several Shader Graphs used by my environment assets (made by Aquarius Max). It was surprisingly easy to use and has really good demos and documentation. It's on sale right now 50% off. Link in the description if you want to check it out! I really like it so far.
@@git-amendThank u very much!
Nice one.
I always make class one by one no need inheritance or anything then if I found CTRL+C alot, then I could merge the class by using inheritance or interface even the generic one.
For programer progress is better but the important thing is make it lazy.
Sounds similar to my usual process. It helps me to write a small amount of code before I decide on an abstraction, if any. Cheers!
Are you creating a sphere that follows the camera and apply the Advanced Dissolve shader to it? (To clear the trees and stuff so you can see the character)
A cylinder actually - it runs from the camera to a game object just above the player. That particular shader has support for many different types of geometrical shapes, and I'm thinking a cone might actually be a little bit better - still playing with it. I integrated that shader with the existing leaves Shader Graph, which was surprisingly easy and documented. Link is in the description if you want to check it out, it's 50% off right now. It's called Advanced Dissolve by Amazing Assets.
@@git-amend I just got the asset. I hope the affiliate link worked, as I also got another asset at the same time.
Can you talk about the game architecture when using DOTS and ESC?
I was really confused about game architecture when I first learned about ESC a few days ago.
At some point we will talk about it. In the meantime, have you seen Code Monkey's new video about DOTS?
@@git-amend Yes, I just watched it. But I'm not sure how to transfer the architectures you taught to ECS.
It would be great if there was an example video, looking forward to it from you
instead of doubling "special" resource fields and methods, there can be a bool for isItSpecial or not.
Nice
Thanks!
I would rather have a BaseNode and SpecializedNode separated, returning array of resources instead. So the base class is open to extension in the future and doesn't have any unused variables when special resources are not configures.
Top Videos
Thank you!
Wait, you can destructure things like you can in Javascript? I've been doing it long hand in C# forever.
It’s only been available with C# 7 onwards - I forget exactly when Unity added support for it, not too long ago
Serialization is such a biyotch when using Interfaces everywhere. And I'd really like simpler ways to share functionality without encapsulating them in a third class!
I sometimes forget how annoying it can be, since I've used Odin in every project for years now.
Gold
Thanks!
Can’t generics cover a lot of this?
👍
awesome work with a sexy voice, what can i ask for more. Thank you very much.
Aww, you are too kind! Thank you!
I say: both
Absolutely!