Pretty intensive video. I tried to keep keep it informational with examples and avoid going to deep into details. Hope you enjoy this video! let me know what's your favourite Design Pattern, if you have one XD.
Loved this video. Long time programmer, recent unity hobby - so this appealed on so many levels! Just to be picky, you used Template Method in your implementation of a state machine in another video - each state class had a set of methods called in a set order... so it is useful for more than just the update loop 😁
As someone who is just starting to be neck-deep in the gamedev learning process that comes AFTER the wonder we all feel in the beginning (tears)... it was so so good to have a laugh. Thanks for bringing humor to a very informative video.
The main advantage of the Visitor pattern seems to be “adding new operations to an existing system without modifying the original codebase” which is not 100% since you need to add the accept method. So, as an alternative I would modify the codebase to fit whatever feature I am adding. Using simpler patterns like Strategy, Bridge,… For example each item could have an associated “LootConfig” directly. It’s more obvious.
@This is GameDev yea composition, seems better here, aka loot table. Though I think most games want to change the loot tables after release so usually it's an api request, so a completely separate service would be best. Each entity could have a loot table Id.
@This is GameDev I think we missed an important detail of the visitor pattern. There should be more than one implementation of the visitor. I'm not sure that the loot example fits with this idea, I haven't come up with an abstract example yet. But maybe there is a loot visitor, a hard-core loot visitor, a gold loot visitor, ect. However, this starts to feel like just options that could be set directly on the loot visitor. Maybe the idea should be a killable entity visitor and loot visitor derives from that, maybe an experience visitor would also derive from killable entity visitor.
Actually most of these patterns are not really specific for games, they are generic across software development. However will be nice to make a video that covers only game programming patterns, here is a great start with this book: Game Programming Patterns by Bob Nystrom, ex Eletronic Arts programmer Your content is amazing regardless
decorator useless? Your usecase is meh. The most common use case is memoize/cache challenging calculations and only add this behaviour in a production build (or add a logging decorator in development mode). Not sure where you would use it in other cases for a gaming system. There is some overlap in gaming with proxy and flyweight.
The thing I hate about OOP is that classes are abused. Take the character class example. It'd much cleaner to have a single class, character, that has a two variables -- a race enum and a class enum. Then you can pattern match on those two variables to get the desired state without ever having to worry about how the object gets built. If you're using a Factory pattern, you're probably doing something wrong.
Factories don't always need to Instantiate something. An Object Pool is a kind of Factory that supplies either a new instance of something, or one that was pooled. Also, Factories are good when you are Deserializing state from a previous Save session. You can Factory-create by an ID for that object and then use the Serialized data to restore their state. I think Factory is a good pattern.
An object pool is not a factory, it is an object pool. The factory pattern deals with the steps it takes to create an object whereas an object pool deals with what piece of memory that object takes up. I guarantee you can have all that serialization/deserialization logic in a "Persistence" class which has nothing to do with the factory pattern.
@@lethicanthus "Use the Factory Method when you want to save system resources by reusing existing objects instead of rebuilding them each time." "Probably the most obvious and convenient place where this code could be placed is the constructor of the class whose objects we’re trying to reuse. However, a constructor must always return new objects by definition. It can’t return existing instances. Therefore, you need to have a regular method capable of creating new objects as well as reusing existing ones. That sounds very much like a factory method." "Check list If you have an inheritance hierarchy that exercises polymorphism, consider adding a polymorphic creation capability by defining a static factory method in the base class. Design the arguments to the factory method. What qualities or characteristics are necessary and sufficient to identify the correct derived class to instantiate? Consider designing an internal "object pool" that will allow objects to be reused instead of created from scratch. Consider making all constructors private or protected. " Sources: Multiple Design Pattern websites, including the one posted as a link in this video.
Pretty intensive video. I tried to keep keep it informational with examples and avoid going to deep into details. Hope you enjoy this video! let me know what's your favourite Design Pattern, if you have one XD.
I feel like the Singleton pattern is going to have such polarized rankings amongst game developers!
because is abused by juniors. It is solid B/A tier pattern when used properly!
Huge applaude about valuing Singleton
Combining composite with visitor is GOD for creating game's inventory.
Loved this video. Long time programmer, recent unity hobby - so this appealed on so many levels!
Just to be picky, you used Template Method in your implementation of a state machine in another video - each state class had a set of methods called in a set order... so it is useful for more than just the update loop 😁
Thanks!
Oh, that’s true! 🤯😅
amazing video man, so well needed :)
Thanks! I am happy you like it :D
This channel is a hidden gem!!
🙏 thanks a lot :D
As someone who is just starting to be neck-deep in the gamedev learning process that comes AFTER the wonder we all feel in the beginning (tears)...
it was so so good to have a laugh. Thanks for bringing humor to a very informative video.
Thanks! Happy you enjoyed it :D
The lootable visitor pattern is interesting, you gave it a C rating. I'm curious as to what alternative pattern you would recommend instead.
The main advantage of the Visitor pattern seems to be “adding new operations to an existing system without modifying the original codebase” which is not 100% since you need to add the accept method. So, as an alternative I would modify the codebase to fit whatever feature I am adding. Using simpler patterns like Strategy, Bridge,…
For example each item could have an associated “LootConfig” directly. It’s more obvious.
@This is GameDev yea composition, seems better here, aka loot table. Though I think most games want to change the loot tables after release so usually it's an api request, so a completely separate service would be best. Each entity could have a loot table Id.
@This is GameDev I think we missed an important detail of the visitor pattern. There should be more than one implementation of the visitor. I'm not sure that the loot example fits with this idea, I haven't come up with an abstract example yet. But maybe there is a loot visitor, a hard-core loot visitor, a gold loot visitor, ect. However, this starts to feel like just options that could be set directly on the loot visitor. Maybe the idea should be a killable entity visitor and loot visitor derives from that, maybe an experience visitor would also derive from killable entity visitor.
Impressive video, thanks a lot
Thanks! Happy you like it!
Hi I'm loving the vid :D I think you might have misunderstood what a bridge is for. It's more complex than what you showed here. ✌and ❤
Thanks! I agree, lots of the patterns can cover more complex use cases.
Amazing video, I'm sad I haven't watched this sooner..
The sort of video I wish I could double like.
The Vivaldi pattern
Actually most of these patterns are not really specific for games, they are generic across software development. However will be nice to make a video that covers only game programming patterns, here is a great start with this book:
Game Programming Patterns by Bob Nystrom, ex Eletronic Arts programmer
Your content is amazing regardless
Chain of responsibility is look somthing like Decision making tree in Ai
Trees or graphs in general are very useful for lots of stuff :D
went singleton 15 years ago, never went back 🤣🤣🤣
Solid choice
decorator useless? Your usecase is meh. The most common use case is memoize/cache challenging calculations and only add this behaviour in a production build (or add a logging decorator in development mode). Not sure where you would use it in other cases for a gaming system. There is some overlap in gaming with proxy and flyweight.
Very good video from Chinese love!!
Awesome! Thank you!
Feels amazing to hear myself being legitimized as a programmer!
The thing I hate about OOP is that classes are abused. Take the character class example. It'd much cleaner to have a single class, character, that has a two variables -- a race enum and a class enum. Then you can pattern match on those two variables to get the desired state without ever having to worry about how the object gets built. If you're using a Factory pattern, you're probably doing something wrong.
Factories don't always need to Instantiate something.
An Object Pool is a kind of Factory that supplies either a new instance of something, or one that was pooled.
Also, Factories are good when you are Deserializing state from a previous Save session. You can Factory-create by an ID for that object and then use the Serialized data to restore their state.
I think Factory is a good pattern.
An object pool is not a factory, it is an object pool. The factory pattern deals with the steps it takes to create an object whereas an object pool deals with what piece of memory that object takes up.
I guarantee you can have all that serialization/deserialization logic in a "Persistence" class which has nothing to do with the factory pattern.
@@lethicanthus
"Use the Factory Method when you want to save system resources by reusing existing objects instead of rebuilding them each time."
"Probably the most obvious and convenient place where this code could be placed is the constructor of the class whose objects we’re trying to reuse. However, a constructor must always return new objects by definition. It can’t return existing instances.
Therefore, you need to have a regular method capable of creating new objects as well as reusing existing ones. That sounds very much like a factory method."
"Check list
If you have an inheritance hierarchy that exercises polymorphism, consider adding a polymorphic creation capability by defining a static factory method in the base class.
Design the arguments to the factory method. What qualities or characteristics are necessary and sufficient to identify the correct derived class to instantiate?
Consider designing an internal "object pool" that will allow objects to be reused instead of created from scratch.
Consider making all constructors private or protected.
"
Sources: Multiple Design Pattern websites, including the one posted as a link in this video.
@this-is-gamedev I was searching for someone who disagree with you - no results. :( (XD)
Haha, I am sure there would be a few XD