Modding - Instance and Type Components

## Instance and Type Components

Some of the entity types in Dream Engines can be defined using a mix & match component system. This system allows you to define the entity's behavior like a puzzle. For example, if a MapObject (building) entity can produce stuff, it will have a production component. But a turret, which is another MapObject entity, will not have a production component, instead it will have an attacker component that will define its attack behavior.

Exactly which components are available depend on the type of entity (as seen above, the MapObject entity can have a production, attacker, and other components - while an Item entity can have a weapon component, an armor component, or a consumable component, depending on how you want it to behave). These are listed in the relevant guide for that entity.

## Instance Components vs Type Components

Instance components are components that are created per instance of an object. For example, a Health component is an instance component, because every instance of an enemy has its own health, some beetles may have taken damage and have lower health, while others may have higher health.

Type components, on the other hand, are not created per instance. These usually describe behavior that is common for all instances of that entity, but they do not have a state that changes between instances.

Sometimes it may seem a bit arbitrary which components are instance and which are type, because it depends on the details of how they are implemented. This is not something you should worry about, but you do need to pay attention when using these, that you place them under the correct parent - "instancecomponents" or "typecomponents" in the entity's configuration.

## Component Class & Parameters

All components have one required parameter - the "class" parameter. This parameter defines the type of the component, it will tell the game whether this component is a production component, a turret component, or something else.

Other parameters are per component. Some classes have additional required parameters, others have optional parameters, and some don't even require any parameters at all, the existence of the component may be enough to affect its behavior.

```
"instancecomponents": {
	"production": {
		class: "MapObjectComponentProduction"
		"recipes": {
			"researchlab-goo": true,
			"researchlab-carbonite": true,
			"researchlab-acidwood": true,
			"researchlab-gel": true,
			"researchlab-dreamcrystal": true
		}
	},
	"upkeep": {
		"class": "MapObjectComponentUpkeep",
		"costs": {
			"power": 7.5
		},
		"assigned": {
			"worker": 8
		}
	}
}

```

The example above defines two components for this building - the first is a production component (class "MapObjectComponentProduction"), and the other is an upkeep component (class "MapObjectComponentUpkeep"). Note that the actual names of the component objects - "production" and "upkeep" are not meaningful, their behavior is determined by their "class". You could call them "component1" and "component2" and it wouldn't change anything.

The production component then receives additional parameters in the form of which production recipes can be produced in it - in this case all the research recipes. The upkeep component receives additional parameters of the resources it consumes per cycle (7.5 power), and the amount of workers that need to be assigned to it (8 workers).