史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 作業系統操作技術文件
忘記密碼?
論壇說明

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2004-10-16, 08:30 AM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 日本 GAME 製作方式

專案目管理檢討

一、 現階段問題點

(1) 組織架構

公司與項目應有不同之架構

(2) 各職務定位

各職務工作執掌與權責須劃分更加清楚,特別是各部經理與總監。

(3) 項目經理與製作人的角色差異

須更進一步劃分工作執掌與權責

(4) 專案目管理


尚未進行,項目是否已算成立? 不清楚界定標準。


二、 附錄 (參考資料)

(1) 何謂專案目管理?

針對特定目標的一系列規劃、組織、人事、上司與控制等活動,其目的在有效運用組織內人力、物力、財力等資源,以達成組織目標。


規劃 為設定項目發展目標、制定政策、研擬原則及實施步驟,及如何達成該目標的基本程序。
設定目標:


目標必須寫下來。

必須讓所有參與者都能清楚明白它的意思。
研擬原則的要點:


1. 要把欲達到的結果,清楚地表達出來。

2. 這些結果要合理可行。設立一個難以達到的目標,會使參與的人望而卻步。

3. 要把一系列的行動細節,詳盡地陳述出來。


4. 必須指定負責人,使整個計劃能因此而推動、進行。

5. 要提供合理的資源。

6. 計劃的每一個階段,均須有時間表。

7. 要設立工作表現的標準,以衡量所欲達到的成就。


組織 為了達成共同的目的,規定各個角色的職務,並依據一定的權限與責任的分配,決定各職務間相互的關係。


管理人必須知道自己究竟負責哪些活動,哪些人需對自己負責、自己又該對哪些人負責。


此外,管理人還必須清楚整個公司的結構、自己在公司的位置、可以使用哪些溝通管道等。


這些都必須以達成部門和公司的目標為主,並且定下所要完成的效果,最後再用文字陳述出來。



許多公司都把組織營建在員工身上,而不是先決定所要的結果,然後再尋找適當的人選來佔據那些職位。通常,小公司並沒有真正的組織架構,都是把現有人員分配去做所有的工作。


不用多久,又會有另一批人被聘來分攤各部門的工作。


一個簡陋架構的公司,有時也能維持好幾年的時間,但這樣很難繼續維持成長。



為了讓企業成功,整個組織必須以「結果為導向」作為建築架構的基礎。公司的目標需明確且實際可行,整個管理工作也必須以達成公司的目標來進行。



公司的架構完全依照所要達成的結果來設計–––每個職位是專為達成某個目的而設,然後再找尋最適當的人選來執行職務。



人事 甄選優秀人員於適當職位上,從事項目各項工作,並培訓他們,以增進工作效率,提升人力素質。


上司 根據項目規劃所制定的原則與工作進度,啟始、影響與鼓舞成員完成工作的行為。
控制 將成本、進度、品質控制在預定的範圍之內。


(2) 項目經理 (Project Manager)


「項目經理」為項目團隊之主管,負責指派及上司工作人員進行項目工作,對上級主管或顧客負責項目成敗,並解決項目內各項問題,實為項目之靈魂人物,亦可謂專案目管理之重心與中心。




(3) 產品經理 (Product Manager)


負責整個產品的處理程序,從研究調查、製造與銷售。


直到產品變成普通生產線的一部份時,「產品經理」仍須負責「維持」與「成長」的工作。

(4) 製作人 (Producer)
一個遊戲的總指揮,從遊戲製作到販賣所有流程都是由遊戲製作人負責。


遊戲製作人可以說是一款遊戲的導演,他必須要掌控遊戲發展的大方向。

其工作範圍包含監督開發工作、掌控遊戲進度、重要事項決定、遊戲預算控制。


同時也是研發團隊與公司之間的視窗,隨時進行雙方面的協調與管理,如何能夠面對雙方,並且妥善的將雙方的訊息傳達,也是遊戲製作人最重要的工作之一。



(5) 執行製作人 (Executive Producer)
執行製作人與遊戲的製作一起工作,其工作範圍包含開發工作分配、執行製作的執行、相關工作的檢查。身為執行製作人需要有較佳的溝通協調與管理的能力。


雖然遊戲製作人也同樣有管理的職權,但遊戲製作人並不能隨時與遊戲研發在一起,所以執行面由執行製作人來負責。



(6) 監製 (Director)


發包、工作分配、製作流程管理、遊戲製作行程管理等實際製作發場的負責人。十分類似工地裡的工頭。


(7) 企劃 (Planner)

撰寫遊戲的企劃書。在這個部分裡,遊戲企劃可以寫出許許多多不同的方式或是系統,寫的越多,遊戲設計人員的選項機會也越多。


而且企劃在撰寫企劃或是新點子的時候,可以發揮充分的想像力,不需要考慮到硬體或是軟體的執行能力,只要是想的到新點子都可以寫在企劃案裡。當然企劃案也不能遠離原本企劃會議中所討論出來的大方向。


(8) 遊戲設計師 (Game Designer)


將遊戲企劃所寫作的企劃書遊戲化,也就是付諸實行。針對遊戲企劃所寫的企劃書中哪裡不合理或是哪裡需要加強的部分,加以移除或是修正,然後真正使之成為遊戲中的一部份。


根據遊戲規模的大小,這個部份中又會細分為遊戲系統設計、戰鬥系統設計、道具系統設計、格鬥系統設計等諸多不同內容設計,每一項工作都會有專長該方面的遊戲設計人員負責。



(9) 編劇 (Scenario Writer)


撰寫遊戲中所有的故事、劇情。有時候這個部分也會邀請非遊戲業界的人來寫劇本。比如說著名的小說家或是劇本作家。會邀請著名小說家撰寫劇本的遊戲大多是冒險遊戲或是角色扮演。


這類遊戲的做法可以讓遊戲的故事內容更加吸引玩家,也可以說是遊戲的賣點之一。將來在宣傳方面也有很大的說明 。


(10) 角色設計師 (Character Designer)
設計創造遊戲中所出現的所有角色。在日本遊戲界中,這個部分也常常會邀請非遊戲業界人員擔任。

比如說著名的漫畫家、插畫家就常常為遊戲設計人物造型。


這樣的做法在日本遊戲界中十分盛行,因為如果邀請到著名漫畫家或是插畫家為遊戲設計人物,通常會使銷售量提升。像鳥山明(七龍珠作者)為「勇者鬥惡龍」系列設計人物、橫山光輝的「三國誌」系列、天野喜孝(日本著名插畫家)為「太空戰士」系列設計人物插畫等等,都讓遊戲的知名度在發售前就已經提高很多。


(11) 2D插畫師 (2D Illustrator)
設計背景或是平面角色。此外也細分成為只製作材質貼圖(背景、物體表面的質感、表面貼圖)的MAPPER和專門畫位圖的DOTER。


(12) 3D插畫師 (3D Illustrator)

製作3D角色或是開頭、過場、結束CG電腦動畫。
(13) 日本遊戲開發流程

草案製作
目前,擁有精英的遊戲製作公司,絕對不是一開始就投入所有人力開始撰寫程序而是先將遊戲製成像「草案」(在日文中的說法稱為「企劃書」)這樣的書面基礎(base)。


  草案其實是沒有類BIOS的格式(STYLE),少的時候有可能只是兩三頁A4大小的紙張,多的時候也有可能是包括參考資料而多達五十幾頁,草案的格式可以說是形形色色。

依照遊戲製作公司的習慣、企劃人員的不同、甚至是遊戲製作計畫的不同,企劃的書寫格式也都不盡相同!此外,有些草案是透過許許多多次Brain Storming(集體創造性會議,公司企劃人員或是其它有好創意的製作人員帶著自己的新創意所參加的會議),經過不斷的討論與建議,而由多位企劃製作人員所共同撰寫出來的。


  一般大家都會以為遊戲的草案,是將企劃者的創意很詳細很詳盡地書寫在草案中,但是實際上卻不是這個樣子!草案實際上只要概略地敘述「這是個什麼樣的遊戲」就可以了。


也就是說,傳達遊戲的概略就是草案的使命。
所以說草案其實不是為了遊戲製作開發而產生的,草案的存在是為了讓相關製作人員瞭解企劃者所要傳達的想法意念(Image)。

也就是說,這樣的草案是讓經營者判斷是否可以將這樣的創意商品化、讓業務販售人員評估銷售量、讓其它製作人員加入不同的意見或是更好的想法,草案在專業的遊戲製作公司裡的主要目的便是如此。


隨著草案,有關遊戲玩法的規則會被寫在草案中,此外「什麼好玩?哪裡好玩?」也是草案中必須書寫的基本條件!許多業餘或是專業的企劃人員,常常在草案中加入攏長壯大的故事劇本或是詳細的角色資料設定。

其實這些有關遊戲的細部設定在草案中都是多餘的。草案可說是說明遊戲「好玩的地方」的最佳方式,因此如何將企劃者所要表達的意念精簡地集結起來就是件十分重要的事。


當企劃者將遊戲中「好玩」的核心點明確地表達出來之後,接下來便是將「開發對應平台?」、「預定發行的時間?」、「適合什麼樣的年齡層?」、「遊戲主要構成畫面草圖(Rough Continuity)」等資料加入,如果有必要的話可以再附上一些參考資料。具備這些東西之後,就算是完成一個草案!

u 決定草案、開始製作企劃書
PS:事實上「企劃書」在日本遊戲製作業界的說法裡是被稱之為「仕樣書」!翻譯成中文為「規格書」。


所以,日本所謂「企劃書」如同我們所謂的「草案」、日本所謂「仕樣書」如同我們所謂的「企劃書」。


  草案完成之後,接下來就是等待篩選的命運。不是所有的草案完成之後都可以被商品化,只有優秀的草案才可以走上實際製作→商品化→發售這樣的程序。


也就是說,事實上遊戲軟體的激烈競爭早在製作成商品擺在市場上販賣之前就已經開始了。

一般來說,只要是稍具規模的遊戲製作公司都會隨時擁有100份以上還未商品化的遊戲製作草案。


這些草案不僅僅都是來自公司內部開發部門企劃人員的筆下,有許多也都是從公司外部募集而來的。由此可見,企劃人員想讓草案商品化的競爭情況實際上是十分激烈的。


  當一份草案經過層層嚴格篩選而雀屏中選之後,遊戲製作的流程也正式從草案階段移到企劃書(規格書)製作階段。企劃書是讓企劃(PLANNER)將自己的想法傳達給程序設計(PROGRAMMER)、圖形設計(GRAPHIC DESIGNER)...等製作小組成員的文件。
psac 目前離線  
送花文章: 3, 收花文章: 1631 篇, 收花: 3205 次
舊 2004-10-16, 08:35 AM   #2 (permalink)
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設

企劃書與草案不同,它不可以是只是「知道遊戲的概略」。而是必須將遊戲中所以大大小小的設定,十分具體地寫到企劃書當中。


從遊戲的開始畫面到遊戲結束畫面、畫面中任何一個角落的表現設定、分數的計算方式、角色的動作...等,遊戲中會出現的任何事件任何事物,都必須在清清楚楚地寫在遊戲企劃書中。


所有與遊戲製作相關的成員,都是以此份企劃書為基礎來執行製作工作,可見這份企劃書的重要性(因此日本會將我們通稱的「企劃書」稱之為「規格書」,也不是不無道理!)。

打個比方來說,企劃書就好比正在建築房屋時所繪製的設計圖一樣。


在撰寫草案階段的創意(Ideas)往往都是很模糊的想法或是個臨時想到的,所以也就沒有很仔細地思考到遊戲的細部結構。


而企劃書則是將原本沒有仔細思考的事物,仔仔細細地書寫到文件上。所以撰寫企劃書的時候,便需要不斷地收集資料,按部就班一步一步都不可馬虎的執行。


  企劃書的撰寫方式,也會依據遊戲製作公司的不同、遊戲內容的不同而有所變化。比如說以一個一個畫面為服務機構的畫面服務機構指導書或是以登場角色來區分的指導書。


所以,事實上企劃書的構成格式是很自由的,撰寫人員可以依照自己習慣而別人又看的懂的方式來撰寫。


同樣是說明角色的動作,企劃書可以用「到達頂點之後暫停一下而後迅速落下」這樣的文字敘述方式,也可以使用圖畫或是圖
解的方式來表示。甚至有時為了讓程序設計人員可以更清楚瞭解,也會使用到計算公式或圖表的方式來表示。


所以,企劃人員表達創意的方式可以是五花八門的。也就是說,企劃書最主要的目的,是讓製作成員瞭解自己需要做些什麼,所以企劃人員是不需要拘泥企劃書中的章節、寫法、體裁。最重要的事與開發團隊成員的意見溝通。


  企劃書要傳達的訊息是相當多的,所以一份企劃書頁數有時也是相當驚人。


特別是像劇本故事結構十分龐大,故事情節分歧管理十分不容易的RPG遊戲,企劃書的頁數更是多的驚人。



而如果真要要說明到底有「多少頁」的話,還不如用「幾公分厚」或是「幾個紙箱」這樣的服務機構還比較適當。


在日本遊戲界常常會聽到這樣一句話:「遊戲才一開始製作,馬上有一整面牆的櫃子裡全都是參考書籍以及企劃書資料」。

專業的遊戲製作公司的草案是相當簡潔,而企劃書則是相當緊密有系統的。所以說,或許大家都不相信,但事實上遊戲一開始製作的時候,其企劃書已經是厚厚的一疊,甚至是裝滿一整個紙箱了。


u 與專業人員組成專業團隊

到目前為止遊戲的製作流程都是單一流程,而且遊戲製作都是集中在以企劃人員(PLANNER)為中心的少數製作人員身上。

不過,當企劃書即將完成之前,便要開始進行整個製作小組人員的整合。而且從這個時候開始,許許多多的工作是平行地同時進行。以下就為大家大略介紹一下流程。



  一般來說,首先整合到執行計畫中的是不使用電腦的工作人員。這裡所謂的「不使用電腦」── 是指公司外部的劇本作家或是角色設定的原作家等人。


這些公司外部的原作者們其實在草案完成的同時,企劃人員(PLANNER)便開始與他們不斷溝通協調,並開始撰寫劇本或是繪製人物造形的工作。

為什麼是這樣的流程呢?那是因為紙上作業的工作是必須在程序設計工作開始之前就必須完成的。

所以這些公司外部的原作者的工作都必須在其它工作人員前完成。


  接下來是將程序設計人員(PROGRAMMER)整合到執行計畫中。


雖然說在企劃書撰寫的同時,企劃人員(PLANNER)已經不斷地與設計人員(PROGRAMMER)溝通協調遊戲內容、表現方式等,但是設計人員(PROGRAMMER)真正忙碌是從這個時候開始。

在初期,程序設計人員(PROGRAMMER)會是先撰寫整個遊戲系統的主要程序,比如說主角的動作、畫面顯示系統等。

程序設計在遊戲製作工作前期,就是建立遊戲系統的基礎。


這樣的工作如果以繪畫的世界來比喻的話,就是準備繪畫用紙、準備畫具以及顏料、然後描繪出圖畫的輪廓。


前期工作盡可能將細節的部分完全去除,而以遊戲系統基本根基以及骨幹程序為主。


為什麼是這樣的是製作流程呢?事實上很多遊戲在企劃階段會遇到有如「有辦法將企劃人員腦海裡所企劃的事物表現出來嗎?」「自己所想的真的會好玩嗎?」,為了證明這些疑慮,企劃人員就可以藉由程序設計人員先期所製作出來實際會動作的畫面來判斷。


這樣的試作遊戲在日本被稱之為「PROTOTYPE」。

這樣的「PROTOTYPE」可以先期驗證遊戲是否真的好玩,如果驗證結果是確定的,那整個遊戲的製作便可以朝完整版的工作繼續進行下去。


  有時候依據情況的需要,程序設計人員不會先直接撰寫遊戲程序,而是先製作「工具(Tool)」、「編輯器(Editor)」等開發用的工具。這就好比在蓋房子之前,先把鋸子等工具做好是一樣的意思。把工具、編輯器等程序都準備好,當遊戲製作到後期時對於動作編輯、地圖編輯等的工作便可以很有效率地進行。



  圖形設計人員(GRAPHIC DESIGNER)的工作幾乎是與程序設計人員同時進行的。在日本遊戲製作公司裡,圖形設計人員大多都是使用相同的CG專用開發電腦來製作遊戲圖像。所以所有圖形設計人員的桌面上都是擺著相同CG專用開發電腦,那樣的場面看起來是很壯觀的。



  雖說是製作映像的資料,不過遊戲中的CG並不是只是一張大張的圖畫而已,而是分為很多不同的元件(Part)。


比如說,角色人物的話就專門繪製角色人物,或是建築物的話就專門繪製建築物。這些各自負責自己所分配到部分的圖形設計人員,最後就會將一開始就準備好的原畫逐一製作組合成3DCG。


  3DCG的製作,首先會先從製作以多邊形(Polygon)組合起來的立體對象開始。在日本,像這樣的立體圖像製作工程被稱之為「Modeling」,而從事這樣工作的專業人員則被稱之為「Modeler」。

這些專業工作人員幾乎都是使用3DCG專用的開發工具來完成「Modeling Data」,但是這樣的Modeling Data只是一種擁有線條而沒有顏色的圖像,稱之為「模型的線架構(Wire Frame)」。
psac 目前離線  
送花文章: 3, 收花文章: 1631 篇, 收花: 3205 次
舊 2004-10-16, 08:37 AM   #3 (permalink)
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設

而接下來的工作是將顏色、材質、燈光等貼上,這樣的工作稱之為「貼圖(Texture Mapping)」。

接下來,這個有形狀又有顏色的圖像資料便要再被加入稱之為「Animation Pattern」的動作資料,這樣就成為會活動的3DCG。


在目前的動畫科技裡,也加入了可以將人類的動作轉換成電腦資料的「動態捕捉系統(Motion Capture)」以及可以將真實物體外型轉換成電腦模型的「3D掃瞄系統(3D Scanner)」。


  接下來是音樂製作的部分。相對於圖形製作的團體工作,音樂製作是屬於比較個人性質的工作。


遊戲音樂的作曲負責人在遊戲草案完成的時候,便要開始配合遊戲加入音樂的影像(Image)。


這個時候並還沒有開始作曲,而是僅止於思考整個音樂風格的走向,是要搖滾風格比較好呢?

還是要古典風格比較好呢?

這段時間可以說是音樂作曲家的摸索時期。


企劃書的完成,接下來便是將遊戲畫面體地呈現給作曲家,「到底用什麼樣的曲子比較好?」「曲子長度要製作幾分幾秒的比較好?」,這些問題在此時也漸漸明確化。


所以大部分的作曲家都是在這個時期開始進行音樂旋律的製作。接下來,負責音樂的人員就要實際操作一個個已完成的遊戲畫面,依據遊戲要表達的意念配上適當的音樂音效。


  為什麼遊戲音樂要配合著一邊操作畫面來進行編曲呢?
這是因為遊戲的場面會依照玩家的意念與偶發的狀況而有所不同,這是與電影、廣告不同。

比如說「GAME OVER」的曲子在何時連接什麼樣的曲子是最可以表示玩家的心情?玩家在什麼樣的場面之下最可以感到緊張的氣氛?
這些都是需要音樂創作人員實際去操作遊戲、實際去感受遊戲,然後再慢慢地調整出遊戲音樂的曲調、曲子與曲子之間的連接,甚至是出現的時機、長度等。所以說製作遊戲的音樂其實也是件十分辛苦的工作。


u 協調、協調、再協調
完整的企劃書、完整的製作小組、完整的製作流程,但許許多多問題還是會伴隨著整個遊戲製作程序。而且隨著各部門工作的進行,麻煩問題會越來越多,也越來越嚴重。


  比如說常常遇到的就是與記憶體相關的問題。


雖然說目前的遊戲主機的記憶體已經比以前多了許多,但是畢竟還是有所限制。

所以遊戲製作計畫一開始時,一般來說便會開始進行各部分記憶體大小的分配工作,如圖形使用○○M、主程序使用○○M、音樂使用○○M。


不過隨著製作工作的進行,往往都會有超出原本記憶體容量設定的問題產生。原因有很多,比如企劃書階段時期計算錯誤、開發小組能力不足、某部門開發小組需要更大的記憶體容量來表現遊戲效果…等。


這個時候製作人(PRODUCER)或是監製(DIRECTER)便必須明確地的判斷。是否還有其它多餘的記憶體容量可以分配?是否削減哪個部分的記憶體容量?是否變更成其它規格?解決的方式雖然有很多種,不過與記憶體相關的麻煩問題是任何一組遊戲製作小組都會遇到的煩惱!


  接下來一般的便是不斷循環的「可能」與「不可能」這樣的問題。在遊戲製作現場中,我們常常會聽到「可能」與「不可能」這兩句話。經大家討論之後,企劃人員將一個新的創意寫入企劃書中後,理論上就應該會是可行的。但是實際作業的時候,程序設計人員又常會出現「這種新創意是不可能做到」的遺憾。


上述的事件對遊戲製作現場的人員來說都是家常便飯,常常發生的狀況。企劃人員會說:「這是可以辦到的吧!你一定要做出來!」,程序設計人員會說「不可能!我做不出來!」,兩部門人員間的緊張火爆氣氛也就時而發生。協調處理這樣的問題(包括組員間相處人際關係)也都是製作人或是監製十分重要的工作。


  除此此外,集合了這麼多位工作人員的大型製作工作,人與人之間的溝通協調問題都是層出不窮。「應該可以再可愛一點」、「我要一種無形的感覺」、「運用比較有速度感的反應方式」……在遊戲製作現場中,在開發小組的成員之間,像上述那樣十分抽像的語言可說是隨時都可以聽到。

因此,發言者的想法與聽到話語的人的理解程度有微妙的差異,甚至是文不對題也都是時有所聞。在遊戲開發程序中,光是要讓所有製作小組成員製作出來的作品保持一定的風格就是一件相當費力的工作。


  其實製作程序中遇到麻煩也不全都是不好的事,有時也會遇到讓人覺得高興的麻煩。比如說,遊戲製作到一半的時候,突然有人說「如果這樣做的話一定會更好玩!」。

從企劃書階段之後經過幾個月,也實際製作出會動的畫面之後,上述的情況就常常會發生。不過是不是要採用預定以外的創意?如果採用了,那既定的工作時間又要從新排定,這對於整個製作小組就會是個大麻煩。當一個很好的新點子、新創意突然浮現腦海的同時,一大堆麻煩的工作調整問題也隨之而來,這就是遊戲製作工作。


遊戲製作工作到了後半段時期,有許多麻煩的問題也會隨著分解到各個製作人員的身上,如何解決這些問題,也就相對成為每位工作人員工作的一部分。有遊戲開發經驗的人員採用負責人在面試的時候,常會說:「遊戲製作人員必須要有很強的抗壓力」。其理由為何,相信也就不需多作解釋了。



u 各部分完成後進入測試工作
當開發人員最辛苦的時期結束的時候,也就是遊戲各部分都完成的時候。



完成的所有資料會全部集中到主程序設計人員的手上。

圖形資料、音樂資料、劇本等文字資料,再加上其它細部的的程序資料,都是在這個階段完成整合。


如果是角色扮演遊戲、射擊遊戲、戰略模擬遊戲等,其遊戲中角色的各種設定數值也都市在這個階段中加入。這樣也就完成游系的試玩版。


  最初完成的試玩版,在日本一般稱作「α版」,使用這個版本製作人員可以進行簡單的Test Play。當然在試玩的程序中,如果有不正常的錯誤就會馬上進行修正,此外也會開始進行遊戲難易度調整。即使整個遊戲製作程序經過十分嚴密組態,但是因為是各部門分工合作,所以還是會出現「看得到樹卻看不到森林」這樣的缺失。像這樣將樹木一顆顆地修正,使其看起來像是一片森林,便是試玩版中必要的修正工作。


  將「α版」中各部分所有的錯誤、不合理的地方加以修改之後,再一次將所有資料整合,這個試玩版便被稱作「β版」。這個版本中的內容基本上與玩家將來在市面上買到的版本內容是一模一樣的。不過由人類做出來的軟體不會是十全十美沒有任何錯誤的。這樣的錯誤在程序設計人員間被稱作「BUG」。因此接下來的工作便是找出這些躲在程序中的「BUG」,並加以修正去除。


假設遊戲中所有會出現的任何狀況,從遊戲訊息一個文字的小小錯誤到會導致遊戲當機的重大錯誤,都必須一點一滴仔仔細細去找出隱藏其中的「BUG」。


這樣的工作也被稱作「Debug」,一般會由開發小組所有組員或是公司外部的工讀人員,甚至會動員到公司其它部門的工作人員。

不論是多麼辛苦所製作出來的遊戲,只要遊戲中出現任何一點小小的錯誤而導致當機,便成了沒有用的「不良品」。


雖然對開發人員而言,遊戲製作流程到了Debug之前的階段是算是可以鬆口氣的時候,但是接下來的Debug工作卻也是最後最重要的大工程。經過上述的程序之後,就到了遊戲軟體的最終版本「Master」,接下來就是等候壓片量產。
psac 目前離線  
送花文章: 3, 收花文章: 1631 篇, 收花: 3205 次
 



發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 12:53 PM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2024, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1