Concevoir un runner infini à trois voies pour clavier et tactile
Un runner à trois voies affiné pour des changements de voie lisibles, des sauts et des glissades sur clavier et tactile.

La promesse d'un runner à trois voies
Un runner infini à trois voies semble simple car le joueur n'a que quelques actions : se déplacer à gauche ou à droite, sauter, glisser et décider quand une pièce vaut le risque. Ce vocabulaire limité est précisément la raison pour laquelle chaque détail compte. Quand le jeu est équitable, le joueur lit la piste, s'engage dans une action et comprend le résultat. Quand il ne l'est pas, les obstacles se fondent dans le décor, les entrées arrivent trop tard ou la caméra cache la route sûre.
Pour la création Endless Runner, la revue s'est concentrée sur la préservation de cette boucle de décision lisible sur clavier et tactile. La version contenait déjà un panneau d'aide initial, deux niveaux de vitesse, des compteurs de score et de distance, des pièces, des menaces mobiles, une pause, un redémarrage et un meilleur score enregistré. Le travail n'était pas d'inventer un jeu différent. Il s'agissait de vérifier que le design existant communique ses règles et répond de manière cohérente.
Les changements de voie doivent être discrets et prévisibles
Le joueur doit toujours savoir laquelle des trois voies est active. Une commande à gauche ou à droite déplace exactement d'une voie, sauf si le personnage est déjà au bord. Les pressions répétées de touches ne doivent pas mettre en file une commande invisible qui s'exécute plus tard. L'animation peut être fluide entre les positions, mais la logique de collision doit correspondre à la position visuelle pendant la transition.
Sur ordinateur, le runner accepte les flèches comme convention principale et prend également en charge A et D. Sur tactile, un balayage horizontal correspond à la même décision de voie unique. Le seuil de balayage doit ignorer les petits mouvements de défilement tout en restant immédiat. Le mouvement visuel, l'état de collision et le cadrage de la caméra doivent être pilotés par le même index de voie afin qu'une fenêtre mobile étroite ne crée pas un ensemble de règles différent.
Saut et glissade nécessitent des contrats lisibles
Sauter et glisser ne sont pas des animations d'évasion interchangeables. Un obstacle au sol demande un saut ; un obstacle bas en hauteur demande une glissade. Chaque obstacle doit avoir un contraste suffisant, une visibilité anticipée et une hauteur cohérente pour que le joueur identifie ce contrat avant la fermeture de la fenêtre d'entrée.
Les joueurs au clavier peuvent utiliser la flèche haut, W ou espace pour sauter, et la flèche bas ou S pour glisser. Les joueurs tactiles utilisent des balayages verticaux. L'écran d'aide doit indiquer ces contrôles, mais la piste elle-même doit les enseigner à travers des exemples précoces et isolés. Combiner un changement de voie avec un saut peut être excitant plus tard ; utiliser cette combinaison avant que le joueur ne comprenne les silhouettes semble arbitraire.
La difficulté doit compresser le temps, pas supprimer l'information
Le premier niveau sert d'échauffement et donne au joueur un objectif de cinq cents mètres. Le deuxième niveau augmente la vitesse et la densité des obstacles vers une cible de quinze cents mètres. Augmenter la difficulté en raccourcissant la fenêtre de décision peut fonctionner, mais le jeu doit préserver l'information visuelle. Un jeu plus rapide nécessite un espacement plus propre, des silhouettes plus fortes et des combinaisons disciplinées plutôt qu'un mur d'objets aléatoires.
Les lignes de pièces sont utiles comme guide doux. Elles peuvent révéler une voie sûre ou inviter à un détour calculé, mais elles ne doivent pas mener directement à une collision illisible. Un système équitable permet à un joueur expérimenté d'anticiper les motifs tout en conservant suffisamment de variation pour la rejouabilité. La survie reste plus importante que de collecter chaque pièce.
La mise en page mobile fait partie de la conception du jeu
Une capture d'écran de bureau ne prouve pas la préparation mobile. L'aperçu protégé a été testé sur une fenêtre de téléphone étroite avec l'aide initiale visible, puis avec le jeu démarré. Les contrôles, les compteurs de statut et les actions de pause devaient rester lisibles sans défilement horizontal. Les gestionnaires tactiles ont été vérifiés pour les quatre directions, et le mode intégré ordinaire restait jouable sans forcer le plein écran.
La page Malaguo environnante compte également. La zone de jeu doit réserver un ratio stable, le contrôle plein écran doit rester accessible, et les actions de partage ou de signalement ne doivent pas couvrir le jeu. Un navigateur mobile ajoute ses propres barres d'adresse et de navigation, donc l'espacement sûr doit tolérer moins d'espace vertical que la taille d'écran nominale ne le suggère.
Ce que la revue a accepté
La version candidate a démarré avec succès après son écran d'aide initial délibéré. Le mouvement à gauche et le saut ont répondu aux entrées clavier, la distance et le score ont avancé pendant le jeu, et la console du navigateur est restée propre. La mise en page mobile et les gestionnaires de balayage couvraient le même ensemble d'actions. Le texte du catalogue a été étoffé pour que les joueurs comprennent les deux objectifs, le risque du train en mouvement, la persistance du meilleur score et les contrôles exacts avant de lancer.
L'approbation ne signifie pas que le design ne peut jamais s'améliorer. Les versions futures peuvent ajouter une meilleure télémétrie d'intégration, plus de séquences de motifs conçus, des options d'accessibilité et un son plus riche. Cela signifie que cette version nommée offre le mécanisme décrit sur sa page, sur les appareils qu'elle prétend prendre en charge, sans cacher une route cassée derrière un lien public.
Une liste de contrôle pour les créateurs de runners
Testez les limites de voie, les entrées opposées rapides, la récupération après saut et glissade, la pause pendant le mouvement, le redémarrage après collision et la persistance de l'aide initiale. Vérifiez chaque étiquette de clavier par rapport au code. Sur tactile, testez les balayages courts et diagonaux, le défilement du navigateur et la plus petite fenêtre prise en charge. Enfin, jouez assez longtemps pour atteindre le niveau de vitesse supérieur. Un runner qui fonctionne pendant les vingt premières secondes peut encore échouer lorsque le timing, la densité d'apparition et le chevauchement d'animations sont sous pression.
Conversation 0
Se connecter pour participer à la conversation.
Lancez une conversation constructive.