Si le premier épisode parlait de « pourquoi l’avoir créé »,
le deuxième épisode traite de « comment l’avoir créé ».

Personnellement, lorsque je développe des applications web, je préfère m’occuper des systèmes basés sur le backend comme Django, PostgreSQL, Redis, et Docker.
Cependant, ce projet a été réalisé presque entièrement en pure vanille JS + HTML5 Canvas.
Des technologies frontend que je n’aurais normalement jamais approfondies sont devenues essentielles dans ce jeu.

Et étonnamment…
c'était extrêmement amusant.
C'est cet aspect technique qui m'a fait plonger davantage dans le projet.

D'ordinaire, je dirais que je « n'aime pas » les tâches liées au frontend, mais peut-être que l'amour pour 豆柴の大群 m'a fait aimer ce qui est « détestable ».

Capture d'écran de l'écran de sélection de personnage

1. HTML5 Canvas – Un monde comme « Paint + Animation »

Commandbox 광고

Le cœur de MAME RUN!! est HTML5 Canvas.
C'est une zone semblable à un 'tableau' créé sur une page web, où l’on construit le jeu en dessinant directement des pixels.

Habituellement, le développement web se déroule selon le flux suivant :

  • Créer des boutons (HTML)

  • Appliquer des styles (CSS)

  • Ajouter un peu d’interactivité (JS)

Mais le Canvas est complètement différent.

Le Canvas est une structure qui redessine continuellement à 30-60 fps.
À chaque image :

  1. Effacer l'arrière-plan

  2. Redessiner

  3. Dessiner le personnage

  4. Dessiner les obstacles

  5. Calculer les collisions

  6. Augmenter le score

  7. Prévoir la prochaine image

Ce processus se répète des dizaines de fois par seconde.

Les navigateurs web d'aujourd'hui sont vraiment puissants, presque autant que les moteurs de jeu.

2. Saut et gravité : « La magie créée par seulement 3 lignes de code »

Le saut, qui est fondamental dans le jeu, est en fait implémenté par une simple physique.

dino.vy += gravity * dt;  // Application de la gravité
dino.y  += dino.vy * dt;  // Changement de position

if (dino.y >= ground) {
    dino.y = ground;
    dino.vy = 0;
}

Avec cette logique simple,
le mouvement de Léona est réalisé de manière fluide lors du saut, de l’atterrissage et de la chute.

Sans moteur de jeu,
il y avait une petite émerveillement en me rendant compte que « ah… même avec cette physique fondamentale, un mouvement fluide peut être obtenu ».

Léona sautant dans le jeu

3. Animation de Sprites – La vie apparaît lorsque Léona court

Commandbox 광고

Le mouvement de course de Léona est comme l'image suivante, un sprite sheet de 6 images.

(※ Il est recommandé d'insérer l'image de sprite dans le blog)

En JS, il suffit de découper le sprite et de dessiner à chaque image :

const frameWidth = sprite.width / 6;
ctx.drawImage(
  sprite,
  frameIndex * frameWidth, 0, frameWidth, sprite.height,
  dino.x, dino.y, dino.width, dino.height
);

Il suffit de changer l'index d'image et
Léona court mignonnement.
C'est à ce moment-là que le jeu a commencé à avoir « vie ».

Les animations sont vraiment importantes dans le développement de jeux.

4. Génération aléatoire d'obstacles – « La clé pour éliminer la monotonie »

Il existe plusieurs types d'obstacles.

  • Con orange

  • Con rouge

  • Con jaune

  • Moto (2 couleurs)

  • Voiture (2 types)

  • Panneaux (trois types)

Si seulement 1 ou 2 obstacles se répètent, cela devient vite ennuyeux,
mais si l'on mélange plusieurs types à des intervalles aléatoires, le flux du jeu s’anime réellement.

const key = OBSTACLE_KEYS[Math.random() * length];
const interval = 0.8 + Math.random() * 1.2;

C'est un simple mode aléatoire, mais
la sensation de jeu change complètement.

5. Détection de collision – La partie la plus difficile et la plus amusante

La détection de collision est souvent appelée « collision par boîte AABB ».

if (dino.x < ob.x + ob.width &&
    dino.x + dino.width > ob.x &&
    dino.y < ob.y + ob.height &&
    dino.y + dino.height > ob.y) {
    // Collision !
}

Ce qui est important ici, c'est :

  • Si la détection est trop stricte, cela rend le jeu frustrant

  • Si elle est trop laxiste, cela diminue la difficulté du jeu

C'est pourquoi, pour Léona et les obstacles, j'ai réduit les hitboxes de 10 à 15% afin de créer une « difficulté agréable ».

Ce réglage minutieux a été assez amusant.
Je commence à comprendre pourquoi les développeurs de jeux investissent tant d’efforts dans l’équilibrage des niveaux.

6. Système de stages basé sur la distance – Terminer en 50 secondes

Le Stage 1 a été conçu pour être terminé en environ 50 secondes.
Ainsi, on a supposé que Léona se déplace à 16 m/s.

Distance cible : 800m  
Vitesse : 16 m/s → environ 50 secondes

Ce n'est pas juste un chiffre, mais en jouant réellement 30 à 40 fois,
j'ai testé si « cette distance donne envie de rejouer après une partie ».

C'était un élément important, bien que petit, qui influence la sensation de jeu.

7. Intégration serveur – Classement des scores et enregistrement

Étant un développeur backend, j'ai configuré la partie serveur naturellement avec Django + DRF.

  • Soumettre le score via POST

  • Validation dans le Serializer

  • Les utilisateurs non enregistrés sont enregistrés avec guest_id

  • Les meilleurs scores des utilisateurs sont gérés dans la table UserScore

  • Les TOP 5 sont retournés en morceaux HTML pour être remplacés par JS

Ainsi, lorsque le jeu est terminé, les classements TOP 5 se mettent à jour en temps réel.

Ce qui est amusant, c'est que même dans le jeu Canvas,
la stabilité du backend et le flux de données structurées sont d'une grande valeur.

La façon dont le backend organise systématiquement les images des personnages et les dialogues, puis les combine pour les envoyer au navigateur.

8. Compatibilité mobile – Bien plus difficile que prévu

L'un des obstacles les plus inattendus lors de la création d'un jeu web était l'environnement mobile.

  • Réponse à la résolution

  • Actions tactiles

  • Ratio du canvas

  • Performances de rendu

  • Correction de la vitesse de défilement de l'arrière-plan

Sur desktop, le jeu fonctionne très fluidement,
mais sur mobile, il y avait des problèmes tels que des drops de frame, réactivité tactile, et calcul de la taille du canvas.

J'ai fini par résoudre ces problèmes,
et c'est à ce moment-là que j'ai pensé « je respecte vraiment les développeurs frontend… ».

9. Conclusion de la Partie 2 – Partie Technique

Étant donné que j'apprécie le développement backend et que je développe principalement des API, c'était la première fois que je créais un jeu dont le design est principal en utilisant JS sur le web. D'habitude, je fais du frontend par obligation, et je n'avais presque jamais utilisé HTML5 Canvas aussi profondément.

Cependant, à travers ce projet, j'ai pu apprendre que :

  • Le web est beaucoup plus puissant que ce que je pensais

  • Le JavaScript, que j’avais précédemment considéré comme désordonné, est en fait un langage assez intéressant

  • Le développement de jeux est une « combinaison de petites techniques »

Bien que ce projet ait commencé par un engouement, c'était un travail qui m'a apporté beaucoup d'apprentissage et de croissance en tant que développeur.

Prochain épisode (Épisode 3 : Édition Histoire)

Dans le prochain article,
je vais aborder des coulisses de la création de l'univers/histoire, telles que « pourquoi commencer à Shibuya ? », « pourquoi le Tokyo Dome ? », « comment définir les caractéristiques de chaque membre ? »