文章開頭先問下大家，13kb 是什麼概念？我給你形容一下。這篇文章上方 “ 差評 ” 兩字的動圖，體積是 481kb。如果把這個動圖切成 37
份，那麼一份就剛好是 13kb。這 37 分 1
的 “ 差評 ” 能幹嘛？說出來你可能不信，有人能用它做出一個遊戲來。最近發現一個很魔性的網頁過關遊戲，正如你猜的那樣，它的體積只有 13kb。
遊戲里我們控制一隻小蜘蛛，要從一個房間的入口一段走到出口，並進入到下一個房間。
這當中我們要躲避各種會旋轉的陷阱，一旦不小心碰到陷阱，小蜘蛛就會沒命。
隨着關卡難度增加，各種奇怪的陷阱也層出不窮。
比如你走着走着會遇到突然出現的方塊，要過關的話，只有記住方塊出現和消失的規律，在一個完美的瞬間穿過去。
再比如這個全圖都在變大變小的圓圈，因為看起來很容易讓人眼花，所以你在移動的時候，一定要保持好距離。。
別的不說，就這賽博風格和各式各樣的陷阱都不敢想，這個有 20 個關卡的遊戲居然只有 13kb。
後來順着遊戲的名字在網上搜了一圈，才發現這個遊戲原來是出自於一場叫 js13kGames 的大賽。
它的比賽規則很簡單，用 JavaScript 開發一個 H5 遊戲，時間期限為 1 個月。
不過有一個要求，你最終提供的遊戲文件 zip 壓縮包大小必須在 13kb 以內，而且你的遊戲不可以使用任何掛載在服務器上的圖片、文件等。
換句話說，這 13 kb 包含了遊戲運行需要的全部文件。
儘管有了體積和時間的限制，但讓人驚訝的是，不管是玩法和畫面，這些網頁遊戲居然還挺豐富的。
比如 2020 年的冠軍作品：Ninja vs.Evilcorp。
遊戲里我們扮演一個忍者，需要從起點出發，通過跳躍、爬牆等方式來到電腦旁偷到資料。
每個關卡中，除了有監控，還有來回巡視的安保，一旦被他們視線掃到，我們就要重來。
光看看忍者屁股後面的幻影效果，還有跳躍時的白色塵土效果這些細節，你告訴我這隻有 13kb？
還有這個叫 The Last Spartan（ 最後的斯巴達人 ），遊戲里我們在一塊草原上進行砍殺，隨着時間不斷增加，敵人的數量和種類也會隨之增多。
遊戲里攻擊招式也比較齊全。
除了普通攻擊，我們可以使用 J + K 來突刺別人，或者是 J + Space 肉彈衝擊，造成範圍性傷害。
再來看看這個小車過河的遊戲，它採用了和紀念碑穀類似的視覺錯位。
這個 3D 畫面下，小車被斷橋擋住了去路，但如果切換到了 2D 畫面，兩個橋樑就很巧妙地連接上了。
隨着難度增加，遊戲也逐漸複雜起來，到後面不僅需要切換 2D 和 3D 畫面，還需要移動視角才能過關。
看到這裡大家一定好奇，這些遊戲是怎麼把體積控制在 13kb 以內的。
說起來你可能不信，除了有過人的編程技術，這些開發者還精通了五花八門的摳門學。
因為他們為了把遊戲體積控制在 13kb ，把能摳的地方都摳過了。。
往往一個遊戲里，素材圖片佔據了很大的比重。
如果要單純地減小這些圖片體積，我們可以使用壓圖工具進行壓縮。
比如一個原本 173kb 的圖片，重複壓縮四次后就只有 80kb ，如果再重複壓縮下去，可能最後只有幾 kb。
當然，這個方法未免有點效率太低。
有些開發者採用了另外一種方法：用光圈來代替原圖。
比如大賽里有一個 3D 迷宮博物館的遊戲，場景里放滿了各種世界名畫，有梵高也有蒙娜麗莎。
要展示一張蒙娜麗莎的畫像，我們可以利用算法，讓幾十個光圈的無限組合，最後得到一張最接近的圖片。
如果你摘掉眼鏡拿遠了看下圖（ 不近視的請嘗試讓眼睛失焦 ），就會發現右邊的光圈看起來其實跟左邊沒啥區別了。
所以，在遊戲里告訴玩家這是一張蒙娜麗莎的畫像，我們不需要放上一張幾百 kb 的圖片。
利用這些光圈，只需要在代碼中敲出每個光圈位置、半徑和顏色數據就行了。
當然了，就算你把素材壓縮足夠小，但要是素材數量太多，還是會超過 13kb 的限制。
所以開發者們最要做的，就是把素材重複利用。
比如上面的忍者遊戲，你仔細觀察會發現看似豐富的場景下，其實有很多重複的素材，有的最多也只是換了一種顏色。
除了上面這些素材圖片要處理，遊戲里的文字也是讓參賽者頭大的一個問題。
要在遊戲里顯示文字，就需要調用字體庫。
儘管一個通用字體庫只有十幾 kb，但這明顯不適合用在 13kb 大小的遊戲上。
所以有聰明的開發者想到做像素字體。
首先他創立一個對象，這個對象由 3×5 個空白格子組成，每個格子里可以填入 true（ 真 ）或者 false（ 假 ）。
當填入 true 的時候，格子就會被塗上一個黑色的像素。
那如果填入 false，這個格子就會被跳過，留下空白。
那麼要把這個對象塗成一個字母 A，我們可以按照下面的方式填入 true 和 false。
這個填入方式對應的代碼也就是：
多 1 個字母就會多佔 1 個字節，為了把體積縮到最小，我們可以用 1 來代替 true，把 false 刪掉。
所以優化后的代碼如下。
這樣一來，原本在遊戲里顯示一個字母 A 需要調用十幾 kb 字庫，現在只需要十幾個字節了。
解決了文字和圖片的問題，開發者還需要把代碼壓縮得儘可能小。
通常做一個遊戲都需要藉助遊戲引擎或者框架，來減少一些工作量。
但常見的遊戲框架肯定不適合做 13kb 的遊戲。
好在這遊戲已經舉辦了不少年，有一些早期參賽選手自己做了一些遊戲微框架，並提供給後來的參賽者。
比如有人做出了一個非常輕量級的遊戲框架 Kontra.js。
如果要在遊戲中做出一個不斷循環的元素，原本可能需要敲下幾十行的代碼，但通過Kontra.js 只需要幾行代碼就能實現。
光是這種方式縮減代碼還不夠。
在編程中有一類工具叫混淆器，它在保證不破壞原功能的前提上，把源代碼混淆成讓人難以理解的格式，來保護源代碼。
怎麼混淆呢？
比如把變量和函數用單字母代替、刪除代碼之間的空格、將多行代碼擠到一行等等。
大家有沒有注意到它的混淆方式中包含了 “ 縮減中間變量和函數 ”，“ 去掉空格 ” 。。
巧了。。
這就意外地讓混淆后的代碼相比之前縮小了 25% 左右。
所以，這個主要用來保護源代碼的工具也被大家用來縮減代碼體積。。
除此之外，還有人建議編寫代碼時盡量少用一些層級目錄（ 少用一些分類文件夾 ）。
雖然這樣編寫時會比較亂，但至少在遊戲文件最終打包的時候，壓縮率會高一點。
特意還做了測試驗證了一下：
把 3 個文件直接放在一個文件夾內，壓縮得到 A.zip。
把同樣的 3 個文件分別放到 3 個小文件夾內，然後把這 3 個小文件夾放到一個大文件夾內，再壓縮得到 B.zip。
經過對比發現，雖然文件一模一樣，但是 A.zip 確實小了幾百個字節。。
不僅是壓縮上摳細節，這些選手還會對壓縮包再壓縮。
用什麼軟件都有講究，比如有人就建議使用 advzip，因為它相對其他的壓縮軟件能多縮小 1kb 。。
看到這些開發者個個跟摳門學大師一樣的操作，其實也能理解他們。
畢竟你要把一個遊戲做得既有趣，又得控制在 13kb 以內，真就好比用電鋸剪鼻毛，每一步都得小心翼翼。。
但恰恰在這些壓力下，開發者會絞盡腦汁去優化自己的代碼，去挖掘自己的腦洞。。
所以反而意外的讓他們做出了這些比較好玩的，有創意的遊戲。
這也讓我想到了另外一個例子：《 超級馬里奧 》。
你可能從未想過，這個多達 32 個關卡的過關遊戲，它只有 40kb。
我們曾經出過一期視頻告訴大家是怎麼做到的，這裡再稍微講講。
和上面講到 13kb 遊戲素材重複利用一樣，馬里奧也是有一套素材包。
我們只需要在需要用到素材的時候，把他拖放過去。
當然了，這些素材包也要能省就省。
比如遊戲里的草垛，其實就是白雲的上半部分換個顏色罷了。
再比如馬里奧一整套的動作，是由 21 張圖像（ 準確說法為 Sprite ）組成的。
但 21 張圖片佔用空間太多，所以開發者把每張馬里奧圖片都切成了 4 份，去掉相同的部分。
這樣剩下的素材依然可以通過組合，來完整馬里奧所有的動作。
如果你仔細觀察，就會發現花朵和星星都是對稱的。
其實遊戲開發者只存儲了半隻花和星星，只是在顯示它們的時候，把它們複製了一下再放出來罷了。
你看，雖然限制非常嚴苛，但這並不妨礙開發者們做出影響了幾代人的《 超級馬里奧 》。
這樣的例子還不少。
比如早期因為機器性能問題，根本做不出 3D 遊戲，那怎麼表現出 3D 效果呢。
在上世紀 80 年代就有開發者想出利用平行投影，通過傾斜視角來展示遊戲畫面，從而產生立體效果。
1982 年世嘉出品的《 Zaxxon 》▼??
這類遊戲也被稱為等距遊戲，這種方式也被各種 RPG 和戰略類遊戲所採用。
還有開發者想到利用視差滾動的效果，讓 2D 畫面更有立體感。
什麼是視差滾動？
我們坐車的時候向窗外看，會感覺遠處的山脈移動速度慢，近處的稻田和建築物移動速度快。
那遊戲里也可以把遠處的背景速度拉慢，距離鏡頭較近的物品速度拉快，模仿人類視覺效果，營造立體感。
1981 年推出的《 Jump Bug 》就採用了視差滾動效果，仔細看近處的大樓要比遠處的白雲移動速度快很多。
這個方式後來經常被用在橫版闖關遊戲里，甚至還有一些網站為了提高逼格，也用上了這種視覺效果。
所以儘管當時各項硬性條件不足，但是開發者還是發揮了他們最大的能力，給我們做出了一代又一代經典的遊戲。
雖說現在隨着科技高速發展，開發者們做遊戲很少有這樣那樣的條件限制。
但是通過這樣一個 13kb 的比賽，我們發現如今依然有人可以在這種嚴苛的限制下，做出優質的遊戲。可以看到只要儘力了，困難永遠都不能限制到他們，辦法也總比困難多嘛。當然在某種層面上，這個道理也適用於所有人。