GMS separates movement control, animation, and data configuration. A Movement Definition holds multiple Movement Sets. The active Movement Set determines which control and animation layer settings are used at runtime.
Current architecture
- Configuration: A Movement Set contains a default control setting and can select a control setting by Overlay Mode. Backend parameters live in the Control Setting's Backend Settings; User Settings hold project-specific data.
- Control: The Movement System Component receives movement requests and works with the active movement backend. CMC is the recommended path; Mover is still under development.
- Animation: The main animation instance reads state, tags, and movement information from the movement system and uses the Movement Set's animation settings to organize its layers.
- Movement mode: Locomotion Mode mirrors the backend's movement mode in GMS. Change the actual movement mode through the relevant backend.
See Movement Definition/Set, Movement Control Settings, and Animation Settings.
Original architecture diagram
The original diagram shows the basic relationship between the Movement Definition, movement component, and main animation instance. Backend settings and the Mover path have since been added. The diagram remains here for reference.
Original design diagram.
note
This is a reasonable and flexible architecture in my opinion. As a regular user, you don't need to care too much about this part. You just need to follow this architecture and use this system. For advanced users who want to extend GMS. Please refer to the expansion guide.