3

分享

遊戲製作入門 - 初試啼聲

經過前幾篇的洗禮,各位想必磨刀霍霍、迫不及待想舉起手中的武器,開始打怪吧?但是稍等一下!得先說明一個我當初有的大哉問,以程式面來看,究竟遊戲是什麼?
現在或許不會有這樣的疑問,畢竟遊戲製作的引擎工具比起當初,何止差了十萬八千里。打開工具軟體,寫寫幾行code,build一下,產生執行檔,點兩下,遊戲畫面就出現了,超神奇!(待會就來實作這個過程)
要了解遊戲程式的第一步,就是分別遊戲與其他軟體結構上的差異,我們隨便拿個軟體來舉例,譬如Windows的「檔案總管」,同時間,也請打開「工作管理員」,有個現象不知您是否有發覺,在工作管理員的CPU那一欄,會顯示軟體使用CPU資源的百分比,通常像檔案總管這類軟體,只要使用者「不去動他」,CPU使用量基本上都是0%。但遊戲可不是這樣了,通常不管使用者有沒有在玩,就算擺在那裡,也是會耗費CPU資源的。

遊戲製作 Unity 程式

CPU資源使用率,可以看到BattleCrusier.exe與Windows檔案總管的差異


有人會說,當然啦,遊戲都有音樂持續播放,或者畫面一直在動,當然會吃CPU資源,但是實際上上圖的結果,是一個「空專案」,畫面上沒有任何東西在動,如下圖。

遊戲製作 Unity 程式

一片虛無...?


我認為上述的說法部分正確。但要詳加解釋,必須從源頭開始,也就是先回答這個問題:大部分遊戲的需求是什麼?
「遊戲是塑造一個活生生的世界」,這個答案我覺得挺貼切。遊戲中大部分的物件都是動態的,主角會動、怪物會動、場景中的物件會動,也因此電腦必須時時刻刻去計算並更新這些會動的東西,那就程式面要如何做到呢?答案是無限迴圈。
什麼?是那個只要一進入就停不下來的那個無限迴圈嗎?對,在程式語言中,通常以while,或是do-while關鍵字來代表迴圈(還有for,也可以,但通常用前兩者較單純),然後把判斷「是否離開迴圈」的條件,設定成「除非使用者想離開遊戲」,這麼一來,就變成無限迴圈了。結果就是,強制電腦在這個無限迴圈中,計算更新所有遊戲世界中的一切。
類似這樣:
  

while (!isPlayerExit)
{
// game loop

}

這就是為什麼大部分遊戲,就算擺著不理他,也是會耗費電腦資源的根本原因。
對比於上述的遊戲,也有一類遊戲,結構上與一般的軟體相似,這種結構在專業上稱呼為:「事件驅動」,也就是必須由使用者來觸發,程式才會進行動作的一種結構。像剛才的例子檔案總管,只要使用者不去點擊介面上的互動元件,基本上除了需要的時候,畫面會重繪之外(通常作業系統包辦了這塊,自動會幫視窗重畫),程式就只是停在當下的狀態,電腦不會去管他。
題外話,什麼時候畫面會需要重繪呢?想像一下,如果拉一個視窗譬如說Line好了,擋在檔案總管前面,檔案總管一部份的視窗就會被蓋掉,這時候把Line移走,如果沒有重繪,檔案總管被蓋掉的地方,就會變成...黑色(還是白色?總之檔案總管一部分的介面顯示會爛掉),如果各位跟Windows戰鬥的時間夠久...應該有過如下圖的經驗:

遊戲製作 Unity 程式

無限對話框!


這應該就是重繪掛了(應用程式當掉,所以也無法重繪,只能正常顯示跳出來的對話框),所以原本應該出現在背景的視窗(以這張圖的例子是IE瀏覽器),畫不出來了。

回到原題,這類遊戲的其中一個例子,就是「踩地雷」,使用者不動,遊戲就不動。

遊戲製作 Unity 程式

跟印象中長得不太一樣,Windows10沒有附遊樂場,要另外找來安裝

遊戲製作 Unity 程式

基本上會是0%,不過因為踩地雷本身有計時器在跑,還是會吃一點資源


了解了這個差異後,我們來實際操作一下Unity吧。首先開個新專案來,然後滑鼠右鍵加入UI,先來個Panel:
遊戲製作 Unity 程式

加個Panel當底

再來加上一個按鈕。
遊戲製作 Unity 程式

在Panel底下加上按鈕

最後變成這樣,畫面中只有一個按鈕。
遊戲製作 Unity 程式

按鈕遊戲

最後build出來看看吧~
遊戲製作 Unity 程式

選擇Build Settings

遊戲製作 Unity 程式

左邊選擇平台,上面Scenes in Build如果空空的,按一下Add Open Scenes。最後按下Build,選擇要放執行檔的位置即可

執行後的結果,畫面中央出現一個按鈕,點呀點呀點呀...(好空虛)
遊戲製作 Unity 程式

按鈕

重點是,這時候打開工作管理員看看:
遊戲製作 Unity 程式

資源消耗

我只是放個按鈕,不只耗費CPU,也用了不少記憶體,對比於踩地雷的資源消耗量...遊戲引擎有利有弊,這只是其中一項。
不過資源消耗這件事,對比於現在電腦硬體等級的迅速攀升,影響越來越小,現在誰會在乎遊戲多吃幾MB記憶體?有些走火入魔的「技術狂」,會盯著程式人員,指指點點效能問題,這邊不需要用Container吧?用一般陣列就好了;迴圈裏面call字串處理函式,會超慢的啦等等。
我對於效能的看法是這樣:出問題再來解決。意即能拖就拖,實在不行了再來改寫。這可不是擺爛,而是以長遠的眼光來看。最主要的原因是,遊戲的重心-玩法-需要精煉,過程涉及修修改改,如果將效能問題優先權擺在前面,工作量會直線上升,絕對不是好事情。
同樣的道理也適用於重構,有人認為為了開發方便,先把架構訂清楚,之後開發照著架構走即可。如果覺得不太順、卡卡的,便花時間重構。結果常常玩法大改,舊的系統直接廢棄。我就在想,花大把時間「規劃系統」,不如速戰速決,有基本的「物件導向」規劃即可,早點將prototype完成,確立玩法(這很難,不如說確立玩法是一個過程,不是一個時間點就能決定的事情),讓遊戲版本不斷更迭,專案有所進展,後期再來慢慢處理程式面的問題。
總而言之,囉嗦了一大堆,實作才是最重要的,接下來的文章,將會試著實作一款日式主流的AVG,看看一些基礎如何在Unity上實現。
遊戲製作 Unity 程式

就是類似長這樣子的遊戲


上一篇:遊戲製作入門 - 冒險者隊伍
下一篇:遊戲製作入門 - 開車啦!
#遊戲製作  #Unity  #程式 
分類:遊戲

熱愛電玩,隨興遊玩。如果能夠一直玩下去就好了呢!

評論
上一篇
  • 遊戲製作入門 - 冒險者隊伍
  • 下一篇
  • 遊戲製作入門 - 開車啦!
  • 更多文章
    載入中... 沒有更多了