Hey everyone,
The Technical Content Marketing team at Unity is excited to announce an updated edition of the e-book Level up your code with game programming patterns, and an updated sample project with actionable examples to follow along.
As a reminder, if you haven’t watched it yet, we also released a five-part video tutorial series to accompany the initial e-book and sample project.
Both the e-book and the sample project include more examples and patterns. The sample project also includes more features from UI Toolkit, including an example that demonstrates databinding, a popular request from the community.
Note: If you want to follow along with the examples in the guide, and the accompanying demo project, make sure to download Unity 6 Preview.
What’s in the updated e-book and project?
An expanded section on how to implement SOLID principles
The five core principles from SOLID now each have actionable code examples implemented in the sample project that are explained in the e-book. As a reminder, SOLID is a mnemonic acronym for five core fundamentals of software design – think of them as five basic rules to keep in mind that can help you keep object-oriented designs understandable, flexible, and maintainable.
As a quick reminder SOLID stands for:
-
Single-responsibility principle: A class should have only one reason to change, meaning it should only have one job or responsibility.
-
Open-closed principle: Classes should be open for extension but closed for modification, allowing them to be extended without changing existing code.
-
Liskov substitution principle: Objects of a superclass should be able to be replaced with objects of its subclasses without affecting the correctness of the program.
-
Interface segregation principle: Clients should not be forced to depend upon interfaces that they do not use. It promotes the creation of specific interfaces over a single, general-purpose interface.
-
Dependency inversion principle: High-level modules should not depend on low-level modules, but both should depend on abstractions.
An expanded section on how to implement programming patterns
The updated e-book and project include four new patterns, bringing the total to 11. Here’s a quick rundown of each one:
-
Factory pattern: A classic use case is when you have powerups (such as speed boosts, shields, or extra lives), which share several attributes yet have different functionality. Here the factory pattern can be used to create instances of these different powerup classes derived from a common interface or base class, enabling flexible addition of new power ups without modifying existing client code.
-
Object Pooling: Some would refer to this as a performance optimization technique rather than a design pattern. In any case, think of it as a way to improve performance by reusing objects instead of creating and destroying them frequently. In our sample scene you will find an example of a gun turret firing large amounts of bullets at rapid speed. Rather than instantiating them (and cleaning up once they served their purpose at significant performance cost) each time we use the pattern to recycle them over and over.
-
Singleton: The singleton is likely one of the common patterns in game development – chances are you are already using it today. It’s useful if you need to have one object that coordinates actions across the entire scene. For example, you might want one game manager in your scene to direct the main game loop. However, there are some pitfalls to watch out for when using the singleton pattern, which we explain in the guide.
-
Command Pattern: You’ve likely seen the command pattern at work if you’ve played a game that uses undo/redo functionality or keeps your input history in a list. It’s a pattern you can leverage for a strategy game, for example, where the user can plan several turns before actually executing them in the order the input was given.
-
State Pattern: This allows an object to change its behavior when its internal state changes, which simplifies the management of complex state-dependent behavior in game characters or UI elements. Think of an enemy NPC that has different behaviors such as “idle”, “patrolling”, or “attacking” which depends on different game scenarios such as where the player is on the map.
-
Observer Pattern: This pattern helps you implement an efficient event system where objects can subscribe, and react, to events dynamically. One use case is that of a player collecting ammo in an action game that triggers different events such as playing a sound, updating the UI, and playing an animation.
-
Model View Presenter (MVP): At its core this pattern is about decoupling the display of state from the actual state, enabling a reactive design where views automatically update in response to model changes, making it a common pattern in UI programming. The model is the data, the view the user interface, and the presenter a mediator which handles the logic for the view and synchronizes the data from the model.
-
Model-View-ViewModel (New): Like the name indicates this one is related to the MVP pattern but expands it by adding runtime data binding which simplifies how UI elements are updated. In our example we leverage the new data binding feature in UI Toolkit and Unity 6 Preview.
-
Strategy Pattern (New): This pattern defines a family of algorithms by encapsulating each one, to make them interchangeable, allowing the algorithm to vary independently from clients that use it. This is a useful pattern for implementing different movement behaviors in game AI, for example.
-
Flyweight Pattern (New): Use this pattern to optimize memory usage by sharing as much data as possible with similar objects. The basic idea is that you centralize the shared data among objects.
-
Dirty Flag (New): This pattern is useful for optimizing performance by marking objects as “dirty” when they change, so they are only recalculated or updated when necessary. This pattern can help you manage costly updates in game loops or in some UI rendering cases.
Before you jump into the updated sample project…
There are a few helpful tips to keep in mind.
Start with the Bootstrap scene. This scene configures the demo and provides access to the main menu (you can learn more about the concept of SceneBootStrapper in the e-book). From the main menu, you can navigate to the appropriate sample. Each scene demonstrates a different SOLID principle or design pattern.
Please note that there may be minor differences between the sample project and the code examples in the guide. To enhance clarity and readability, some examples feature simplified code like public fields.
Your team might prefer a coding style different from the conventions used in this guide or the sample project. We recommend creating a C# style guide tailored to your specific needs and following it consistently across the team. Check out our e-book on how to create your own style guide to learn more.
Consider the examples provided and determine which design pattern aligns best with your project needs. As you familiarize yourself with these patterns, you’ll discover their potential to streamline and improve your development workflow.
Thanks for reading! Please share your thoughts in the comments section below on the e-book and sample project and let us know which design patterns you use more frequently in your work.
