7. States

Introduction

Gum supports the concept of states, which are very similar to states in Glue. This tutorial will discuss how to use States which are created in Gum when integrating Gum objects in Glue.

This tutorial will cover both regular (uncategorized) as well as categorised states.

If you’d like to see how to work with states in Gum, see this tutorial.

If you’d like to see how to work with categorized states in Gum, see this tutorial.

Since the tutorials shown above do a good job of walking you through how to create states and categories this tutorial will assume you understand these concepts and will skip over setting up a component. This tutorial will use the CategoryDemoScreen and CategoryDemo set up in the category state tutorial listed above.

Adding a Screen in Glue

Just like with previous tutorials you will need to have a Gum project added to your Gum project, and you should have a Glue screen which references the CategoryDemoScreen from Gum. If you have set this up correctly then you should see a CategoryDemo component instance on screen when you run your game:

GumBigBlueInFrb.PNG

Controlling States in Code

So far we have shown that any states which are set (including categorised states) will properly show up in our game. We can also change the state of instances at runtime. For this example, we’ll change the state of the CategoryDemoInstance with keys presses.

To do this, we need to get access to the CategoryDemoInstance object in Glue. The steps are:

  1. Drag+drop your Gum screen onto the Glue screen’s Files folder
  2. Select “CategoryDemoInstance” in the source name dropdown (or the name of your instance)
  3. Type the name CategoryDemoInstance (or whatever name you’d like to have for your object in Gum)

Now this can be modified in code. To do so, add the following code to your Screen’s CustomActivity:

AfterStateSetOnGumInCode.PNG

Simple Button Using States

Whenever you create a new State in Gum, Glue will automatically generate code for you to use this state. States are useful for creating standard UI behavior like reacting visually to a push. Note that states for UI behaviors should be defined on the component itself (not on instances of the component) and events to react to UI events should also be defined in the button.

For users of FlatRedBall.Forms, this section provides some insight into how states can be used in code. If you are using FlatRedBall.Forms, you will likely not need to write code like this because the Button class already has built-in state changing logic.

For this example, consider a component named Button. For this component we will have the following states:

  • Normal
  • Pressed
  • Highlighted

Note that in the image below the three states are categorized in a category called UiStates. We recommend categorizing states whenever possible.

All Gum components create two code files for you: a file for custom code and a file for generated code.

The generated file (in this case ButtonRuntime.Generated.cs) will contain entries for each of the states. Note that each category will create its own enumeration and associated property in generated code:

The following screenshot shows the enumerations defined for the states:

The following screenshot shows the properties for the states:

Note that categorized states are nullable, allowing the category to not be set at all (which is the default when the Button is created at runtime).

These states can be used in code. For example, a simple, functional button could be created by adding events to the button in its CustomInitialize function.

 

 

<- 6. Exposed Variables — 8. Adding Code to Gum Objects ->