I struggled to find a spot where I couldn't : )

You're very welcome!

Great to hear! More on the way!

You're welcome!

Fantastic!

Awesome! I'm sure you'll find a place for a factory!

Thanks! Glad you are getting a lot out of the videos!

Glad you like it!

Thank you!

Glad to hear that!

Thank you for your insightful question. While it's possible to have Sword and Bow as Scriptable Objects and assign them directly, the Factory pattern introduces a layer of abstraction that allows for more complex creation logic that can be easily modified or extended - for instance, if creating a weapon involves setting up multiple parameters or state, a factory can handle this complexity in one place and you won't need a different Scriptable Object for every type of Sword or Bow in your game. In the example in the video, the Sword and Bow are very simple, but you might want your Weapon Factory to have a reference to a secondary Factory which produces a Strategy for calculating damage or for targeting. And if the Factory becomes fairly complex, I would add an internal Builder to it as well.

Thank you! Cheers!

Right on, that's what I like to hear!

Hi mate, One thing i did run into implementing this method (i'm still fairly beginner), is that interfaces and scriptable objects cannot implement monobehaviour. Which also means no Coroutines. I managed to find a workaround by creating a static class which you can pass a coroutine onto and it creates a single empty object to instantiate it. I was just wondering if there was any other strategies to implement monobehaviour using an abstract method like this pattern? My use example was trying to implement a burn over time with 'ticks' over the duration? Otherwise would a concrete abstract class that inherits scriptable objects as triggers for the effects be a better solution? Love your content mate, still getting across it but its the best videos of design patterns with actual unity examples i've come across! keep doing your thing.

@@modiKuts For me personally, I tend to roll my own timers. You'll see that in other videos, but you can also see the code here: github.com/adammyhre/3D-Platformer/blob/master/Assets/_Project/Scripts/Utils/Timer.cs Alternatively, there is a very good free asset you can use for Coroutines that gives you a lot more control and does not require monobehaviours: assetstore.unity.com/packages/tools/animation/more-effective-coroutines-free-54975

amazing. Thanks mate, i'll get across it today. legend.@@git-amend

One last question, Can you please point me in the direction of where to get Copilot integrated for unity like you have it? Cheers.@@git-amend

Wow thank you!

@@git-amend Your content is of great quality, your videos are impressive.

Personally I tend to use C# objects as much as possible, however MonoBehaviours make life easier when you want to hook into the Unity lifecycle. Maybe I can talk about that more in the future. A few people have made similar requests to your video suggestion, so there will be a future video about that too. Cheers!

Absolutely. My general practice is to start with an interface, create 2-3 concrete types and at that point determine if it's worth extracting common elements into an abstract base class. Cheers!

You're welcome for your answer.@@git-amend

In a simple game assigning a Scriptable Object directly to the player is often sufficient. However, in a more complicated game you would begin to use development principles such as separation of concerns, dependency inversion and abstraction. Assigning items directly to the Player tightly couples the Player to the base class of the item, and the more tightly coupled your game is, the harder it is to make changes in the future. We'll be talking about Inventory systems in some upcoming videos.

That is unexpected and very gracious - but I do not actually have anything like that yet. I'm happy to hear my videos helped you out, and I'm curious about your project. Once the channel is a little bit bigger, I have some ideas for some extra resources / rewards that might be of interest to people who want access to those kinds of things through something like Patreon, or maybe even a full course on these kinds of topics.

@@git-amend I will be the first one to buy your full course, or support you on Patreon. My project is a university final project and your video helped me immensely advancing into building my shoot em' up. What I liked the most is how you apply the design patterns in game development, I usually use them in other software development area, seeing how you were able to implement them and get great value from it in game development was very nice to see and really exciting for me. Again, I'm very grateful for your work, I hope to see this channel grow and that your content get the audience it deserves.

@@anasmostefaoui3027 Thanks for the kind words, and congrats on your final project. I'm very happy to hear that; it's very motivating to hear that a subscriber has benefited from the channel! I will certainly keep you posted on future developments!

As your projects grow in complexity, you'll start wanting both to work from abstractions and also move more and more away from MonoBehaviour. The factory gives you the power to supply any interface, or multiple interfaces without tighlty coupling a Sword to your Player. Instead the factory determines what IWeapon to supply at run time, and that could be for all entities in your game. I forget the exact example I used, but the purpose is to decouple your game objects. If your Player just has a [SerializeField] Sword, they can only ever have a Sword. Try to see beyond the 'Weapon' example too though. You might have an ISaveSystem and a SaveSystemFactory that supplies a Json save module, but later you decide to change to Unity cloud save. You only have to change what the Factory supplies and not every single class that needs access to the save system.

Well, that's more than I can answer in a comment, but will be a topic of a future video.

Great comment, and perhaps a great topic for a future video, as I know this is a pain point for many people. While the Factory pattern is useful for creating objects, a more suitable pattern for this scenario could be the Strategy pattern. Here's a brief overview: The Strategy pattern is used to define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from objects that use it. In this context, each type of armor part (helmet, arm, etc.) could be treated as a strategy. You can create an interface, say IArmorPart, with a method like ApplyPart() or ChangePart(). Then, implement this interface in different classes representing different armor parts. This approach will remove the need for switch cases and will make the code more organized. Each armor part's behaviour is encapsulated in its respective class. You could still use a Factory to create your various Weapons and Armor, but when creating them, you also provide each with an appropriate Strategy that will contain the logic for applying themselves to your character(s). Small example: public interface IArmorPart { void ApplyPart(GameObject character); } public class PlayerEquipment : MonoBehaviour { public IArmorPart currentArmorPart; // or maybe Dictionary equipment; public void ChangeArmorPart(IArmorPart newArmorPart) { currentArmorPart = newArmorPart; currentArmorPart.ApplyPart(gameObject); } } [CreateAssetMenu(...)] public class HelmetPlacementStrategy : ScriptableObject, IArmorPart { public Mesh helmetMesh; public Material helmetMaterial; public void ApplyPart(GameObject character) { // Logic to actually change the armor on the character. // For example, find the helmet mesh renderer and apply the new mesh and material, // or activate/deactivate GameObjects. } } This way your various strategies determine what happens when you 'Apply' them to your character, and not a huge list of conditional statements. Hope that helps give you some ideas!

Many thx for this amazing fast and detailed answer. I will track the video about strategy patterns and will try my best to update my code in a clean and efficient way. Thank you so much :) @@git-amend

Haha thanks!

Great to hear that you found the video helpful and are interested in diving deeper! You're right; design patterns like the Abstract Factory often show their true colors when the complexity of the system increases. To address your question: The value in having separate factories and then grouping them into an abstract factory lies in modularity, separation of concerns, and ease of extension. By keeping individual factories, you can specialize them for creating particular types of objects, which may involve complex instantiation logic that is best kept isolated. An Abstract Factory serves as an orchestrator that can produce a family of related objects by composing these specialized factories. In a game development context, imagine you're making a multi-theme game with "Forest" and "Desert" environments. Each environment has its own types of enemies, plants, and weather conditions. By having individual factories for each category (EnemyFactory, PlantFactory, WeatherFactory), and then using a "ForestAbstractFactory" or "DesertAbstractFactory" to group them, you can easily switch between environments by simply switching the abstract factory. Each specific factory already knows how to create enemies, plants, etc., specific to its environment. So, when you decide to add a new theme like "Ocean", you can easily extend the system by creating new individual factories and a new abstract factory without touching the existing code. This makes your code more maintainable and scalable.

​@@git-amend I think I understand now, thank you! Though following up on your example, would it be recommendable to have the abstractEnvironmentFactories (forest, desert, and ocean) all inheret from one class that has all the factories or would you recommend another approach. I ask, cause I was curious about the organization of the elements within the factories and I know having too many inheretances can get messy quickly. Thoughts?

@@zerothehero.takeasip6612 Great follow-up question! Like all engineering decisions, the answer is always, 'it depends!' Generally speaking, I would start with a base interface that your consumer class can use. For example, IEnvironmentStrategy could define methods for CreateEnemy, CreatePlant, and CreateWeather. This keeps things simple and doesn't add unnecessary layers of inheritance. If there are common behaviours or shared resources among all the environment factories, then having an additional base abstract class might make sense. The base class could implement some common logic and hold references to shared resources, even concrete sub-factories, if used by all types of environment factories. However, this approach does introduce an additional layer in your inheritance hierarchy, which, as you mentioned, could get messy if not managed carefully. I tend to only include an abstract base class if there are some common variables or resources needed by all concrete implementations of the interface - I start with the simplest way possible and only refactor to a higher level of complexity when the need arises. Often, you will find that once the concrete versions of your factory start to take shape, you'll find enough common elements to warrant a shared abstract class, at which point the refactoring is clear and easy to do.

@@git-amend Thank you for the great reply, I am still trying to habitually implement these patterns into my coding. Keep up the good work!