Level up your code with game programming patterns: Factory pattern | Tutorial 

Absolutely love your stuff! Your jump tutorials (espeically the stuff about verlet integration) got me back into coding again and taking it seriously for the first time, and really shows how important it is to understand some concepts on a deeper level. Thank you so much!

You are correct they look similar, but there is a difference in the types of jokes they produce. WalksIntoABarJokeFactory creates instances of WalksIntoABarJoke; WhyDidTheChickenJokeFactory creates instances of WhyDidTheChickenJoke. Though both of these factories produce objects that adhere to the IJokeTeller interface, they have unique implementations of the TellJoke method that correspond to the specific style of joke. Each joke has its own timing and content nuances which a generic prefab couldn't accommodate effectively. An underlying concept here is that we are anticipating that joke types have some kind of gameplay importance. We don't want all IJokeTellers to be lumped together. If it helps, I imagined something fun like chickens being offended by chicken jokes but salesmen love knock knock jokes. The gameplay might involve trying to understand the audience, so the player may eventually choose the type of joke. I don't know, I kept it vague because that's how ideas start, haha. My main motivation with the example is to illustrate how factories empower the creation of diverse modular behaviors. Thanks for keeping a close eye on things!

Or just using a generic would do the trick

i think it's because the player might chose what kind of joke he want the character to do and then the game chose one of this type into a list.

Our pleasure! ☺

JOBS and ECS: Am I a joke to you?

Thank you, we appreciate it!! 😊

I came here to say this. Why not just stick to game concepts that are so well-known to gamers? Power-ups please, forget the jokes nonsense.

You are absolutely right--the Factory Pattern is simple: factories create products. The ebook example is simple and a great starting point. A "product" however isn't restricted to just objects--they can be behaviors, interactions, or even abstract concepts (like a particular set of rules). A "factory" in this sense is broader than our everyday notion of factories making stuff. What's great about this pattern is that you can start creating your ideas even if they are vague or incomplete. You may not know what power ups you want or how they each function in the game, but with the factory pattern you can still build something and make progress as your vision takes shape. The stand-up comedian then is a modular behavioral example + a demonstration of using the factory pattern to start building out a vague game idea.

I chose the stand-up example to highlight that factories aren't limited to just creating game objects. They can also be used to create products that are behaviors, interactions, or abstract concepts like a set of rules. Behavior in games can be very complex. I wanted to use jokes as an example because, as behaviors, they are essentially just words and timing. Yet, there is a huge variety of jokes. The example then showcases the Factory Pattern's ability to create variations in behavior. And it highlights how the pattern makes it easy for the comedian to access and use the different behavior products. I would love to do some behavior-oriented scriptable object videos though, so thanks for your input! It really helps us figure out how to better present advanced materials.

Definitely! Serializable dictionaries are really helpful for mapping joke type to joke factory in a flexible, easy way. For example, a Halloween joke type is more about the theme of the joke rather than the version of joke. So with serializable dictionaries, "Halloween" can be flexibly mapped to appropriate bar joke, knock knock joke, and chicken joke factories. Especially handy when performing for a crowd of spooky skeletons.

Let me try using an analogy from games like Dwarf Fortress and Rimworld. In these games, colonists create crafts. When a colonist creates an item, they might use a command like ItemFactory.CreateItem(myCharacterAttributes). The quality of the resulting item is influenced by factors like the colonist's skills and mood (i.e. myCharacterAttributes). The Factory Pattern simplifies the process - the colonist doesn't need to know the details of item creation; they simply provide their character attributes. Similarly, the item (the product of the factory) isn't burdened with its own creation logic; it exists purely as an item. In the comedian example, the "product" is a behavior, not a physical game item. Different joke factories produce a variety of jokes, each capable of being told or performed. The comedian can tell any of the jokes without needing to know specifics of each joke. This is possible because all jokes implement the "TellJoke" method required by the "IJokeTeller" interface. Back to the colony sim example, if the crafted item (the product of the item factory) is a tool, each tool could have the ability to be used because they implement an interface like "IToolUsable" that requires a "UseTool" method. Let me know if that helps!

Agreed, I would do the same. This feels like unnecessary abstraction which causes the code to become much harder to follow. At least in the example given.

Thanks for your comment! Embedding the creation logic directly within the Joke class itself and using a list of prefabs is a straightforward approach. And if this is some background ambient behavior or a cut scene in a narrative game, honestly, that's perfect. However, the framing of this example is that we’re in an early concept stage of a game centered around stand-up comedy. It's not just about getting the fish to tell some jokes, we want to eventually build novel gameplay systems and give shape to our vague idea. In that case, the factory pattern offers some important advantages. The power-up example covers flexibility/extensibility, so here are a couple other key aspects: Separation of concerns: Utilizing a factory allows us to cleanly separate the joke-creation logic from the Joke class. This allows the Joke class to focus solely on what a joke is and how it behaves, while the factory is responsible for the creation of the jokes. You might want to try prompting gpt/bard/muse with a system idea, ask to see versions with and without the factory pattern, and just see how it plays out as you throw ideas out there. Dynamic creation: Imagine gameplay where the player gets to experiment with joke construction on the fly. The player can choose jokes and then learn things about the audience from the response. The player then is able to tailor jokes to the audience. For example, an audience of sloths tends to prefer a long pause before a punchline, skeletons love Halloween jokes, etc. The Factory Pattern handles this kind of dynamic, context-specific complexity more gracefully than if we were to integrate creation logic directly into each individual joke class. Consider games like Dwarf Fortress or Rimworld where the attributes and even mood of your colonists influence the quality of the crafts they produce. In our comedy game, the level, rizz stat, or even outfit of a comedian could influence the creation/delivery of jokes. In these cases, something simple like Factory.CreateThing(myCharacterAttributes) allows the factory to handle all the creation details, while the resulting created product can just be what it is or perform whatever function it performs. The main idea is to establish a foundation that supports the creativity and potential complexity of your idea as it takes shape and evolves. I hope that helps clarify things! ☺

It really depends. I don't think the very first example in the video seems very useful, the later ones seem more useful - but this video also seems to be made to be accessible so there are a few decisions you might not take like that in production. I agree that people sometimes just use patterns without evaluating if they really have the problem that it solves, that should be avoided. In this case, you have an added abstraction on object creation, you can extend and change behaviour of it without having to modify the class that consumes the created thing. For very simple games such abstractions might be overkill, but it can make it easier to add/extend/modify behaviour in more complex projects. For factory specifically, you just defer the responsibility and implementation of object creation to another class. Maybe a more practical usage is if you define jokes in a scriptable object, or even just a spreadsheet, and some code parses this and feeds it to the joke consumption code, so you can design jokes in the editor or even outside, and don't have to hardcode them in. Another way to look at this is if you have multiple classes or places that consume a thing and you always create it by making a new object, and then assigning values. Somewhere down the line you notice that you want that object to behave a bit differently, or have different default values. If you used a factory or some other abstraction for object creation, you could just make a single change in the class responsibly for creating the object, instead of having to adjust the code everywhere where a new object of that type is used.

This is just a demonstration. You would most likely not use this for anything that's the same scale as what's shown in the video. This is meant for large, complex projects

@@Th3-Mast3rmind I'll need to see it to believe it. Sometimes I think that project's complexity is just an excuse for coders to realize their wet dreams of coding for the sake of coding :)

@@kardahaspindal if you like you could tell me a little about a game you are making or would like to make, and I'll suggest where and why the factory pattern might be helpful to consider

Thank you for the feedback! Please do highlight a specific example of what you mean. I tried to make the naming conform to how the pattern would read in the wild. That is, there's a benefit in seeing the tidy example (the e-book) vs an in-game example. I'll be curious to hear your opinion of the naming in our final "Pattern combo" video with the Street Fighter/Mortal Kombat style attack combos. 😅

For me Joke prefabs inheriting from IJokeTeller was confusing at first because I was subconsciously thinking of inheriting interfaces as an "is a" relationship. Thinking this way raised the question: "How is a joke a joke teller? Shouldn't the comedian be the teller?". Reading the book and watching the video several times finally flipped my mind and now I correctly think about inheriting an interface as a "how it does something" instead of an "is a" relationship. That being said the word "tell" is still confusing for me. Maybe IJokeGetter and GetJoke() would make more sense to me. Maybe this relationship between interfaces and MonoBehaviours could have been explained better. I know the concept of interfaces was beyond the cope of this video, but if I was asked what was confusing about the naming conventions used, that would be my answer. *EDIT* Now that I think about it TellJoke() is not just getting a joke, but it implements how to display it, so I guess it really does tell a joke. Anyway, still a bit confusing, not sure what would make it clear for me.

Thank you for this@@sima19995 Your feedback is so helpful, it really gives me some things to think about in how I approach future tutorials. I completely understand the initial confusion. This is a behavioral implementation of the factory pattern where the product is a behavior and not a physical game object, so the interface is meant to indicate the ability or action something has -- in this case, "has the ability to be told." The term "tell" here was chosen to reflect not just the retrieval of the joke, as you point out, but its delivery and presentation (TextMeshPro component). When I'm working on a game, I definitely have mixed feelings about what certain things are called. As I work with it, the feeling resolves as it makes more sense, or things change. What starts as "IJokeTeller" might morph into "IDisplayJoke" and "IAffectAudience." Or something still feels a bit off, and I can't think of a better name. In that case, I just shrug and say, well, the most important thing is that the little fish is pretty cute up there ☺

Consider instead a situation like a colony sim character writing a book or crafting something. We don't want the creation details (e.g. determining the quality of the book) to be a part of the character or the book. The book is an item, and we don't want to clutter the character AI with item creation logic. Instead, we make a book factory that takes in details about the character, and the factory uses that info to make the book. The standup example allows us to experiment with what a joke is (is there a joke effect on the audience like a spell?) without needing to change the comedian script. If we did a follow-up, I'd make comedian stats and pass them into the factory and use that to determine the quality of the joke. The more creation details there are, the more the factory handles, and the more obvious it becomes that we want the creation logic focused where it is. So it makes sense that you are confused because there aren't many creation details right now.

That's ok! Something to work towards☺

Its basically creating a parent script and subscripts which the subscripts can be used in the parent script just as the same as creating the one script but doing it this way makes it more easier to implement new subscripts.

I appreciate the feedback! I'll move slower in future videos. Thank you for being patient with me figuring out how to cover more advanced topics😅

@@HomeMechbro this is not your video

@Charan_Vendra I made the video with Unity, but it's easier to respond to devs through my account. I want people to know their feedback helps. ☺️

@@HomeMech oh got it

Can you elaborate more?