ConjuGate

A collection of 6 posts
ConjuGate

在學習遊戲裡做 Boss 戰:ConjuGate 的關卡設計

ConjuGate 是一個學日文動詞變化的遊戲。玩家一邊閃避敵人一邊回答文法題,答對加分,答錯扣血。這個循環玩 10 分鐘就膩了。每一關的體驗都一樣:敵人出現、答題、過關、下一關繼續。沒有高潮。 我加了 Boss 戰來解決這個問題。每關答對 8 題之後,畫面停止捲動,一隻史萊姆王從畫面頂端降下來。玩家要在 60 秒內答對 6 題把它打倒,答錯會被反擊扣血。打贏拿 500 分和 15 秒時間獎勵,打不贏 Boss 就飛走,遊戲結束。 Boss 戰的節奏設計 Boss 戰跟一般遊玩階段最大的差異是壓力來源不同。一般階段的壓力是空間性的:敵人從上面衝下來,你要一邊閃一邊答題。Boss 戰的壓力是時間性的:畫面不再捲動,你不用閃避,但你有 60
閱讀時間 6 分鐘
iOS 開發

從色塊到動畫:獨立遊戲的美術迭代踩坑記

ConjuGate 第一版的畫面:綠色方塊是玩家,紅色方塊是敵人,藍色方塊是無人機。全部都是 SKSpriteNode(color:size:) 生出來的純色矩形。 現在的畫面:史萊姆有 Run/Hurt/Death 三組動畫,玩家有四方向行走動畫,Boss 是一隻完整的 slime knight。從色塊到這裡,中間經過了大量的素材處理踩坑。這篇記錄我怎麼一步步把色塊換成動畫,以及過程中遇到的具體問題。 色塊階段:為什麼一開始不用美術 第一版用色塊有一個好處:我可以專注在 gameplay 上。移動手感對不對、碰撞判定準不準、出題節奏快不快,這些都跟美術無關。用色塊測試,改一行 code 就能跑,不用等素材。 色塊階段持續了大約整個大改有 20 多次 。在這段時間裡,我加了射擊系統、砲塔、10 關制、FSRS 出題排程。
閱讀時間 6 分鐘
iOS 開發

做了才知道不要的東西:兩次 Revert 教我的事

ConjuGate 的 git log 裡面有兩個 revert commit。一個把無人機的水晶動畫砍回藍色方塊,一個把石磚道路砍回純色背景。兩個功能加起來花了五個 commit,最後全部退回原點。 為什麼 revert 不是浪費,以及怎麼 revert 才不會痛。 Case 1:水晶無人機 ConjuGate 裡有無人機繞著玩家轉圈射擊。一開始是 16×16 的藍色方塊,能用但醜。我找了一組水晶的 sprite sheet,重構了兩次才做好,而且code調很久: * 第一次重構:用水晶 sprite 替換藍色方塊,載入四個方向的動畫 atlas(上下左右各 6 幀) * 第二次重構:根據無人機繞圈的位置自動切換面向方向 加完之後跑起來看,水晶 sprite 的風格跟遊戲裡的史萊姆敵人完全不搭。史萊姆是圓潤的 pixel
閱讀時間 4 分鐘
SpriteKit 效能調校:三個讓遊戲不再掉幀的改動
iOS 開發

SpriteKit 效能調校:三個讓遊戲不再掉幀的改動

ConjuGate 在只有玩家和敵人的時候跑得很順。加了砲塔、無人機、散射之後,畫面開始掉幀,手機開始發燙。 我在三個地方找到了瓶頸,修完之後掉幀消失,耗電量也降了下來。這篇把三個問題和對應的解法寫下來。 問題一:每秒 68 次 alloc ConjuGate 的武器系統有普通子彈、散射、雷射、無人機、砲塔。砲塔加無人機全開的時候,一秒大約發射 68 顆子彈。每顆子彈都是 BulletNode(style:) 新建一個 SKSpriteNode instance。 一秒 68 次 alloc + init,Swift 的 ARC 要追蹤 68 個新物件的 reference count,SpriteKit 要把 68 個新 node
閱讀時間 6 分鐘
讓遊戲記住你哪裡不熟:FSRS 間隔重複的簡單實作
iOS 開發

讓遊戲記住你哪裡不熟:FSRS 間隔重複的簡單實作

你有 80 個日文單字要學,每個單字有 5 種變化形。隨機出題的話,你已經會的「食べます」和你老是搞混的「食べさせられる」出現的機率一樣。你的時間有一半浪費在已經會的東西上。 FSRS(Free Spaced Repetition Scheduler)解決的就是這個問題:讓你不熟的東西多出現,熟的東西少出現。我在 ConjuGate 裡面實作了一個簡化版的 FSRS,這篇用最簡單的方式解釋它怎麼運作。 先從一張卡片開始想 假設你正在學「飲む」的 ます形。你第一次看到它,答對了。下一次什麼時候該再出現? 如果太快再出,浪費時間。如果太晚再出,你已經忘了。FSRS 的核心就是找到這個「快要忘記但還沒忘」的甜蜜點。 做法很直覺:每張卡片有一個 interval(間隔),代表「隔多久再出一次」。答對了,interval
閱讀時間 5 分鐘
遊戲寫到一半才懂的事 — 什麼時候該拆 Class?
iOS 開發

遊戲寫到一半才懂的事 — 什麼時候該拆 Class?

如果你問我「寫遊戲的時候,什麼時候該把程式碼拆開?」我的答案是:等你痛了再拆。 這不是在開玩笑。我在做 ConjuGate(一個用 SpriteKit 寫的日文動詞變化學習遊戲)的過程中,真的是先把所有東西塞進一個 GameScene.swift,等到痛到不行了才開始拆。回頭看,這反而是對的。 一開始:所有東西都在 GameScene 裡 第一版的 ConjuGate,整個遊戲邏輯就是一個 1,132 行的 GameScene.swift。玩家移動、敵人生成、子彈發射、HUD 更新、碰撞判定——全部在同一個檔案裡。 你可能會說:「這不是很糟嗎?」 其實不會。在早期階段,你還在探索遊戲到底長什麼樣子。今天加了一個機制,明天可能就砍掉。如果一開始就花時間設計完美的架構,這些架構很可能跟著被砍掉的功能一起進垃圾桶。 想像你在畫草稿——你不會先把鉛筆線條上色。先畫出形狀,確定構圖對了,
閱讀時間 5 分鐘