Strongly Typed Components Using Code Generation
Last updated
Last updated
The types used in the previous tutorials fall into two categories:
Standard runtime types like TextRuntime
Forms types like Button
Games often need to interact with custom components which do not fall into either of these two categories. This tutorial shows how to create custom classes, which we refer to as runtime types for custom components.
For this tutorial we'll create a component which can be used to display score. It has three parts:
A NineSlice for the background
A text for the "Score:" label
A text for the score value
If we add an instance of this component to our screen, we can interact with it as shown in code. First, we need to drag+drop an instance of the ScoreComponent into our Screen.
We can interact with ScoreComponentInstance by using the following code:
Although this code is functional, it can be difficult to maintain in a larger project. We are relying on values like "ScoreValue"
to find the text object. If we spell this wrong, or if we change the name of our Text in Gum, this code breaks. Also, this code is quite verbose and it can be difficult to write from memory.
We can use strongly-typed classes to solve these problemsl
The Gum tool supports code generation which allows us to interact with Gum components without needing to cast or use string names. We can enable code gen in Gum by checking the check boxes in the Code tab. Also, be sure to switch the Output Library to MonoGame.
This produces a fully-generated class named ScoreComponentRuntime. In this case, the code is using FullyInCode instantiation type, which means the generated code shows the code necessary to create this component without loading the gum project. If you would like to use generated code without loading a Gum file, then this approach might be useful. Usually this approach is useful if you would like to avoid file IO or if you cannot read from disk (such as on an embedded device).
Since our project loads from disk, we'll switch to using FindByName as our Object Instantiation Type. By switching to this Object Instantiation Type, the generated code is modified to look for instances by name.
The code should look similar to the following:
We can enable automatic saving of generated code in Gum by specifying the location of our .csproj file. To do this, set Code Project Root to the full path of folder containing your .csproj:
We can force code generation once by clicking the Generate Code button.
This creates two code files - a generated code file and a custom code file:
The generated code file contains the same code as is shown in the code generation preview.
The custom code file can be used to customize the runtime class
This component can be used in code as shown in the following snippet:
Note that all screen and components default to a Generation Behavior of GenerateAutomaticallyOnPropertyChange. This means that any changes result in re-generation of the .Generated.cs file.
We can also create runtimes for screens. Once properties have been set up, adding additional runtimes is much easier. In fact, clicking Generate Code button the produces generated code for the screen.
Once we have a runtime class for our Screen, we can delete code from Game1 and write it in the CustomInitialize method as shown in the following snippet:
This tutorial shows how to generate types for screens and components which are used automatically when loading a Gum project.
The next tutorial shows how to work with multiple screens.