MAME RUN!! Herstellung Hinter den Kulissen – Technischer Teil

Teil 1 handelte davon, „warum wir es gemacht haben“,
Teil 2 beschäftigt sich mit „wie wir es gemacht haben“.

Ich persönlich fühle mich beim Erstellen von Webanwendungen viel wohler mit Backend-Systemen wie Django, PostgreSQL, Redis und Docker.
Jedoch wurde dieses Projekt fast ausschließlich auf Basis von reinem Vanilla JS + HTML5 Canvas umgesetzt.
Technologien im Frontend, die ich normalerweise nie tiefgreifend behandelt hätte, wurden in diesem Spiel zum Kern.

Und überraschenderweise…
es hat enorm viel Spaß gemacht.
Das war der technische Faktor, der mich weiter motiviert hat.

Normalerweise würde ich die Aussage, dass ich die Arbeit im Frontend „nicht mag“ eher mit „nicht mag“ statt mit „hasse“ beschreiben, aber ich denke, die Liebe zu 豆柴の大群 hat „Hassaufgaben“ in etwas gemacht, das ich mag.

1. HTML5 Canvas – „Eine Welt wie ein Malprogramm + Animation“

Der Kern von MAME RUN!! ist HTML5 Canvas.
Das ist ein Bereich, der wie ein „Malprogramm“ auf der Webseite erstellt wurde, in dem direkt Pixel gezeichnet werden, um das Spiel zu machen.

Normalerweise läuft Webentwicklung so ab:

• Tasten erstellen (HTML)

• Farbe anwenden (CSS)

• Ein wenig Interaktivität hinzufügen (JS)

Aber mit Canvas ist es ganz anders.

Canvas funktioniert mit 30–60 fps, indem es fortlaufend neu gezeichnet wird.
In jedem Frame:

1. Den Hintergrund löschen

2. Neu zeichnen

3. Den Charakter zeichnen

4. Die Hindernisse zeichnen

5. Kollisionen berechnen

6. Punkte erhöhen

7. Das nächste Frame planen

Das wird viele Male pro Sekunde wiederholt.

Heutzutage fühlt sich der Webbrowser so mächtig an wie ein Spiel-Engine.

2. Sprünge und Gravitation: „Die Magie von nur 3 Zeilen Code“

Der Grundbaustein des Spiels, das „Springen“, ist eigentlich einfach mit Physik umgesetzt.

dino.vy += gravity * dt;  // Gravitation anwenden
dino.y  += dino.vy * dt;  // Position ändern

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

Mit dieser einfachen Logik
führt Leonas sanftes Springen, Landen und Fallen ganz natürlich aus.

Ohne eine Spiel-Engine gab es den kleinen Aha-Moment,
„Ah... mit nur dieser grundlegenden Physik kann man schon wirklich flüssige Bewegungen erreichen“.

3. Sprite-Animation – Leben kommt in Leonas Laufbewegung

Leonards Laufanimation besteht aus einem Sprite-Sheet mit 6 Bildern.

(※ Blog empfiehlt das Einfügen von Sprite-Bildern)

In JS kann man die Sprites einfach in jedem Frame ausschneiden und zeichnen:

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

Wenn man nur den Frame-Index kontinuierlich ändert,
läuft Leona süß.
In diesem Moment hatte das Spiel „Leben“ bekommen.

Animationen sind wirklich wichtig für die Spielentwicklung.

4. Zufällige Hinderniserzeugung – „Der Schlüssel zur Beseitigung von Monotonie“

Es gibt verschiedene Arten von Hindernissen.

• Orangene Kegel

• Rote Kegel

• Gelbe Kegel

• Motorräder (2 Farben)

• Autos (2 Arten)

• Schilder (drei Arten)

Wenn nur 1–2 Stück wiederholt werden, wird es schnell langweilig,
aber wenn man viele Typen mit zufälligen Abständen mischt, wird der Spielfluss lebendig.

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

Sehr einfache Zufallszahlen, aber
das Spielerlebnis verändert sich komplett.

5. Kollisionserkennung – am schwierigsten und gleichzeitig die lustigste Aufgabe

Die Kollisionserkennung erfolgt auf die Methode, die oft als „AABB-Kollisionsbox“ bezeichnet wird.

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) {
    // Kollision!
}

Wichtige Punkte dabei sind:

• Wenn die Erkennung zu strikt ist, frustriert das Spiel

• Wenn sie zu locker ist, sinkt der Schwierigkeitsgrad

Daher habe ich sowohl Leonas als auch die Hindernisse die Hitboxen um 10–15% verkleinert, um ein „angenehmes Schwierigkeitsniveau“ zu schaffen.

Diese feine Anpassung machte viel Spaß.
Ich hatte ein wenig verstanden, warum Spielentwickler so viel Seele in die Balance des Schwierigkeitsgrades stecken.

6. Distanzbasiertes Stagesystem – Clear in 50 Sekunden

Stage 1 wurde so gestaltet, dass es in ca. 50 Sekunden abgeschlossen werden kann.
Daher wird angenommen, dass Leona 16 m pro Sekunde zurücklegt.

Zieldistanz: 800m  
Geschwindigkeit: 16 m/s → ungefähr 50 Sekunden  

Es geht nicht nur um Zahlen; ich habe tatsächlich 30–40 Mal gespielt und
„Ist das die Länge, die man spielen möchte, um dann wieder spielen zu können?“
stetig getestet.

Ein kleines, aber wichtiges Element, das das Spielerlebnis beeinflusst.

7. Server-Integration – Punkte-Ranking und Speicherung von Ergebnissen

Als Backend-Gestalter wurde der Server-Teil selbstverständlich in Django + DRF umgesetzt.

• Punkte über POST übermitteln

• Validierung in Serializer

• Nicht angemeldete Benutzer werden mit guest_id gespeichert

• Die besten Punkte pro Benutzer werden in der UserScore-Tabelle verwaltet

• TOP 5 werden als HTML-Fragment zurückgegeben, um durch JS ersetzt zu werden

So wird bei einem Game Over sofort das Ranking der TOP 5 in Echtzeit aktualisiert.

Es ist interessant, dass selbst im Canvas-Spiel
die Stabilität des Backends und der strukturierte Datenfluss enorm hilfreich sind.

Die Bilder und Dialogdaten der Charaktere werden systematisch im Backend verwaltet und dann in Kombination an den Browser gesendet.

8. Mobile Anpassung – viel schwieriger als erwartet

Das unerwartetste Hindernis beim Erstellen von Webspielen war die mobile Umgebung.

• Auflösung angepasst

• Touch-Interaktionen

• Canvas-Verhältnis

• Rendering-Leistung

• Korrektur der Scrollgeschwindigkeit des Hintergrunds

Es läuft auf dem Desktop sehr flüssig, aber
im Mobilen gab es Probleme mit geringen Frame-Drops, Touch-Reaktivität und der Berechnung der Canvas-Größe.

Es wurde gelöst, aber
in diesem Prozess ist mir der Satz „Ich respektiere Frontend-Entwickler…” einfach so herausgerutscht.

9. Teil 2 – Verabschiedung vom technischen Teil

Als jemand, der Backend-Entwicklung mag und hauptsächlich API-gestützte Entwicklungen macht, war es für mich das erste Mal, ein designorientiertes Spiel in JS im Web zu erstellen. Auch wenn ich zwangsweise im Frontend arbeiten muss, war ich noch nie so tief in HTML5 Canvas eingetaucht.

Aber durch dieses Projekt konnte ich lernen:

• Das Web ist leistungsstärker als gedacht

• JavaScript, das ich einmal als unordentlich bezeichnet habe, ist eigentlich eine recht unterhaltsame Sprache

• Spieleentwicklung besteht aus einer „Kombination kleiner Technologien“

Das war ein Projekt, das aus der Fanliebe entstand,
aber es war eine Arbeit, aus der ich auch als Entwickler viel gelernt habe und gewachsen bin.

Vorschau auf den nächsten Teil (Teil 3: Story Teil)

Im nächsten Beitrag will ich die Produktionshintergründe der Weltanschauung/Story auflisten,
„Warum fangen wir in Shibuya an?“, „Warum im Tokyo Dome?“, „Wie wurden die Charaktere für jedes Mitglied festgelegt?“

• Vorherigen Beitrag ansehen