“caveman”這名字聽起來就像是從復古卡帶里蹦出來的。我最近把它用在一個個人小項目上做成了一個網(wǎng)頁端的原始人生存模擬游戲。你不用裝引擎也不用配環(huán)境打開瀏覽器就能玩你扮演一名穴居人白天去采漿果、打野兔、撿樹枝生火晚上躲回山洞防野獸目標是撐過 30 天。這個項目的定位很純粹一方面想驗證一下“不依賴現(xiàn)代前端框架只用原生 Canvas 能不能做出一款完整可玩的游戲”另一方面也是想用最“原始”的方式過一次獨立游戲開發(fā)的手癮。適合誰看呢想用原生 JS 練手的同學、對游戲數(shù)值設計感興趣的玩家還有那些一打開編輯器就想先 npm install 一堆依賴的人這篇內容應該都能讓你有一點收獲。1. “caveman”是什么一個故意返祖的生存小游戲1.1 一句話定位不是大制作是“可玩”優(yōu)先caveman 的核心玩法當天就定下來了玩家扮演一個住在山洞里的原始人在 30 天內靠采集、狩獵、生火和休息活下去。每天分成兩個階段——白天出門搜集資源晚上回到山洞用資源換取生存機會。如果生命值歸零或者第 30 天結束時部落人口沒有達到目標游戲就判定失敗。這里有個很關鍵的取舍我不打算把它做成《饑荒》那種高度擬真的生存沙盒而是做成“一局半個小時能玩完”的回合制小游戲。因為項目只有一個人開發(fā)周末兩天要是把精力全耗在無縫地圖、多人同步、復雜合成系統(tǒng)上大概率連一個能跑通的 Demo 都拿不出來。所以我給項目定的規(guī)格非?？酥茊沃鹘?、單地圖、回合制、像素風、純本地存儲。所有資源包壓縮到一頓晚飯的時間能消化完剩下的火力集中在“玩起來有沒有意思”。1.2 為什么叫 caveman又為什么用“原始”開發(fā)方式項目名 “caveman” 有雙關意思。游戲題材是穴居人而整個開發(fā)過程也刻意向“原始狀態(tài)”靠攏不碰框架、不用構建工具、不引入任何運行時依賴。打開編輯器就是一個 HTML 文件配上兩個 JS 文件寫完直接扔瀏覽器跑。這聽起來像自虐實際上是一種非常解壓的寫代碼方式?，F(xiàn)在很多前端項目上來先裝 200 MB 的 node_modules改一行樣式都要等編譯。開發(fā) caveman 的時候我完全繞開這些改完刷新頁面立刻能看到結果調試也從“讀編譯報錯”回到“看打印日志和肉眼找像素塊”。這種體驗讓我找回早期寫網(wǎng)頁腳本時那種直接、快速、不受工具鏈綁架的感覺。用原生 Canvas 還有一個現(xiàn)實原因這個項目的核心是 2D 矩形碰撞、簡單的狀態(tài)機和定時隨機事件這些用瀏覽器 API 完全夠了。引入 Phaser 這樣的游戲引擎當然更省事但對一個體量這么小的游戲來說引擎本身的體積和學習成本反而會成為干擾。做個人項目刻意“少用東西”有時候比“堆滿東西”更難也更有價值。1.3 項目整體結構一覽我把代碼分成三個文件每個文件職責單一這也是個人項目里保持清醒的關鍵文件職責核心內容index.html頁面骨架Canvas 畫布、HUD、消息面板、開始/結束界面game.js核心邏輯狀態(tài)機、回合流程、資源計算、隨機事件、存檔render.js繪制層背景、角色、野獸、樹木、山洞、晝夜特效這樣一來邏輯和渲染完全分離開。我白天調數(shù)值的時候不用去翻繪制代碼晚上修渲染 bug 的時候也不會誤傷游戲狀態(tài)。哪怕后面想加場景、加角色只需要往 render.js 里塞新的繪制函數(shù)game.js 那套狀態(tài)機完全不用動。2. 核心玩法循環(huán)白天是獵人晚上是獵物2.1 為什么選擇“回合制”而不是即時制生存游戲常見的做法是即時制角色隨時可以走動野獸隨時會追過來。但即時制會引入一連串躲不開的問題角色的加速度、野怪尋路、地圖遮擋關系、幀率波動對判定影響這些都得單獨處理。項目只有兩天時間我不想把周末貢獻給路徑規(guī)劃算法。所以我選了“回合制 時間片”的混合方案。整個白天的行動被切成若干個行動點每個行動點消耗 1 個小時玩家可以從“采集、狩獵、砍柴、探索、返回山洞”里選一個動作。選完不暫停立刻結算結果然后進入下一個行動點。這套循環(huán)的邏輯像極了桌游你做一個決定系統(tǒng)告訴你發(fā)生了什么事你再做下一個決定。非常容易實現(xiàn)也非常容易調平衡?；睾现七€有一個隱性好處玩家有足夠時間看清屏幕上的每個像素。即時游戲節(jié)奏一快很多細節(jié)根本來不及觀察而 caveman 需要在 30 天里慢慢積累資源、形成策略回合制正好匹配這個節(jié)奏。2.2 資源數(shù)值設計讓每個選擇都有代價我設計了四個核心數(shù)值生命值、飽食度、溫度、火堆狀態(tài)。前兩個比較好理解溫度是一個偏門但很重要的指標——如果夜晚沒有生火角色體溫會持續(xù)下降降到臨界點就會扣血。數(shù)值范圍設計成 0100方便顯示進度條。經(jīng)過十幾輪試玩我最終把每天的行動點定為 8 個小時白天一共 16 小時玩家在“出門”和“回山洞”之間最多能執(zhí)行 6 次行動剩下 2 小時用于往返。這樣玩家每次都必須在“再采集一次”和“留夠時間回山洞”之間糾結策略深度立刻就有了。各行為的數(shù)值變化大概這樣行為飽食度生命值溫度收獲風險采集漿果200食物3低狩獵100食物5中可能受傷砍柴000木頭2低探索-100隨機物品/事件不定生火休息-2520消耗木頭1無這些數(shù)值不是拍腦袋定的。我當時的想法是必須讓“狩獵”看上去收益最高但風險也最明顯必須讓“采集”成為安全兜底但效率更低必須讓“砍柴”本身不產(chǎn)生食物卻決定你晚上能不能安全度過。玩家只有在三種行為間反復橫跳才可能撐過 30 天。2.3 黑夜階段把白天攢的資源變成生存概率夜晚的處理也走簡化路線。進入夜晚后玩家不能自由移動只能看到山洞里的一堆畫面系統(tǒng)根據(jù)“是否有火、是否有食物、是否制作了木矛”這幾個條件計算野獸襲擊和體溫下降的概率。這個設計讓白天和夜晚形成了天然的鉤子白天收集木頭不只是為了取暖還決定了晚上會不會被狼摸進來白天獵到的肉如果沒吃完第二天會變質所以必須精打細算地吃掉白天發(fā)現(xiàn)的燧石可以用來升級工具工具又能提高狩獵成功率。資源之間的耦合關系越多玩家就越難無腦重復同一個動作。夜晚結束后的早晨階段系統(tǒng)還會生成一個隨機事件比如“暴風雨破壞了你的山洞入口木頭-1”“遠處傳來獸群的聲音今天狩獵風險提高”“你發(fā)現(xiàn)了一顆巨大的野生果樹采集收益翻倍”。隨機事件表我寫了二十多條目的是讓每次 30 天旅程都不完全一樣。事件概率用簡單的加權隨機實現(xiàn)權重根據(jù)當前天數(shù)動態(tài)調整越到后期兇險事件出現(xiàn)概率越高。3. 關鍵模塊的代碼級拆解3.1 用一臺狀態(tài)機管住整個游戲流程caveman 的所有流程都可以用狀態(tài)機描述BOOT、MENU、DAY_ACTION、DAY_END、NIGHT、GAME_OVER、WIN。我把狀態(tài)機定義放到了 game.js 最前面方便所有函數(shù)引用。const GameState { BOOT: BOOT, MENU: MENU, DAY_ACTION: DAY_ACTION, DAY_END: DAY_END, NIGHT: NIGHT, GAME_OVER: GAME_OVER, WIN: WIN };在每一幀的 update 函數(shù)里我只做一件事根據(jù)當前狀態(tài)調用對應的處理函數(shù)。function update(dt) { switch (game.state) { case GameState.DAY_ACTION: updateDayAction(dt); break; case GameState.DAY_END: updateDayEnd(dt); break; case GameState.NIGHT: updateNight(dt); break; case GameState.GAME_OVER: updateGameOver(dt); break; } }這個寫法最大的價值是“強制隔離”。白天行動階段絕對不會不小心觸發(fā)夜晚的野獸襲擊判定夜晚的體溫扣除也不會漏到白天邏輯里去。后來我往游戲里加功能幾乎所有改動都只碰某個狀態(tài)對應的更新函數(shù)幾乎沒有出現(xiàn)過跨狀態(tài)的連帶 bug。3.2 玩家移動和地圖碰撞AABB 就夠用地圖做成了 480×320 的邏輯尺寸按像素風渲染放大兩倍。玩家、樹木、石頭、野獸都是矩形碰撞體碰撞檢測直接用 AABB軸對齊包圍盒那套經(jīng)典算法function hitTest(rectA, rectB) { return rectA.x rectB.x rectB.w rectA.x rectA.w rectB.x rectA.y rectB.y rectB.h rectA.y rectA.h rectB.y; }我沒有給角色做瓷磚地圖或者四叉樹空間索引。原因很簡單場景里的實體數(shù)量最多也就二十來個每一幀做兩兩檢測不過幾百次比較性能完全夠用。與其提前優(yōu)化不如把時間留給玩法。做小游戲最重要的一條經(jīng)驗就是——性能優(yōu)化永遠等到確實卡了再說。移動方面玩家通過鍵盤方向鍵操作按住不放會持續(xù)朝那個方向走。為了讓移動手感不飄我在 render.js 里加了簡單的摩擦力速度以每秒 120 像素為目標實際位移通過插值靠近目標值這樣角色從靜止到奔跑會有個短暫的加速過程看起來會自然很多。3.3 野獸 AI一只只會直線沖鋒的“原始狼”野獸 AI 也是刻意做得笨的。狼的行為只有三種狀態(tài)漫游、發(fā)現(xiàn)玩家、逃跑。漫游時在地圖下半部分隨機晃悠發(fā)現(xiàn)玩家后直接朝玩家當前位置直線沖刺沖到身邊就發(fā)動攻擊。啟動攻擊前會有一個短暫的“齜牙”停頓給玩家反應時間。這個“停頓”非常關鍵否則狼一旦出現(xiàn)就秒殺玩家會覺得自己是被隨機數(shù)干掉的。function updateWolfAI(wolf, player, dt) { if (wolf.mode roam) { wolf.x wolf.vx * dt; if (Math.random() 0.01) { wolf.vx (Math.random() - 0.5) * 40; wolf.vy (Math.random() - 0.5) * 40; } } else if (wolf.mode chase) { const dx player.x - wolf.x; const dy player.y - wolf.y; const dist Math.hypot(dx, dy); wolf.x (dx / dist) * 80 * dt; wolf.y (dy / dist) * 80 * dt; } }直線沖鋒會讓狼在撞到樹之后卡住但這恰好成為了玩法的一部分玩家可以利用樹木當掩體繞圈走位狼會因為瘋狂撞樹而露出破綻。這種 AI 缺陷反而制造了“操作空間”比費大力氣寫的尋路算法更適合這個小體量游戲。3.4 晝夜切換和 Canvas 繪制晝夜是渲染層最重要的視覺信號。白天用暖黃色調夜晚用深藍色中間用半小時過渡動畫而不是瞬間切換。過渡通過一個 nightly 變量實現(xiàn)范圍從 0白天到 1深夜每一幀根據(jù)當前游戲時間計算。function drawBackground(ctx) { const r Math.floor(235 - 150 * game.nightly); const g Math.floor(215 - 120 * game.nightly); const b Math.floor(150 - 80 * game.nightly); ctx.fillStyle rgb(${r}, ${g}, $); ctx.fillRect(0, 0, canvas.width, canvas.height); }夜晚時可見范圍縮小我蓋了一層半透明黑色遮罩然后用“destination-out”挖出一個圓形光圈光圈內部是正常視線外部全黑。這樣不僅渲染出“燭火照明”的感覺還能讓玩家一眼看出天黑后視野受限強化“必須回山洞”的緊張感。實現(xiàn)光照遮罩也很簡單不需要任何 WebGLctx.globalCompositeOperation source-over; ctx.fillStyle rgba(10, 10, 30, 0.85); ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.globalCompositeOperation destination-out; ctx.beginPath(); ctx.arc(lightX, lightY, 70, 0, Math.PI * 2); ctx.fill();這個技巧夠用到任何 2D 小游戲里而且代碼量極少。如果你也想做像素風格的小游戲建議先畫矩形版本確認玩法好玩以后再考慮加光照、粒子這些視覺糖霜千萬別在核心循環(huán)沒通之前陷進視覺效果里。4. 實測中踩過的坑性能、觸控和“太難了”4.1 卡頓問題出在重繪上而不是計算第一個可玩版本跑起來以后最明顯的毛病是畫面掉幀。我開始以為是碰撞計算太慢后來用瀏覽器自帶性能面板一看耗時大頭全在 Canvas 重繪上。因為我每一幀都會把整個畫布重新填色、重新繪制所有樹木和地表紋理即使有幾十個不動的靜態(tài)對象也全部重畫一遍。解決方法非常原始把靜態(tài)地形先繪制到一個離屏 Canvas 上之后每一幀只用 drawImage 把靜態(tài)背景貼上去動態(tài)人物、野獸再單獨畫。這招效果立竿見影FPS 從三十幾直接穩(wěn)到六十。// 初始化時一次性繪制背景 staticCanvas document.createElement(canvas); staticCanvas.width 480; staticCanvas.height 320; drawStaticBackground(staticCanvas.getContext(2d)); // 每幀先貼背景再畫動態(tài)對象 ctx.drawImage(staticCanvas, 0, 0); drawPlayer(ctx); drawWolves(ctx); drawParticles(ctx);這個優(yōu)化思路對所有 2D 游戲都通用把“不變的圖層”和“變化的圖層”分開別讓靜態(tài)元素重復消耗幀預算。4.2 手機上沒法玩觸控適配是大坑最初版本只考慮鍵盤結果一放到手機上就露餡沒有手柄也沒做任何觸控按鈕。后來我在屏幕上加了一個虛擬搖桿左下角畫一個圓形底托和一個可以拖動的圓鈕監(jiān)聽 touchstart、touchmove、touchend把拖動的偏移量映射成角色移動方向。觸控和鼠標事件有個容易踩的深坑touchmove 默認會觸發(fā)頁面滾動還會讓 Canvas 區(qū)域發(fā)生縮放。必須對畫布所在的元素調用 preventDefault并且加上 CSS touch-action: none。canvas { touch-action: none; user-select: none; }這個改動之后手機端才真正能玩。個人項目開發(fā)時我強烈建議從一開始就把觸控當?shù)谝惠斎朐O備來做不要等桌面版做完再補。補適配的代價遠高于一開始做雙輸入。4.3 數(shù)值失衡第一天死了二十次第一輪測試我自己玩都是連續(xù)暴斃。原因在于夜晚溫度下降得太快而木頭的獲取量又太少。我連續(xù)調了三組參數(shù)把初始木頭從 0 改成 2把砍柴每次獲得的木頭從 1 改成 2再把夜晚溫度下降速度從每回合 15 點降到 8 點。這才讓第一晚存活率超過 50%?！半y度曲線”不能靠感覺一定要記錄下來。我做了個簡單的表格記錄每一天測試中玩家的生命、飽食、溫度然后用“是否感覺資源被卡死”作為評判標準。調整數(shù)值的原則也很樸素前期允許玩家犯錯但不致郁中期增加隨機壓力后期看玩家能否把資源正向循環(huán)運轉起來。如果你也做生存游戲記住一個口訣第一晚別殺人第一周別勸退資源卡脖子要慢慢來。4.4 存檔把進度給吞了因為想要“隨時關掉瀏覽器再回來繼續(xù)”我做了一個 localStorage 自動存檔每天結束時寫入。第一次測試發(fā)現(xiàn)第二天恢復存檔后角色位置直接跑到了地圖外面數(shù)值全部變成 NaN。排查后發(fā)現(xiàn)是存檔時沒有做數(shù)據(jù)校驗存儲 JSON 里的坐標、數(shù)值偶爾會寫成 undefined。解決方式是寫一個 save 函數(shù)和一個 load 函數(shù)load 時對每個字段做一次默認值兜底和類型檢查function loadGame() { const raw localStorage.getItem(caveman_save); if (!raw) return null; const data JSON.parse(raw); return { day: validInt(data.day, 1), hp: validInt(data.hp, 100), stamina: validInt(data.stamina, 100), wood: validInt(data.wood, 0), food: validInt(data.food, 0), x: validNumber(data.x, 240), y: validNumber(data.y, 160) }; }不要相信任何舊存檔的字段完整性。版本迭代后字段可能變少、變多類型也可能變化不加校驗就會把用戶辛苦打的進度廢掉。這是做本地存檔最實際的教訓。5. 發(fā)布上線與玩家反饋實錄5.1 部署三步便宜、快、省心這個項目沒有后端部署靜態(tài)文件就夠了。我的上線流程很簡單把 HTML、CSS、JS 上傳到一個靜態(tài)托管目錄終端跑一條同步命令然后訪問返回的網(wǎng)址就開始試玩。整個過程不到五分鐘。只要沒有數(shù)據(jù)庫、沒有用戶系統(tǒng)個人小游戲完全可以走這條路不要一上來就搭服務器。caveman 只有三個文件總大小不到 90 KB加載幾乎瞬間完成。這種輕量也是刻意做出來的——不引入任何 UI 庫進度條用 Canvas 自己畫字體用系統(tǒng)默認的 monospace音效用 Web Audio API 臨時生成的“嗶嗶”聲。自己生成音效其實是意外收獲比找外部音頻文件省事得多還能規(guī)避素材授權問題。5.2 玩家反饋里最有用的三個聲音內測階段我給朋友發(fā)了一個鏈接收集到三條反饋直接影響了最終版本。第一條是“前期不知道干嘛”。最開始沒有新手引導玩家站在原地不知道采集要走到樹旁邊。我加了一段極簡引導第一天的前三個行動點用高亮虛線框圈出可交互物體并顯示“走近樹采集果實”的提示文字。這個改動把新手的懵圈時間從五分鐘縮短到二十秒。第二條是“到后期無聊了”。雖然隨機事件能帶來新鮮感但第 20 天之后行為開始重復。我給后期增加了一個特殊事件發(fā)現(xiàn)神秘洞穴可以選擇進入并獲得一個隨機強力遺物比如“石斧狩獵成功率提升 30%”。這個鉤子讓后期游戲有了明確的追求。第三條是“想看結局故事”。原版只有“你活過了 30 天”一行大字。我后來給勝利場景加了一段簡單的文本故事主角帶領部落走出了山谷發(fā)現(xiàn)山下有一條大河。沒有圖片純文字但玩家反饋說“感覺完整多了”。很多時候一個簡單的情感落點比復雜的成就系統(tǒng)更有效。5.3 后續(xù)如果繼續(xù)做我會擴展什么caveman 目前的體量當一個周末項目已經(jīng)完全合格但真要往完整作品方向走我會優(yōu)先做三件事增加第二個地圖地圖之間的物資差異讓探索選擇變得更有意義增加 NPC 伙伴解決單人行動時孤獨感太強的問題添加“季節(jié)循環(huán)”讓 30 天不再是一條直線上升的資源曲線而是一年四季的生存考驗。我最想做的是把“食物保質期”這個系統(tǒng)深化?，F(xiàn)在食物只有 24 小時變質如果能區(qū)分漿果和肉類肉需要煙熏保存漿果可以釀成飲品那資源的深加工鏈就會自然形成。不過這些明顯不是一兩天能做完的留給以后隨緣更新。6. 最后一點實操心得寫 caveman 這個過程我最大的體會是“少即是多”在個人項目里比想象中重要。不裝依賴、不做過度設計每天只聚焦一個核心玩法循環(huán)你反而更容易把一個項目從零做到能發(fā)布。那些復雜的工具鏈和炫酷的引擎特性都放在玩法跑通之后再考慮也不遲。如果你也想做類似的小游戲我建議你把范圍再縮小一點先做一個只有一天時長的 Demo讓玩家在一分鐘內完成“采集—生火—遇襲—存活”的最小循環(huán)。跑通以后再加天數(shù)、加地圖、加隨機事件。千萬不要第一天就把三十天數(shù)據(jù)填完你會在平衡性調整上把自己累死。最后分享一個小經(jīng)驗隨手記錄每一次數(shù)值調整前后的玩家反饋比任何測試工具都管用。caveman 的最終數(shù)值就是靠幾十行手寫的測試筆記一點點磨出來的。