切換
舊版
前往
大廳
主題

【心得】遊戲開發與管理心得-程式與資料庫篇

Яков | 2014-02-02 22:28:41 | 巴幣 292 | 人氣 7229

仍然是之前在自製遊戲公會RC群給大家講解的遊戲開發與管理心得系列,與【企劃篇】和【美術篇】屬於同一個系列。
其他兩篇的傳送門:
 
=======================================================================
 
就一個團隊所需要的團員而言,事實上程式和資料庫原則上不一定要有嚴格的界定,如果企劃自己也懂一些相關的部分那麼就可以自己兼任一些;同樣的,如果做介面的美術總監懂一些介面程式,那麼也可以分擔一些,因此程式和資料庫原則上是兩個工作,但事實上不一定需要分開若干人,這個跟遊戲需要寫的程式「腳本量」和資料庫「設定量」有關。
 
以我們團隊為例:我們的遊戲是因為把VA內建程式全部砍掉重做,資料庫也是完全自訂;從武器裝備物品到技能狀態幾乎沒有用一點內建,所以對於我們團隊而言,程式腳本和資料庫一個人就顯得吃不消了。
就單純程式腳本的部分,這裡講一下我的心得,每一個程式都有自己寫程式的習慣,每一個腳步師寫出來用於同一個功能的腳本都不盡相同;因此,如果說請很多程式來做,事實上有時候不僅不會加快進度,反而會相互影響。
 
第一:每個程式習慣句法不同,要看懂別人寫的就要花很多精力和時間了。
第二:程式組合起來是一個「系統」,而系統的特定就在於「不同的組成部分彼此負責不同功能而又要整體互相協調配合」。
 
一個腳本師在寫腳本時,不僅僅考慮目前寫的這個功能,還要考慮到「是否會和別的腳本衝突」、「如何配合其他的腳本」、「如何配合整體系統」諸如此類的問題。如果讓不同人同時寫,不僅很難相互配合,而且一旦出錯發生腳本衝突,再修改起來就非常麻煩;所以,最好的情況是程式腳本由一個信得過可靠的人一個人包到底。
 
其他的數據庫、介面、企劃如力所能及可以做一些小的輔助性的工作,但主體還是一個人負責。
然後,「程式的編寫」和「系統的設計」是兩回事,前者是程式腳本師需要負責的部分,而後者則應該是企劃負責主導的部分。
一個遊戲需要怎樣的系統,都要有哪些功能,怎樣戰鬥,怎樣升級,有哪些隱藏功能,這些功能大致怎麼排版,這些都應該是企劃自己需要明確並且他能夠明確的 。
 
就我們團隊而言,系統功能的設定、大致排版等等都是我在做,我先設計好需要的功能和排版,再由我們的程式進行具體編寫,最後交個美術總監美化介面,之後程式重新調整功能檢查BUG,我們大家再一起跑遊戲測試。
就程式的本分而言,魂之前給我講過業界的規則【企劃>美術>程式】這樣,因此在業界程式講常常面對因為企劃的要求or美術需要而砍掉重做的現象Q_Q
程式是非常辛苦任勞任怨,事實上支持著整個遊戲的運作,但是又往往最不容易為人所知讓人重視到的職務Q_Q
當一款遊戲出爐的時候,大部分的玩家關注的往往都是那些精美的人設和CG,那感人的劇情,那些激動人心的音樂,而一旦發現不足的時候,則埋怨的卻是那些系統性和遊戲性。
然而,支撐這些精美人設、讓這些精美的畫面運行起來成為一款真正的「遊戲」而不再是素材的單純雜糅的,卻正是程式的辛勞。
 
因此大家要對程式多多愛護哦~
 
順便先講一下,這裡「愛護」的體現可不是摸摸頭就算愛護的哦
這裡的體現在於「對程式努力工作的尊重」,也就是說需要哪些功能,需要哪些設定,最後一開始就把大致基本上的都想好。
之後雖說可以做功能上修正,但傷筋動骨大改就是很讓人傷腦筋了,比如一開始說做ARPG,程式已經把系統做好了,企劃說改成AVG或者SRPG,而做了一半換系統平台則是更不可取(比如XP換成VX、VA或者相反)。
就像每個繪師有自己擅長的人物和畫風一樣,每個程式也有自己習慣的製作平台和系統,這點最好是一開始就問清楚。
 
比如我們團隊的魂就專門擅長研究VA,而我個人研究XP多一些。我一開始稍微有考慮過XP,考慮到魂的情況決定以VA為系統,而這平台一旦確定後,就不能再改。
說句題外話,我親眼見過某個當時挺著名的遊戲就是因為企劃前後大改劇本和系統最後分崩離析坑掉;因此,如果說對程式的愛護,不如說是對程式辛苦工作的一份尊重
 
 
接下來是資料庫的部分:資料庫,或者說數據庫,是一個遊戲的平衡性的關鍵之所在,這部分的設定是一個相當漫長且苦力的工作。
 
接下來是資料庫的部分:資料庫,或者說數據庫,是一個遊戲平衡性關鍵所在,這部分設定是一個相當漫長並且苦力的工作,對於資料庫設定,企劃本人需要用主體上基本的概念;並且在很多情況下,是企劃本人親自去設定。
資料庫的設定要嚴格配合著系統和程式,可以說是相輔相成的存在,資料庫的改動一般是最頻繁最多,無論是出於系統需要還是平衡性調整都很容易變化,但同樣要有對資料庫設定者的尊重,設定資料的數值部分反復調整是可行的,然而整批設定全部砍掉重做──這就是對資料庫設定不尊重的體現了。
當然,還有包括對程式工作的不尊重──因為資料庫的變化是和程式緊密聯繫的;就比如說技能的部分,就是程式腳本在支撐,把某個技能的傷害數值,範圍、屬性做調整,無論怎麼改都是OK,但如果整系列技能刪掉就很不好。
 
無論是企劃、程式、資料庫分不同的人還是不分,負責這些工作的人都應該能夠對程式系統資料庫有比較多了解;比如,企劃應該了解某些系統的優劣,可能存在的BUG;程式應該明白資料庫設定的技能需要的編寫方法,資料庫需要了解遊戲整體的系統、功能和平衡性等等。.
這樣就可避免造成企劃一個人自說自話要求很多不切實際的程式腳本,寫出來之後又不讓人家重做這種現象。
 
再然後,一旦有新版本出現,無論企劃本人懂程式碼與否,都應該主動去多多測試跑遊戲幫忙找BUG,一個人可以注意到的方面畢竟有限,一個人的時間精力也有限。因此作為一個團隊最主要的凝聚力的體現,就是企劃對大家彼此的「關愛」,能夠幫助團員們盡可能的減少一些壓力和麻煩,就是一種有實際行動的關愛的體現
 
以我們團隊為例:我程式碼是一竅不通,但是每次只要版本更新,我都會馬上擠出來時間幫忙做一遍又一遍的遊戲測試找BUG,如果發現BUG,馬上做好記錄,截圖,然後匯報(以免之後忘記)。
 
此外,企劃應該能夠明白做各種系統的難易程度以及需要的取捨,因此不能一味以個人好惡而要求程式,而是應該視實際條件而定,打個比方,我們遊戲在設定的時候,有考慮過一下效果比較複雜的道具和裝備,這些編寫起來事實上程式告訴我們會非常麻煩,會顛覆整個系統,而這幾個道具和裝備對於遊戲整體而言,並沒有什麼太多實質性影響,於是綜合考慮,我們決定放棄這幾個個別設定。
另外,企劃需要考慮的程式的優先程度和工時性,比如讓程式編寫主系統肯定優先與編寫幾個回復道具的效果,也就是說,在安排任務的時候,企劃需要考慮哪個部分讓程式先做哪些後做;道具、技能、狀態、人物成長屬性……這些是和資料庫密切相關,而遊戲主系統、戰鬥系統、成長系統等等,則是需優先考慮,這就像地基和房子的關係,有了地基才能有房子。
 
如果房子窗戶不漂亮,可以砸了改O_O,但是如果地基有問題,就需要砍了重建了Q_Q
 
關於如何設定資料庫,舉個小例子,就像這樣:
 
女式手槍(完成)
說明:貴族女生防身用的手槍,小巧美觀而輕便,但是威力是不俗的。
限女性裝備
STR + 12 SPD+2 DEX+5
範圍1~3格菱形
販售價格:600   
 
簧輪槍
說明:最古老的手槍款式之一。因為射程、射速等諸多問題已經退出實戰,其華麗的造型受到很多貴族和收藏家的喜愛,亦是從前貴族們之間進行決鬥的常用武器。
STR + 6
攻擊範圍1~3格菱形
價格:80
 
如果是狀態設定,那麼比如這樣:
中毒:每回合減HP 4%,戰鬥中不自動解除,戰鬥后不會解除(地圖上每走15步減血一次)
混亂:會不分敵我進行普通攻擊,持續2~5回合,戰鬥后恢復
麻痹:無法進行移動和任何攻擊(包括戰技,但可以使用靈力),但是可以使用道具,時效3~5回合,戰鬥后恢復
眩暈:行動輪到他的時候會自動跳過他,1~3回合(隨機)后自動恢復,戰鬥后也恢復
睡眠:無法操縱該角色,行動輪到他的時候會自動跳過他,1~3回合(隨機)后自動恢復,遭遇攻擊之後會接解除眠狀態醒來,戰鬥后也恢復
炎傷:每回合減HP 5%,3~5回合(隨機)后自動恢復,戰鬥后也恢復
凍結:無法操縱該角色,且每回合HP-10%,3~5回合后恢復,戰鬥后也恢復。遭到火屬性攻擊后自動解除。
凍傷:無法操縱該角色,且每回合HP-20%,3~5回合后恢復,戰鬥后也恢復。遭到火屬性攻擊后自動解除。

技能的例子:
突刺(sp10):
目標類型:自身中心,十字2格
以極快的速度衝向目標並給予強力的一擊,造成力量110%的物理傷害,並且移動到目標身旁,此技能使用時額外增加約10%的暴擊率,其數值受到己方的精神與敵方的耐力影響
升級:  115% 120% 125% 130%   等級3之後範圍變為十字三格內
12% 14% 16% 18% 爆擊率增加
使用 5 / 10 / 20 / 40 次升級

雙破斬(sp10):
目標類型:自身中心,3x3方格內敵人單體
以敏捷的身手向敵人揮砍兩次。每一次將造成力量60%的物理傷害。
目標在以自身為中心3x3方格範圍內,選擇敵方單體發動,對該對象造成兩下 60%傷害。
升級: 70% 75% 80% 85% 兩下  
使用 5 / 10 / 20 / 40 次升級
 

需要說明的是,我們的遊戲戰鬥系統是類似空軌和月哮那樣的戰棋模式,而且我們設定每個技能都可以隨著使用次數而升級,因此這是我們的一個特色,其他遊戲製作時技能需要哪些設定因視具體情況而動。
 
需要注意的,企劃還要考慮到以下的問題:為了實現這樣的技能需要哪些系統?這樣的技能會影響到哪些系統?等等,諸如此類。
 
因此,企劃本人雖然是可以對程式碼完全一竅不通(比如我=_=),但是對於整體的宏觀調控能力,則是一點不能少
程式是最接近遊戲實際製作工作的職位,而資料庫則是相輔相成的存在,因此從某種意義上來說,這是會和企劃聯繫最密切的兩個存在。
我們可以設想:美術跑了,點陣跑了,可以重新招人畫;但是程式和資料庫一旦發生人事變動,就可能會徹底傷筋動骨。
 
因此,企劃雖然可以不懂「程式碼」,但是卻不能不懂「系統設定」,這意思是:企劃可以不懂具體那個功能的程式腳本怎麼寫,但是卻應該懂他需要一個整體是怎麼樣的系統,這些系統應該包括哪些功能,這些功能如何發揮、要怎麼樣的效果,這些功能需要有哪些彼此之間的聯繫等等等……
並且一個團隊做最終決定最高決策的只能有一個人,這就是企劃的使命和責任。
 
在進行實際製作的時候,企劃需要和程式、數據庫保持高度的聯繫,同樣的,程式、數據庫也只需要對企劃負責;比如,劇本不應該去干涉程式該怎麼寫,點陣不去干涉數據庫怎麼編──除非劇本點陣就是企劃本人。
 
以上,關於企劃和程式、數據庫的配合部分以及注意事項我就講到這裡。
還是謝謝大家的觀看與指教~

創作回應

閑風
嗯~ 我補充一下,若有誤歡迎討論。

站在公司為主體的情況下,程式的著眼點會立於可維護性與辨識性,相對的就需要有骨幹與旁支;在人員的交替、規格的變更後,依舊要能銜接的上,或捨去與調整。
通常由比較資深或有實力者擔任設計骨幹,再由其他人去撰寫各部份旁支,事前討論、統一整合的方式與規範,最後才不至於變成車子要輪子,另一人卻設計出翅膀的窘境。

而站在自製方,我可以很肯定的說,程式算是稀有財;較不像企劃與美術算是比較容易招募(或辨識*1)的角色,因此通常所有的負擔,均會落在1~2個人身上。若沒有協調好,非常容易造成上述的車子跟翅膀的狀況。
在自製側我贊同版主的論調,以一個人為主,通包去做比較好;或者可以說,這樣反而比較保險,可以較容易避開顧此失彼的情況。
畢竟現實較難以出現,同時有數個業界程式在一個團隊自製的情況;分工合作轉變為分頭拉鋸的情況反而較可能出現。

*1 所謂的辨識是指個人的專長特色,例如企畫專精軍武題材、美術擅畫機械風格都易於分辨;但程式的分界較難看出是精通何種語言,較熟 Client 端或 Server 端,甚至更有可能其實此人只是該程式語言略有涉獵而已。
2014-03-04 22:11:15
Яков
了解!
我是非業界的人士,所以講述的是自製遊戲網路組團時候的心得。
非常感謝您做出如此詳細的業內資訊補充![e34]
2014-03-06 15:02:39
Anly
能遇到一個積極、肯負責而且肯關心幕僚人士的企劃
其實也是團員的大幸福[e12]

寫程式的人真的需要和企劃保持溝通啊...
2014-07-05 15:06:55
Nacht-Eule
因為我也略懂一點"程式",道也能理解程式人員在幕後的辛苦...
不過隨著"遊戲引擎"套裝軟體的推陳出新...
加上每次"硬體"改變強迫"軟體"升級的速度...
未來想要在寫"軟體"程式上"謀生"(非營利條件者除外),
恐怕也是吃力不討好之事吧...哎~"~
2015-01-12 02:25:09
JS昵
話VA的腳本是用什麼語言寫的
2015-02-23 14:47:44
羊肉肉肉肉
所以以後我遇到程式會好好愛護的 XD
2015-08-11 23:30:22
Яков
是的~
2015-08-12 21:27:37

更多創作