Dans un jeux ou chaque client fait avancer son personnage, et ou tout se passe dans le serveur.

Comment gériez-vous le client qui reste appuyer sur sa touche avancer, côté client ?
Un message "avancer" toutes les X ms ?

Ca depend del'architecture de ton jeu. Si c'est un jeu qui discretise le temps, tu envoie le message a chaque frame. Si c'est un jeu avec untemps continue, tu envoyes deux types de message "je commence a avancer" et "j'ai fini d'avancer". Mais comme de plus en plus de jeux utilise des mesure continue d'avancement avec des manettes analogique, j'imagine qu'il faut envoyer l'etat du message a la resolution utile supportes par la connexion reseau.

Le temps est un élément primordiale de mon jeux (zelda-like 2D multi).
Selon toi, la solution serait de partir sur un "je commencer à avancer" et un "j'ai stop" alors ? (Je n'ai pas réellement compris la dernière partie de ton message).

C'est très intéressant ta réponse, car le client n'auras pas à gérer le temps entre PRESS et RELEASE, et ainsi devoir calculer combien de fois il aurait avancer, ou combien d'avancement devra-t-il envoyer dans le temps ou quoi.

Du coup, justement même pour un simple press/release "instantané" pour le client, ca ce passerait de la même facon que le mec qui appuis pendant 10 secondes?
Après faut savoir comment le client se débrouille pour envoyer son message, et si ce temps d'envoie dépasse celui du release, enfait faudrait envoyer en thread, chaque élément déclenchant un thread d'envoi ? (ps : C).

Plus particulièrement ce qui m'inquiète c'est d'avoir la logique côté serveur comparé à la vitesse de communication entre sockets TCP.
Après j'imagine une simulation côté client, mais c'est du travail, alors si y'a pas besoin, je préférerais m'en passer

Pour donner un example concret, le protocole client vers serveur du moteur source (cs go, team fortress 2, ...):

Le serveur a un nombre de mises a jour/seconde fixe: le tickrate (usuellement 64).

Le client envois un nombre fixe de paquets/seconde au serveur (cl_cmdrate), ce nombre peut être inférieur ou égal au tickrate. Un paquet peut contenir une ou plusieurs commandes.

Une commande a trois variables (parmis d'autres):

//	forward velocity.
float	forwardmove;
   
//  sideways velocity.
float	sidemove;     
 
//  upward velocity.
float	upmove; 

A chaque mise a jour (tick), le serveur fait (grossièrement)

FOREACH commande IN commandesRecues:
  clients[commande.client].forwardmove = commande.forwardmove
  clients[commande.client].sidemove    = commande.sidemove
  clients[commande.client].upmove      = commande.upmove
  ...

calculeTrame();
envoisTrame();

Définition: https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/sp/src/game/shared/usercmd.h

Encode/décodage: https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/mp/src/game/shared/usercmd.cpp

Exécution d'une commande: https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/server/player_command.cpp#L315

Mise a jour des mouvements du client: https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/server/player_command.cpp#L133

Merci pour ta réponse, ca me parait être aussi une solution viable, qui s'allie plus à une game loop (nécessaire) côté serveur IMO

Wow, super topic ! Je m'intéresse aussi à ce sujet et ça fait plaisir de voir des réponses aussi détaillées, merci à vous !

apres il y a aussi une histoire de prediction, parce que quand t'es a plus de 50/100 ms de ping ca va devenir genant le decalage entre le moment ou t'appuie pour avancer et le moment ou le perso avance (le temps d'un aller retour client/serveur en fait)