儘管只有 146 KB，但還是 11 個 js13k

• 開發期間社群也鼓勵在 X 上用 #js13kgames 發 devlog——邊做邊被看見，是很好的推進力
• 參賽者互相玩、互相評分：Theme / Innovation / Gameplay / Graphics / Audio / Controls 六個面向，而且要寫文字回饋
• Post Mortem Fest：投票期間大家寫開發回顧文，分享技術跟卡關

實際看看 JS13K 遊戲 demo

• 2048 那樣的操作：上下左右滑，卡片就往那個方向推
• 撞到敵人是攻擊，撞到裝備是撿起來，同款相撞會合成升級
• 三個職業：騎士靠武器、法師靠藥水、防衛者靠反擊——同一套規則，三種玩法
• 每走 13 步出現菁英敵人、物品重量達 13 後每一步扣血（呼應當年的主題）

Templar's Final Stand ／ js13kGames 2024 ／ 13,266 bytes
角色、敵人、裝備合成、音樂、音效，全部在裡面

第一次參賽時，完全沒概念一個功能會吃掉多少 bytes。所以我做的第一件事，是去玩前一年的作品。

• 2023 年我拿 Dan Price 的 Norman the Necromancer 當標竿
• 先看清楚「13KB 大概能裝多少東西」——有幾種敵人、幾個關卡、美術做到什麼程度
• 再回頭決定自己的題目要做多大

接著透過 paper prototype 測試。當場就發現第一個點子行不通，在寫任何一行程式之前就砍掉了。

js13kGames 2022 ／ 用 PNG spritesheet 的像素美術路線

Kontra.js 它幫我做了什麼

GameLoop、Sprite、Animation、輸入（鍵盤／點擊／手勢）、Quadtree 碰撞、Scene、物件池、TileEngine、Vector、Text。沒有框架的話，以上都需要自己刻一份。

ZzFX：一個音效，就是一串數字

• 數位音訊原理——喇叭發聲靠振膜推動空氣，數位音訊藉由記錄每秒 44.1k 次「振膜推到哪」。所以一秒鐘的聲音 = 44,100 個數字
• ZzFX 做了什麼——平常播 mp3，瀏覽器是把檔案解碼成這串數字；ZzFX 直接用一組參數算出來
• 算完怎麼播——zzfxG(參數…) 產生數字陣列 → 記錄在 AudioBuffer（記憶體裡的一段聲音）→ 接上輸出 → start()

attackSFX = [3, , 179, , .03, .06, , 2.8, …]

ZzFXM 在 ZzFX 上加一層樂譜：樂器欄位放的就是一組 ZzFX 參數，所以加音樂不用第二套引擎。

• 變數與函式名換成 a、b、c
• 拿掉所有空白、換行、註解
• 能簡化的語法就簡化（if/else 併成三元、合併宣告、砍掉用不到的分支）

程式碼還是同一支程式，只是再也不是為了讓人讀懂而存在的。

<!-- dist/index.html 總共只有四行 -->
<script>
M='Kfh~MyXFmkUstuJshrq@zLPaBXlp?lLuBwtufeWuty…'  // 16,890 字元：壓縮後的資料
c=1<<15;h=[0,…];a=new Uint16Array(51e6)…       // 641 字元：解碼器
</script>

• 它吐出兩行：第一行是資料（存進變數 M），第二行是專門為這份資料生成的解碼器——只有 641 個字元
• 打開網頁時，解碼器把 M 還原成原始 JS 字串，再交給 Function 執行

zip 的壓縮（DEFLATE）做兩件事：

• 找重複(LZ77)——出現過的內容不再寫一次，改成「往回第 3 個字、抄 9 個」這樣的指標
  abcabcabcabc → abc ＋（往回 3，抄 9）
• 常出現的用短碼(Huffman)——對於常出現的給予較短編碼。像摩斯電碼，最常用的 e 給最短的 . 訊號
  aaaabbcd → a=0 b=10 c=110 d=111　64 → 14 bits

• 畫的時候就先省——刻意減少錨點、把同色區塊合併成一塊。能少一個點就少一個點
• 拿掉 metadata——編輯器存出來的 SVG 夾帶一堆用不到的東西：編輯器版本、圖層名稱、註解、多餘的屬性
• 降低每個點的數值精度——座標常常是 11.5407，這種小數對視覺來說，分辨不出來。SVGOMG 可以一路壓到最低精度

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 24.0.3, SVG Export
     Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.2" baseProfile="tiny" id="圖層_1"
  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
  viewBox="0 0 6.9 6.9" xml:space="preserve">
<g>
  <circle fill="#AE5D40" cx="3.5" cy="3.5" r="3.5"/>
  <rect x="3.1" y="2.4" fill="#79444A" width=".7" height="2"/>
  <polygon fill="#D1B187" points="3.1,3 3.8,3 3.7,3.7 3.2,4 2.6,3.9"/>
</g>
</svg>

1.51 KB → 653 bytes，壓到原本的 42%。右邊那排開關就是在拿掉 doctype、XML 指令、註解、metadata、編輯器資料。

2023：路徑寫進程式碼，執行時生成 img

const SVG_DATA = {
  shield: '<circle cx="13.8" cy="13.8" r="13.8"…',
};
// 執行時才把字串變成 <img>
Object.entries(SVG_DATA).forEach(…);
// 再用 drawImage 畫到 canvas

2024：把向量拆成座標，程式直接畫

// SVG polygon 的座標 → 取整 → 直接畫
drawPolygon(ctx, "1 12 7 12 11 0 0 0 1 12", RED);

// 內部就是 moveTo / lineTo / fill
// 連 img 都不用生成了

整款遊戲的造型，最後就是 50 幾組這樣的數字。

但省多少？我把 32 處 gI 全部改回 getInstance 重 build：

minified 檔上看起來省了 288 bytes，到 zip 只剩 21。94% 是壓縮器本來就會吃掉的。

getInstance 重複 32 次，第二次之後每一次都被壓成一個「往回抄 11 個」的指標。