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 :

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.

1.7 KiB Raw Blame History