> For the complete documentation index, see [llms.txt](https://dev-enabled.gitbook.io/endless-runner-creator/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev-enabled.gitbook.io/endless-runner-creator/5.player-classes.md).

# 5.Player Classes

**Player Base Class:**

All **playable** classes in the example templates derive from the **BP\_PlayerBase** class inside of the **Common** folder structure.

This class handles all of the most **generic** functionality that most **endless runner** games tend to implement such as managing the state of play to **enable/disable player input**, **player collision**, **spawning** and **respawning**, **effects**, **Invincibility flash** and much more.

On top of this things like the **material instance** for the current **playable** class type will be stored. This is done by calling the function **StoreMaterialInstance** from the **EventBeginPlay.**

![](https://2652413008-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUDyOt9uCITn87sX2RFJa%2Fuploads%2FFi5RFV7EsOpBEUtXVsdj%2F0?alt=media)

This function will call a global **function library** to check against the validity of either a **Skeletal Mesh**, **Paper Flipbook**, **Static Mesh** or **Paper Sprite**.

This will allow you to have one **parent** class that accounts for any type of component type to visualise your player depending on the type of game you’re making. Be sure here though that you’re not filling multiple component types as this will return an ambiguous **Player Material Instance** reference which will stop things like the **invincibility flash** or **colour swapping** from working correctly.

**Child Classes:**

The child classes are all responsible for handling their **game type** specific functionality for the provided **templates**.

The main thing for each of the **child player** classes in the examples are the handling of **player input**. Each class has this dropped into a specific **Input** graph.

![](https://2652413008-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUDyOt9uCITn87sX2RFJa%2Fuploads%2FtJ2zIiPk5Rur61Esihn6%2F1?alt=media)

This is intended to help keep the classes tidy whilst also making it easy to find and update the way your **player** class will respond to **player input**.

There’s also an example of multiple levels of inheritance in the **Lizard Runner** template. Here the **BP\_PlayerBase** handles all of the **generic** functionality. Then the **BP\_PlayerBaseLizardRunner** handles all of the **game type** specific logic such as **movement input**, **switching colours** and the unique **lose** condition. **BP\_PlayerBaseLizardRunner** is then the parent class of both the **BP\_PlayerLizardRunner3D** and **BP\_PlayerLizardRunner2D** which handle the **2D** and **3D** specific functionality such as the **jump/land** visual effects and the **player visualisation**.