Finally, we are publishing the second post for our Indie Dev Insights, which kind of makes it a proper series. In this week‘s topic, we want to talk about another important design decision in our game art process: the color palette.
Originally, every 3D asset consisted of a model and a specific texture on which the faces of the model were mapped on, to color the object appropriately. This makes a lot of sense for complex objects, like our plants, which have gradients and smaller details in their textures. For simpler objects, however, we use a distinct set of colors to color the different parts of the asset. Each part is then colored uniformly by only one color. This is the case e.g. for the plant spots, the buckets, or the compost. So every asset would require a separate texture which would consist of only a few pixels representing the asset‘s color set. This solution is not only suboptimal for performance (since every texture must be loaded from storage one by one), but also causes a lot of work to create and organize these textures.
As a solution, we decided to implement one master texture: our color palette. This texture would hold all the basic colors of our color scheme in small fields (as shown in the image below). All simple colored objects would then refer to this texture, mapping its parts on the corresponding color field of the texture. Therefore we would only need to load one file. Further, we would automatically have a fixed color scheme to build some consistency in the look of our game art.
During the implementation of the color palette, we experienced some issues and had to try different approaches until we found a way that worked for us.
First, we tried using the Unity extension „ClicktToColor“, which is designed exactly for this use case. It should let you generate the texture and change the specific colors very easily. However, the tool didn‘t quite work as well as expected. It has limitations when setting the texture size and neighboring fields of the same color are not supported.
In the end, we decided to go with a fixed color palette, which would have 4 color variations each of less important colors, and 8 variations each of more commonly used colors. We would also reserve a certain part of the texture for more colors to be added later by leaving some blank fields. The disadvantage of this approach of keeping the colors of the fields unchanged is that in order to change the color of an object after the fact we will need to change the mapping of this object to another color field. However, we can be sure to only change the color of this one object while all other faces that are mapped on the color field stay on the same color. In contrast, changing the field‘s color (like in the approach of the color picker tool described above) would of course cause all associated objects to change its color.
We found this solution to be very convenient for us, although it took us a while to adjust all existing objects which did not need a specific texture to use the color palette. What experiences have you made in color management? Let us know in the comments!