對(duì)于游戲的熟悉程度，估計(jì)沒有哪個(gè)開發(fā)人員會(huì)比游戲策劃更清楚了。大到游戲框架，小到界面熱鍵，一點(diǎn)一滴都需要策劃人員進(jìn)行詳細(xì)的描述和設(shè)計(jì)，也只有策劃才能對(duì)游戲的實(shí)現(xiàn)情況進(jìn)行全面的把握。所以一旦策劃和其他開發(fā)人員發(fā)生溝通上的障礙，整個(gè)項(xiàng)目的進(jìn)展就會(huì)受到極大的影響；如果策劃能夠協(xié)調(diào)好各部分的工作，那么項(xiàng)目進(jìn)展就只需要看個(gè)人能力了。而在現(xiàn)實(shí)開發(fā)中，策劃人員由于自身的個(gè)性或者其他條件所限，往往在溝通這個(gè)環(huán)節(jié)上出現(xiàn)一些致命問題導(dǎo)致進(jìn)度的延誤。如何把握好自己的情緒，從大局觀出發(fā)是成為一個(gè)成熟策劃人員的關(guān)鍵所在。
文檔不管寫的多詳細(xì)，對(duì)其他人來講仍然會(huì)存在理解上的錯(cuò)誤或漏洞。策劃經(jīng)常把注意力都放在了如何把游戲設(shè)計(jì)的更完善上，而忽視了別人的理解能力和感受。因?yàn)閷?duì)任何一件作品來講，每個(gè)人的看法都是不同的，策劃應(yīng)該知道如何去聽別人的意見并吸收到自己的設(shè)計(jì)中來。這并不是說堅(jiān)持自己的立場(chǎng)是錯(cuò)誤的，而是在大多數(shù)情況下策劃本身容易把自己的設(shè)計(jì)當(dāng)作一個(gè)孤立的個(gè)體，對(duì)其他外來的思想用全部拋棄的態(tài)度來對(duì)待，這是極其危險(xiǎn)的。就算是別人的意見是多么的滑稽可笑，你也應(yīng)該認(rèn)真的聽完并加以分析，任何渠道的意見對(duì)你的設(shè)計(jì)來說都是有益的。
在前面講過如何書寫流程圖和安排工作進(jìn)度，在這些設(shè)計(jì)過程中和其他部門的溝通都是非常重要的。我不提倡大規(guī)模的定期會(huì)議，因?yàn)檫@樣會(huì)影響其他人員的開發(fā)進(jìn)度，而且會(huì)導(dǎo)致很多問題的擴(kuò)大化。公眾場(chǎng)合下不適宜對(duì)個(gè)人問題進(jìn)行討論，大量的溝通和談話應(yīng)該以私人或者小型會(huì)議的形式來進(jìn)行。大部分開發(fā)人員不喜歡開會(huì)，尤其是這種針對(duì)性不是很強(qiáng)的例行會(huì)議。所以如果確定要召開會(huì)議，那么就一定要先確定這個(gè)會(huì)議要解決哪些問題，需要哪些人來參加，最后要達(dá)到什么樣的效果。純粹為了開會(huì)而開會(huì)，尤其是一些例行會(huì)議是沒有必要的，這樣只會(huì)增加別人對(duì)你的厭惡情緒，導(dǎo)致關(guān)系間的不協(xié)調(diào)。如何盡可能減少大規(guī)模會(huì)議，通過單獨(dú)會(huì)談來解決問題是溝通的一個(gè)有效手段。
如果你想知道其他人員對(duì)你的策劃方案是否有意見，單純的把文檔發(fā)送給程序或美術(shù)不是一個(gè)好辦法。無論你的文檔多詳細(xì)，別人都很難完整的理解你的意思，利用好黑板和紙筆通過講課的方式進(jìn)行溝通，可以一次性讓大量的相關(guān)人員了解你的設(shè)計(jì)。在講解完畢后讓大家以發(fā)表見解的方式來發(fā)現(xiàn)并解決問題才是有效的解決手段，你所要做的只是把你的想法表述給大家，而不是爭(zhēng)吵。在你的講解過程中要以聽為主，對(duì)于一些核心內(nèi)容進(jìn)行強(qiáng)調(diào)，認(rèn)真做好筆記，在會(huì)議后對(duì)別人的意見進(jìn)行總結(jié)，讓別人知道他的看法你是很重視的。只有對(duì)別人尊重別人才會(huì)尊重你，想處理好與他人的關(guān)系首先就是讓別人感覺到你對(duì)他的意見是重視的。
在完成了第一次講解后，就不要再召集這種大規(guī)模的會(huì)議了。剩下的工作你就應(yīng)當(dāng)找對(duì)應(yīng)的工作人員進(jìn)行單獨(dú)會(huì)面，只和他談?dòng)嘘P(guān)他這個(gè)方面的設(shè)計(jì)問題。對(duì)程序就是描述游戲流程以及一些需要確認(rèn)的技術(shù)實(shí)現(xiàn)問題，而和美術(shù)則應(yīng)該談界面實(shí)現(xiàn)以及整體效果等問題。
給程序員交流要求你能跟的上他的邏輯思路，就是說你要對(duì)計(jì)算機(jī)的編程有個(gè)大概的了解。起碼你應(yīng)該知道程序流程是通過條件分支、循環(huán)以及函數(shù)等組成的，而且要對(duì)面向?qū)ο蟮腃 語言有一些了解，否則他會(huì)認(rèn)為你的思路太混亂而產(chǎn)生很多理解上的概念混淆。最好你是拿著一個(gè)游戲設(shè)計(jì)流程圖來和他交流，這張圖應(yīng)該類似于程序設(shè)計(jì)的流程圖，由幾種基本的圖形和線條來實(shí)現(xiàn)。這樣一邊描述你的思路一邊給他指出需要完成的模塊，發(fā)現(xiàn)問題進(jìn)行記錄并修正你的文檔就能夠讓雙方都保持清醒的頭腦，而不是產(chǎn)生做出來產(chǎn)品后和你所想象的完全是兩個(gè)東西。這時(shí)經(jīng)驗(yàn)就會(huì)起到非常關(guān)鍵的作用，如果策劃本身就是程序員或者做過程序員就完全不用考慮這個(gè)問題了，可如果你對(duì)程序一竅不通或者根本就不知道那些東西是怎么實(shí)現(xiàn)的，那你最好去找本介紹編程基礎(chǔ)的書看一下。多和主程交流應(yīng)該是最省事的辦法，只要交代給他哪些工作需要在多長(zhǎng)時(shí)間完成就可以了，但很多情況下是主程和策劃一樣固執(zhí)，這時(shí)他會(huì)不經(jīng)過考慮就告訴你很多想法都是不能實(shí)現(xiàn)的。你要拿出詳細(xì)的解決方案才可以說服他，或者讓他提出一種合適的解決方案。總之，用程序的思路來和程序員進(jìn)行交流是最好的解決辦法，給程序員一份詳細(xì)的流程圖要比給他一份幾百幾千頁的文字說明要管用！
給美術(shù)人員交流更困難。因?yàn)槊總€(gè)人的美術(shù)風(fēng)格都不相同，要求幾十個(gè)美術(shù)人員畫同樣一副圖你所獲得的結(jié)果肯定千奇百怪！通過主美進(jìn)行協(xié)調(diào)是一個(gè)好辦法，這樣可以減少你很多口舌的。在你寫策劃方案時(shí)，不要對(duì)美術(shù)做太多的要求，而應(yīng)該先和主美術(shù)確定好游戲的整體美術(shù)風(fēng)格。美術(shù)方面具體的人員安排和工作量限定等事情都交給主美術(shù)或者美術(shù)總監(jiān)去處理，除非說你對(duì)美術(shù)非常精通能夠把握住整體風(fēng)格，否則你的工作只是描述你需要什么樣的東西就可以了。當(dāng)美術(shù)完成樣品后，一起和主美術(shù)進(jìn)行審查，風(fēng)格一旦確定就不要再修改了，否則這對(duì)美術(shù)人員來說完全是種摧殘！美術(shù)人員工作量往往是最大的，美術(shù)風(fēng)格的改變可能會(huì)造成大部分工作的重做，從而嚴(yán)重影響工程進(jìn)度。把交流的事情交給美術(shù)方面的負(fù)責(zé)人，這是最好的同美術(shù)人員的交流方法。
保持好自己的心態(tài)，用積極的態(tài)度來解決問題，不要抱怨多聽別人的想法是一個(gè)策劃人員需要掌握的基本方法。只有溝通順暢才能夠讓項(xiàng)目按計(jì)劃進(jìn)行，擴(kuò)大自己的知識(shí)面，多和主程與主美交流，少開大規(guī)模會(huì)議，用私人交談的方式來解決問題。把握好上述幾點(diǎn)，項(xiàng)目的完成就只是時(shí)間上的問題了。 |