[程式] 本地化遊戲專案經驗

本地化遊戲專案經驗 這一篇文章補充描述一下我曾做過的案子關於多國語系的做法 網誌完整版 https://ndark.wordpress.com/2024/11/15/%e6%9c%ac%e5%9c%b0%e5%8c%96%e9%81%8a%e6%88%b2%e5%b0%88%e6%a1%88%e7%b6%93%e9%a9%97/ 縮網址 https://tinyurl.com/mr2zex9c 完全不做本地化 是的，如果是接案公司，或者是只打單一語言市場，是很有可能完全不做多國語系的。 在這樣的前提之下，工程人員如果判斷“沒有”這項規格，可以加速多少時程。確實因為 這個原因完全不做多國語言的系統。 最陽春的做法是把語系文字寫在程式碼裡面。 讀者一定會浮出這樣的疑問：誰會這樣做遊戲！ 在談下去之前，我先談一下我在2012 Kobayashi Maru Commander(小林丸指揮官)的案子 的做法 標籤參數的格式 在小林丸這個案子，是使用語系分離，分行式標籤參數格式文字檔的做法。 如果讀者去看Unity的meta檔案可以發覺就是用類似標籤參數格式來存資料。通常是以每 行一條<標籤>:<數值>的格式來存取。 在筆者2018年服務於Ubisoft的Growtopia案子中，伺服器傳給客戶端的通訊資料也是這樣 存的。 在小林丸案的每個語系裡面存相同的標籤，例如： 中文語系內是 System_Config:系統設定 英文語系內則是 System_Config:Config. 如果我沒有記錯，Android的語系設定也是以語系分離。 語系分離的好處是存取檔案後在切換語系前都不用再讀取。 而語系結合的缺點當然就是相反過來，讀取語系文字檔的時候，就會同時取得其他語系的 內容。其他語系的內容即便沒有使用，仍會佔用到記憶體。 回到把語系文字寫在程式碼裡面。 就連草根開發者NDark都懂得要把多國語系存成一個參數檔。 但如果我告訴各位，我職業生涯中看過不只一次完全不做多國語系的案子。 我在Ubisoft服務維護的Growtopia案因為一開始是獨立開發，所以起步時就決定只做英文 版，所有的文字都寫在程式碼內，直接以明碼方式傳給客戶端。產品紅了之後繼續維護每 個月持續版更，內容當然越來越多，要重新針對所有遊戲內容進行翻譯的成本就越高，所 以後面不管多國語系的呼聲需求多強烈，都會在討論中被駁回。 我在2015年我參與過本地化的日本遊戲<Hortensia Saga(蒼之騎士團)>的前幾個版本日本 原廠團隊也是一樣把日文寫在程式碼中。原廠團隊是要委託代理商發行台港澳中文版後發 現了這個是一個問題，才調整優先度做出決定在後續的版本將多國語系抽出為Excel的決 定。 在這個過渡迭代的過程中，交付給台灣的第一版還不具有Excel，所以日本代理商SEGA還 派出工程師做出了文字分析工具（Parser）。將程式碼內的文字挖出來，做成類似csv的 檔案，然後翻譯後再使用另一個腳本工具去將中文取代入程式碼內。這樣就是當時前幾版 的中文版的做法。 不過值得一提的是日本開發團隊通常都具有強大的Excel功力。可以看到他們習慣透過 Excel表單內的腳本進行包版運作。這點我在台灣團隊比較少看到。 當然因為日文Excel軟體製作的腳本在中文電腦跑有沒有什麼不相容的問題，這就是另一 個故事了。 因此得證，只要規格沒有要求多國語系，或是只做單一市場，或是為了趕時程。不做多國 語系也大有人在。 開始使用Google Spreadsheet 在2017年的時候我製作了<Really Really(真的)>這款遊戲，這款遊戲我就開始使用 Google spreadsheet。透過NGUI內建的功能，將試算表轉為以逗點為區隔的csv使用。 <真的>案是以文字對話/長輩梗/迷因梗為主的遊戲，我當時還委託專業翻譯人員做英語版 翻譯。 比較有值得一提的是有些文字不適合直譯所以關於地區梗的部分我會直接向翻譯人員下指 導棋（例如說太陽花/德國眼鏡翻譯成Young Protestor/X-Ray Glasses）。 也正是在Caravaneer 2的翻譯經驗，在<真的>一案，其實是有兩個繁體中文版本，一個是 繁體中文，一個是網民中文版本。 <真的> 一案中還有針對不同的語系的圖檔，語音檔案也做出多國語系。這邊是使用 Assets Bundle 的 variant 標籤，以相同檔名不同variant來實作（在Addressable系統 是叫做label），判斷語系來顯示該語言的圖字，特效，及語音檔。 順帶一提，2022年的<Supernature Event Control Inc.(打怪特勤隊)>案我嘗試做台語的 多國語系，當時是切成台語漢字，台語教薦字，台文三種語系，很可惜我沒辦法資助台語 工作者來完成整個語系的翻譯。目前台語語系是透過伺服器設定檔將其隱藏起來。 使用Google translation的指令做機翻 在2020年的<Village Master(村莊蓋出去，野獸進不來)>的案子中開始將多國語系的經驗 擴展，當然<真的>一案中發覺委託翻譯社的費用以自資案來說是一筆無法負擔的支出，最 後決定先使用機翻，看哪個市場比較有希望再進行推廣，最後透過機器翻譯的幫助下，除 中文英文外，總共翻譯了馬來，德文，西文，法文，葡文，俄文，日文，韓文，波蘭文， 總語言數達到十一個語系。 除了遊戲內的內容，在平台商店的更新版本內容，行銷文字，在社交媒體的行銷文字，也 都是透過這樣的表格來做翻譯。 表格的命令其實一點也不難。只需在試算表中加入命令： =GOOGLETRANSLATE(E860, "en","de") 指定要翻譯的內容，原文字碼，翻譯目標語言字碼即可。 不過小心，如果機翻數量龐大腳本也需要一定時間完成所有試算表欄位的翻譯。如果翻譯 完成，建議將翻譯的結果重新以文字方式複製一份貼上原處，取代命令算式，固定下來。 避免每次表單變更的時候都觸發機器翻譯。（另外提醒，就我的經驗，這個語法有機會會 因為某些暫存的原因而出錯誤訊息卡住。） 至於機械翻譯有沒有效果呢？我個人的經驗是，比什麼都沒有好。尤其是在幾個國際化不 高的語言國家，被好像看得懂的文字騙去下載，然後留言說："遊戲有趣，就是翻譯是個 屎！"還是比完全被忽視好得多。（包含幾間公司的經驗是韓國與日本很在意標題與商城 畫面的截圖要有當地文字，俄羅斯等前蘇聯邦國家，與阿拉伯國家因為地緣政治的關係算 是遊戲市場的孤兒，所以有當地的語言會很容易進入玩家的視野。） 介面尺寸在不同語言的適應性 部署多國語系，有一個很大的問題，這個問題至今我還沒辦法解決。 那就是每個語言針對翻譯結果的長度不好控制。 如果介面是以英文或中文還好調整，畢竟文字內容開發者自己可以代換。但是碰到其他語 言，尤其是字母符號不同體系的語言就很難處理。想改也不知道怎麼動手。 比如說德文就是出名的長單字。（筆者自己有德文基礎，所以我還能知道要拆字該怎麼著 手。） 阿拉伯文自右書寫的系統（句子內阿拉伯數字又是左起）會很令開發者意外。 如果調整文字尺寸讓其自動縮小適合介面，那麼長單字會注定被縮到看不清楚。 而且介面上忽大忽小的文字簡直就是對美術人員的一種逆鱗。 這點我希望讀者能分享一些意見。 跟翻譯外包相關的議題 使用google spreadsheet的時候如果有多人協作或是外包作業的需求建議將所有翻譯條目 的索引或順序固定，不要因為好看或是分群忍不住調整順序。盡量能遵從後到遞增的守則 來持續開發。 其原因是從開始委託外包到收回是需要時間的，為了不要讓人為作業疏失干擾到原始的檔 案，最好的情況是開始委託外包時，就複製一份表單給翻譯者。 所以回收時如果翻譯條目的順序改動了，那就無法整個表單複製整合起來。必須人工確認 貼上。而需要翻譯時多半團隊內都缺少懂該語言的成員（否則為了節省成本都有可能自己 翻）。所以不能大範圍貼上，很容易造成人為作業疏失。 順帶一提，2018年Growtopia的案子中，另一個之所以無法下決定開始翻譯的原因是：開 發週期過短。當時遊戲是以一個月為一週期在開發新功能，每個月產出三十到五十個包含 裝飾或系統甚至故事的功能，時程已經擠到不行，企劃都是在送審打包最後一刻才能把英 文順好。因此若要再擠入三天五天甚至一週的翻譯工期，就得更早交付翻譯者原文。這對 於Growtopia這種幾乎大多數營收都來自每個月更新釋出的新道具新功能，顯得不實際（ 翻譯如果到了第二個月才更新，那麼對營收貢獻也不夠有成效了）。（Ubisoft 是一個龐 大的帝國，帝國內不乏有各種服務支援部門，Growtopia曾經靠著帝國支援移植手機平台 到家機，完成不可能的任務。連我們團隊也判斷很難在帝國內找到能這樣一個月只緊急高 強度配合一到三天的翻譯工作者。） 還是建議及早部署多國語系的系統 從工程的角度來看，不管最初版本是否只有一個語系，文字有多少，都建議及早部署多國 語系的系統。這樣才不會陷入Growtopia的成本沈沒效應（內容越多，就越難做出開始翻 譯的決策），所以LocalCoop想要重現的滾動式翻譯才這樣有意義。 當然我連續幾個專案都沿用同一個系統，所以重複部署這個功能對我來說就只是複製一份 雲端表單而已。 更不用說因為變成了一個資源檔案，那麼實現下載更新，就容易許多了。 使用滾動式的翻譯平台的好處 在2014年Caravaneer2的案子中，也就是目前 LocalCoop 嘗試重現的方案，是採用滾動式 的方式來與社群合作。滾動式的好處體現在幾個地方： 第一個是開發是持續的。與代理案能夠一次性不同的是，自研案的內容都是逐步產出 的，而每次的版更都有可能造成舊文字的變動，此時翻譯協作也必須知道舊的修改到底在 哪裡，才能迭代翻譯步驟，而不是全部重新翻譯。程式人員對於版本控制已經相當熟稔， 但翻譯工作的版更管理比較少人關心。 第二個是由於遊戲內容的產出是滾動式的，早期的翻譯者不會知道某些伏筆會在後續 的篇章中出現，所以有必要在翻譯的過程中逐步建立一套關鍵字的索引機制（通常是陣列 中索引比較小的那些條目）讓舊的翻譯者能夠回顧，新的翻譯者也在進場後先查閱這些條 目。這就像是給翻譯人員用的教學。 第三是翻譯的進度也是滾動式的，翻譯者隨時都可以進場，以追上原文的進度為目標 。在重大版本的釋出時，做一個驗證，只有達到一定程度翻譯完成的進度的語系。才會被 打包進入版本交付給玩家。 -- "May the Balance be with U"(願平衡與你同在) 遊戲設計教學，討論，分享。歡迎來信。 黑水溝歷史文庫 https://ndark.wordpress.com/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.193.160.149 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1732275957.A.0AD.html