前往
大廳
主題 達人專欄

聊聊寫了十幾年小說轉獨立遊戲製作,試著當甲方,最後被企鵝們逼著承認我就爛的故事。

說書人 貓皮 | 2025-05-25 14:27:13 | 巴幣 16216 | 人氣 7582

中文名稱:城隍愛麗絲
英文名稱:
類  型:橫向卷軸╱冒險解謎╱回合戰鬥
產  地:臺灣
  作:
  
美  術:
遊戲時長:16-24小時
級  別:
平  台:PC(Steam)
價  格:NTD$???(暫定)
客觀評價:窩還不知道
上市日期:2025-2026未定

  大家好,在下貓皮。
  這次要接著跟大家聊聊獨立遊戲製作心得的第二彈。
  主題如下:


  上次跟大家聊到製作遊戲的金錢觀、找到優秀夥伴的重要性,這次就跟大家聊聊,若是以已經擁有了這兩者為前提,距離一款遊戲的DEMO版被催生出來還隔了多少具體難關。
 
  從現階段的製作狀況說起,對我這個新米製作人來說,現階段就好像玩RPG初期練等那樣,正在歷過一段等級飛快上漲的時期,『還有成長空間』這種話對我來說會變成一種非常具體的困擾,每次解決一個問題,每渡過了一個難關,我都會得到新的審視方法與對應技能。
  這本來應該是好事,但問題在於…原本我以為大致正確、理所當然又多年根深蒂固的常識性觀念,就像陶土糊的繩紋盾牌對上芝加哥打字機一樣,不知道被打碎了多少,好不容易學了新的觀念去適應,又不到兩個禮拜就被突發狀況給逼得又要推翻、重構,痛苦的很,但儘管如此,我也再無法假裝自己從來不知道有這個角度。
  而且不只限於新的、沒見過的難關本身,原本以為已經解決的難關也會因為視角優化而變得更複雜,使我又急需新的技能點去適應新的難關,但新的技能點又會產生新的視角,然後開始新的迴圈…。
 
  這也是我這篇文章一直沒辦法順利寫出來的原因,至於巴哈姆特ACG創作大賽的截止期限(5/20),與我本職申報營所稅的期限(5/31)一起夾擊我,則又是另一個故事了,看倌們不會有興趣,也根本不值一提。
  除非你非要跟我聊聊,為什麼申報期限明明被改到6/30,但我家的報稅死線仍在5/31 。
 
不就是老闆在搞,還需要什麼新觀點。
你看,我是不是說過不值一提了,還是做遊戲有趣多了。
 
  今天,我會延續之前的文章,具體聊到:
 
1.     角川遊戲企劃班到底教了什麼?有沒有用?和實際做遊戲之間有多少落差?
2.     若錢錢已經管飽管夠,夥伴們也非常優秀,這就算是完美遊戲的配方了嗎?
3.      所謂DEMO版的定義到底是什麼?要做到什麼程度才算「合格」?
4.     最後小結,這個遊戲企劃的短期目標又是什麼。
 
那麼,我們就直接進入正題了。
 

首先,角川遊戲企劃班教會了我什麼,與實際做遊戲有多少差距?
 
  先說一個大前提。
  這門課對我一個只懂寫故事的小白來說,絕對是非常必要的一堂課。
  剛加入這門小班制的課程時,只見每個同學就像剛來英雄協會報名一樣,起手技能與固有特性差異極大,兩個同學有工程背景,想一人大軍幹光整個製作工程,另一人則是已經擁有完整團隊,自己是作為團隊螺絲釘前來進修,而我則是事先準備好鈔能力與故事大綱,但完全沒有個人製作的條件,卻連第一個夥伴都不知道該怎麼找、怎麼談。
  但我們仍有一個共同的目標,就是希望透過這門課,把各自的『設計概念』落地化為實際的『製作方針』,此外,於我個人而言,我還得多學會把『創意』化為『具體工作』給交代出去的能力。
  這兩個目標看似相近,但其實非常不同,後面看下去就會明白。
 
  這個將不同能力、相同目標的我們連接起來的關鍵字,就是『企劃』。
  那麼,遊戲『企劃』到底是什麼,若是把課程關鍵字簡單列出來的話,大概包括以下內容:
 
定義核心玩法。
定義遊戲規格書與數據單位。
簡單介紹基礎遊戲製作工具。
(如Unity∕RPG製作大師等,但沒有教具體操作,根據學員特性或需求,有可能會接觸RPG製作大師,但當時同學們都沒這需求。
定義戰鬥系統的交互規則。
定義經濟系統的閉環邏輯。
定義遊戲劇本的敘事方法。
定義遊戲UI的互動區塊與功能設計。
引導協作工具的使用(如心智圖等)。
 
  理論上,把這些概念學通之後,再透過實際撰寫工作表、規格書或工程與數據表格,學期末便可產生一套足以啟動的概念,最後我們再將那個概念化為一款遊戲的demo版,由此視為『設計概念』已然成為『製作方針』,於是整個學期的階段性指標就可以宣告達成了。
 
  但是,這裡馬上就可以提出第一個差距。
  這堂課的主要目標其實並不完全在於輔助學員完成demo版,那充其量只是課表到了可以畢業的一個象徵。
  先不說五、六個月的時間,一邊兼顧上課、修改與交件根本不可能完成,五還在冥夢,六月懵懂,七月著手,等到原始發想足以支撐基礎製作之後,這都來到九月初了,而且這還是學生只有四個人的情況下,老師還能細細的逐個查看,挑出錯誤,就這,老師還經常看作業看到延後下課,要是像去年十來個同學,明年又八個同學,我都不敢想像看作業時是何等的兵荒馬亂。
  此外,由於學員們的起始技能不同,畢業作品的完成方式也完全不同,敘事比較好的同學會出PPT模擬遊戲進程,工程比較好的同學則是省略敘事,直接用製作工具展出簡單的核心玩法,我的話因為動了點鈔能力,兩個都有,但時間不夠打磨,變成敘事與機制都是半桶水。
  (而且我還一畢業就直接把那半桶水踢翻重來了)
 
  綜上所說,如果期末作品不是這堂課程的主要價值,那麼,這堂課的真正意義究竟在哪裡?
 
  一言以蔽之,這堂企劃課有三個目標:
1.    至少跑過一次製作流程,人人有功練。
2.    取得將流程具體化,設計規格並轉為表格的能力。
3.    檢討表格從第一人稱撰寫再過渡到第二、第三人稱閱讀是否仍然有效。
 
  以我的立場來說還有一個額外收穫,那就是透過『流程』發現原先的設計概念還有多少『尚未被定義』的細節、糾正被『誤定義』的細節。
  若未來我有了團隊,以上的課程目標,將能保證我身為發明這些度量衡的甲方,可以將『被創造出來的定義』正確傳達出去,使團隊成員能依照我的所設計的概念正確地執行。
 
  這裡就可以順勢來到第二個論點。


  即使已經創造出一套看似合理的定義,完全足以讓第一個人看懂,卻也未必能讓第二個人順利理解。
  為什麼?
  因為規格書與企劃書完全不是一套標準化的模組。
 
  如果一句話太抽象,那就來舉個例子吧,假設我要設計一個裝備鍛造臺,可能會在開會時,向工程用中文很沒效率的描述:
 
  『不同規格的鍛造臺存在於不同城市,有等級限制,每個鍛造臺能鍛造的裝備不同,可以被鐵匠、商人、初心者互動,鐵匠可以用高等的,商人與初心者只能用低等的,互動成功之後出現某某特效與某某音效…云云』。
 
  工程大概聽懂了之後,我就會提交一個表格,接著,鍛造臺可能會在企劃書中被展示為以下結果:
 
物件
  
城市
  
職業
  
強化型
  
強化上限
  
特效組
  
音效組
  
鍛造臺A型
  
typeA
  
T(1+2)B(0)
  
type12
  
3
  
Effects099
  
Sound010
  
鍛造臺B型
  
typeB
  
T(2)
  
type12 3
  
5
  
Effects100
  
Sound010
  
 
  規格書則是標註:
  鍛造台的基礎功能A型、B 型。
  城市代碼:
  A=普蘭德拉,楊柳村,說話村
  B=漁人村,矮人鐵堡
  強化裝備代碼:
  type1:木甲、皮甲…
  type2:木劍、皮弓...
  type3:鋼甲、銅甲...
  可操作職業代碼:
  商人系(T):
  村民系(B):
  無轉職=0,一轉=1,二轉=2
 
  如大家所見,這樣的設計,與各種遊戲中常見的鍛造臺相比,已經算是要素很少的了,但即使是這種很簡單、直觀還半中文化的表格,若沒有往細著說明的話,其實再厲害的工程師仍然很難掌握工作細節,會頻頻抓你來問:
 
  『你這樣寫到底是什麼意思?type是地點分類碼?類型碼?區域編號?所以這張表不看材料?職業對應技能呢?你要在另一張表控制嗎?能不能寫在同一張表上?啊這張表是要跟地點還是跟物件?你說清楚。』
 
  然後我就會跟他辯解:
  『type只是代表那個欄位模式是抓組合代碼,不是直接引用數據,對應角色的技能我會統一寫在技能專用的表格,材料會放在道具專用的表格,全部寫在一起表格會非常大,如果三張表都寫明細會有大量重複的數據,至於跟城市還是跟物件我是覺得要先問你...。』
 
  或許你會覺得,這有可能是我表格設計與舉例太爛,狗都寫得比我好,也有可能覺得,這是工程師根本理解力不夠,豬都比他會讀。
  但更多的人(特別是工程師)就會朝我這個甲方唾罵說:
 
  『你為什麼不一次講清楚。』
 
  但事實上,光一個工作臺我可能就要花幾十分鐘解釋機制,換了另一個物件可能又是幾十分鐘,幾個物件下來,一個下午的開會時間就這樣過了,一旁的美術就會用看著兩個傻逼互撕的眼神,一邊看手錶想著什麼時候散會。
 
  若要我自行檢討的話,我會說寫的人的技巧占一半,讀的人的理解方式也占一半。
  因為工程有時候思考、理解設計的方式會比較直接,比方說人物物件太大的時候會過不了門,這要繞過去並不困難,但工程就是會卡在這個小問題老半天,你嘗試性的問他可以不可以這樣解,然後就解了,或是手電筒的扇形燈光範圍太小、太大需要柔個邊,Unity也有預製工具可以輕易調整,但他就是會去無視,直接上預設版本。
 
  有時,也的確就需要企劃耐心的一一說明:
  『這裡為什麼要這樣打光,為什麼這裡繞過去就可解開云云。』
 
  而不是一句:
  『快捷道具按快捷鍵就可以使用不是理所當然的事情嗎?我企劃書不是也寫了?總之你給我做出來就對了!』
 
  因為這種情況肯定是把一大包設定一口氣講出來、寫出來、交代出來所導致的結果。
  重申一次就解了,何必呢。
 
  有些地方,我這個設計可能會覺得工程有點直,這麼明擺著的東西還需要特地解釋,工程也會覺得美術跟甲方根本不懂Unity操作,讓他很累,美術大概也覺得工程與設計夾著他補補改改很煩,然後這兩個人大概也會在某些層面,覺得這個甲方就是個傻逼。
 
  上述臺詞、狀況,相信許多關注過、好奇過其他遊戲製作團隊狀況的看倌,絕對不會不熟悉。
  但是,這的的確確就是獨立製作遊戲的每一天,是一群剛嘗試做遊戲的人那絕對無可避免的常態。
  每次開會就跟打仗一樣,但如果這關都過不了,以後就別說要踢球了。
  所以,我寧可讓他們覺得我就是個傻逼,而我也確實承認我的確是小白。
  我耐心承認自己的錯誤,解釋自己為何誤判,聽取被誤判的根源,再重新說明自己的想法。
 
  再說了,如果交代與執行雙方都是自認能力很強的人,反而問題會更大。
 
  為什麼?
 
  撇除個人溝通能力誤差的問題,拿老師在授課時所使用的表格教材來說,他以之前在遊戲公司工作時實際使用的表格來作為教學範本(因保密義務,我在文章中無法提供),裡面充斥各種暗號、代號化的數據,連表首中文字都完全代號化,活像是要先學會黑道的行話才能進入這個領域工作,更看不懂。
  但這並不是故意要讓外人看不懂,而是用中文字一一定義很沒效率,所以才訂下規格書這種『暗號母本』。
 
  所以非得像老師那樣,把所有表格的中文化代詞精煉到只剩代號,就是我們追求的目標嗎?我寫的他看不懂,是不是因為工程師看到代號的敏感度反而更高於中文?
  這問題當時聽起來超級白癡,甚至直到畢業時我還真沒搞懂,直到我跟我家工程具體合作了幾個月,我才漸漸明白,關鍵不是儘可能在第一代就寫到完美,而是方便進入迭代。
 
  其實一開始寫得很白癡並沒有什麼錯,磨合與吵架也很正常,代號化也當然是最終目標,但是,其實正確的企劃養成流程,不過就是兩個臭皮匠一路走來,一路吵架,直到越吵越少,直到雙向溝通足以代號化的默契養成。
  這是兩個人的成長,絕不是自己溝通能力好就行,也不是工程應該要先敏銳的察覺到每一種做法到底行不行。
 
  而是甲乙方兩個人在長期溝通下,去訓練那條溝通的橋樑,從一開始沒效率的純語言與文字描述,到透過用PPT表述,再到透過心智圖表述,再到透過表格表述,再到透過線上表格雙向更改,直到篩選出流程無法解釋的難題,再開會講明那些講不開的細節,然後再從PPT開始正向循環下去。
 
  就算兩個人都已經一百等,那條「橋」還是得從等級一慢慢蓋。
  而兩人的基礎經驗與天賦,頂多只是影響這條橋蓋得快不快,但本質上,還是跟兩隻新米菜雞互啄沒兩樣,而且新米菜雞還有個好處,就是大家都有彼此很菜的認知的話,對彼此的耐受力還更高,兩個等級很高的人反而有種難以跨越的自尊與專業鴻溝。
 
  所以,這堂課的真正目標,絕不是讓學生學會老師所創造的標準定義與定義範例(也就是說,不是去學他們公司的行話),而是讓學生學會『定義』的底層邏輯,並掌握自我創造與修正『定義』的能力。
  換句話說,所謂的『企劃書』與『規格書』,其實是為了顧及『設計與企劃組』與『工程、美術與執行組』雙方,彼此的撰寫習慣、接收與閱讀習慣,進而整合成的一張約定成俗的『暗號表』。
  而這張『暗號表』的價值,並不在於寫得多清楚,多精準,多簡單,而是它是否具備『能夠經得起雙方反覆協調與頻繁修改』的靈活度。
 
  結論,企劃班給了你創造第一版企劃書、規格書的能力,再教導你修正第 一版的能力,但這份企劃書是否有那個彈性,能不斷透過修改表達方式再適應到所有人身上,則是仰賴企劃人與執行者之間的長期磨合修行與經驗。
 
  這樣一來,大家可以明白『製作人∕甲方∕企劃』不只乖乖出錢要緊,不只要找到優秀的夥伴,更明白出的一張嘴更是多麼重要的工作了吧(誤)。
  而且除了工程層面之外,對美術、音效、音樂、劇本,甚至是對金主乾爹也都有各自的橋樑模式需要訓練,好比剛剛舉例的對接工程,就需要設計人對程式對應表格的導入方式有基礎理解,對美術、音效、音樂、劇本也都要各自有分鏡、審美、音軌、剪接等基礎概念,對金主爸爸就更複雜了,展開來講會沒完沒了。

  所以,我們就導入最後一個話題吧。
 

  DEMO做出來的意義到底是什麼,企劃班的要求是什麼,需要展示什麼,我們的短期目標又是什麼。
 
  從結果而言,有三種功能。
  能玩-對玩家。
  能看-對宣傳、評審(賽事型)。
  能懂-對投資方、合作方與評審(投資型)。
 
  一般玩家對 DEMO 的定義其實相當模糊,這三種版本中任何一個,對他們來說都可以算是DEMO。
  不過對玩家來說,最重要的往往是遊戲體驗與流暢度,能順暢玩完一個完整章節的遊戲,通常比每一個按鈕全都寫好功能、卻缺乏完整體驗的版本更容易獲得高評價,這也是廣義上眾人對 DEMO版本的常見印象。
 
  但對投資方、合作方與專業審查者而言,則有一個更狹義的定義,也就是整套遊戲的核心玩法是否已經『至少』展示過一輪。
  若是以即時戰略《世紀帝國》為例,就是展現村民如何蓋建築物,資源量種類與採集互動模式,建築物如何占地與升級條件限制,如何消耗資源出兵升級,戰鬥方式如何運作(近戰、射程、駐紮、範圍傷害、招降等),時代升級會帶來什麼改變,至少一個種族的基本差異,湊成一桌麻將看起來是怎麼打來打去的。
  以上的所有變數與代表單位都展現過一輪之後,他們就能看出你這個遊戲有多少擴展的潛力,進而決定你應該得到多少錢力。
 
  如果是面向玩家的賽事,就得要『能看』,說白了就是得兼顧『展示核心』與『展示可玩性』。
  僅僅只展現核心玩法,評審與專業投資者雖然了解遊戲架構未來會成形,但玩家的反應通常會更直觀也更情緒化,就算技術與設計俱佳,也可能會因為體驗的不完整,使得獎後的說服力都受到影響,若無法說服玩家,那也失去了比賽在宣傳上的意義。
  但若優先展示較高的可玩性,有些製作團隊的常見手段是,選擇先用少量的可操作玩法搭配量產美術資產,來營造高完成度的錯覺,好比說把大量兵種設計出來,兩百人互打一定比一個村民把每一種建築都蓋一次來得熱鬧又有趣,但是懂行的投資人也會立刻察覺『這根本就還沒把關鍵的地方做完』,要嘛不敢投資,要嘛最後遊戲實際端出來與期待值落差過大,反而導致評價被爆打的狀況更是數不勝數。
 
  但是,這個矛盾就是所有遊戲製作團隊最大的痛點,特別是獨立遊戲,要是目前製作量能能兼顧兩者,誰不想兼顧兩者,如果我有額外的宣傳部門或預設資源,我大可以等遊戲做到五六成再來砸宣傳,但事實卻是,能力稍大的公司需要提前展現價值以吸引投資,小團隊的引資就當撿到不提了,但還是要到處趕集曝光參加比賽、參展,慢慢堆疊關注與口碑,因為實在沒能力在發售前來一波大的,可是這個節奏,往往與製作面的階段性節點是完全錯開的。
 
  如果,你問我這篇文章會怎麼兼顧二者,我會說,這樣的矛盾幾乎是所有製作團隊都會面臨的永恆業力,不罕見卻又確實無解。不過,我還是勉強說出一個稱不上解法的平衡點。
 

也就是,我們當前的短期目標,不放過比賽與任何曝光的機會,慢慢地推進進度。

  這個方案來自於我在投稿參賽時遇到的困境,就是我原本打算在5/20時在DEMO版表現探索玩法與戰鬥機制,但是我大約在四月中的時候察覺戰鬥機制根本不可能做完,而探索機制部份還有許多BUG與對接不齊的修正沒完成,所以,我最後的解法是放棄完成戰鬥機制,全力修正已經完成的探索機制BUG,改成以宣傳片影片演示未來的戰鬥畫面,至於還沒動手的部份,則先完全不要進行任何預告。
 
  至少,對玩家,我已經交代了一個小型但體驗相對良好的的迴圈,雖然內容真的不長,但應該已經足以表達這款遊戲的探索氛圍。
  對評審與未來的合作者而言,我也透過影片與整體設計交代了未來的規劃與擴展方向。
 
  至於這樣的策略是否有效?區區在下我我此刻也無法斷言,因為老天還沒拉著我的手走到那一步。我只能說,這是我在有限資源下,所能做出的最誠實選擇。等入圍結果出來之後,我會再來和大家分享這次的嘗試究竟帶來什麼樣的收穫與教訓。
 
  那麼,這篇文章就寫到這裡了,這些不成熟的經驗純粹是我的碎碎念,又臭又長又不放圖美化,我其實也不會太期待大家能看到這裡。
  但是,如過真的有看倌來到這個段落。
  請收下我微不足道的感謝。

  如果有興趣的話,也可以追蹤我們的粉絲專頁,才剛草創,但我們會不定期的公佈開發進度。





 
  謝謝各位看倌的關注,我們下次再見囉。
  其實在我們家美術的眼中,我們大家還是很融洽的啦~。


2025-05-28 16:27:59
我覺得遊戲的畫面看起來風格不太統一是大問題,除非是當金主只出錢和想法,那就可以找一個專業的遊戲總監做這件事,不然的話獨立遊戲甲方的工作應該比較像音樂專輯製作裡面母帶工程的部分,你得保證遊戲所有元素看起來更像是一個整體 現代玩家都是身經百戰,元素拼接感太嚴重的話即使不用專業人士也會稍微察覺(還有你得先打死團隊內外那些一直跟你說作品看起來很棒的傢伙 而,他們才是最壞的敵人,如果你需要聽這些鼓勵的話才能展開創作工作,還不如把錢省下來去聲色場所找個說話更好聽的)
2025-05-28 22:14:09
其實風格統一的問題我一直都有注意到,因為兩名美術的風格不同,但又不太可能完全只交給一個美術,會畫不過來,我其實也正在想辦法要解決這個問題...。[e3]
2025-05-26 23:23:55
1. 不是index,是窮舉。而且一個正常流程進行的需求,是不應該在會議討論後任意調整更動,這很影響開發進程,所以你在這裡列出的事後調整是應該避免的。

2. 協作這件事其實比較依賴工程師之間的溝通,我不覺得企劃案標註資料型態能幫助工程師什麼,明確標明產品規格與邏輯流程才是首要的。

3. 你說的這個東西應該是伺服器端對外開出的api或協議規格,這件事是需要工程師自己寫文檔,已經不是產品應該做的事。更何況這篇文章提及之開發遊戲似乎只是一個單機遊戲,如有多位工程師協作的話,合作範圍可能也相對集中於同一專案內部,這類資訊可以直接在專案中共用與維護,那麼工程師自行在專案裡確認就足夠了。
2025-05-27 13:08:29
原來如此(點頭點頭)[e1]
2025-05-26 20:29:55
雖然不是遊戲,但做過幾次企劃領銜,或是自個也有在弄小說作品的公開與運作,真心能感覺到人手不足是個大到爆炸的問題,還是跟外包談各種價碼和成品細節合不符合,這類零零總總真的會讓人很吐血。Orz
2025-05-26 20:33:49
如果兩個美術風格/工程/音樂很難統合就會大爆炸www
2025-05-26 19:48:17
另外,也有很多策畫的專業更偏向於美術或是商業向的設計,但基本上負責系統開發的策畫,我覺得多少都會需要懂一些基礎的程式邏輯,這樣才能更好的跟對方溝通;而如果有誤用的情況,那就期望能在會議中通過協商解決或達成共識。
2025-05-26 20:11:55
比較複雜的是,其實我還真沒有工程背景,所以才會變的像這樣從地基開始打造溝通條件的方式
2025-05-26 19:42:24
Haku 你好,
我能理解你的看法,但就我個人的遊戲策畫工作經驗來說,標註資料型態會有以下幾個好處:

1. 在跟工程師討論和對接的時候,這些資料型態能夠幫助對方理解你的設計目的,在這個階段,他完全是可以改變的,向你提到的string和int的變化,完全可以在討論後調整和改變。但我這邊會認為你指的是index列上的int,而string部份則單純只是遊戲UI中顯示的單位名稱,可能完全不涉及其他邏輯。

2. 在開發過程中,有時候常常會涉及多個工程師協同開發,例如服務器和客戶端就是很常見的情況,而標註資料類型有時候是涉及的這個功能之前已經開發過了,並且有其他表格需要協同調用。例如城鎮功能已經開發完成了,這時候通常是配合城鎮所使用的表格內容去做設計。

3. 在開發結束後,這個資料標註常常會以策劃案的形式建檔保存,當下次有相關系統需要時,無論是再開發或是關聯系統開發時,這些都常並非是之前原班底在開發,這時候接手的策畫(對策畫來說很重要,他就不用特別再去翻一大堆表格去找資料)和工程師可以很方便通過這個紀錄了解具體的運行邏輯。

這些是從策畫的角度回答,不知道這樣能不能讓你認同[e12]
2025-05-26 20:11:01
還不知道那位大大人不認同,但反正我是認同了,我這真是拋磚引玉了我www
追蹤 創作集

作者相關創作

更多創作