# 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.