Implementing flyweight patterns

Questions & Answers
1

Having recently decided to take my developer skill with Unity to the next level I have become interested in design patterns and how to implement them in Unity. A specific design pattern that I am interested in is the Flyweight pattern.

I noticed that in most of the games that I make, I end up using a lot of instanced of the same prefab. (enemy space ships, puzzle pieces, trees, platforms, etc.) The Flyweight pattern seems ideal to help optimise the usage of these specific assets.

My question is twofold:

  • Does Unity internally optimise
    prefabs in this way without telling
    me making this coding exercise
    pointless?

  • Assuming that it does not: What would
    be a good way to implement this for
    say a level tile in Unity?

2

Actually Unity does implement the flyweight pattern internally, but not as your expecting. the trees in the terrain composer all share the same container instance. with the exception of their transform (which is stored in a array from some container class) all trees share the exact same state. this is why you can’t go in and modify any of the trees individually, cause the data driving one tree is driving all trees. as you can guess this really helps in reducing memory and cpu overhead when applying effects like wind to thousands of trees. so as you can tell from the tree editor, Flyweight does have its uses, but it has specific gotchas that limit its widespread use.

Does Unity internally optimise prefabs in this way without telling me making this coding exercise pointless?

There are limitations to the flyweight pattern, in that one instance can’t behave in a way that’s independent of its clones (at least very easily). so while its great for the trees, it doesn’t make sense for unity to implement a flyweight for prefabs. prefabs are basically just blueprints that you can use to make copies that can behave independently from other copies. with flyweight, you can’t turn one blue cube red without making ALL of them red.

that is, unless you make the “color” property one of the unique variables, but now you have ten thousand cubes using ten thousand instances of blue and one instance of red color. this ends up being a huge waste of memory as far as a Flyweight is concerned (the main reason to consider flyweight). the Transform for the trees made sense since usually every single tree would have a completely different transform.

Assuming that it does not: What would be a good way to implement this for
say a level tile in Unity?

you’ll need two classes. one class, the LevelTile for example, can’t store any variables nor be instantiated. flyweight Objects are meant to have all their data to be stored in a SINGLE instance, not thousands of instances. So you have a container class that handles adding new instance copies as raw struct data, all the data unique to each copy (preferably as structs) will be stored in array of structs, while all the data that every copy shares will be data belonging to the container (outside the array). the containers methods usually affect ALL copies of the levelTiles unconditionally.

The unique data for the Leveltile will likely be a UV coordinate,the texture to show at that uv coordinate, and possibly some data like if the tile is occupied. things like a collider (for when you click on the map) will likely be on the container object and collisions managed through the single collider on the container.