Programming

[2010] 沙漠商旅C的遊戲設計(0)


作者﹔NDark

時間﹔201001

前言

事實上前言寫得有點多,簡而言之,這幾篇文章寫下一些我個人的經驗。
但不見得是 “正確的"。讀者必須自己判斷什麼是適合的,什麼是有用的。

這不是最佳解,不要把這些內容當作圭臬。

因為遊戲設計的多樣性,很難找到一套固定的公式可以一勞永逸。
往往只要平台一切換,以前作好的東西就要重新作。
你能留下來的是:

  • 越來越好的設計概念,這幾篇主要的內容;
  • 除錯技巧,這幾篇不會提到;
  • 以及電腦裡的工具程式,這裡指的是﹔Photoshop,轉檔,文字編輯等讓你日常工作順利的程式。而非開發的編輯器。

這些都只是我的經驗,一定曾經有人這樣作。現在也一定有人作的比我更好。
已經在業界的朋友每間公司都有自己的解決方式。沒有必要比出優劣高下。

這樣可以work並不代表你的專案可以這樣套。

軟體工作常常必須小心不要有硬體廠的思維-東西有了兜起來就能用。
某笑話是這樣的: “(人家的)code都有啦,很簡單吧!!"
別人有的東西移植到自己的專案時常常比自己開發一個相同功能的元件花更多時間。
EPIC的投影片也講:如果一項設計造成你開發時間(週期)變長,那就是一個壞的設計。
優秀設計的元件通常不是極度方便就是極度不方便。
(很鬆到只是個小類別)   (很緊到你完全抽不出來只好陷下去)

我著重的方向在遊戲層。而非引擎層(圖學)或平台(如XNA或iPhone)。

因此你不會看到討論的內容造成什麼很炫的特殊畫面。
我很了解圖學人最喜歡的就是一個小設定產生畫面變成很漂亮的特效。
但是我更注重的是這個設計是不是使用頻繁,是不是減少其他開發週期的時間。
因此不會看到什麼跟平台有關的奇淫絕技。更不會在使用特定軟體功力大進。
相反的。我所討論的內容是你在各個平台開發時都能套用的大概念。
在每個遊戲軟體上都可以有幫助的設計。

學習與成長是持續的,我們會一直看到更好的設計,工具,或平台。

但並不代表舊的(已開發的)東西就必須全部都丟到垃圾筒。
某id強者曾說: “如果要變強,就把code重寫一遍"。從變強的角度來講我同意。
但Joel也說過,開發一個專案,當發現設計不完美,切記千萬不要把專案全刪掉。
因為一重來,進度就又歸零了,這時落後再多的對手都立即變成超前你。
兩件事都正確,只是分別從技術者與專案開發者的角度來看事情。
專案是有延續性的,工具是有延續性的,同時支援舊與新的規格是同樣重要。
有時候即使是刪掉一個已經不用的函式都可能會造成未來的風險。
一個人寫作時常常可以即興地依據設計/功力進步而修改架構。
但是在多人同時配合的時候有些改進最好都經過其他人的思考與背書。
以及進而思考這個問題:這個改進是否這麼重要,值得放下其他工作。(優先度)
世界充滿著不完美,能接受這些不完美也是一種雅量。
因此我總是認為,能work就是好code。

開發時程及內容簡介

在繼續之前,我必須先講一下我近一年多在進行的東西-

Flash遊戲Caravaneer(沙漠商旅)的移植(Clone),簡稱為沙漠商旅C。

自2008九月開始到2009十二月為止,利用每天下班後的一或二個小時進行。
週末可以進行比較多。但是偶爾會因為工作繁忙而中斷。
(本段強調沒有占用到本業工作時間)

前面三個月(2008/9~12)大概是進行核心類別的開發。這時都在win32 console上。
接著的日子是平台與系統的建立。繪圖平台轉換到windows form。
還有大部分時間花在開發編輯器,或是說熟悉介面開發的一些工具。
(譬如說.net的一些元件要怎麼用)
所以整個成果看起來並不豐碩(大部分進度是在開發=看不到的地方)
最後的三個月大部分的編輯器都已經整理完畢,比較多時間在擴充遊戲的事件。
撰寫那些比較重要的部分。(因為看來是寫不完了XD)

原先目標:希望一般狀態下完成交易與商業的運作,再加上基本的戰鬥狀態。

完成度

  • 一般狀態下只填了三個城市的市場資料(很多商店還沒開門,也買不到武器跟裝備)
  • 戰鬥狀態下移動與電腦AI未完成(因此敵人只好呆呆的讓你打死)
  • 運輸工具與動物連接的板車系統未完成。
  • 碰撞系統是最低限度。

不過流程上都有準備了空間,屆時要繼續擴充都沒問題。
因此我打算先回頭來整理沙漠商旅C的心得。

另一個比較欠缺的部就是圖形部分,人物都先用幾何代替。
整體看來大概像是我曾說過"一個醜陋無比只有方塊的遊戲"。
不過皮相的部分本來就不是我所擅長且預定要進行的,這些後述。

為什麼我要移植 沙漠商旅(Caravaneer)

沙漠商旅遊戲連結:http://freegame.com.tw/flash/slg/slg_p_057.htm
作者官網:http://www.d-mah.com/

我的工作雖然與圖學有關,但是大部分是新技術系統原型的建置,
開發常常沒有延續性,原型開發出來之後就專案終結。
常常使用新的技術來作系統整合,成果雖然有突破,
但卻沒時間調整到好就被逼著進行其他的方向。

因此我自前年(2008)九月開始打算利用工作空閒對遊戲設計再進行一些磨練,
利用一些以前的經驗反覆修正我的想法。

主要專注在遊戲層上,如下遊戲分層架構圖:

Engine Level
Engine Level

以三大領域來論(美術,程式,企劃)
我並不打算學美術,也不打算去設計一個新的遊戲架構。
所以最後的方案想當然爾就是去抄一個現成有的遊戲。
這樣我就可以借用(剽竊)他的骨(設計)與皮(圖像)。
我選擇沙漠商旅的原因是
他麻雀雖小五臟俱全,

  • 有劇情-甚至還有隱藏分歧。
  • 有經營(商業)-城市的物資與經濟會因為現實而改變,玩家買賣的東西也會反饋到市場價格中。
  • 有戰鬥-各式武器及彈藥。
  • 有成長-可以培養主角的能力及雇用傭兵來作戰。

因此正好可以讓我嘗試遊戲層的概念。
另外則是他圖像部分是平面(2D)的,我借用(偷)起來比較容易。
他是Flash遊戲移植到視窗介面整個系統必須重新建立。

順帶一題,雖然我口口聲聲說借用,但其實我很願意與原作者分享我的成果。
然而幾次的發信似乎都沒有回應,略感遺憾。
我僅能作到在遊戲開始的時候註明這只是個實驗性與研究性專案絕對不會侵害原作權益。

我透過沙漠商旅要進行的主要目標是嘗試撰寫一個 “通用可擴充性的遊戲層架構"。
這個架構套用到任何遊戲應該都是沒問題的。(反過來說是每個遊戲設計上重疊的部分)
不只是遊戲系統,而是包含整個開發的過程。

這幾篇文章主要設定的讀者群是那些Programmer(PG)

a.寫過第一個遊戲,對於系統架構或是開發流程不甚滿意。
b.有豐富的程式設計經驗,卻對於遊戲設計很陌生。
c.目前使用一個不完全或簡陋的遊戲引擎,有需要撰寫一些額外的元件架構。

難度由1至5大概在2。不會牽涉到程式技巧與函式庫使用。
但有些流程用C++或其他語言的片段來說明。

在cook到 “沙漠商旅C的遊戲設計"的主題前,我想先討論這個主題:

容易被遺忘的遊戲設計模組" 。

原因是比較有趣,對讀者比較有用。
然後之後再談我的沙漠商旅移植作品,避免開始就是自顧自的講古,老王賣瓜。

容易被遺忘的遊戲設計模組,依我的經驗,列出了四項,分別是

1.FPS counter
2.Event Creating/Handling/Reporting
3.Resource/Stage Paragraphing
4.Update data by first time/change once/every frame

這幾項並不是什麼了不起的設計概念,
甚至只要有點經驗的開發者都會在開發時自然領悟到這些元件。
但就因為太不起眼了,所以入門到進階的開發者常常會把優先度排到後面,以致遺忘。
遺忘這些元件對於原型的開發不會有什麼影響。
確實如同Gary所說

“有些重要的重要的元件必須優先把他完成,讓整個遊戲能跑起來,再去搞其他次要的部分。"

但是它對於遊戲的完成度或是擴充性卻是相當重要的一環。
好像少了它,牛肉麵只有牛肉跟麵一樣,就是差人一截。(好餓)

<!–[if !mso]> <! st1\:*{behavior:url(#ieooui) } –>

開發時程及內容簡介

在繼續之前,我必須先講一下我近一年多在進行的東西-

Flash遊戲Caravaneer(沙漠商旅)的移植(Clone),簡稱為沙漠商旅C。

自2008九月開始到2009十二月為止,利用每天下班後的一或二個小時進行。

週末可以進行比較多。但是偶爾會因為工作繁忙而中斷。

(本段強調沒有占用到本業工作時間)

前面三個月(2008/9~12)大概是進行核心類別的開發。這時都在win32 console上。

接著的日子是平台與系統的建立。繪圖平台轉換到windows form。

還有大部分時間花在開發編輯器,或是說熟悉介面開發的一些工具。

(譬如說.net的一些元件要怎麼用)

所以整個成果看起來並不豐碩(大部分進度是在開發=看不到的地方)

最後的三個月大部分的編輯器都已經整理完畢,比較多時間在擴充遊戲的事件。

撰寫那些比較重要的部分。(因為看來是寫不完了XD)

原先目標:希望一般狀態下完成交易與商業的運作,再加上基本的戰鬥狀態。

完成度:

一般狀態下只填了三個城市的市場資料(很多商店還沒開門,也買不到武器跟裝備)

戰鬥狀態下移動與電腦AI未完成(因此敵人只好呆呆的讓你打死)

運輸工具與動物連接的板車系統未完成。

碰撞系統是最低限度。

不過流程上都有準備了空間,屆時要繼續擴充都沒問題。

因此我打算先回頭來整理沙漠商旅C的心得。

另一個比較欠缺的部就是圖形部分,人物都先用幾何代替。

整體看來大概像是我曾說過"一個醜陋無比只有方塊的遊戲"。

不過皮相的部分本來就不是我所擅長且預定要進行的,這些後述。


為什麼我要移植 沙漠商旅(Caravaneer)

沙漠商旅遊戲連結:http://freegame.com.tw/flash/slg/slg_p_057.htm

作者官網:http://www.d-mah.com/

我的工作雖然與圖學有關,但是大部分是新技術系統原型的建置,

開發常常沒有延續性,原型開發出來之後就專案終結。

常常使用新的技術來作系統整合,成果雖然有突破,

但卻沒時間調整到好就被逼著進行其他的方向。

因此我自前年(2008)九月開始打算利用工作空閒對遊戲設計再進行一些磨練,

利用一些以前的經驗反覆修正我的想法。

主要專注在遊戲層上,如下遊戲分層架構圖:

__

/ \

/遊戲層\

/ 引擎層 \

/  圖學層  \

/   硬體層   \

-----------

以三大領域來論(美術,程式,企劃)

我並不打算學美術,也不打算去設計一個新的遊戲架構。

所以最後的方案想當然爾就是去抄一個現成有的遊戲。

這樣我就可以借用(剽竊)他的骨(設計)與皮(圖像)。

我選擇沙漠商旅的原因是

他麻雀雖小五臟俱全,有劇情-甚至還有隱藏分歧。

有經營(商業)-城市的物資與經濟會因為現實而改變,

玩家買賣的東西也會反饋到市場價格中。

有戰鬥-各式武器及彈藥。

有成長-可以培養主角的能力及雇用傭兵來作戰。

因此正好可以讓我嘗試遊戲層的概念。

另外則是他圖像部分是平面(2D)的,我借用(偷)起來比較容易。

他是Flash遊戲移植到視窗介面整個系統必須重新建立。

順帶一題,雖然我口口聲聲說借用,但其實我很願意與原作者分享我的成果。

然而幾次的發信似乎都沒有回應,略感遺憾。

我僅能作到在遊戲開始的時候註明這只是個實驗性與研究性專案絕對不會侵害原作權益。

我透過沙漠商旅要進行的主要目標是嘗試撰寫一個"通用可擴充性的遊戲層架構"。

這個架構套用到任何遊戲應該都是沒問題的。(反過來說是每個遊戲設計上重疊的部分)

不只是遊戲系統,而是包含整個開發的過程。

這幾篇文章主要設定的讀者群是那些Programmer(PG)

a.寫過第一個遊戲,對於系統架構或是開發流程不甚滿意。

b.有豐富的程式設計經驗,卻對於遊戲設計很陌生。

c.目前使用一個不完全或簡陋的遊戲引擎,有需要撰寫一些額外的元件架構。

難度由1至5大概在2。不會牽涉到程式技巧與函式庫使用。

但有些流程用C++或其他語言的片段來說明。

在cook到"沙漠商旅C的遊戲設計"的主題前,我想先討論這個主題:

容易被遺忘的遊戲設計模組"。

原因是比較有趣,對讀者比較有用。

然後之後再談我的沙漠商旅移植作品,避免開始就是自顧自的講古,老王賣瓜。

容易被遺忘的遊戲設計模組,依我的經驗,列出了四項,分別是

1.FPS counter

2.Event Creating/Handling/Reporting

3.Resource/Stage Paragraphing

4.Update data by first time/change once/every frame

這幾項並不是什麼了不起的設計概念,

甚至只要有點經驗的開發者都會在開發時自然領悟到這些元件。

但就因為太不起眼了,所以入門到進階的開發者常常會把優先度排到後面,以致遺忘。

遺忘這些元件對於原型的開發不會有什麼影響。

確實如同Gary所說"有些重要的重要的元件必須優先把他完成,

讓整個遊戲能跑起來,再去搞其他次要的部分。"

但是它對於遊戲的完成度或是擴充性卻是相當重要的一環。

好像少了它,牛肉麵只有牛肉跟麵一樣,就是差人一截。(好餓)

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s