Breaking one of the bullets from #49 into its own issue.
There have been a number of code patterns that have come and gone during rapid iteration. It would be great to identify the most valuable ones and attempt to formalize them throughout the code base. It might even be useful to break some of them off into demo repos under sporadic-labs (maybe a basis for tutorials?).
A few guiding principles:
The patterns need to provide a way to hook into the Phaser engine's lifecycle
Deep prototype inheritance chains are brittle. Avoid chains that go deeper than inheriting from Phaser.Sprite/Phaser.Group/etc.
A few patterns to start:
Favoring util modules when a function is used in more than one place (e.g. recursive collision detection helpers in sprite-utils.js). This allows functionality to be shared directly.
Building plugin systems for features that can be easily added on top of the Phaser engine. E.g. our custom physics or lighting. The advantage here is that the plugin system makes it easy to hook into lifecycle events. These plugins should be broken off into separate repos so that we can reuse them across projects.
Favor a component based pattern when possible. E.g. player's movement-contoller.js. When an individual game object has multiple independent pieces of logic (e.g. player keyboard input, player abilities, player collision), that's often a good place to refactor the independent domains into separate components that can be reused across multiple game objects.
State management & integrating Phaser with Preact/React - TBD
Breaking one of the bullets from #49 into its own issue.
There have been a number of code patterns that have come and gone during rapid iteration. It would be great to identify the most valuable ones and attempt to formalize them throughout the code base. It might even be useful to break some of them off into demo repos under sporadic-labs (maybe a basis for tutorials?).
A few guiding principles:
A few patterns to start:
movement-contoller.js. When an individual game object has multiple independent pieces of logic (e.g. player keyboard input, player abilities, player collision), that's often a good place to refactor the independent domains into separate components that can be reused across multiple game objects.