一個網頁專案從「能跑」到「人們愛用」之間，有很大的差異。

開發「Test Merkezim」時，一開始的目標很單純：讓使用者不用註冊，就能直接在瀏覽器評估自己的認知能力、玩智力遊戲的快速平台。

但隨著專案成長，我發現工作遠遠不只是「顯示題目」或「做幾個遊戲」而已。使用者流程、行動裝置體驗、成績安全、遊戲難度、頁面效能都和遊戲本身一樣重要。

在這篇文章裡，我想分享開發過程中遇到的主要問題與心得。

把使用者帶到測試的流程要越簡單越好

最初的設計是：使用者點主頁按鈕 → 測試介紹頁 → 再點一次開始按鈕 → 輸入姓名 → 再點「開始測試」。技術上流程沒問題，但使用者卻要重複三次同樣的操作。

因此我拿掉了中間的介紹步驟。使用者從主頁直接進入測試畫面，可選擇輸入姓名後立即開始。

這讓我再次確認一個簡單的事實：

每多一次點擊，就多給使用者一次放棄的機會。

如果一個畫面真的不需要，與其把它做得更漂亮，不如直接移除。

為什麼選擇 PHP 與 Vanilla JavaScript？

專案跑在共享主機上，需要輕量架構，因此不想引入大型框架或強制建置流程。

整體結構如下：

  • 伺服器端使用 PHP
  • 遊戲機制使用 Vanilla JavaScript
  • 共用頁首、頁尾、音效、排行榜等元件使用 PHP 片段
  • 成績與遊玩資料透過伺服器端 API 處理
  • 各頁面各自包含 HTML、CSS、JavaScript

最大的好處是部署容易：更新檔案直接上傳即可，不需安裝相依套件。

缺點是如果沒把共用元件抽離好，類似程式碼會在不同遊戲中重複。因此我只把真正共用的部分集中到共用檔案，遊戲特有的邏輯仍留在各自頁面。

智力遊戲其實是小型狀態機

開發遊戲時很容易把焦點放在視覺設計，但真正困難的是管理遊戲的所有狀態：

  • 遊戲開始前哪些按鈕要啟用？
  • 非法操作要如何處理？
  • 撤銷操作會影響分數或步數嗎？
  • 重新整理頁面後，玩家能從中斷處繼續嗎？
  • 遊戲結束後要禁止新的輸入嗎？
  • 觸控與滑鼠操作行為是否一致？

例如在「連線解謎」遊戲中，玩家必須用一條不中斷的線填滿所有格子，並依序點擊編號點。

因為長時間按住滑鼠在桌上型電腦很累，我加入了「點擊同一行或列的遠端格子時，自動填入中間有效格子」的功能。規則不變，但操作更輕鬆。

這個小調整在不降低難度的情況下，減少了使用摩擦。

難度不只由棋盤大小決定

一開始我以為「關卡越高，編號點越少」就能讓遊戲變難。但過多的點也會把路線綁在更多強制檢查點上，反而增加某些關卡的難度。

因此我改用混合結構：

  • 棋盤大小從 5×5 逐步增加到 8×8
  • 同尺寸棋盤內，點的密度會上升或下降
  • 進階關卡混合 3 到 9 種不同密度
  • 每七關會把所有密度各使用一次
  • 避免連續出現相同點數

這樣玩家就無法預測下一關的結構。在程序生成中，除了隨機性，更重要的是「受控的多樣性」，才能維持平衡。

不能信任從客戶端送來的分數

瀏覽器遊戲的遊戲邏輯都暴露在使用者眼前，因此只接受 JavaScript 送出的分數是不安全的。

我在伺服器端加入了以下檢查：

  • 用白名單驗證遊戲 ID
  • 檢查各遊戲允許的難度值
  • 為每個遊戲設定合理的分數範圍
  • 拒絕不合理的完成時間
  • 對同一玩家或 IP 限制送出次數
  • 寫入排行榜前先清理輸入

在休閒遊戲平台上，要在伺服器完整重現所有遊戲可能過於複雜。但幾個低成本的驗證，就能阻擋大部分自動作弊。

核心原則很清楚：

客戶端負責使用者體驗，伺服器決定資料是否接受。

行動裝置體驗不該是事後才加的功能

因為大部分遊戲都是在手機上玩，所以只把桌面版縮小是不夠的。

在行動版需要特別處理：

  • 遊戲區域依螢幕寬度縮放
  • 控制按鈕、步數、時間顯示不互相重疊
  • 觸控目標要夠大
  • 文字與圖示對齊
  • 選單不超出畫面
  • 避免捲動與遊戲操作衝突

響應式設計不只是使用 width: 100%，還要決定內容呈現順序，以及使用者手指能點到的位置。

效能優化不一定要大型基礎建設

我在效能方面做了幾個簡單的選擇：

  • 字型從本地伺服器載入，而非外部服務
  • 大圖轉成 WebP 格式
  • 畫面下方的圖片使用 lazy load
  • 共用 CSS 保持精簡
  • 避免不必要的 JavaScript 函式庫
  • 圖片加上 width 與 height 屬性
  • 首屏不需要的資源延後載入

這些優化單獨看很小，但在行動網路下累積效果相當明顯。

SEO 與使用者體驗並非兩回事

準備 SEO 內容時，很容易把同一段資訊重複放在不同區塊。

我採取的做法是：

  • 每頁只用一個清楚的主標題
  • 直接回應搜尋意圖
  • 讓可見內容與結構化資料一致
  • 相似頁面保持標題一致性
  • 不要讓使用者停留在不必要的介紹畫面
  • 在遊戲下方真正說明規則與機制

目前這個專案提供：無需註冊的 IQ 測試、即時結果畫面，以及針對不同能力的瀏覽器智力遊戲。

另外也會清楚說明線上測試並不能取代專業或臨床評估，這是建立信任的重要部分。

從這個專案學到的核心教訓

我把開發過程中最重要的幾點整理如下：

  1. 「能用」的流程不等於「好用」的流程。
  2. 隨機生成如果沒有控制，難度就不會均衡。
  3. 行動版操作必須與桌面版分開設計。
  4. 客戶端送來的分數絕對不能直接信任。
  5. 多個小幅效能優化累積起來會產生大差異。
  6. SEO 內容如果不能真正回答使用者問題，再長也沒用。
  7. 讓玩家持續玩下去的關鍵，不只是難度，而是不斷變化的體驗。

隨著專案持續發展，我會繼續研究新的遊戲機制、更平衡的計分系統，以及更好的無障礙選項。

你在開發瀏覽器遊戲時，會如何管理遊戲狀態與程序生成的難度？歡迎在留言區分享你的做法。