56 lines
1.7 KiB
Markdown
56 lines
1.7 KiB
Markdown
<!-- file: docs/architecture/004-INPUT_AND_CONTROLS.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Abstraction des entrées et contrôles
|
|
|
|
## Règle générale
|
|
|
|
Le gameplay manipule des actions logiques et non des périphériques physiques. Une action comme `Primary`, `Left` ou `Pause` peut donc provenir d'un clavier, d'une souris, d'un écran tactile ou d'un gamepad sans modifier les règles du jeu.
|
|
|
|
## Desktop
|
|
|
|
Entrées possibles :
|
|
|
|
- clavier : flèches, WASD, espace, touches de fonction ;
|
|
- souris : clic principal/secondaire, position, mouvement relatif, molette ;
|
|
- gamepad et joystick ;
|
|
- trackpad lorsqu'il est présenté comme pointeur ou geste exploitable.
|
|
|
|
## Android
|
|
|
|
Schémas de contrôle envisagés :
|
|
|
|
- boutons virtuels ;
|
|
- tap simple ;
|
|
- swipe horizontal ou vertical ;
|
|
- drag direct ;
|
|
- joystick virtuel ;
|
|
- touch relatif sans joystick visible ;
|
|
- multitouch ;
|
|
- accéléromètre, gyroscope et orientation lorsqu'un jeu le justifie ;
|
|
- vibration/haptique comme retour, derrière un service plateforme.
|
|
|
|
## Web
|
|
|
|
Le navigateur peut combiner clavier, souris et tactile. Le mapping doit produire les mêmes actions logiques que les autres plateformes.
|
|
|
|
## État normalisé
|
|
|
|
Une représentation de type suivant peut être introduite lorsque nécessaire :
|
|
|
|
```rust
|
|
pub struct InputState {
|
|
pub move_x: f32,
|
|
pub move_y: f32,
|
|
pub primary: bool,
|
|
pub secondary: bool,
|
|
pub pause: bool,
|
|
}
|
|
```
|
|
|
|
Cette structure n'est pas imposée comme API définitive à la baseline ; elle illustre le contrat recherché.
|
|
|
|
## Orientation d'écran
|
|
|
|
Portrait convient particulièrement aux jeux one-button, merge, puzzle, idle, stacking et climber. Paysage convient mieux aux shooters, runners latéraux, survivor-like, tower defense et jeux utilisant deux zones de contrôle.
|