A persistent custom event system for Unity
ClapClapEvent
ClapClapEvent is a long term project that have been improve during multiple game projects made with Unity.
Features:
- Create event
- Call event from editor (generally for simple types)
- Modify event
- Register function by name (shortcut)
- Editor that track those used in scenes
- Debugs (registers, calls, …)
- Samples scenes
The tool allows for a smooth and fast workflow, mainly when working with multiple open scenes. Based on the listener/observer pattern, the main point is to allow the philosophy “scenes are independent, and we can play them without errors”.
With this tool, we don’t need to search and reference objects in other scenes, and instead we use events to communicate between them with a custom parameter type if we want.
Since Unity does not have a global event system, it is also useful even within the same scene for user interface or communication between different objects.
There are already systems designed for this, but they are by code only, or lack some features like a debugging window to view, search and track played events.
For now, the main shortcomings are rather the debugging system which is limited by memory (since it is a global view of all events and uses reflection with C#), which prevents it from being used in a large production with a lot of game objects, and also the workflow which needs to have a formatted name for the events in order to be efficient and smooth.
With this tool, we don’t need to search and reference objects in other scenes, and instead we use events to communicate between them with a custom parameter type if we want.
Since Unity does not have a global event system, it is also useful even within the same scene for user interface or communication between different objects.
There are already systems designed for this, but they are by code only, or lack some features like a debugging window to view, search and track played events.
For now, the main shortcomings are rather the debugging system which is limited by memory (since it is a global view of all events and uses reflection with C#), which prevents it from being used in a large production with a lot of game objects, and also the workflow which needs to have a formatted name for the events in order to be efficient and smooth.
