專案管理檢討
一、 現階段問題點
(1) 組織架構
公司與專案應有不同之架構
(2) 各職務定位
各職務工作執掌與權責須劃分更加清楚，特別是各部經理與總監。
(3) 專案經理與製作人的角色差異
須更進一步劃分工作執掌與權責
(4) 專案管理
尚未進行，專案是否已算成立? 不清楚界定標準。
二、 附錄 (參考資料)
目前，擁有精英的遊戲製作公司，絕對不是一開始就投入所有人力開始撰寫程式而是先將遊戲製成像「草案」（在日文中的說法稱為「企劃書」）這樣的書面基礎（base）。
草案其實是沒有固定的格式（style），少的時候有可能只是兩三頁a4大小的紙張，多的時候也有可能是包括參考資料而多達五十幾頁，草案的格式可以說是形形色色。依照遊戲製作公司的習慣、企劃人員的不同、甚至是遊戲製作計畫的不同，企劃的書寫格式也都不盡相同！此外，有些草案是透過許許多多次brain storming（集體創造性會議，公司企劃人員或是其它有好創意的製作人員帶著自己的新創意所參加的會議），經過不斷的討論與建議，而由多位企劃製作人員所共同撰寫出來的。
一般大家都會以為遊戲的草案，是將企劃者的創意很詳細很詳盡地書寫在草案中，但是實際上卻不是這個樣子！草案實際上只要概略地敘述「這是個什麼樣的遊戲」就可以了。也就是說，傳達遊戲的概略就是草案的使命。所以說草案其實不是為了遊戲製作開發而產生的，草案的存在是為了讓相關製作人員了解企劃者所要傳達的想法意念（image）。也就是說，這樣的草案是讓經營者判斷是否可以將這樣的創意商品化、讓業務販售人員評估銷售量、讓其它製作人員加入不同的意見或是更好的想法，草案在專業的遊戲製作公司裡的主要目的便是如此。隨著草案，有關遊戲玩法的規則會被寫在草案中，此外「什麼好玩？**好玩？」也是草案中必須書寫的基本條件！許多業餘或是專業的企劃人員，常常在草案中加入攏長壯大的故事劇本或是詳細的角色資料設定。其實這些有關遊戲的細部設定在草案中都是多餘的。草案可說是說明遊戲「好玩的地方」的最佳方式，因此如何將企劃者所要表達的意念精簡地集結起來就是件十分重要的事。當企劃者將遊戲中「好玩」的核心點明確地表達出來之後，接下來便是將「開發對應平台？」、「預定發行的時間？」、「適合什麼樣的年齡層？」、「遊戲主要構成畫面草圖（rough continuity）」等資料加入，如果有必要的話可以再附上一些參考資料。具備這些東西之後，就算是完成乙個草案！
決定草案、開始製作企劃書
ps：事實上「企劃書」在日本遊戲製作業界的說法裡是被稱之為「仕樣書」！翻譯成中文為「規格書」。所以，日本所謂「企劃書」如同我們所謂的「草案」、日本所謂「仕樣書」如同我們所謂的「企劃書」。
草案完成之後，接下來就是等待篩選的命運。不是所有的草案完成之後都可以被商品化，只有優秀的草案才可以走上實際製作→商品化→發售這樣的過程。也就是說，事實上遊戲軟體的激烈競爭早在製作成商品擺在市場上販賣之前就已經開始了。一般來說，只要是稍具規模的遊戲製作公司都會隨時擁有１００份以上還未商品化的遊戲製作草案。這些草案不僅僅都是來自公司內部開發部門企劃人員的筆下，有許多也都是從公司外部募集而來的。由此可見，企劃人員想讓草案商品化的競爭情況實際上是十分激烈的。
當乙份草案經過層層嚴格篩選而雀屏中選之後，遊戲製作的流程也正式從草案階段移到企劃書（規格書）製作階段。企劃書是讓企劃（planner）將自己的想法傳達給程式設計（programmer）、圖形設計（graphic designer）．．．等製作小組成員的檔案。企劃書與草案不同，它不可以是只是「知道遊戲的概略」。而是必須將遊戲中所以大大小小的設定，十分具體地寫到企劃書當中。從遊戲的開始畫面到遊戲結束畫面、畫面中任何乙個角落的表現設定、分數的計算方式、角色的動作．．．等，遊戲中會出現的任何事件任何事物，都必須在清清楚楚地寫在遊戲企劃書中。所有與遊戲製作相關的成員，都是以此份企劃書為基礎來執行製作工作，可見這份企劃書的重要性（因此日本會將我們通稱的「企劃書」稱之為「規格書」，也不是不無道理！）。打個比方來說，企劃書就好比正在建築房屋時所繪製的設計圖一樣。在撰寫草案階段的創意（ideas）往往都是很模糊的想法或是個臨時想到的，所以也就沒有很仔細地思考到遊戲的細部結構。而企劃書則是將原本沒有仔細思考的事物，仔仔細細地書寫到檔案上。所以撰寫企劃書的時候，便需要不斷地收集資料，按部就班一步一步都不可馬虎的執行。
企劃書的撰寫方式，也會依據遊戲製作公司的不同、遊戲內容的不同而有所變化。比如說以乙個乙個畫面為單位的畫面單位指導書或是以登場角色來區分的指導書。所以，事實上企劃書的構成格式是很自由的，撰寫人員可以依照自己習慣而別人又看的懂的方式來撰寫。同樣是說明角色的動作，企劃書可以用「到達頂點之後暫停一下而後迅速落下」這樣的文字敘述方式，也可以使用圖畫或是**的方式來表示。甚至有時為了讓程式設計人員可以更清楚了解，也會使用到計算公式或圖表的方式來表示。所以，企劃人員表達創意的方式可以是五花八門的。也就是說，企劃書最主要的目的，是讓製作成員了解自己需要做些什麼，所以企劃人員是不需要拘泥企劃書中的章節、寫法、體裁。最重要的事與開發團隊成員的意見溝通。
企劃書要傳達的資訊是相當多的，所以乙份企劃書頁數有時也是相當驚人。特別是像劇本故事結構十分龐大，故事情節分歧管理十分不容易的rpg遊戲，企劃書的頁數更是多的驚人。而如果真要要說明到底有「多少頁」的話，還不如用「幾公分厚」或是「幾個紙箱」這樣的單位還比較適當。在日本遊戲界常常會聽到這樣一句話：「遊戲才一開始製作，馬上有一整面牆的櫃子裡全都是參考書籍以及企劃書資料」。專業的遊戲製作公司的草案是相當簡潔，而企劃書則是相當緊密有系統的。所以說，或許大家都不相信，但事實上遊戲一開始製作的時候，其企劃書已經是厚厚的一疊，甚至是裝滿一整個紙箱了。
與專業人員組成專業團隊
完整的企劃書、完整的製作小組、完整的製作流程，但許許多多問題還是會伴隨著整個遊戲製作過程。而且隨著各部門工作的進行，麻煩問題會越來越多，也越來越嚴重。
比如說常常遇到的就是與記憶體相關的問題。雖然說目前的遊戲主機的記憶體已經比以前多了許多，但是畢竟還是有所限制。所以遊戲製作計畫一開始時，一般來說便會開始進行各部分記憶體大小的分配工作，如圖形使用○○m、主程式使用○○m、**使用○○m。不過隨著製作工作的進行，往往都會有超出原本記憶體容量設定的問題產生。原因有很多，比如企劃書階段時期計算錯誤、開發小組能力不足、某部門開發小組需要更大的記憶體容量來表現遊戲效果…等。這個時候製作人（producer）或是監製（directer）便必須明確地的判斷。是否還有其它多餘的記憶體容量可以分配？是否削減哪個部分的記憶體容量？是否變更成其它規格？解決的方式雖然有很多種，不過與記憶體相關的麻煩問題是任何一組遊戲製作小組都會遇到的煩惱！
接下來常見的便是不斷迴圈的「可能」與「不可能」這樣的問題。在遊戲製作現場中，我們常常會聽到「可能」與「不可能」這兩句話。經大家討論之後，企劃人員將乙個新的創意寫入企劃書中後，理論上就應該會是可行的。但是實際作業的時候，程式設計人員又常會出現「這種新創意是不可能做到」的遺憾。上述的事件對遊戲製作現場的人員來說都是家常便飯，常常發生的狀況。企劃人員會說：「這是可以辦到的吧！你一定要做出來！」，程式設計人員會說「不可能！我做不出來！」，兩部門人員間的緊張火爆氣氛也就時而發生。協調處理這樣的問題（包括組員間相處人際關係）也都是製作人或是監製十分重要的工作。
除此此外，集合了這麼多位工作人員的大型製作工作，人與人之間的溝通協調問題都是層出不窮。「應該可以再可愛一點」、「我要一種無形的感覺」、「運用比較有速度感的反應方式」……在遊戲製作現場中，在開發小組的成員之間，像上述那樣十分抽象的語言可說是隨時都可以聽到。因此，發言者的想法與聽到話語的人的理解程度有微妙的差異，甚至是文不對題也都是時有所聞。在遊戲開發過程中，光是要讓所有製作小組成員製作出來的作品保持一定的風格就是一件相當費力的工作。
其實製作過程中遇到麻煩也不全都是不好的事，有時也會遇到讓人覺得高興的麻煩。比如說，遊戲製作到一半的時候，突然有人說「如果這樣做的話一定會更好玩！」。從企劃書階段之後經過幾個月，也實際製作出會動的畫面之後，上述的情況就常常會發生。不過是不是要採用預定以外的創意？如果採用了，那既定的工作時間又要從新排定，這對於整個製作小組就會是個**煩。當乙個很好的新點子、新創意突然浮現腦海的同時，一大堆麻煩的工作調整問題也隨之而來，這就是遊戲製作工作。遊戲製作工作到了後半段時期，有許多麻煩的問題也會隨著分解到各個製作人員的身上，如何解決這些問題，也就相對成為每位工作人員工作的一部分。有遊戲開發經驗的人員採用負責人在面試的時候，常會說：「遊戲製作人員必須要有很強的抗壓力」。其理由為何，相信也就不需多作解釋了。
各部分完成後進入測試工作
當開發人員最辛苦的時期結束的時候，也就是遊戲各部分都完成的時候。完成的所有資料會全部集中到主程式設計人員的手上。圖形資料、**資料、劇本等文字資料，再加上其它細部的的程式資料，都是在這個階段完成整合。如果是角色扮演遊戲、射擊遊戲、戰略**遊戲等，其遊戲中角色的各種設定數值也都市在這個階段中加入。這樣也就完成游系的試玩版。
最初完成的試玩版，在日本一般稱作「α版」，使用這個版本製作人員可以進行簡單的test play。當然在試玩的過程中，如果有不正常的錯誤就會馬上進行修正，此外也會開始進行遊戲難易度調整。即使整個遊戲製作過程經過十分嚴密配置，但是因為是各部門分工合作，所以還是會出現「看得到樹卻看不到森林」這樣的缺失。像這樣將樹木一顆顆地修正，使其看起來像是一片森林，便是試玩版中必要的修正工作。
將「α版」中各部分所有的錯誤、不合理的地方加以修改之後，再一次將所有資料整合，這個試玩版便被稱作「β版」。這個版本中的內容基本上與玩家將來在市面上買到的版本內容是一模一樣的。不過由人類做出來的軟體不會是十全十美沒有任何錯誤的。這樣的錯誤在程式設計人員間被稱作「bug」。因此接下來的工作便是找出這些躲在程式中的「bug」，並加以修正去除。假設遊戲中所有會出現的任何狀況，從遊戲訊息乙個文字的小小錯誤到會導致遊戲當機的重大錯誤，都必須一點一滴仔仔細細去找出隱藏其中的「bug」。這樣的工作也被稱作「debug」，一般會由開發小組所有組員或是公司外部的工讀人員，甚至會動員到公司其它部門的工作人員。不論是多麼辛苦所製作出來的遊戲，只要遊戲中出現任何一點小小的錯誤而導致當機，便成了沒有用的「不良品」。雖然對開發人員而言，遊戲製作流程到了debug之前的階段是算是可以鬆口氣的時候，但是接下來的debug工作卻也是最後最重要的大工程。經過上述的過程之後，就到了遊戲軟體的最終版本「master」，接下來就是等候壓片量產。
日本專案管理方式和文化
1.中國和日本的文化差異 飯店吃飯 在中國，我到飯店吃飯，發現很多飯店都是要催的，不催他，他就不上菜，但是日本人即使很餓，也不會催促，也就是即使他心裡很不高興，他也不說，不抱怨，但是下一次是絕對不會再來了。但中國人可能很快就會催促，甚至會大聲責怪，但下一次他還有可能來吃飯。所以，和日本企業第一次做軟...
Flash動畫製作快捷方式
箭頭工具 v 部分選取工具 a 線條工具 n 套索工具 l 鋼筆工具 p 文字工具 t 橢圓工具 o 矩形工具 r 鉛筆工具 y 畫筆工具 b 任意變形工具 q 填充變形工具 f 墨水瓶工具 s 顏料桶工具 k 滴管工具 i 橡皮擦工具 e 手形工具 h 縮放工具 z m 新建flash檔案 ctr...
日本14歲初中生因涉嫌製作勒索病毒被逮捕
techweb報道 6 月 5 日訊息，據日本 報道，日本 今日以製作加密電腦資料以索要贖金的 勒索病毒 涉嫌製作非法指令電磁程式設計客棧記錄等為由，逮捕了大阪府高槻市初三男生 14 歲 勒索病毒wannacry 據 介紹，這是該國首次因製作勒索軟體嫌疑而立案。該男生承認了嫌疑。該男生交代稱，製作勒...