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