• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            策劃與程序和美工的溝通

             
              對于游戲的熟悉程度,估計沒有哪個開發人員會比游戲策劃更清楚了。大到游戲框架,小到界面熱鍵,一點一滴都需要策劃人員進行詳細的描述和設計,也只有策劃才能對游戲的實現情況進行全面的把握。所以一旦策劃和其他開發人員發生溝通上的障礙,整個項目的進展就會受到極大的影響;如果策劃能夠協調好各部分的工作,那么項目進展就只需要看個人能力了。而在現實開發中,策劃人員由于自身的個性或者其他條件所限,往往在溝通這個環節上出現一些致命問題導致進度的延誤。如何把握好自己的情緒,從大局觀出發是成為一個成熟策劃人員的關鍵所在。

              文檔不管寫的多詳細,對其他人來講仍然會存在理解上的錯誤或漏洞。策劃經常把注意力都放在了如何把游戲設計的更完善上,而忽視了別人的理解能力和感受。因為對任何一件作品來講,每個人的看法都是不同的,策劃應該知道如何去聽別人的意見并吸收到自己的設計中來。這并不是說堅持自己的立場是錯誤的,而是在大多數情況下策劃本身容易把自己的設計當作一個孤立的個體,對其他外來的思想用全部拋棄的態度來對待,這是極其危險的。就算是別人的意見是多么的滑稽可笑,你也應該認真的聽完并加以分析,任何渠道的意見對你的設計來說都是有益的。

              在前面講過如何書寫流程圖和安排工作進度,在這些設計過程中和其他部門的溝通都是非常重要的。我不提倡大規模的定期會議,因為這樣會影響其他人員的開發進度,而且會導致很多問題的擴大化。公眾場合下不適宜對個人問題進行討論,大量的溝通和談話應該以私人或者小型會議的形式來進行。大部分開發人員不喜歡開會,尤其是這種針對性不是很強的例行會議。所以如果確定要召開會議,那么就一定要先確定這個會議要解決哪些問題,需要哪些人來參加,最后要達到什么樣的效果。純粹為了開會而開會,尤其是一些例行會議是沒有必要的,這樣只會增加別人對你的厭惡情緒,導致關系間的不協調。如何盡可能減少大規模會議,通過單獨會談來解決問題是溝通的一個有效手段。

              如果你想知道其他人員對你的策劃方案是否有意見,單純的把文檔發送給程序或美術不是一個好辦法。無論你的文檔多詳細,別人都很難完整的理解你的意思,利用好黑板和紙筆通過講課的方式進行溝通,可以一次性讓大量的相關人員了解你的設計。在講解完畢后讓大家以發表見解的方式來發現并解決問題才是有效的解決手段,你所要做的只是把你的想法表述給大家,而不是爭吵。在你的講解過程中要以聽為主,對于一些核心內容進行強調,認真做好筆記,在會議后對別人的意見進行總結,讓別人知道他的看法你是很重視的。只有對別人尊重別人才會尊重你,想處理好與他人的關系首先就是讓別人感覺到你對他的意見是重視的。

              在完成了第一次講解后,就不要再召集這種大規模的會議了。剩下的工作你就應當找對應的工作人員進行單獨會面,只和他談有關他這個方面的設計問題。對程序就是描述游戲流程以及一些需要確認的技術實現問題,而和美術則應該談界面實現以及整體效果等問題。

              給程序員交流要求你能跟的上他的邏輯思路,就是說你要對計算機的編程有個大概的了解。起碼你應該知道程序流程是通過條件分支、循環以及函數等組成的,而且要對面向對象的C 語言有一些了解,否則他會認為你的思路太混亂而產生很多理解上的概念混淆。最好你是拿著一個游戲設計流程圖來和他交流,這張圖應該類似于程序設計的流程圖,由幾種基本的圖形和線條來實現。這樣一邊描述你的思路一邊給他指出需要完成的模塊,發現問題進行記錄并修正你的文檔就能夠讓雙方都保持清醒的頭腦,而不是產生做出來產品后和你所想象的完全是兩個東西。這時經驗就會起到非常關鍵的作用,如果策劃本身就是程序員或者做過程序員就完全不用考慮這個問題了,可如果你對程序一竅不通或者根本就不知道那些東西是怎么實現的,那你最好去找本介紹編程基礎的書看一下。多和主程交流應該是最省事的辦法,只要交代給他哪些工作需要在多長時間完成就可以了,但很多情況下是主程和策劃一樣固執,這時他會不經過考慮就告訴你很多想法都是不能實現的。你要拿出詳細的解決方案才可以說服他,或者讓他提出一種合適的解決方案。總之,用程序的思路來和程序員進行交流是最好的解決辦法,給程序員一份詳細的流程圖要比給他一份幾百幾千頁的文字說明要管用!

              給美術人員交流更困難。因為每個人的美術風格都不相同,要求幾十個美術人員畫同樣一副圖你所獲得的結果肯定千奇百怪!通過主美進行協調是一個好辦法,這樣可以減少你很多口舌的。在你寫策劃方案時,不要對美術做太多的要求,而應該先和主美術確定好游戲的整體美術風格。美術方面具體的人員安排和工作量限定等事情都交給主美術或者美術總監去處理,除非說你對美術非常精通能夠把握住整體風格,否則你的工作只是描述你需要什么樣的東西就可以了。當美術完成樣品后,一起和主美術進行審查,風格一旦確定就不要再修改了,否則這對美術人員來說完全是種摧殘!美術人員工作量往往是最大的,美術風格的改變可能會造成大部分工作的重做,從而嚴重影響工程進度。把交流的事情交給美術方面的負責人,這是最好的同美術人員的交流方法。

              保持好自己的心態,用積極的態度來解決問題,不要抱怨多聽別人的想法是一個策劃人員需要掌握的基本方法。只有溝通順暢才能夠讓項目按計劃進行,擴大自己的知識面,多和主程與主美交流,少開大規模會議,用私人交談的方式來解決問題。把握好上述幾點,項目的完成就只是時間上的問題了。

            posted on 2009-05-19 14:19 RedLight 閱讀(255) 評論(0)  編輯 收藏 引用 所屬分類: 策劃與游戲設計

            <2009年6月>
            31123456
            78910111213
            14151617181920
            21222324252627
            2829301234
            567891011

            導航

            統計

            公告


            Name: Galen
            QQ: 88104725

            常用鏈接

            留言簿(3)

            隨筆分類

            隨筆檔案

            相冊

            My Friend

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            99久久99久久精品国产| 99久久无色码中文字幕| 亚洲精品tv久久久久久久久久| 久久综合伊人77777| 久久WWW免费人成一看片| 久久精品国产亚洲AV香蕉| 久久福利青草精品资源站| 人妻中文久久久久| 国产精品青草久久久久婷婷| 精品久久久久一区二区三区| 久久国产免费直播| 久久国产成人精品国产成人亚洲| 思思久久99热只有频精品66| 国产成人精品久久综合| 波多野结衣AV无码久久一区| 久久久久久久综合日本亚洲| 国产香蕉久久精品综合网| 亚洲午夜久久久精品影院| 亚洲精品无码久久久久| 色综合久久天天综线观看| 中文字幕亚洲综合久久| 久久夜色精品国产网站| 久久99九九国产免费看小说| 丁香五月综合久久激情| 精品久久久无码人妻中文字幕豆芽| 久久婷婷人人澡人人| 久久最新精品国产| 996久久国产精品线观看| 亚洲色欲久久久综合网| 日韩人妻无码一区二区三区久久99| 国产巨作麻豆欧美亚洲综合久久| 久久久久亚洲AV无码永不| 久久偷看各类wc女厕嘘嘘| 亚洲人成精品久久久久| 99久久国产综合精品女同图片| 伊人久久大香线蕉无码麻豆| 人妻少妇精品久久| 欧美国产成人久久精品| 国产亚洲精品久久久久秋霞| 久久精品国产2020| 国产综合久久久久久鬼色|