Defining sprite parameters is relatively simple because all that's required for each parameter is a name. (See more about picking the name at the bottom.) Each sprite parameter represents a numeric (integer) value that can be associated with each instance of this sprite type. A common use for this is to add a "CoordIndex" parameter to a sprite type that usually follows a path. The specific name isn't important, but some numeric value is required when calling rule functions that make the sprite follow a path. The parameter is used to track which coordinate of the path the sprite is corrently heading toward. But parameters can be used for a variety of purposes, so long as they can be represented as an integer.

To add a parameter, type a new name into the last line of the grid. To delete a parameter, select a line in the grid and press the delete key. Deleting a parameter will delete all values provided for this parameter on all instances of this sprite type.

For each parameter defined for a particular sprite definition, every instance of that sprite will show a row in the sprite properties grid in the map editor. This allows initial values to be set for every parameter (intrinsic and user-defined) of every sprite instance.

The name of a parameter must follow the rules of most names. It must be unique within the sprite definition (other sprite definitions' parameters can reuse the same names). It must start with a letter and contain only letters, digits and spaces. However, because sprites also support many other properties and functions, the name is restricted further because the parameters cannot conflict with these. The name of a sprite parameter must not conflict with any intrinsic parameter or with any rule function that applies to sprite definitions. Below is a list of reserved names that cannot be used for sprite parameters. This list may not be complete because the list of rule functions is always expanding, and can be customized by updating GeneralRules.cs or SpriteBase.cs. But if a parameter name conflicts with an existing "reserved" name, the problem will be readily apparent when the project is generated/compiled. The output window will show obvious errors. (Names are case-sensitive so a title-cased name would not conflict with an all-lowercase name.)