Lately I have been devoting some time to studying design patterns from an academic point of view. These are ways to structure code in a game or application.
Link1: https://refactoring.guru/design-patterns/csharp
Link2: https://www.habrador.com/tutorials/programming-patterns/
The "Proxy" pattern is useful in an engine, for processing and preparing graphics data for the GPU in in a separate thread, so the game works in parallel for the next frame since two threads cannot touch the same objects.
The "Object Pool" has been useful for me here and there, to reuse game objects because creating and destroying them in engines like Unity is very slow.
I have used a lot of the "Observer" pattern over the years as it seems like the most direct way of handling notifications across many game objects, regardless of the engine I am using.
Others like the "Mediator" pattern was first introduced to me while dissecting the source code of the Box2D library, where collision is handled by a mediator for contact manifolds. In other words, two objects colliding use a separate object to compute the proper collision response, rather than have the objects work it out for themselves. This way, all collisions can be handled properly in one go.
The "Type Object" pattern is by far my absolute favorite. I was introduced to this while attempting to decipher the rather esoteric C code in open source games that use the Quake 2 engine. I still use this pattern in pretty much every game I have written. However, I can see that the amount of data can grow and become too difficult to manage in a much larger game.
I was intrigued seeing "Singleton", and "Factory Method". These are patterns I had been using for a long time without learning about them from an academic point of view.
In other words, I was glad to be familiar with many of these design patterns. I am studying some unfamiliar ones such as "Chain of Responsibility" and "Bridge", even if they are not immediately useful to me. I understand these, and now question how to use them for practical purposes.
Following design patterns, I intend to research data structures. Even some unpopular ones that are used sparingly. I have experience with several and even authored some manually in C during my time studying 3D graphics, but now I am curious of ones that are less common and underappreciated.
Meanwhile, I have been spending some evenings studying deeper concepts in the Unity engine. I am broadening my skills by expanding both extremities - both the high-level and low-level programming topics.
 |
| Image from Refactoring.Guru |
Link1: https://refactoring.guru/design-patterns/csharp
Link2: https://www.habrador.com/tutorials/programming-patterns/
Some ramblings...
The "Proxy" pattern is useful in an engine, for processing and preparing graphics data for the GPU in in a separate thread, so the game works in parallel for the next frame since two threads cannot touch the same objects.
The "Object Pool" has been useful for me here and there, to reuse game objects because creating and destroying them in engines like Unity is very slow.
I have used a lot of the "Observer" pattern over the years as it seems like the most direct way of handling notifications across many game objects, regardless of the engine I am using.
Others like the "Mediator" pattern was first introduced to me while dissecting the source code of the Box2D library, where collision is handled by a mediator for contact manifolds. In other words, two objects colliding use a separate object to compute the proper collision response, rather than have the objects work it out for themselves. This way, all collisions can be handled properly in one go.
The "Type Object" pattern is by far my absolute favorite. I was introduced to this while attempting to decipher the rather esoteric C code in open source games that use the Quake 2 engine. I still use this pattern in pretty much every game I have written. However, I can see that the amount of data can grow and become too difficult to manage in a much larger game.
I was intrigued seeing "Singleton", and "Factory Method". These are patterns I had been using for a long time without learning about them from an academic point of view.
Moving on...
In other words, I was glad to be familiar with many of these design patterns. I am studying some unfamiliar ones such as "Chain of Responsibility" and "Bridge", even if they are not immediately useful to me. I understand these, and now question how to use them for practical purposes.
Following design patterns, I intend to research data structures. Even some unpopular ones that are used sparingly. I have experience with several and even authored some manually in C during my time studying 3D graphics, but now I am curious of ones that are less common and underappreciated.
Meanwhile, I have been spending some evenings studying deeper concepts in the Unity engine. I am broadening my skills by expanding both extremities - both the high-level and low-level programming topics.
No comments:
Post a Comment