0.1.0-0-pre.2

docs/architecture/004-INPUT_AND_CONTROLS.md

@@ -0,0 +1,55 @@
+<!-- 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.