1篇是「為什麼要製作」的故事，
2篇則是 「怎麼製作」 的故事。
個人來說，在製作網頁應用時，我更習慣使用 Django、PostgreSQL、Redis、Docker 等後端基礎系統。
然而這個專案幾乎完全是 純粹的香草JS + HTML5 Canvas 基礎 進行的。
通常我不會深入研究的前端技術，在這個遊戲中成為了關鍵。
更意外的是…
真的非常有趣。
這也是讓我更加投入的技術因素。
平時我對前端的工作是用「不喜歡」來形容，而不如用「討厭」來更恰當，但 豆柴の大群 的愛的力量讓我喜歡上了「我討厭的事情」。
1. HTML5 Canvas – “像畫板 + 動畫”的世界
MAME RUN!! 的核心是 HTML5 Canvas。
這是一個在網頁上創建的「畫板」類似的區域，通過在上面直接畫像素來製作遊戲。
通常的網頁開發流程是
-
建立按鈕 (HTML)
-
填充顏色 (CSS)
-
增加一些行為 (JS)
這樣的流程，但 Canvas 則完全不同。
Canvas 是 以 30~60fps 的頻率不斷重繪的結構。
每一幀：
-
清除背景
-
重新繪製
-
繪製角色
-
繪製障礙物
-
計算碰撞
-
提升分數
-
預約下一幀
這樣每秒重複數十次。
如今的網頁瀏覽器真的是強大到不遜於遊戲引擎。
2. 跳躍和重力： “僅僅 3 行代碼創造的魔法”
遊戲的基本「跳躍」實際上是通過簡單的物理實現的。
dino.vy += gravity * dt; // 應用重力
dino.y += dino.vy * dt; // 位置變更
if (dino.y >= ground) {
dino.y = ground;
dino.vy = 0;
}
僅僅這段簡單的邏輯就能讓
雷歐娜 平滑地跳躍、著陸和下墜 的動作顯得自然。
在沒有遊戲引擎的情況下，
「啊…這樣的基本物理就能讓動作如此靈活」
讓我感到了一些小感動。
3. 精靈動畫 – 雷歐娜跑動時賦予了生命
雷歐娜的奔跑動作是如下一張 6 幀的精靈圖。
(※ 建議在部落格中插入精靈圖片)
在 JS 中，只需將精靈切割並在每一幀繪製：
const frameWidth = sprite.width / 6;
ctx.drawImage(
sprite,
frameIndex * frameWidth, 0, frameWidth, sprite.height,
dino.x, dino.y, dino.width, dino.height
);
只需不斷改變幀索引，
雷歐娜就可愛地奔跑。
這個時候感覺遊戲中充滿了「生命」。
在遊戲開發中，動畫是非常重要的。
4. 障礙物隨機生成 – "消除單調的關鍵"
障礙物有多種類型。
-
橙色錐
-
紅色錐
-
黃色錐
-
摩托車 (兩種顏色)
-
汽車 (兩種型號)
-
標誌 (三種)
如果只是重複 1~2 種，很快就會厭倦，
而將多個類型以 隨機間隔 混合，可以讓遊戲節奏感大增。
const key = OBSTACLE_KEYS[Math.random() * length];
const interval = 0.8 + Math.random() * 1.2;
雖然是非常簡單的隨機，但
遊玩的感覺卻完全不同。
5. 碰撞判定 – 最困難但也最有趣的部分
碰撞判定通常所謂的「AABB box 碰撞」。
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) {
// 碰撞！
}
這裡重要的是
-
如果判定太嚴格，遊戲會讓人感到沮喪
-
如果過於寬鬆，則遊戲難度會下降
因此我將雷歐娜和障礙物的 碰撞盒縮小 10~15%，創造出一個「愉快的難度」。
這樣的微調相當有趣。
我開始明白為什麼遊戲開發者會對難度平衡投入心血。
6. 距離基礎的關卡系統 – 50 秒內完成
第一關被設計為約 50 秒 內完成。
因此我假設雷歐娜的移動速度為每秒 16m。
目標距離: 800m
速度: 16 m/s → 約 50 秒
這不是單純用數字確定的，而是進行了 30~40 次的實際遊玩，
反覆測試「這樣的長度能讓人享受一局再想再來嗎？」
雖然小，但卻是影響遊玩感的重要因素。
7. 伺服器連接 – 分數排名與記錄保存
作為後端開發者，自然是使用 Django + DRF 來構建伺服器部分。
-
通過 POST 提交分數
-
在序列化器中進行有效性檢查
-
未登入用戶使用 guest_id 記錄
-
每位用戶的最高分在 UserScore 表中管理
-
TOP 5 以 HTML 片段返回 JS 替換
因此在遊戲結束時， 排名 TOP5 即時更新。
有趣的是，在 Canvas 遊戲中，
後端的穩定性和結構化數據流是巨大的助力。
後端系統化整理角色的圖片和對話數據，並結合後發送到瀏覽器的模式。
8. 行動裝置適配 – 遠比想像中困難
在製作網頁遊戲中，最意想不到的障礙是 行動裝置環境。
-
解像度適配
-
觸控操作
-
畫布比例
-
渲染性能
-
背景滾動速度補正
在桌面上運行非常流暢，但在行動裝置上卻存在幾個問題，例如：細微的幀掉落、觸控反應、畫布尺寸計算等。
雖然最終解決了，但在這個過程中，我不禁說出了「尊敬前端開發者...」。
9. 第二篇 – 技術篇結語
我喜歡後端，所以主要以 API 為中心進行開發，這是我第一次用 JS 為主要設計的遊戲製作。不過平常前端也要做，因此也只能勉強應付，尤其是對於這麼深入使用 HTML5 Canvas 的經驗幾乎沒有。
但透過這個專案，
-
網頁比想像中更強大
-
曾經因雜亂無章而討厭的 JavaScript，其實是一門相當有趣的語言
-
遊戲開發是一系列「小技術的結合」
我學到了這些。
這是由粉絲情懷開始的專案，
作為開發者也獲得了相當多的學習和成長。
下一篇預告 (第三篇: 故事篇)
在下一篇文章中，
「為什麼在澀谷開始？」「為什麼是東京巨蛋？」「每位成員的角色設定是怎麼決定的？」
我打算整理同一世界觀/故事製作的背後故事。
目前沒有評論。