Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 21, 2014
arrowPress Releases
August 21, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Code Generation Fun with Unity
by Lior Tal on 03/11/14 06:32:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


This post was originally posted on my blog at

Many Unity code samples use a string identifier, such as the game object’s tag for various things (e.g: checking for a collision with “player”). In this post i will explore a different, safer and automated technique that achieves the same result, but does not require using strings.

The String Problem

Consider the following code:


The code is not type safe: it relies on a string identifier to perform an object lookup. This identifier may change, making this code “out of sync” with the project, or be misspelled, making the code fail. In addition, this string might be used in many different locations of the code, increasing the risk of previous mentioned concerns.

A Solution “Sketch”

A possible solution to this issue is to create a static helper class that will expose all tags as public (static) fields. When needed, Instead of using a string, we’d use the class’s static fields:


Accessing this tag is safer now, since we’re not (directly) relying on the string representation of the tag:


Effectively, the code will operate the same as before, but now we have a single location where the tag is declared.

There are 2 main issues with this approach:

  1. In case there are many tags defined in the project, creating the helper class can be a somewhat tedious task (creating a field per tag).
  2. In case a tag’s name changes in the Unity editor, you have to also remember to replace it’s corresponding value in the helper class.

It seems that this solution is a step in the right direction, but we need some extra “magic” to make it perfect.

Code Generation To The Rescue

Code generation is an (sometimes) overlooked practice, where code is being automatically generated by some other code, a template or some tool.

In particular, code generation really shines in cases where we want to generate long, repetitive code from an underlying data source.

Translating this to the problem described above, we would like to generate a static helper class with many static fields from an underlying data source (a collection with all of the project’s tags).


To achieve this, we’ll use one particular implementation of a code generation engine called T4:

T4 is a template engine that comes with Visual Studio (which also heavily relies on it for various tasks), and also comes out of the box with Mono (yes, the same one that is installed with Unity).

A T4 template is a file (with a .tt extension) that mixes a body of text with special directives. The template generates a single output file (usually, a code file, although it can generate any other file format).

T4 Templates

In order to add a T4 template to your project, right click on your code project in MonoDevelop, and select: Add->New File. T4 Templates can be found under Text Templating on the left:


T4 Template Types

There are 2 types of available templates (ignore Razor templates as they’re irrelevant for this discussion):

  1. T4 Template – a template file that gets transformed during compilation time into the output file. This type of template is used to generate code files that are needed at design time (e.g: think of Microsoft’s Entity Framework, where a set of classes can be generated at design time from a database, instead of being created manually by the developer).
  2. Preprocessed T4 Template – a template file that creates an “intermediate” class that can later be used to generate the output code file.

Unity currently does not support adding T4 templates (.tt files) to scripting code – after compilation, all .tt files will be dropped from the code project (I reported this bug here: T4 Bug)

This forces us to use option #2 – creating a one-time “intermediate” class. This class will be used by a Unity edior extension, from which we can generate the class we want and add it to the project.

Show Me the Code!

Here is the preprocessed T4 template that will generate the Tags class for us (although the provided sample uses the same template to generate a Layers class in exactly the same manner):


A few things that should be noted:

  1. Any text that not contained within <# #> tags is being output as is.
  2. The template is a preprocessed template. This means it does not generate an output code file directly. Instead, it generates an intermediate (partial) class with a TransformText() method that returns the template final output (the text with the generated class).
  3. The code prints out a header (the class declaration with some comments), then it iterates all elements in source and outputs a public static readonly field for each item (does a small manipulation to make sure the field name does not have spaces in it).
  4. The variables classname, item and source are actually implemented in a code file (a partial class with the same name as the template class. Remember I said the template generates a partial class? this allows mixing the template with some custom code. For more clarity, see the full code in the link below).

In Conclusion

This post aimed to open a hatch to the wonderful world of code generation (and T4 in specific), while showing how it can solve real world problems in a short and simple way.

I did not dive into T4 syntax or more advanced topics (leaving it for you to explore, or as a subject for future posts). For more information regarding T4 – see the links below.


Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — woodland hills, California, United States

Build Engineer-Infinity Ward
Disney Consumer Products
Disney Consumer Products — Glendale, California, United States

Contract Game Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States

Lead Network Engineer
Cloud Imperium Games
Cloud Imperium Games — Santa Monica, California, United States

Animation Programmer


Michael Thornberg
profile image
I abhor generators. I could write at length on what kind of shitty coding it invites, but I won't. It is enough I get to see examples of it at work. Generally speaking, as soon as a coder can stick their hands into generated code, all kinds of bad things happen. And then I haven't touched the issue about trust.. if the generated code is good or even free from bugs itself. But.. go ahead and use it if you please. It is surely good on occasion. I (personally) just haven't found a valid reason to use them. But it is my opinion anyway. :) (edit: I just added a smilie to emphasize I am not that angry or upset here :) )

Florian Putz
profile image
A valid scenario for code generation is anything like a parser / compiler or data processor. I wouldn't write something like that by hand. These tools are being successfully used for decades now and I guess man-made code would be a lot shittier and bugprone in that scenario ;). Although there might be some rare issues with tools like yacc or antlr, I'm convinced that one can generally trust them.

Lior Tal
profile image
@Michael: I think it all comes down to what sort of things you use code generators for. I tried to emphasize the typical scenarios where they may be useful. At the end of the day, shitty code can be created both by programmers and generators :)

Michael Thornberg
profile image
true true :)

Will Hendrickson
profile image
Great article! And, excellent meme usage!

This provides a great way to use decoupling, which for me is a very important tool. Thanks for the excellent post.

Jorge Gonzalez
profile image
Great article, i'll try this out just for the learning opportunity as i haven't used generators with visual studio in any way, but as i like to play it safe(coder safe) i think in the future i'll stick to helpers classes

Jimmy Tjandra
profile image
Thank you so much for this. I've had some worries when developing mobile games.

Searching numerous game objects or even identifying them through the 'general' method seems far too heavy on processing for often simple tasks.

I'll definitely use this method in future projects or tests to see how I can implement it efficiently.

Stephane Bessette
profile image
I abhor string identifier since they break at run time rather than at compile time. Another approach is via an enum, where the name of the enum can be converted back to a string. But these approches (enum, constant) require discipline in a multi-programmer environment; there's always someone who "does not have the time" to create a new enum/constant and hard-codes a string.

Code generators are great when the source is dynamic, such as with the example of Unity's list of tags. It makes maintenance much easier since changes (except additions) will break at compile time.

Florian Putz
profile image
Nice article - but I also favour real types over strings.

Alexander Jhin
profile image
Switching to enum does provide some nice compile time type safety. To do this, change the TT to generate an enum and create a helper static function to replace GameObject.FindByTag (sadly, we can't create a static extension, which would be awesome here, because C# doesn't allow it.)

Unfortunately, coders can still break the system by using GameObject.FindByTag directly. I guess you could write a custom compile time rule or something to make sure no one is using GameObject.FindByTag.

Here's some untested code to do just that (assuming TagEnum is the enum generated by T4). This may be slow since it uses Reflection... but it may not, I haven't tested it:

class GameObjectHelper
public static GameObject FindByEnum(TagEnum tagEnum)
return GameObject.FindByTag(Enum.GetName(typeof(TagEnum), tagEnum));

And here's the possible T4, again, untested:

public enum <#= enumName #>
<# foreach (var item in source)
<#= item#>,