Table of Contents

Introduction

Grids come with a few minimal cells, but for your own game you will probably use cells that are better suited for the game you are making. This Article gives some guidelines for doing that.

Section1

These are the built-in cell classes:

These cells only have minimal features, and provide the bare minimum for grid builders to work. Here are a few examples of typical cases where you want to make your own cells:

  • To support switching to a different sprite or changes color when clicked.
  • To support a cell that displays text.
  • To support a cell that knows whether it is accessible for using your grid with AStar.
  • To support a cell that display different sprites depending on its "type" (for example, you may have different terrain types).
  • To support cells that can be "empty".

To make your own cell is easy. In general, cells can be of any type. However, you may want to choose a specific base type as explained here:

  • If you want your cells to display in the scene as game objects, you need to make your own cell extend from at least MonoBehaviour.
  • If you want to use your cells with Tile Grid Builders (so that you can build your grid in the editor, and not just in code), your class can from TileCell. Alternatively, you can use TileCell on your prefab, and derive your own cell from any class.

Here are a few guidelines when implementing cells:

  • Avoid making cells know their grid positions. This is often difficult to maintain (especially if you swap cells or move them), and can lead to more intricate main logic.
  • Avoid making cells know their neighbors. As above, this can lead to more intricate main logic.
  • Keep cells as dumb as possible. Cells can keep state, but should not (usually) calculate their own state. Their state should be calculated by the main logic, and then set from there.
  • Use the following idiom to update presentation based on state:

Use the following idiom to update presentation based on state:

public class MyCell: MonoBehaviour
{
   //Keep states private
   private State1 state1;
   private State2 state2;

   //Provide public properties to change the state
   public State1 State1
   {
      get { return state1; }
      set
      {
         state1 = value;
         UpdatePresentation(); //Update presentation to display new state.
      }
   }

   public State2 State2
   {
      get { return state2; }
      set
      {
         state2 = value;
         UpdatePresentation();
      }
   }

   private void UpdatePresentation()
   {
      //logic to change cells appearance based on two states
   }
}