Ranking ALL Design Patterns for Games under 30min
Вставка
- Опубліковано 2 лип 2024
- I reviewed and ranked all software design pattern for game development specifically. This is not an extensive or in-depth tutorial. Yes, some examples can be argued about. And sorry, a few typos slipped through. Let's discuss :D
Make your own ranking here:
tiermaker.com/create/software...
More Resources:
► refactoring.guru/design-patterns
► sourcemaking.com/design_patterns
········································
★ Join the Kingdom:
/ discord
► The GameDev Website: gamedev.lu
········································
★ Chapters:
00:00 Introduction
01:25 Factory
02:30 Abstract Factory
03:56 Builder
04:48 Prototype
05:51 Singleton
08:10 Adapter
09:40 Bridge
10:10 Composite
11:04 Decorator
12:38 Facade
13:15 Flyweight
14:00 Proxy
15:27 GameDev Kingdom
15:37 Chain of Responsibility
17:04 Command
17:54 Iterator
18:35 Interpreter
18:48 Mediator
19:38 Memento
20:24 Observer
20:41 State
21:12 Strategy
22:12 Template Method
23:18 Visitor
24:48 Final Words
········································
For the cool ones:
● Instagram: / gamedev.lu
● Twitter: / gamedevlu
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!
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
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
This channel is a hidden gem!!
🙏 thanks a lot :D
Impressive video, thanks a lot
Thanks! Happy you like it!
Huge applaude about valuing Singleton
The Vivaldi pattern
The sort of video I wish I could double like.
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.
Very good video from Chinese love!!
Awesome! Thank you!
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.
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
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.
@@evanhowlett9873
"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.
Feels amazing to hear myself being legitimized as a programmer!