<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://lankudot.airfishlab.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://lankudot.airfishlab.com/" rel="alternate" type="text/html" /><updated>2025-12-14T23:27:27+08:00</updated><id>https://lankudot.airfishlab.com/feed.xml</id><title type="html">烏龜漫遊 2.0</title><subtitle>記錄分享在 Unity 上製作遊戲的筆記與心得</subtitle><author><name>烏龜</name></author><entry><title type="html">[遊記] Montreux Jazz Festival Japan 2025</title><link href="https://lankudot.airfishlab.com/blog/2025-12-mjfj-2025/" rel="alternate" type="text/html" title="[遊記] Montreux Jazz Festival Japan 2025" /><published>2025-12-14T00:00:00+08:00</published><updated>2025-12-14T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/mjfj-2025</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-12-mjfj-2025/"><![CDATA[<p>人生第一次參加爵士音樂節就給了 MJFJ 2025，除了為了心心念念的 Persona 5 Big Band 之外，還有著名的大師 Nate Smith 跟 Herbie Hancock 也有參演這次的音樂節。由六組表演組成長達 9 小時演出，對於初次體驗的我來說相當滿足。</p>

<p><img src="/assets/images/blog/2025/2025-12-14-mjfj-2025/key-visual-2.png" alt="key-visual-2" />
<img src="/assets/images/blog/2025/2025-12-14-mjfj-2025/posters.png" alt="posters" />
<em>前幾屆 MJFJ 的海報也有在會場內展示</em></p>

<p>今年 MJFJ 舉辦在橫濱的 PIA Arena MM，不愧是經常舉辦演唱會的日本，體驗跟在台灣完全不一樣。PIA Arena MM 場地超大音響輸出也很有力，可惜的是因為是演唱會設置，大鼓與電 Bass 的聲音太沉，而且延音很長，低頻的聲音完全混在一起，要形容的話，就是耳朵溺水，對爵士樂來說體驗差了一點。</p>

<p><img src="/assets/images/blog/2025/2025-12-14-mjfj-2025/pia-arena-mm-2f-view.png" alt="pia-arena-mm-2f-view" />
<em>從 2 樓看可以發覺場地真的很大</em></p>

<p><img src="/assets/images/blog/2025/2025-12-14-mjfj-2025/my-seat-view.png" alt="my-seat-view" />
<em>這次抽到的位置很棒，1 樓中間，也可以清楚看到舞臺上的演出</em></p>

<p>前兩團 Shuta Hasunuma Phil 與 L’Osmose 感覺都是實驗性質的音樂，弦律會持續很久，然後一直再疊不同的音色上來，最後達到最滿的狀態，讓人感覺很迷幻。</p>

<p>再來是 MJFJ TB×ER UNIT with BIGYUKI，薩克斯風手馬場智章是在《藍色巨星》動畫電影中，擔任角色宮本大的音樂演出，而特別來賓的鼓手石若駿同是擔任電影角色玉田俊二的音樂演出。在開始演出之前，我對他們的印象就是來自電影，但沒想到他們的音樂風格會是混和 DJ、電音、嘻哈。馬場智章會搭配錄音介面，錄製再重播上一段演奏，彷彿同時有好幾把薩克斯風同時在演奏，石若駿的演奏也相當狂野。聽下來氣氛很嗨，而且還有聽眾站起來跟著音樂一起搖擺，還以為來到音樂祭了。</p>

<iframe data-testid="embed-iframe" style="border-radius:12px" src="https://open.spotify.com/embed/track/6D2FjYhr2L8XhOcuQ5mlzT?utm_source=generator" width="100%" height="152" frameborder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

<iframe data-testid="embed-iframe" style="border-radius:12px" src="https://open.spotify.com/embed/track/0uniIrDLtvdypzbMtmLmVV?utm_source=generator" width="100%" height="152" frameborder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>
<p class="video-caption"><em>馬場智章的音樂跟在電影中的風格一樣奔放</em></p>

<p>Persona 5 Special Big Band 是我想參加 MJFJ 的主要原因。當初 P5BB 的專場演出抽了 4 次票都沒中，後續一直關注相關消息，就看到他們也有要在 MJFJ 上演出。P5BB 由原有歌曲的主唱 Lyn，與來自日本與海外的音樂好手組成，這麼豪華的陣容怎麼可以錯過。第一首《Wake Up, Get Up, Get Out There》前奏一下就開始起雞皮疙瘩，當然也少不了《Life Will Change》，而在我最喜歡的《Beneath the Mask》中 Lyn 更是展現爵士的唱歌功力。另外沒想到《Hymn of the Soul》是用小號做為主奏，也別有一番滋味。讓人驚奇的是指揮居然擔崗一部份的吉他演奏跟打擊樂器，第一次看到這麼忙的指揮。這場演出無疑是我最喜歡的演出，好希望他們的專場演出會出 BD 或是 CD。</p>

<p><img src="/assets/images/blog/2025/2025-12-14-mjfj-2025/p5bb-booklet.png" alt="p5bb-booklet" />
<em>在會場買了 P5BB 專場的小冊子，才知道專場一共演奏了 20 首音樂</em></p>

<p>最後分別是 Nate Smith 與 Herbie Hancock 這兩位爵士大師帶來的演出。Nate Smith 和融合爵士樂團 Snarky Puppy 的 leader Michael League 與 James Francies 一起演出。Nate Smith 的爵士鼓演出很迷人，尤其是在 solo 的時候，還會讓人覺得鼓的節拍稍微慢了一點，再接回原本的速度。而 Herbie Hancock 很喜歡用合成器與取樣的聲音做為音源，讓他的音樂充滿電子聲響，這也是讓我喜歡上的原因。像是《Butterfly》與《Rockit》再加上即興，在現場聽跟聽 CD 又有不同的感覺。而最後一首跟馬場智章、石若駿、小曾根真一起演出，聽到《Chameleon》的前奏一下時，感動到不行，真的是不能少了這首經典音樂。整首音樂 Herbie Hancock 拿著 Keytar 在舞臺上跟每個樂手進行 solo 對話，其中還有做了開合跳，沒想到 85 歲高齡的他還是這麼活潑，一直在「玩」音樂。當然這首把整個活動帶到最高潮，結束後，全場無不起立鼓掌。</p>

<!-- Courtesy of embedresponsively.com -->

<div class="responsive-video-container">
    <iframe src="https://www.youtube-nocookie.com/embed/L_XJ_s5IsQc" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe>
  </div>

<p class="video-caption"><em>Snarky Puppy 中我最喜歡的音樂之一</em></p>

<iframe data-testid="embed-iframe" style="border-radius:12px" src="https://open.spotify.com/embed/track/4Ce66JznW8QbeyTdSzdGwR?utm_source=generator" width="100%" height="152" frameborder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>
<p class="video-caption"><em>能在現場聽到 Chameleon 既興奮又感動</em></p>

<p>從下午 1 點入場到晚上 10 點才離開，能夠如願聽到 P5BB 的演出，又能看到大師的表演，這 9 個小時的體驗真的很棒，之後還會想到日本參加類似的活動。而 MJFJ 也有製作一份這次演出的樂團與樂手的經典曲目的播放清單，有興趣的話值得一聽。</p>
<iframe data-testid="embed-iframe" style="border-radius:12px" src="https://open.spotify.com/embed/playlist/1llb2E2iYWsdft4113xpp7?utm_source=generator" width="100%" height="152" frameborder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="遊記" /><summary type="html"><![CDATA[人生第一次參加爵士音樂節就給了 MJFJ 2025，除了為了心心念念的 Persona 5 Big Band 之外，還有著名的大師 Nate Smith 跟 Herbie Hancock 也有參演這次的音樂節。由六組表演組成長達 9 小時演出，對於初次體驗的我來說相當滿足。]]></summary></entry><entry><title type="html">[開發日誌 #4] 原型時期的程式開發方式</title><link href="https://lankudot.airfishlab.com/blog/2025-10-programming-tips-in-prototyping-stage/" rel="alternate" type="text/html" title="[開發日誌 #4] 原型時期的程式開發方式" /><published>2025-10-26T00:00:00+08:00</published><updated>2025-10-26T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/programming-tips-in-prototyping-stage</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-10-programming-tips-in-prototyping-stage/"><![CDATA[<p>在開發遊戲原型時，最重要的是盡快實現遊戲玩法，但一開始自己走了許多歪路，反而花更多心力在不重要的地方。在 TDGF 上聽到分享與請教朋友之後，學到不少在原型階段的開發方式，就透過這篇文章來分享減少走錯路的方法。</p>

<h2 id="能動就先用不急著重構">能動就先用，不急著重構</h2>

<p>開發時總是會想要重構程式碼，可能是因為覺得有更好的作法，或是覺得現在的架構不適合新的功能。但是在開始重構之前最好先評估要花多久，以及牽涉到的範圍有多廣。因為在原型時期的遊戲規格變動很快，如果花了大把時間重構的功能要再修改，甚至被打掉的話，花的時間就白費了（<a href="/blog/2025-08-seek-first-to-have-but-do-not-take-long-way-around/">上一篇的悲慘經驗</a>）。所以當需要增加或是修改功能時，先順著繼有的架構去作，等功能確定之後才來重構，此時的規格也比較完整，重構才有效益。</p>

<h2 id="嘗試不同作法的好時機">嘗試不同作法的好時機</h2>

<p>在原型階段，程式結構還沒有很複雜，是可以嘗試用不同作法或是新套件來開發功能的好時機。可能是在之前的開發中遇到的問題有更好的作法，或是知道有不錯的套件可以使用。在這個階段多多嘗試與實驗，知道使用的作法或套件的極限到哪裡，如果不合適的話，替換掉的成本也相對低。</p>

<p>這次開發的遊戲為了能更方便管理與播放角色動畫，就嘗試使用 <a href="https://assetstore.unity.com/packages/tools/animation/animancer-pro-v8-293522">Animancer</a> 套件來製作相關的功能。一開始我先列出想要這個套件實現的功能，然後花兩三天的時間「玩」這個套件，看看有哪些功能可以實現，哪些要自己實作，而且要花多久時間實作。評估這個套件合適後，才導入到專案中。</p>

<h2 id="新內容用新功能">新內容用新功能</h2>

<p>那如果是開發到一半，發現有更好的作法時要怎麼辦？那最好的作法是只在新的內容用新的功能，一來可以不用先花時間重構既有的功能，二來也可以驗證新的作法是不是真的比較好。如果不合適，那也只有新的內容會受到影響。如果合適的話，則在舊內容需要修改時，或是時機成熟時，像是用新作法的內容製作流程確立，再改成使用新作法，慢慢取代掉舊功能。</p>

<p>這次開發的遊戲中有不同的敵人，在戰鬥邏輯上就使用這樣的開發方式。原本的戰鬥邏輯是使用 ScriptableObject 來設定數值與時機，但後來為了配合角色動畫，這些資訊得改成由播放的動畫提供。所以我只有先在新的敵人上使用動畫來控制戰鬥邏輯，而既有的敵人就先不動，等到需要的時候，就直接用新功能來做擁有同樣能力的敵人，直接取代舊的敵人。</p>

<h2 id="功能要有隨時被改掉的覺悟">功能要有隨時被改掉的覺悟</h2>

<blockquote>
  <p>我要修改… 部份規格!!! ー《大東京玩具箱》</p>
</blockquote>

<p>在原型階段最常發生的事情就是規格改變。所以不要過度設計功能，不要想著這功能要囊括所有可能性，或是未來的需求。否則花了大把時間精心設計的功能，因為測試後覺得在遊戲中不好玩，而要被拿掉的話，只有滿滿的失落感，勞神又傷心。因此功能能解決現階段的需求就可以了，製作時間也不用花太多，先拿出來被驗證才是首要目標。</p>

<h2 id="永遠考慮時間是否夠用">永遠考慮時間是否夠用</h2>

<p>寫程式沒辦法兼顧「快」與「好」，在原型階段只能做取捨，就是以快速實現遊戲玩法為主要目標。所以在製作功能或是重構前，先評估要花多久時間才能完成。如果時間可以接受，就能開始動工。如果不行，就看瓶頸在哪邊，有沒有方法可以先繞過那部份，又可以掌握在可以控制的程度。再真的沒辦法，就是跟團隊討論，看能否縮減規格，或是能接受花時間下去製作。</p>

<p>在程式的架構設計上我以功能為單位來切割元件，一個元件（不一定只有一個程式碼檔）專門負責一個功能（一個功能下面也可能有子功能），呼叫功能的角色不用在意其中做了什麼事，只要控制什麼時候呼叫就可以了。這樣程式碼混雜的地方就只會集中在各自的元件內，無論是要替換或是修改，受影響的範圍就不大。</p>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="開發日誌" /><summary type="html"><![CDATA[在開發遊戲原型時，最重要的是盡快實現遊戲玩法，但一開始自己走了許多歪路，反而花更多心力在不重要的地方。在 TDGF 上聽到分享與請教朋友之後，學到不少在原型階段的開發方式，就透過這篇文章來分享減少走錯路的方法。]]></summary></entry><entry><title type="html">[開發日誌 #3] 先求有，但別繞路</title><link href="https://lankudot.airfishlab.com/blog/2025-08-seek-first-to-have-but-do-not-take-long-way-around/" rel="alternate" type="text/html" title="[開發日誌 #3] 先求有，但別繞路" /><published>2025-08-28T00:00:00+08:00</published><updated>2025-08-28T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/seek-first-to-have-but-do-not-take-long-way-around</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-08-seek-first-to-have-but-do-not-take-long-way-around/"><![CDATA[<p>很常聽到在專案開發初期，做功能最好是「先求有，再求好」。在發覺做了兩個月的白工後，才體會到這句話的意思應該是「先求有，以此為基礎，再求好」，而不是「先求有，之後再做一個全新且更好的」。</p>

<p><img src="/assets/images/blog/2025/2025-08-28-seek-first-to-have-but-do-not-take-long-way-around/cover-image.png" alt="cover-image" /></p>

<h2 id="發現白做">發現白做</h2>

<p>這次開發的遊戲中，戰鬥事件的時機跟動畫有很大的關係，像是閃避時，在哪一段時間中是無敵的，或是攻擊時，什麼時候進行傷害判定等等。在開發初期時，因為動畫還沒開始製作，所以選擇先用秒數來表達這些事件的時機點，一開始也覺得這是很直覺的作法。而隨著戰鬥規格的發展，這套參數系統也越來越複雜，最近還花了兩個月把它整理一番。</p>

<p><img src="/assets/images/blog/2025/2025-08-28-seek-first-to-have-but-do-not-take-long-way-around/dash-config-using-timing.png" alt="dash-config-using-timing" />
<em>使用秒數來表達時機，指定在前幾秒的時間內，可以觸發</em></p>

<p>然而在開始套動畫之後，發覺這套以時間為主的參數系統完全無法使用。因為透過動畫趨動的事件是以開關為主，像是閃避無敵可以透過在動畫開頭開啟無敵狀態，接著在後面某個影格關閉來定義無敵的時間，或是攻擊的傷害判定時機，也可以在對應的影格上放置事件就好。</p>

<p><img src="/assets/images/blog/2025/2025-08-28-seek-first-to-have-but-do-not-take-long-way-around/dash-config-using-animation-clip.png" alt="dash-config-using-animation-clip.png" />
<em>使用動畫來控制變數來表達時機，在指定變數為 true 的時候，就是可以觸發的時候</em></p>

<p>這才意識到，既然已經知道戰鬥系統會跟動畫關聯，當初就應該以動畫為基礎去製作戰鬥系統，而不是先做一個之後用不到的暫代版本。因為到頭來，花在暫代版本的時間都會白費之外，還要重做一套全新的版本。如果有其它功能是基於暫代版本去做的話，還要一併修改，也得再確認一次這些功能有沒有 bug，所花的時間不會只有開發新版本的時間。</p>

<p><img src="/assets/images/blog/2025/2025-08-28-seek-first-to-have-but-do-not-take-long-way-around/time-spent.png" alt="time-spent" />
<em>除了開發新版本的時間，其餘都是白花的</em></p>

<h2 id="先求有但別繞路">先求有，但別繞路</h2>

<p>所以如果知道要做的功能未來會怎樣時，最好一開始就以此為方向來開發功能，還沒有所需資料或素材就用暫代的。像戰鬥系統就算還沒有動畫，可以先用幾何形狀拉簡單示意動作，如果不用幾何形狀，也可以先把動作的時長用兩個 keyframe 簡單表示就好。因為前期的重點是把戰鬥事件實作出來，先驗證這些事件在遊戲中如何運作比較好。等到可以套上動畫之後，就可以以此為基礎，去調整事件的功能。想想如果當初就這樣做的話，就可以少花這兩個月的時間了 :cry:。</p>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="開發日誌" /><summary type="html"><![CDATA[很常聽到在專案開發初期，做功能最好是「先求有，再求好」。在發覺做了兩個月的白工後，才體會到這句話的意思應該是「先求有，以此為基礎，再求好」，而不是「先求有，之後再做一個全新且更好的」。]]></summary></entry><entry><title type="html">[分享] 2025 TGDF 筆記 - 九日篇</title><link href="https://lankudot.airfishlab.com/blog/2025-08-2025-tgdf-notes-02-nine-sols/" rel="alternate" type="text/html" title="[分享] 2025 TGDF 筆記 - 九日篇" /><published>2025-08-18T00:00:00+08:00</published><updated>2025-08-18T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/2025-tgdf-notes-02-nine-sols</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-08-2025-tgdf-notes-02-nine-sols/"><![CDATA[<p>今年《九日》相關的議程也很多，從開案時期的探索，到如何設計讓玩家能享受的遊戲機制，遊戲的設計秘辛亳無保留地分享出來。</p>

<h2 id="兩年的噩夢找尋九日類隻狼系統的誕生">兩年的噩夢找尋，九日類隻狼系統的誕生</h2>

<p>這場分享《九日》是如何找到現在的類隻狼玩法，要找到突破點花了相當多的時間，其中的過程也很辛苦。</p>

<ul>
  <li>世界觀設定
    <ul>
      <li>「道龐克」</li>
      <li>一個太陽對九個太陽的復仇</li>
      <li>外星人來到地球留下了道教科技與故事</li>
    </ul>
  </li>
  <li>想到以動作加上銀河戰士的玩法
    <ul>
      <li>九個太陽所在的九個區域對應他們各自的設定</li>
    </ul>
  </li>
  <li>八個月就完成有基本玩法與畫面的「Hollow Cat」</li>
  <li>但為了避免 Hollow Knight 感花了一陣子，也打掉第一版，並重新思考機制
    <ul>
      <li>2D 版隻狼？但慢節奏、沒 Y 軸戰鬥、沒平台挑戰</li>
      <li>參考《Katana Zero》為了要快節奏，不加入對峙，也沒有體幹值</li>
      <li>想要有平台挑戰，加入空中格擋</li>
      <li>但如《Katana Zero》的快節奏，敵人看一兩次就被打倒，與隻狼要對招一兩次所帶來的深度不同</li>
    </ul>
  </li>
  <li>又回到類銀河的玩法上，但把體幹值改成點數制
    <ul>
      <li>要格擋才有氣能貼符</li>
      <li>為了避免等格擋時機而太被動，加入普攻來算節奏</li>
      <li>為了以格擋為主，普攻的攻擊力比貼符還要低很多</li>
      <li>避免一直按普攻，普攻三連擊的第三下無法直接進入格擋</li>
      <li>敵人被普攻打中後，會減攻擊 cd，讓敵人更容易主動攻擊，來讓玩家有機會格擋</li>
    </ul>
  </li>
  <li>加入潛行？
    <ul>
      <li>2D 畫面視野很小，而且角色動很快不適合潛行，而且每個敵人也要設計暗殺動畫</li>
      <li>最後改成「背襲」</li>
      <li>但關卡還是有潛行的設計，如被電之後行動不便，只能潛行</li>
    </ul>
  </li>
  <li>貼符的體驗
    <ul>
      <li>貼符到懸崖邊會自動停住，避免瞬移距離過長而掉落</li>
      <li>在地面貼符時，會先瞬步到敵人前再貼符，再繼續瞬步一段距離，但是在空中貼符則會直接貼</li>
    </ul>
  </li>
  <li>把技能樹當教學用
    <ul>
      <li>例如：點了背襲技能，知道可以背襲</li>
    </ul>
  </li>
  <li>大家對技能功效有不同的想像，有人想加有人不想，做成玉石系統來讓玩家自已選</li>
  <li>如何知道找到醬汁了？成功讓玩家想要一做再做</li>
</ul>

<h2 id="九日戰鬥設計雜談">《九日》戰鬥設計雜談</h2>

<p>這場一樣有分享到《九日》開案時的構想，並且著重在怪物行為的設計，以及攻擊模式的小技巧，讓戰鬥更豐富。</p>

<ul>
  <li>開案起源
    <ul>
      <li>《返校》跟《還願》還是以華語圈為主，新作方向能否打入歐美市場？</li>
      <li>以玩法為核心能否有文化穿透力？像《Dead Cells》跟《Hollow Knight》</li>
    </ul>
  </li>
  <li>參考《Hollow Knight》，但是不是只能做出劣化版的《Hollow Knight》</li>
  <li>風格找尋：<br />
<img src="/assets/images/blog/2025/2025-08-18-2025-tgdf-notes/nine-sols-style-coordinate.svg" alt="nine-sols-style-coordinate" />
    <ul>
      <li>當然在 2D 以格擋為主的風格下，還是有其它遊戲</li>
    </ul>
  </li>
  <li>以格擋為主，所以要引導玩家用格擋
    <ul>
      <li>普攻傷害低，貼符有大傷害 ← 要格擋才有氣能貼符</li>
    </ul>
  </li>
  <li>怪物製作流程，實際執行時沒有清楚細分步驟，但為了演講還是整理出大致統程
    <ol>
      <li>前期溝通：確定怪物定位，如：難度、外貌、參考對象</li>
      <li>灰盒驗證：設計戰鬥的 fantasy（要帶來什麼樣的感覺）
        <ul>
          <li>讓玩家要用什麼 pattern 來對應</li>
          <li>Boss 攻擊前的動作能不能讓玩家找到對招時機</li>
          <li>這時就會在 animation clip 上做怪物行為</li>
        </ul>
      </li>
      <li>美術原型：在 animation clip 上套皮，看感覺</li>
      <li>程式美術整合：在套皮後重調數值，再看感覺</li>
      <li>內部測試：內部回饋、改善</li>
      <li>後期：套音效、特效</li>
      <li>外測：玩家公開測試</li>
    </ol>
  </li>
  <li>在量產期會做前五個步驟，但是在打磨階段才會做後期與外測</li>
  <li>戰鬥難，讓玩家克服時有成就感，感覺「原來我可以做到」</li>
  <li>怪的攻擊有一定節奏，但是後期怪的攻擊脫離前面的節奏會帶來難度，也會有新奇感</li>
  <li>一些攻擊模式的技巧
    <ul>
      <li>利用位移來做攻擊前置動作，如：水鬼</li>
      <li>過身：攻擊時，怪物會穿過玩家到另一邊</li>
      <li>脫手攻擊：出招後，那招會延遲攻擊（如：緩慢的投射物），讓怪物可以再開其它招</li>
      <li>以預期讓玩家的輸入 pattern 來設計招式</li>
      <li>玩家一直按格擋會縮段精準格擋的窗口</li>
      <li>終結技可以輸出大傷害，作為獎勵
        <ul>
          <li>boss 打完一輪的休息窗口，讓玩家可以輸出大量傷害</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

<h2 id="為九日而研發的狀態機架構monofsm">為《九日》而研發的狀態機架構《MonoFSM》</h2>

<p>最近在開發上在煩惱角色狀態機的設計，所以這場也是有興趣的演講之一。演講主要圍繞在 MonoFSM 為什麼會誕生，雖然沒有著墨太多技術上的細節，但是在製作 prototype 時的經驗分享也很受用。</p>

<ul>
  <li>第一階段為了開發要快而硬 A，使出戰術龍捲風！
    <ul>
      <li>但當內容一多就開始 A 不動，程式碼耦合重、bug 不好修，而且很難加入新功能</li>
    </ul>
  </li>
  <li>遊戲開發架構金字塔由底層到塔頂依序為：
    <ul>
      <li>引擎：開發使用的遊戲引擎</li>
      <li>系統：為遊戲功能開發的功能</li>
      <li>資料：功能所需要的設定、數值、素材等</li>
      <li>設計：遊戲玩法、功能、行為等</li>
      <li>體驗：遊戲給玩家的殘體驗</li>
    </ul>
  </li>
  <li>而戰術龍捲風就是把系統、資料、設計全部混在一起做</li>
  <li>第二階段開始把資料抽離出來，利用 animation clip 來綁定動畫及開關元件或事件（絕對不要用 Event 來開關）
    <ul>
      <li>好處是可以在同一個地方編輯動畫及事件，也可以視覺化資料</li>
    </ul>
  </li>
  <li>到量產期後發現需要重新設計架構
    <ul>
      <li>參考 visual scripting 把邏輯跟系統分離</li>
      <li>要支援 prefab</li>
      <li>可以通用的 FSM 設計</li>
    </ul>
  </li>
  <li>用 MonoBehaviour 來描述狀態與狀態轉換，且基於 prefab 的 MonoFSM 誕生了
    <ul>
      <li>在 Hierarchy 顯示 FSM 的狀態及相關變數的數值</li>
      <li>Per-instance Debugging：可以以 GameObject 為單位來 debug，不用在程式碼中寫 debug 訊息</li>
    </ul>
  </li>
  <li>漸近重構
    <ul>
      <li>實驗期：在小地方嘗試，先展現價值</li>
      <li>推動期：新內容用新規格作。舊的東西有 bug 或想調整太難做的話，也替換成新架構</li>
      <li>能動的東西就不要改!</li>
    </ul>
  </li>
  <li>團隊應該集中在「遊戲體驗」上，作工具就是為了加速迭代</li>
</ul>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="分享" /><summary type="html"><![CDATA[今年《九日》相關的議程也很多，從開案時期的探索，到如何設計讓玩家能享受的遊戲機制，遊戲的設計秘辛亳無保留地分享出來。]]></summary></entry><entry><title type="html">[分享] 2025 TGDF 筆記 - 遊戲設計篇</title><link href="https://lankudot.airfishlab.com/blog/2025-08-2025-tgdf-notes-03-game-design/" rel="alternate" type="text/html" title="[分享] 2025 TGDF 筆記 - 遊戲設計篇" /><published>2025-08-18T00:00:00+08:00</published><updated>2025-08-18T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/2025-tgdf-notes-03-game-design</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-08-2025-tgdf-notes-03-game-design/"><![CDATA[<p>這篇包含了三場演講，侍達遊戲的戰鬥設計主管分享如何設計戰鬥，而《Patrick’s Parabox》則分享開發過程與如何設計解謎遊戲，最後是 Ferran 分享音樂遊戲不只有節奏遊戲，還有更多可以探索的方向。</p>

<h2 id="當敵人先出剪刀淺談戰鬥關卡設計的四個層級與選擇引導">當敵人先出剪刀：淺談戰鬥關卡設計的四個層級與選擇引導</h2>

<p>侍達遊戲的戰鬥設計部主管帶來的這場演講，介紹如何設計遊戲中的戰鬥，讓玩家有跡可遁而能做出對應的策略。</p>

<ul>
  <li>什麼是戰鬥設計？
    <ul>
      <li>戰鬥是什麼？是勝負，像是擊敗敵人、審判攻防，甚至克服地形也可以是戰鬥</li>
      <li>設計是什麼？有資訊讓玩家判斷如何贏，以及有對錯，玩家有輸的風險，答對則讓玩家有成就感</li>
    </ul>
  </li>
  <li>以剪刀石頭布為例：
    <ul>
      <li>1/3 隨機出拳 → 玩家不知道如何對應，不是設計</li>
      <li>看到敵人要出剪刀 → 玩家可以選擇出石頭，是設計</li>
      <li>看到敵人要出剪刀，但敵人很狡猾 → 玩家可以改出剪刀，是設計</li>
    </ul>
  </li>
  <li>所以戰鬥設計是：有勝負、有資訊（判斷他要做什麼）、有對錯（知道什麼選擇是對的）</li>
  <li>戰鬥設計的四個層級
    <ul>
      <li>設計什麼：想像力是你的超能力
        <ul>
          <li>把非戰鬥情境變成戰鬥情境</li>
          <li>選定戰鬥主題，例如：「按摩」</li>
        </ul>
      </li>
      <li>如何設計：如何表現「按摩」的戰鬥
        <ul>
          <li>按摩要合適的力道 → 傷害要恰當 → 每回合的傷害控制</li>
        </ul>
      </li>
      <li>玩法打磨：以提問建構內容
        <ul>
          <li>如何判斷按摩力道？傷害區間</li>
          <li>玩家如何知道要控制力道？敵人說教，傷害太高 → 按太大力 → 「太痛了吧！」</li>
          <li>玩家如何知道具體區間？包裝成管家指南，指示傷害值對應的力道</li>
          <li>被按摩者會攻擊嗎？不會，現實中被按摩的人也不會打按摩師</li>
          <li>但確立核心要避免機械解法，要避免讓玩家一直以 10% 傷害攻擊
            <ul>
              <li>要讓核心有變化</li>
              <li>代入現實體驗，痠的地方要按的力一點</li>
              <li>再發展成機制，加入傷害 buff，所以傷害要高一點</li>
            </ul>
          </li>
          <li>答對能對敵人造成傷害，但答錯要如何懲罰？
            <ul>
              <li>錯三次才會失敗，但是有漏洞</li>
              <li>玩家可以打兩次大傷害，再打一個成功的傷害 → 修正：打太大力直接失敗</li>
              <li>打太小，慢慢打完 → 回合限制及每回合回血</li>
            </ul>
          </li>
          <li>強制完家每次都要控傷害</li>
        </ul>
      </li>
      <li>驗證 × 觀察 × 修正
        <ul>
          <li>正向測試：以預期方式去測，看有無符合預期</li>
          <li>反向測試：以預期外方式去測，看要不要修漏洞</li>
          <li>觀察：體驗不如預期時，先記錄感受，不要提示及反駁</li>
          <li>分析修正：整理問題，思考原因，並改善</li>
        </ul>
      </li>
    </ul>
  </li>
  <li>玩家體驗是準則，如果不符預期，就要改變設計</li>
</ul>

<h2 id="patricks-parabox的解謎設計挑戰">《Patrick’s Parabox》的解謎設計挑戰</h2>

<p>《Patrick’s Parabox》是一款以遞迴為主題的解謎遊戲，講者 Patrick Traynor 分享開發過程中遇到的困難，以及如何精煉關卡，讓玩家在解題過程中能一直得到新鮮感。</p>

<!-- Courtesy of embedresponsively.com -->

<div class="responsive-video-container">
    <iframe src="https://www.youtube-nocookie.com/embed/HAvS-RwkjdA" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe>
  </div>

<ul>
  <li>動機：我有個很酷的系統想秀給朋友看，及玩家想看酷系統如何發揮</li>
  <li>核心系統：遞迴與自我參照</li>
  <li>花了四年的時間迭代遊戲玩法
    <ul>
      <li>一開始是兩人的倉庫番解謎，但兩人玩家在不同的尺度下運作</li>
      <li>變成三人的倉庫番解謎，且尺度更多層</li>
      <li>改成單人，而且玩家自己可以穿越不同的尺度</li>
      <li>不同的尺度間都有個自己，而且尺度空間是一樣的（就像俄羅斯娃娃），只要移動，不同尺度的自己都會移動</li>
    </ul>
  </li>
  <li>如果觸發悖論要怎麼辦？
    <ul>
      <li>直接設計一個悖論發生場景，而且不能再回原來的場景</li>
      <li>等同於跟玩家說你贏了！比起不能發生還要更好</li>
      <li>而且還可以用悖論做為機制來設計新關卡</li>
    </ul>
  </li>
  <li>背景音樂符合關卡的調性，音效也很重要</li>
  <li>關卡設計
    <ul>
      <li>玩家是來玩機制的！</li>
      <li>專注在機制上，<strong>簡單</strong>，不混合大量不同機制，也不堆疊謎題難度
        <ul>
          <li>玩家是來玩遞迴的謎題，而不是很難走出去的迷宮</li>
          <li>設計者覺得很棒，但是困難的關卡可以放在支線關卡中，讓玩家可跳過，想挑戰的人可以去玩</li>
        </ul>
      </li>
    </ul>
  </li>
  <li>在新機制出現時，先放直覺的教學關來教玩家機制，才放真的想讓玩家玩的關卡及支線關卡</li>
  <li>刪除不好的關卡也很重要！
    <ul>
      <li>遊戲中一共有 364 個關卡，但也有 600 多個沒用上的關卡</li>
      <li>持續試錯，找到最好的謎題</li>
    </ul>
  </li>
  <li>幫助思考的法則
    <ul>
      <li>夠自然嗎？</li>
      <li>要多少關卡才有樂趣？</li>
      <li>做關卡簡單嗎？</li>
      <li>夠豐富嗎？能做越少得越多嗎？</li>
    </ul>
  </li>
</ul>

<h2 id="玩音樂節奏遊戲之外的更多可能">玩音樂：節奏遊戲之外的更多可能</h2>

<p>這場演講是線上日的議程之一（<a href="https://www.twitch.tv/videos/2511224346?t=03h53m14s">Twitch 連結</a>），身為一名節奏遊戲的愛好者，所以也對這場演講很有興趣。講者 Ferran 擁有豐富的音樂遊戲開發經驗，對這類遊戲的研究也很有經驗，分享音樂遊戲不只有節奏遊戲，還有更多的探索方向。</p>

<ul>
  <li>雖然電玩的英文是「Video Game」，但音樂也一直存在在電玩遊戲之中</li>
  <li>聲音場景（Soundscape）：背景音樂 + 音效</li>
  <li>音樂遊戲一開始想到的就是「節奏遊戲」
    <ul>
      <li>在正確的時間按下正確的按鍵</li>
      <li>再來有下落式，甚至跳脫按鍵，以觸控為主</li>
      <li>除了手指之外，這有全身舞動的玩法</li>
      <li>後來發展越來展多元，將節奏遊戲與不同遊戲類型結合，像結合彈幕的《Just Shape &amp; Beats》、結合策略的《Patapon》</li>
      <li>甚至強調格檔的動作遊戲也可以是節奏遊戲，如《九日》</li>
    </ul>
  </li>
  <li>節奏遊戲可以算是動作遊戲的一類，是即時的、需要配合時機</li>
  <li>但音樂不只有「節奏」，音樂遊戲不是只有節奏遊戲，如《Ape Out》猩猩角色的動作會影響音樂的組成</li>
  <li>而且音樂也不只是「背景」，如：瑪利歐 wii 版，敵人會隨音樂反應，是世界的一部份</li>
  <li>不止節奏
    <ul>
      <li>用玩具形式「創作」出一首音樂，如《ODDADA》、《Poly-60》</li>
      <li>探索弦律線
        <ul>
          <li>玩家可以自由創造弦律，而遊戲會配合弦律演奏，如《Wii Music》的 Instrument Improv 模式</li>
          <li>非同步錄製，玩家只能演奏一個樂器，然後跟其它人合，如《10 Second Mixtape》</li>
        </ul>
      </li>
      <li>探索和聲，在基礎弦律上找出正確和聲，如《Blob Opera》、《Pianobots》</li>
      <li>探索歌詞，即時選擇歌詞，遊戲隨選擇演唱，如《Kentucky Route Zero》的第三幕、《Evergreen Blues》</li>
      <li>互動式音樂專輯，每首歌是一個互動小遊戲，如《Off-Score: A game of songs》</li>
    </ul>
  </li>
  <li>遊戲是互動媒體，讓玩家可以玩你的音樂，而且音樂不只有節奏</li>
  <li>如果遊戲中有音樂的話
    <ul>
      <li>越早加入越好（包含音效），讓音樂能激發靈感，也可以讓早期遊戲像個遊戲</li>
      <li>讓遊戲會對音樂互動</li>
    </ul>
  </li>
</ul>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="分享" /><summary type="html"><![CDATA[這篇包含了三場演講，侍達遊戲的戰鬥設計主管分享如何設計戰鬥，而《Patrick’s Parabox》則分享開發過程與如何設計解謎遊戲，最後是 Ferran 分享音樂遊戲不只有節奏遊戲，還有更多可以探索的方向。]]></summary></entry><entry><title type="html">[分享] 2025 TGDF 筆記 - CDPR 篇</title><link href="https://lankudot.airfishlab.com/blog/2025-08-2025-tgdf-notes-01-cdpr/" rel="alternate" type="text/html" title="[分享] 2025 TGDF 筆記 - CDPR 篇" /><published>2025-08-18T00:00:00+08:00</published><updated>2025-08-18T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/2025-tgdf-notes-01-cdpr</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-08-2025-tgdf-notes-01-cdpr/"><![CDATA[<p>今年是第三次參加 TGDF，經過兩天的英聽訓練後，才發覺自己的英聽能力一點也沒進步，低頭做完筆記後，就完全跟不上臺上講者的進度了。話雖如此，這次的 TGDF 還是收獲良多，從遊戲設計到專案管理的分享都有，對於正在參與開發的遊戲也有很大的幫助。這次的筆記就整理成 CDPR、九日、遊戲設計三篇文章。</p>

<p><img src="/assets/images/blog/2025/2025-08-18-2025-tgdf-notes/pass.png" alt="參加證" /></p>

<h2 id="電馭叛客-2077解碼電影動畫的祕密">《電馭叛客 2077》：解碼電影動畫的祕密</h2>

<p>這場演講是 CDPR 帶來的兩場演講之一。首席電影動畫師 David Cordero Iglesias 介紹在《電馭叛客 2077》中，如何讓 NPC 更生動自然，以及更真實的第一人稱敘事運鏡，讓玩家更有沉浸感。</p>

<h3 id="模擬現實互動">模擬現實互動</h3>

<ul>
  <li>減少黑幕切換
    <ul>
      <li>NPC 在場景中會自然對話，直到玩家進來互動後，會自然結束跟其它 NPC 的對話，並轉頭過來開始跟玩家的劇情對話</li>
      <li>利用牆面設置位置來避免玩家看到 NPC 重置的不連續感。例如：在一個追逐從後門逃跑的 NPC 的劇情中，玩家可以選擇追上去，或是從前門繞路追上他，而 NPC 一定會在暗巷中被夥伴給攔住。利用牆面的 90 度轉角，讓玩家走過牆面後，才會看到事件發生。</li>
      <li>但遊戲中還是會為了玩家昏厥或是醒來的情境使用黑幕</li>
    </ul>
  </li>
  <li>玩家控制角色的能力可以分成四個層級，增強敘事能力
    <ul>
      <li>第一階：玩家可以自由控制角色</li>
      <li>第二階：部份控制被限制。例如：搬重物時，移動速度變慢</li>
      <li>第三階：只能移動視角，而且角度有限制。例如：被壓制在地上時</li>
      <li>第四階：劇情控制，玩家完全無法操作</li>
    </ul>
  </li>
  <li>NPC 自然動作
    <ul>
      <li>NPC 的動作反應這個 NPC 的個性</li>
      <li>NPC 在等待玩家回答時，會繼續做手邊正在做的事情，例如：吃一口飯、繼續看雜誌，而不會呆呆看著你</li>
    </ul>
  </li>
  <li>敘事運鏡要視野清晰
    <ul>
      <li>要避免 3D 暈，可以找會 3D 暈的同事來測試 :D</li>
      <li>利用 Framing（決定什麼內容要出現在畫面中） 與 Composition（排列在畫面中的這些內容），讓玩家快速理解目前正在發生的事情。例如：在跑酷劇情下，讓手腳一部份出現在畫面中，提示動作的來源，並用攝影機的位移來呈現慣性</li>
    </ul>
  </li>
  <li>身體意識
    <ul>
      <li>玩家坐定後，仍然可以自由移動視角，模擬現實談話人會亂看</li>
      <li>在劇情拿槍時，攝影機會照向拿槍的手，模擬現實的視線移動</li>
      <li>被 NPC 拉著走時，無法控制位移或是視角</li>
    </ul>
  </li>
  <li>環境意識
    <ul>
      <li>角色會自然看向環境中可以互動的物件</li>
      <li>在場景中也要標記這些可互動的物件，及如何互動</li>
    </ul>
  </li>
  <li>手指細節
    <ul>
      <li>真實的手指反應，例如：把完拿取的物件，或是彈吉它時的手指行為</li>
      <li>有一整個手指資料庫</li>
    </ul>
  </li>
</ul>

<h3 id="動畫技術">動畫技術</h3>

<ul>
  <li>動捕很重要
    <ul>
      <li>自然真實的動畫源自現實的動作</li>
      <li>即使是第一人稱視角遊戲，還是會錄玩家角色的動作</li>
    </ul>
  </li>
  <li>還是有 key frame 動畫
    <ul>
      <li>機具行為，車輛的互動</li>
      <li>整理動捕資料</li>
    </ul>
  </li>
  <li>提供跨軟體平台的整合資料庫
    <ul>
      <li>動畫師可以自由選擇製作的動畫軟體</li>
    </ul>
  </li>
  <li>動畫類型可以分成待機動作（Idle Animation）與象徵動作（Gesture Animation）
    <ul>
      <li>以抽煙來說，待機動作是拿著煙，而象徵動作則可以是吸一口煙或是丟煙等動作</li>
      <li>動作之間也會設定轉換（Transition）</li>
      <li>也有完全設定好的客制動畫，例如：彈吉他、劇情用動畫</li>
      <li>在《電馭叛客 2077》中有七千多個待機動作，三萬五千多個象徵作，以及更多的動畫轉換</li>
    </ul>
  </li>
  <li>有內部工具來管理與編輯動畫的轉換
    <ul>
      <li>角色的動畫為 workspot，編輯工具可以設置轉換條件與觸發來效果</li>
      <li>workspot 之間的互動也可以編輯，例如：兩個 NPC 在聊天時的動作</li>
      <li>在開放世界中，讓 workspot 自行決定要做的事情，讓玩家經過同一個地方時，NPC 的行為也會不一樣</li>
      <li>在劇情場景中，workspot 可以在玩家回答前，自由播放待機動畫，使 NPC 更自然</li>
    </ul>
  </li>
  <li>臉部動畫也有對應的待機動作及象徵動作
    <ul>
      <li>對於有真實演員的 NPC，也會把臉部變化（如皺紋）key frame 進去</li>
    </ul>
  </li>
  <li>嘴型會隨輸入聲音變化，不同語言的語音會呈現不同嘴型</li>
</ul>

<h3 id="劇情動畫製作流程">劇情動畫製作流程</h3>

<ol>
  <li>分鏡：簡單場景設置與運鏡來驗證劇情動畫的觸發流程</li>
  <li>動捕：分段拍攝劇情所需的動畫</li>
  <li>Alpha：直接把動捕資料套入場景中並加入運鏡</li>
  <li>Beta：消除鏡頭過度晃動，套入 IK 並跟場景物件互動</li>
  <li>加入失敗動畫，如 QTE 失敗後的結果</li>
</ol>

<h2 id="解鎖隱藏價值cdpr-式最終產品背後的-ux">解鎖隱藏價值：CDPR 式「最終產品背後的 UX」</h2>

<p>CDPR 的第二場演講則是以內部工具的 UX 體驗為主題，資深 UX/UI 設計師 Anna Nojek 認為，有好的內部開發工具，能讓開發人員能有好的開發體驗，進而能開發出好的遊戲。</p>

<h3 id="好的開發環境造就好的遊戲體驗">好的開發環境造就好的遊戲體驗</h3>

<ul>
  <li>讓玩家能享受遊戲的要素很多，像是故事、玩法、挑戰性等，但對開發者來說讓玩家能享受遊戲的要素是來自好的開發體驗。以開發體驗為優先，能讓開發者發揮能力，最後做出好的遊戲體驗。</li>
  <li>以往開發環境的問題
    <ul>
      <li>資源及知識過於分散：asset 散佈在不同平台且不同格式，要找一個 asset 很困難</li>
      <li>資訊透明度差：大家各自做各自的</li>
      <li>客制的開發流程：鎖碎及複雜的開發流程，甚至佔了開發 50% 的時間</li>
      <li>過度依賴其它人：如果一個人卡住了，其它人也不能做事</li>
      <li>只專注在功能：開發工具的人不熟使用者的習慣，只專注在實作功能上，讓工具不好使用</li>
    </ul>
  </li>
  <li>當開發者面臨的問題沒有解決的話，會感到挫折，讓作品延期、容易出 bug，甚至感到心累，最後產出不好玩的遊戲</li>
</ul>

<h3 id="了解問題">了解問題</h3>

<ul>
  <li>製作工具先暫時處理問題，再改善解法
    <ul>
      <li>情境：企劃要找一個素材得要問一堆人才找的到</li>
      <li>暫時解法：開一個共用的 excel 表單，請製作人員匯出素材時，去更新表單的狀態</li>
      <li>長期解法：製作人員匯出素材後，自動更新資料庫</li>
      <li>暫時解法得由人工操作，但可以暫時解決企劃要依賴他人的問題。而長期解法則是自動化，是改善後的解法，一樣解決依賴問題，也讓製作人員不用手動更新</li>
      <li>會先有暫時解法，等待時機成熟後，再實作長期解法</li>
    </ul>
  </li>
  <li>開發出內部用的素材管理工具：Asset Hive
    <ul>
      <li>支援集中管理，能搜尋、複用、預覽素材的工具</li>
    </ul>
  </li>
  <li>工具是提供問題的解法，但如果不了解問題，則作出工具也不能解決
    <ul>
      <li>要去了解、觀察、討論才能知道真正的問題所在</li>
      <li>也不要只追隨請求，而是問為何需要這個請求</li>
      <li>當有人傾聽別人的請求時，別人也會更有動力，且更積極</li>
    </ul>
  </li>
  <li>作出好的工具讓開發人員能專注在創造工作，改善遊戲成品。透過使用體驗回報，也能培養反饋與支援的氛圍</li>
</ul>

<h3 id="工具與-ux">工具與 UX</h3>

<ul>
  <li>UX 是為了簡化執行某個特別任務的手段</li>
  <li>UX 開發流程，每個階段都有機會退回上個階段
    <ol>
      <li>有人提出問題</li>
      <li>討論、分析、面談問題</li>
      <li>設計工具需要的功能有什麼</li>
      <li>測試</li>
      <li>設計介面</li>
      <li>測試</li>
      <li>交由工程人員開發功能</li>
      <li>測試</li>
    </ol>
  </li>
  <li>以使用者為中心的溝通
    <ul>
      <li>同理心地圖（Empathy Map）：展示使用者在使用工具時的想法、行為、言論、感受</li>
      <li>使用者體驗地圖（User Journey Map）：展示使用者在使用工具達成任務時的使用流程，並標示每個階段的情緒、優缺點，以及如何改善</li>
    </ul>
  </li>
  <li>省下來的時間 = 原本所需要的時間 - 改善後的時間 - 開發工具所需要的時間</li>
  <li>UX 與所有人相關
    <ul>
      <li>團隊的製程：製程的架構流程</li>
      <li>明確的目標：什麼樣的目標才算成功/完成</li>
      <li>透明度與反饋回圈：工具一定是持續迭代的過程</li>
    </ul>
  </li>
  <li>回到一開始的問題：是什麼要素讓玩家能享受遊戲? 所有創作遊戲的人</li>
</ul>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="分享" /><summary type="html"><![CDATA[今年是第三次參加 TGDF，經過兩天的英聽訓練後，才發覺自己的英聽能力一點也沒進步，低頭做完筆記後，就完全跟不上臺上講者的進度了。話雖如此，這次的 TGDF 還是收獲良多，從遊戲設計到專案管理的分享都有，對於正在參與開發的遊戲也有很大的幫助。這次的筆記就整理成 CDPR、九日、遊戲設計三篇文章。]]></summary></entry><entry><title type="html">[開發日誌 #2] A 需要跑步但 B 只要走路</title><link href="https://lankudot.airfishlab.com/blog/2025-06-refactor-general-module/" rel="alternate" type="text/html" title="[開發日誌 #2] A 需要跑步但 B 只要走路" /><published>2025-06-04T00:00:00+08:00</published><updated>2025-06-04T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/refactor-general-module</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-06-refactor-general-module/"><![CDATA[<p>在這次開發的遊戲中，角色有不同的移動方式，像是玩家角色會以方向做為移動輸入，而敵人角色則是以路徑做為移動目標，而這兩者又有以距離為主的移動方式，如：瞬步、攻擊墊步。所以一開始做了通用的移動模組來整合這些方式，讓所有角色使用。但隨著敵人角色的移動方式增加，為了讓模組能保持「通用」，部份功能只能做在模組之外，造成移動方式無法集中管理。最後受不了重新設計移動模組一番，讓模組能夠為不同的角色提供各自需要的功能，又可以保持增加移動方式的彈性。</p>

<h2 id="通用模組的問題">通用模組的問題</h2>

<p>一開始通用模組設計如下圖：</p>

<p><img src="/assets/images/blog/2025/2025-06-04-refactor-general-module/original-design-uml.svg" alt="original-design-uml" /></p>

<ul>
  <li>通用移動模組 <code class="language-plaintext highlighter-rouge">CharacterMovementModule</code> 中提供不同的移動方式的子模組：
    <ul>
      <li>靜止的 <code class="language-plaintext highlighter-rouge">IdleMovement</code></li>
      <li>以速度向量為主的 <code class="language-plaintext highlighter-rouge">VelocityMovement</code></li>
      <li>以距離為主的 <code class="language-plaintext highlighter-rouge">DashMovement</code></li>
      <li>以路徑為主的 <code class="language-plaintext highlighter-rouge">PathMovement</code></li>
    </ul>
  </li>
  <li>移動模組同時只會有一個子模組在執行，當子模組執行結束後（如：移動路徑走完了），會自動轉到 <code class="language-plaintext highlighter-rouge">IdleMovement</code></li>
  <li>尋路用的模組 <code class="language-plaintext highlighter-rouge">PathFindingModule</code></li>
</ul>

<h3 id="提供用不到的功能">提供用不到的功能</h3>

<p>這是遊戲中各類角色需要的移動功能：</p>

<table>
  <thead>
    <tr>
      <th>移動方式</th>
      <th>玩家角色</th>
      <th>敵人角色</th>
      <th>NPC</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>靜止</td>
      <td>:heavy_check_mark:</td>
      <td>:heavy_check_mark:</td>
      <td>:heavy_check_mark:</td>
    </tr>
    <tr>
      <td>速度向量</td>
      <td>:heavy_check_mark:</td>
      <td>:x:</td>
      <td>:x:</td>
    </tr>
    <tr>
      <td>距離</td>
      <td>:heavy_check_mark:</td>
      <td>:heavy_check_mark:</td>
      <td>:x:</td>
    </tr>
    <tr>
      <td>路徑</td>
      <td>:heavy_check_mark:（路徑更新一次）</td>
      <td>:heavy_check_mark:（路徑定期更新）</td>
      <td>:heavy_check_mark:（一次跟定期更新都要）</td>
    </tr>
  </tbody>
</table>

<p>設計成通用模組的問題是，使用的角色會有用不到的功能。敵人角色用不到速度向量的移動功能，而 NPC 一樣用不到速度向量的移動功能之外，也用不到距離為主的移動功能。</p>

<h3 id="不易擴充">不易擴充</h3>

<p>另外從上面的表可以看到，以路徑移動的形式有兩種：只要更新一次路徑（移動到指定位置）跟定期更新路徑（持續追隨）。為了讓移動模組能「通用」，所以只提供傳入路徑再移動的功能。這時玩家角色需要實作讓尋路模組來找路徑後傳入移動模組的功能，而敵人角色則需要實作定期更新路徑的功能，然而 NPC 卻兩種形式都要，所以就得要再各實作一次一樣的功能。雖然可以把這兩種路徑移動形式連同尋路模組一起整合到移動模組內，但這樣移動模組就會相依於尋路模組，而且爾後有需要其它模組的移動方式的話，都會讓移動模組相依更多模組。如果有新的角色是不需要路徑移動方式的話，為了移動模組還要再生成尋路模組就顯得多餘了。</p>

<p><img src="/assets/images/blog/2025/2025-06-04-refactor-general-module/original-design-coupling.svg" alt="original-design-coupling" />
<em>讓模組相依於其它模組的問題是無論用不用的到對應的模組，都得要生成依賴的模組</em></p>

<h2 id="重構版本">重構版本</h2>

<p>這是重構後的版本：</p>

<p><img src="/assets/images/blog/2025/2025-06-04-refactor-general-module/refactor-design-player-uml.svg" alt="refactor-design-player-uml" /></p>

<ul>
  <li>移動方式各自獨立成外部子模組，繼承自 <code class="language-plaintext highlighter-rouge">IMovement</code>，並自行提供所需要的建構子與初始化函式</li>
  <li><code class="language-plaintext highlighter-rouge">CharacterMovementModule</code> 只保留移動方式切換的功能，透過 <code class="language-plaintext highlighter-rouge">IMovment</code> 介面存取移動方式子模組</li>
  <li>角色需要實作自己所需的移動模組，像玩家要實作 <code class="language-plaintext highlighter-rouge">PlayerMovementModule</code>，在裡面建立與初始化所需的移動方式子模組，並註冊給 <code class="language-plaintext highlighter-rouge">CharacterMovementModule</code> 管理</li>
  <li>角色自己的移動模組也會存建立的移動方式子模組，在需要切換移動方式時，先設置好參數，再切換移動方式</li>
</ul>

<p>如此一來，通用移動模組就不用依賴其它模組了，而是由角色自己的移動模組傳入需要的模組。另外移動方式獨立成子模組後，就可以像積木一樣，由角色自己的移動模組拼出所需要的移動功能。如敵人與 NPC 的移動模組會像這樣：</p>

<p><img src="/assets/images/blog/2025/2025-06-04-refactor-general-module/refactor-design-enemy-uml.svg" alt="refactor-design-enemy-uml" />
<img src="/assets/images/blog/2025/2025-06-04-refactor-general-module/refactor-design-npc-uml.svg" alt="refactor-design-npc-uml" /></p>

<p>另外兩種不同的路徑移動方式也分成路徑走一次的 <code class="language-plaintext highlighter-rouge">PathMovement</code> 與路徑定期更新的 <code class="language-plaintext highlighter-rouge">FollowMovement</code>，而這兩個移動方式的共同邏輯則是取出做成一個 <code class="language-plaintext highlighter-rouge">PathHelper</code> 來幫助執行路徑移動。</p>

<h2 id="總結">總結</h2>

<p>使用情境差不多的話，做成通用模組是合適的方法，而且一開始規格還不明確的時候，太早設計成這樣也可能殺雞用牛刀。但當出現一些清況，就得要開始思考這樣做適不適合了，像是：</p>

<ul>
  <li>有部份功能只是為了某些使用者存在</li>
  <li>模組是不是開始相依其它模組的功能</li>
  <li>每次加入新功能時，模組邏輯是否得要大幅修改</li>
  <li>為了配合新功能，其它使用者是否也要改變使用方式</li>
</ul>

<p>如果有這樣的情況就得要考慮重構了。</p>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="開發日誌" /><summary type="html"><![CDATA[在這次開發的遊戲中，角色有不同的移動方式，像是玩家角色會以方向做為移動輸入，而敵人角色則是以路徑做為移動目標，而這兩者又有以距離為主的移動方式，如：瞬步、攻擊墊步。所以一開始做了通用的移動模組來整合這些方式，讓所有角色使用。但隨著敵人角色的移動方式增加，為了讓模組能保持「通用」，部份功能只能做在模組之外，造成移動方式無法集中管理。最後受不了重新設計移動模組一番，讓模組能夠為不同的角色提供各自需要的功能，又可以保持增加移動方式的彈性。]]></summary></entry><entry><title type="html">[開發日誌 #1] 狀態機奮鬥記</title><link href="https://lankudot.airfishlab.com/blog/2025-05-fight-with-state-machine/" rel="alternate" type="text/html" title="[開發日誌 #1] 狀態機奮鬥記" /><published>2025-05-08T00:00:00+08:00</published><updated>2025-05-08T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/fight-with-state-machine</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-05-fight-with-state-machine/"><![CDATA[<p>時光荏苒，參與新專案到現在也超過半年了。因為是第一次做動作遊戲，面對沒開發過的機制，看了許多資料，也踩了不少的坑，就覺得應該來寫個開發日誌，多少記錄一下開發過程的酸甜苦辣鹹。開張第一篇先來分享開發狀態機時的碰壁。</p>

<blockquote>
  <p>成功的經驗很棒，但失敗的經驗也值得參考啊</p>
</blockquote>

<p>在新專案之前，沒想到都沒有開發過狀態機，就算有需要狀態的地方，也因為是線性流程，所以不需要用狀態機。但在動作遊戲中，狀態機是遊戲的核心，角色要狀態機，關卡流程也要狀態機，然後狀態機裡面也可能要有自己的狀態機。</p>

<h2 id="狀態轉換機">狀態（轉換）機</h2>

<p>雖然知道通常會在狀態機中執行角色的行為，但是一開始功能單純，就設計成讓狀態機專責處理狀態轉換的判斷，而狀態的執行還是在角色中：</p>

<p><img src="/assets/images/blog/2025/2025-05-08-fight-with-state-machine/bad-state-machine.svg" alt="bad-state-machine" /></p>

<p>角色會提供角色狀態（status）給狀態機判斷，狀態機中對每個狀態（state）提供不同的判斷函式，在角色中則是提供不同的執行函式。當狀態機判斷要切換狀態後，會通知角色也切換執行函式，角色執行函式就會更新角色狀態。</p>

<p>但當狀態開始變多與功能變複雜時，這樣的設計出現了兩個問題。第一個問題是因為狀態（state）要用到的狀態（status）都是由角色提供與更新，所以就算那個變數只是為了給某個狀態使用（像是控制一個狀態執行多久的計時器），也要宣告在角色上，造成那個變數有機會被其它狀態更新到：</p>

<p><img src="/assets/images/blog/2025/2025-05-08-fight-with-state-machine/bad-state-machine-variable-problem.svg" alt="bad-state-machine-variable-problem" /></p>

<p>另外這些類變數一多起來，管理上也不方便。</p>

<p>第二個問題是如果狀態中要額外做其它事會變得相當麻煩。由於判斷都是交由狀態機執行，所以狀態機判斷要做額外的事情時（像是在攻擊狀態中被打時，不轉換成硬直狀態，而是只改變一點位移），得要另外傳資料出來，因為原本狀態機回傳的資料是告知狀態轉換的資訊：</p>

<p><img src="/assets/images/blog/2025/2025-05-08-fight-with-state-machine/bad-state-machine-sub-operation-problem.svg" alt="bad-state-machine-sub-operation-problem" /></p>

<p>再者，用來傳遞額外資訊的物件，可能會因為每個狀態需要做不同的額外事情，而讓變數越來越多，出現與第一個問題同樣的情況。</p>

<h2 id="繞了遠路">繞了遠路</h2>

<p>為了解決這個有問題的狀態機，就開始想：</p>

<ul>
  <li>為什麼不讓狀態判斷函式變成類別，讓它自己管理需要的變數就好？</li>
  <li>為什麼不讓狀態執行函式自己判斷需要額外做的事情就好？</li>
</ul>

<p>然後就想到：<strong>為什麼不直接把狀態自己的判斷跟執行函式都放在同一個類別就好？</strong></p>

<p>唉呀，繞了一圈，結果還是做最典型的狀態機就好了啊：</p>

<p><img src="/assets/images/blog/2025/2025-05-08-fight-with-state-machine/state-machine-redesign.svg" alt="state-machine-redesign" /></p>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="開發日誌" /><summary type="html"><![CDATA[時光荏苒，參與新專案到現在也超過半年了。因為是第一次做動作遊戲，面對沒開發過的機制，看了許多資料，也踩了不少的坑，就覺得應該來寫個開發日誌，多少記錄一下開發過程的酸甜苦辣鹹。開張第一篇先來分享開發狀態機時的碰壁。]]></summary></entry><entry><title type="html">[遊記] 2025 F1 日本大獎賽 - 行程準備</title><link href="https://lankudot.airfishlab.com/blog/2025-05-f1-japan-grand-prix-trip-planning/" rel="alternate" type="text/html" title="[遊記] 2025 F1 日本大獎賽 - 行程準備" /><published>2025-05-03T00:00:00+08:00</published><updated>2025-05-03T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/f1-japan-grand-prix-trip-planning</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-05-f1-japan-grand-prix-trip-planning/"><![CDATA[<p>自 2020 年入坑以來，看 F1 也進入第 6 年了。大概從前年萌生到現場看比賽的念頭，也看了一些現場觀賽的分享文後，毅然決然選定了今年的日本大獎賽。選擇日本場的原因除了日本旅遊環境友善之外，比賽舉辦的時間剛好落在清明連假，賽道當地的鈴鹿與鄰近的名古屋也是櫻花季的時期，因此這趟現地之旅就成行了。受惠於前人的分享文，所以這篇文章也來分享如何規劃行程。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/suzuka-circuit-gp-entrance.png" alt="suzuka-circuit-gp-entrance" /></p>

<h2 id="門票">門票</h2>

<p>通常在比賽舉辦日的半年前開始售票，像今年日本大獎賽辦在 4 月初，去年 10 月中開放購票。所以在去年公布今年的賽曆之後，就開始關注售票的資訊了。購買 F1 日本大獎賽門票的管道有兩個：<a href="https://tickets.formula1.com/en" target="_blank">F1 官網</a>與賽道方使用的 <a href="https://ticket.mobilitystation.jp/" target="_blank">Mobility Station</a>，雖然 F1 官網會比賽道方還要早開放售票，但是只能選區域不能選座位，而且價格也貴上許多。而賽道官網則是有限制可以購買的國家，但今年台灣可以從賽道官網購票，此外還可以選擇位置，所以我這次是透過賽道官網購票。</p>

<p>在開放售票前就可以先研究要買哪一區，在<a href="https://www.suzukacircuit.jp/zh-tw/course_s/" target="_blank">賽道官網</a>上可以看到每一區的視野與影片。位置選擇的話可以考量：</p>

<ul>
  <li>視野好不好：能看到賽車經過的時間有多久，另外下層座位可能被護欄和鐵網擋到</li>
  <li>能不能看到螢幕：鈴鹿賽道一圈約 1 分半，大約有 1 分鐘沒有賽車經過，所以能看到螢幕的話，就可以知道其它地方發生了什麼事，上面也有即時的排名與秒差。在賽道官網的視野地圖上也有標出螢幕的設置位置</li>
  <li>超車熱點：比賽最刺激的就是看超車攻防，通常會發生在 DRS 區的尾端</li>
</ul>

<p>我偏向超車熱點，以鈴鹿賽道來說就是大直線的尾端的 A2 區或是第 1, 2 彎的 B2 區，比賽大部份的超車都發生在這裡，也是起跑後的第一個攻防點。此外這兩個區可以完整看到賽車入彎到出彎，另外鈴鹿賽道的第 1 彎的入彎速度也很快，可以體驗到速度感。而 A2 區還可以看到賽車出 pit lane，當然這兩區的價格上也不便宜。如果有預算上的限制，在選擇上可以以能不能看到螢幕為優先選擇。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/a2-zone-in-map.png" alt="a2-zone-in-map" />
<em>F1 舉行時會增設看臺，A2 區就是其中之一</em></p>

<p>在門票開賣那天，理所當然會湧入大量購票者，Mobility Station 也會有流量管制。但進入排隊也不用覺得沒希望，而且也可能提前進入購買頁面（顯示 90 分鐘以上等待，但沒多久就進入頁面了），所以要時時留意排隊狀況。然而如果一開始瞄準的是熱門區域的話，最好要有備案。我這次排了 1 小時之後，B2 區售罄，但 A2 區還是有很多位置可以選，最後就選了 A2 區後排，也可以看到螢幕的位置。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/a2-zone-view-1.png" alt="a2-zone-view-1" />
<img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/a2-zone-view-2.png" alt="a2-zone-view-2" />
<em>A2 區的視野，可以看到 pit 出口以及第 1, 2 彎，這邊也是超車熱點</em></p>

<p>使用 Mobility Station 購買門票會是電子票券，當天進場就直接用票券顯示的 QR Code 即可，在比賽日進入座位區也要再出示座位資訊，如果不放心也可以印出來備用。</p>

<h2 id="行程安排">行程安排</h2>

<p>F1 日本站賽程一樣為期三天，週五的練習，週六的練習與排位賽，跟週日的重頭戲正賽。另外，鈴鹿賽道在週四早上 9 點到 12 點還有開放參觀賽道的起點大直線與 pit lane，可以走在賽道上及看到車隊在車庫整備，是不容錯過的機會，所以可以從週四開始安排行程。而鈴鹿賽道鄰近名古屋，在沒有看比賽的時間也可以在名古屋旅遊。我這次的行程安排是這樣：</p>

<table>
  <thead>
    <tr>
      <th>日期</th>
      <th>行程</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>4/2 (三)</td>
      <td>中午抵達日本</td>
    </tr>
    <tr>
      <td>4/3 (四)</td>
      <td>早上參加賽道日、下午回名古屋</td>
    </tr>
    <tr>
      <td>4/4 (五)</td>
      <td>名古屋</td>
    </tr>
    <tr>
      <td>4/5 (六)</td>
      <td>鈴鹿賽道</td>
    </tr>
    <tr>
      <td>4/6 (日)</td>
      <td>鈴鹿賽道</td>
    </tr>
    <tr>
      <td>4/7 (一)</td>
      <td>中午回台灣</td>
    </tr>
  </tbody>
</table>

<p>基本上到了賽道後，就會整天待在那邊，所以除了觀看 F1 之外，還可以安排其它活動。像是同期間也會有其它賽事，這次有保時捷卡雷拉盃（Porsche Carrera Cup）跟法拉利挑戰賽（Ferrari Challenge）的賽程，可以體驗不同賽車車種的音浪。戶外廣場有車手週邊與活動攤位，主舞臺也有車手訪談與知識分享，在官方網站中都會公佈相關時間表，可以在比賽間隔前去聆聽。此外鈴鹿賽道裡還有遊樂園與本田博物館，遊樂園的摩天輪可以飽覽整個賽道，博物館則有展出許多經典的 F1 賽車。不過主舞臺、遊樂園、博物館都在離在正門比較近的區域，如果觀賽座位在比較遠的地方，可以在進場之後，先去逛這些地方，下午再到座位上觀賽。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/ferris-wheel.png" alt="ferris-wheel" />
<img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/view-from-ferris-wheel.png" alt="view-from-ferris-wheel" />
<em>摩天輪一圈約 15 分鐘，可以一覽整個園區</em></p>

<p>非常推薦在週四就到賽道，除了賽道日活動之外，因為人潮不多，遊樂園或是活動攤位很好排，是體驗這些設施的好時間。另外這天就可以購買車手與賽道的週邊，除了商品充足之外，一樣也不太需要排隊，比賽日也不需要大包小包。而且這天的座位區不用驗票，所以也可以去看看在大直道的座位體驗是什麼感覺。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/v-zone-view.png" alt="v-zone-view" />
<em>在賽道日去了 V 區坐了一下，可以看到 pit 的工作情況</em></p>

<h2 id="機票與飯店">機票與飯店</h2>

<p>因為是清明連假期間，所以即使是廉航，票價一樣不便宜。像這次是搭虎航，來回就要 2 萬 4，後續關注價格也越來越貴，但說不定其實後來有促消特價，只是考慮到連假機票比較搶手，所以在一開賣就購買機票了。不過如果可以提前幾天出發或是晚幾天回來的話，機票價格就可以少掉一半。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/window-view-from-airplane.png" alt="window-view-from-airplane" />
<em>一直很想坐窗邊的位子，這次終於圓夢了</em></p>

<p>至於飯店的部份，地點首選是名古屋。除了方便抵達賽道之外，週圍行程也很好安排，另外晚上從賽道回來也還有地方可以吃晚餐。我這次是住在榮附近的飯店，搭地鐵到名古屋站不到 10 分鐘，而且榮地鐵站也是重要節點，搭乘到其它地方也相當方便。</p>

<p>然而因為會有十幾萬人來參加 F1 賽事，所以飯店也是非常搶手，另外價格也會比平常高。這次在訂完 F1 門票之後才開始找飯店，但發現交通比較方便又價格可以接受的選擇不多了。建議可以提前找能夠退訂的飯店，選擇應該會比較多，而且到時沒有搶到 F1 門票的話，也可以再退訂就好。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/nagoya-prime-central-tower.png" alt="nagoya-prime-central-tower" />
<em>中部電力塔就在住宿飯店附近</em></p>

<h2 id="交通">交通</h2>

<p>到賽道可以選擇自駕或是搭乘大眾交通工具，而我只能選擇大眾交通。從名古屋到賽道有兩個選擇，一個是從名古屋站搭乘近鐵線到白子車站，再轉搭接駁車到賽道，是我這次的搭乘方式；另一個是從名古屋站搭 JR 線到四日市站，再轉乘伊勢鐵道到鈴鹿稻生站，最後走路到賽道。這兩個的差別主要是前者可以不用走太多路，也不用轉乘，而後者則是可以從一號彎門入場，不過也可以再走到正門入場。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/train-and-bus-access-information.png" alt="train-and-bus-access-information" /></p>

<p>搭乘近鐵可以事先在近鐵的<a href="https://www.ticket.kintetsu.co.jp/vs/en/T/TZZ/TZZ10.do?op=tDisplayVisitorMenu">官方網站</a>上預訂特急的車票，搭乘特急的好處是有位子坐之外，停的車站也比較少，特急約 40 分鐘，而急行則是要 1 小時。近鐵的特急車票是由普通車票與特急乘車券兩張車票構成，可以想成一張是基本費用，另一張則是升等特急車廂的車票。從名古屋到白子的費用是基本車資 1000 日元加上特急車資 920 日元。而能在官網預訂的只有特急乘車券，而且只提供電子證明（沒有 QR Code，也不能領實體票），所以預訂完成後要將座位資訊擷圖下來供查票用，但進站時不用特別出示。普通車票則是在進站時刷 IC 卡或是在車站購買車票，但不建議用電子車票，因為現場出站人潮多，然而 QR Code 掃描機數量不多，很容易塞住。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/shiroko-station.png" alt="shiroko-station" />
<em>白子車站前圓環的歡迎布條</em></p>

<p>到白子車站後，跟著人群走就會到接駁車的等待隊伍。我分別在週六 9 點與週日 8 點抵達車站，排隊隊伍算順暢，大約 15 ~ 20 分鐘後上接駁車，車程約 30 分鐘。接駁車車資 500 日元，是在接駁車下車處支付，可以用 IC 卡也可以付現，所以不用在上車時付錢。而下車處是在賽道外的停車場，所以還要再走 20 分鐘才會到正門。不過週四的接駁車不太一樣，因為非比賽日，所以班次比較少，雖然人也不多，但是我剛好遇到沒班的時間，等了 1 小時多才搭到，不過下車處在正門口，另外是在乘車處支付票錢。</p>

<p>這次去程的時間是這樣：</p>

<table>
  <thead>
    <tr>
      <th>時間</th>
      <th>名古屋出發</th>
      <th>白子抵達</th>
      <th>接駁車上車</th>
      <th>抵達賽道正門</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>週四</td>
      <td>(四日市出發，急行)</td>
      <td>9:20</td>
      <td>10:35</td>
      <td>11:10</td>
    </tr>
    <tr>
      <td>週六</td>
      <td>8:10</td>
      <td>8:49</td>
      <td>9:10</td>
      <td>10:00</td>
    </tr>
    <tr>
      <td>週日</td>
      <td>7:30</td>
      <td>8:09</td>
      <td>8:30</td>
      <td>9:20</td>
    </tr>
  </tbody>
</table>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/ticket-booth.png" alt="ticket-booth" />
<em>接駁車下車處的付錢處，左邊是付現買票，右邊則是刷 IC 卡</em></p>

<p>當然越晚出發人潮越多，等待時間就越久。為了避免花太多時間在排隊上，比較建議比賽日早上 7 點到白子車站，早一點到賽道就可以好好逛逛，而且在主舞臺週五週六兩天的車手訪談分別是在 10 點跟 9 點半開始，晚到就錯過了。而週四賽道日則建議 8 點到白子車站，因為賽道與 pit lane 參觀的開放時間只到中午 12 點，我這次 11 點到賽道差點來不及。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/saturday-morning-crowd.png" alt="saturday-morning-crowd" />
<em>早上入場還算順暢，但是場內的攤位已經需要排隊了</em></p>

<p>至於從賽道的回程，因為沒辦法預估什麼時候能到車站，所以沒有預訂特急車票，而是到車站後搭急行（不要選到普通車，等同於台灣的區間車，會站站停）。比賽日離場的人很多，因此等待接駁車的時間會很久。我這次買在 A2 席，所以可以在排位賽跟正賽結束的時候，早一點到接駁車的乘車處，但週日還是等了 1 小時多，想當然如果更晚離開就得要等更久，我在比賽日這兩天還可以回到名古屋吃晚餐。至於週四賽道日則是在正門搭乘接駁車，人不多也不用等待，只是下午 1 點才有回程的接駁車。</p>

<p>回程的時間是這樣：</p>

<table>
  <thead>
    <tr>
      <th>時間</th>
      <th>離場</th>
      <th>抵達乘車處</th>
      <th>接駁車上車</th>
      <th>抵達白子</th>
      <th>上火車</th>
      <th>抵達名古屋</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>週六</td>
      <td>16:00</td>
      <td>16:25</td>
      <td>16:50</td>
      <td>17:10</td>
      <td>17:28</td>
      <td>18:23</td>
    </tr>
    <tr>
      <td>週日</td>
      <td>15:40</td>
      <td>16:15</td>
      <td>17:30</td>
      <td>17:50</td>
      <td>18:14</td>
      <td>19:10</td>
    </tr>
  </tbody>
</table>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/returning-crowd.png" alt="returning-crowd" />
<img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/waiting-line.png" alt="waiting-line" />
<em>比賽日回程的人潮很恐怖，聽說有些人不想等車，直接徒步回白子車站</em></p>

<h2 id="飲食">飲食</h2>

<p>賽道園區內會有賣食物與飲料的攤販，只是價格會比較高，而且品質不穩定。可以事先採買好午餐、零食、飲料，再帶到園區內，現場也不時可以看到有人提著一袋食物入場。但如果想要吃點鹹的熱的，還是可以到攤販區逛一下，只是要找到好吃的得碰運氣。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/normal-bentou.png" alt="normal-bentou" />
<em>因為嘴饞買了這個 1200 日元的便當，但不好吃QQ</em></p>

<h2 id="總結">總結</h2>

<p>這篇文章除了記錄這次的行程規劃之外，如果之後要再次衝現地的話，也可以作為改善行程的參考，也希望這篇文章能幫助到有需要的人。這趟旅程也是做好行前準備，才能在比賽週好好體驗賽道慶典，留下很棒的回憶。</p>

<p><img src="/assets/images/blog/2025/2025-05-03-f1-japan-grand-prix-trip-planning/sakura.png" alt="sakura" />
<em>賽道也種植許多櫻花，看比賽與看櫻花一次滿足</em></p>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="遊記" /><summary type="html"><![CDATA[自 2020 年入坑以來，看 F1 也進入第 6 年了。大概從前年萌生到現場看比賽的念頭，也看了一些現場觀賽的分享文後，毅然決然選定了今年的日本大獎賽。選擇日本場的原因除了日本旅遊環境友善之外，比賽舉辦的時間剛好落在清明連假，賽道當地的鈴鹿與鄰近的名古屋也是櫻花季的時期，因此這趟現地之旅就成行了。受惠於前人的分享文，所以這篇文章也來分享如何規劃行程。]]></summary></entry><entry><title type="html">[電影] 2024 看過的那些電影們</title><link href="https://lankudot.airfishlab.com/blog/2025-03-watched-movies-in-2024/" rel="alternate" type="text/html" title="[電影] 2024 看過的那些電影們" /><published>2025-03-30T00:00:00+08:00</published><updated>2025-03-30T00:00:00+08:00</updated><id>https://lankudot.airfishlab.com/blog/watched-movies-in-2024</id><content type="html" xml:base="https://lankudot.airfishlab.com/blog/2025-03-watched-movies-in-2024/"><![CDATA[<p>去年因為工作變得比較繁重，所以電影看的不多，不過這樣反而可以寫得比較詳細。為了篇幅，就簡單分成真人電影與動畫電影兩篇，這篇就記錄真人電影的部份。去年最喜歡的電影就是《沙丘：第二部》了，去二刷的時候還選了 IMAX 的版本，對於太空科幻的題材真的愛不釋手啊。</p>

<h2 id="沙丘第二部">沙丘：第二部</h2>

<p><img src="/assets/images/blog/2025/2025-03-30-watched-movies-in-2024/dune-part-2-poster.png" alt="dune-part-2-poster" /></p>

<p>被哈肯能家族襲擊，失去駐地與家人的保羅．亞崔迪加入史帝加帶領的弗瑞曼人部族後，開始集結弗瑞曼人組織對抗哈肯能家族的行動。同時保羅的母親潔西嘉女士，也利用貝尼．潔瑟睿德姐妹會事先散佈的預言以及弗瑞曼人的信仰，將保羅塑造成救世主，以獲取弗瑞曼人的支持。而哈肯能家族在奪回厄拉科斯的主導權後，繼續以往的香料採收事業，但弗瑞曼人則利用遊擊戰術破壞哈肯能人的設備以干擾採收。哈肯能男派出心狠手辣的侄子菲得．羅薩，前往厄拉科斯剷除弗瑞曼人。</p>

<p>我很喜歡太空科幻中，用宗教、文化、儀式、服裝來帶出一個種族或勢力的個性與特色。像是哈肯能家族的母星羯地主星上，人民都是光頭，穿著黑色長袍，也有著獨特的歡呼手勢。為了慶祝菲得的生日，則是在鬥技場中讓他獵殺三名亞崔迪家的俘虜。再再顯示哈肯能家是邪惡的好戰勢力。不過菲得登場的這場戲，也是我喜歡的片段之一，為了還原羯地主星所在的星系的太陽是發出紅外線光，導演特別用紅外線攝影機來拍攝，讓畫面呈現都是黑白色的。相比 1984 年《沙丘魔堡》電影裡的菲得是瘋瘋巔巔的殺手，這版的菲得顯得冷酷多謀，很有反派魅力。</p>

<p>保羅與菲德的一對一最終決戰也相當精彩，沒有過份的晃動鏡頭，可以很清楚地理解發生了什麼事。看了幕後花絮知道他們都為了戲中的打鬥練習了很多，也才知道在鬥技場跟菲得打到最後的那名演員就是本片的武術指導。當然最終保羅贏得勝利，在獲得漠大的權力後，準備向宇宙的氏族宣戰，然而此舉讓卻保羅的心上人荃妮感到生氣又失望，同時保羅夢到的聖戰已經被觸發。</p>

<h2 id="gt跨界玩家">GT：跨界玩家</h2>

<p><img src="/assets/images/blog/2025/2025-03-30-watched-movies-in-2024/gran-turismo-poster.png" alt="gran-turismo-poster" /></p>

<p>《GT：跨界玩家》是真人真事改編的電影，主角揚從小就迷上《Gran Turismo》，並且夢想成為一名職業賽車手。有一天在遊戲賽道上創下的最佳記錄，讓他獲得參加由 Nissan 與遊戲開發商共同舉辦的「GT 學院」的機會。這個學院聚集了 8 位頂尖玩家，並把他們培養成職業賽車手，最後篩選出 1 位來參加他們的車隊。這對於一直被家人反對玩遊戲的揚來說，無疑是可以證明自己的機會。</p>

<p>雖然這類電影可以知道主角的結果，但是過程怎麼發展才是電影的重點，與家人的衝突、訓練的艱苦、被職業選手看輕，一再地為主角的成功加上更多的份量，也知道這結果得來不易。電影的賽車畫面也都是實車實地拍攝，就為了給觀眾最真實的比賽體驗，而故事的真人揚也在電影中擔任特技替身。比較可惜的是賽車中的畫面不夠長，經常在人物跟賽車間切換，看得不夠過癮。《Gran Turismo》也是我第一款接觸的賽車遊戲，所以得知這部電影時，就一直有興趣。但上映那時沒有時間到電影院觀看這部電影，直到在 Netflix 上架，才有機會補完，看完覺得如果當初能到電影院體驗引擎的轟隆聲，那感覺一定很棒。</p>

<h2 id="秘境探險">秘境探險</h2>

<p><img src="/assets/images/blog/2025/2025-03-30-watched-movies-in-2024/uncharted-poster.png" alt="uncharted-poster" /></p>

<p>《秘境探險》是同名遊戲的改編電影，主角奈森流著探險家的血液，原本在酒吧擔任酒保的他，遇到寶藏獵人蘇利文告訴他正在尋找埋藏的黃金，而原本的合伙人就是奈森的哥哥ー山姆。山姆在奈森小時候，為了不想被因為多次闖入博物館偷東西被關而逃離孤兒院，雖然當時約好會回來找奈森，但是這個承諾一直沒有兌現。做為幫助蘇利文，同時為了尋找哥哥山姆的下落，奈森踏上這趟尋寶旅程。</p>

<p>做為尋寶冒險電影，肯定少不了謎題、陷阱、覬覦同個寶藏的壞人與同夥的背叛。只是可惜的是，覺得這部電影對這些要素只是把它放進去，但沒有加深刻劃。劇情的走向可以猜得到，但也沒有意外的發展。像是敵人可以找到最後的埋藏點，只是因為剛好看到主角開船往那個方向移動，雖然可以合理解釋為什麼敵人可以到達那邊，但就是選了個最普通的原因。最驚喜的反而是彩蛋，像是遊戲制作公司頑皮狗的貼紙、遊戲中奈森的真人演員諾蘭也有參一腳。另外就是當主角奈森無意戴上腋下槍套背帶，成為遊戲中的造型時，更是令人興奮。</p>

<h2 id="小丑雙重瘋狂">小丑：雙重瘋狂</h2>

<p><img src="/assets/images/blog/2025/2025-03-30-watched-movies-in-2024/joker-2-poster.png" alt="joker-2-poster" /></p>

<p>原本以為作為《小丑》的續作，再加上「雙重瘋狂」的副標題，覺得這次應該是要開始讓高譚市瘋狂了，然而整部電影就只有「亞瑟」沒有「小丑」。每當你以為亞瑟要開始瘋狂、情緒要爆發的時候，亞瑟就退縮了，說其實自己沒有想要成為小丑，電影看完只留下壓抑的感受。</p>

<p>不過滿喜歡電影前半的部份，使用歌舞做為小丑的內心幻想或是情緒延續。歌曲用在美國脫口秀中由 house band 演奏的那類爵士樂，搭配戲謔的歌詞，以及一直在背景的不協調單音。雖然充滿脫口秀的那種戲謔歡樂氣氛，但不協調的單音也帶著壓抑感，彷彿說著這一切只不過是個「Joke」。但是這種穿插歌舞表演的形式到了後半反而變成一種濫用，一到需要表達內心情感的時候，就開始唱歌，反而相當破壞節奏，甚至覺得有點煩燥。不知道是不是為了配合 Lady Gaga，才用歌舞表演的形式呈現。只是具體地把情感用歌詞唱出來，反而覺得有點多此一舉，畢竟不是所有情緒表現都適合用歌舞呈現。不過在只有小丑的幾場戲中，瓦昆還是有只用演出，就把小丑的內心狀態直接帶給觀眾，當下覺得瓦昆的演技真的很厲害。</p>

<p>從劇情來看，這版的小丑不會是以往大家對小丑的印象，雖然看起來是還想要有續集，但是亞瑟的故事應該是到這裡為止了。如果想看小丑發揮的話，這部電影不是個好選擇。</p>]]></content><author><name>烏龜</name></author><category term="blog" /><category term="電影" /><category term="心得" /><summary type="html"><![CDATA[去年因為工作變得比較繁重，所以電影看的不多，不過這樣反而可以寫得比較詳細。為了篇幅，就簡單分成真人電影與動畫電影兩篇，這篇就記錄真人電影的部份。去年最喜歡的電影就是《沙丘：第二部》了，去二刷的時候還選了 IMAX 的版本，對於太空科幻的題材真的愛不釋手啊。]]></summary></entry></feed>