![]() I like the Static Create Method approach because it is like the Init method above wrapped in some syntactic sugar. Unable to use the Awake Method to set up anything else that relies on speed (this will also be a common theme moving forward).Unable to enforce use of the Init Method (we will discuss this later). ![]() Simply add an Init method to any class that needs to be set up with values as soon as it is created. The Init Method is the most simple implementation which, likely because of its simplicity, is also the most useful in most situations. What are some ways we can get around this? * EVERYWHERE.* The gun probably shouldn’t even know how a projectile goes together, it should just be able to make one. If we want to change the projectile to use a prefab instead of a new game object any class that makes a Projectile has to go and implement these changes. ![]() It is super flexible, values can be added in the Editor or via code, but because of that a lot code based implementations feel very tightly coupled. This is the crux of most of the Unity pattern. We also have no good way to make sure the projectile has a valid speed when it is created. Not only is there a lot more boilerplate code here but we have broken the encapsulation on the Projectile by making the speed float public. The Unity way to create our projectile and set it’s speed would look something like the following. If you’d like to read about it here is a short Official Unity Blog post. In 2016 Unity introduced errors whenever trying to call Unity “main thread” API endpoints from constructors (and pretty much everything is a main thread API endpoint). Using them can lead to editor and engine breaking side effects when used improperly. However in Unity we are forbidden from using constructors on MonoBehaviours because they are utilised by the Editor before and after serialisation. Ideally, in an Object-Oriented paradigm we would pass this value in through the constructor like so. This article will explore different design patterns that attempt to provide constructor-like functionality to MonoBehaviours to make them a little more user-friendly for programmers used to the Object-Oriented programming paradigm.įor the purposes of this article we want to create a new Projectile which will be used by a Gun and when we create that projectile we want to give it an initial speed. So there is a fine balancing act instantiating and seeding MonoBehaviours when they are being added to a scene dynamically via code. ![]() One of the complications with using them is that we cannot utilise constructors when creating an instance of these objects. The backbone of Unity games are GameObjects and MonoBehaviours. I assume a basic understanding of inheritance and generics as well as Unity functions such as AddComponent. This article is intended for novice programmers who are looking at using Unity in a repeatable and less tightly coupled way than they currently are. ![]()
0 Comments
Leave a Reply. |