2010/12/06

UDK十一月新增功能


個月的UDK更新又來了, 期待的全新地形系統(landscape)並沒有如期出現. 不知是為了參加哪個展覽, 這次新增功能還搭配了這個影片, 在影片的後面說明了主要功能, 但是這個兩年後的硬體配備才可能跑的順的展示, 並不是全都展示全新功能, 絕大部分是舊功能.

Directional Light Shafts方向光的耶穌光效果

Color Grading調色功能, 做出更有氣氛的色調

Cascaded Shadow Maps 根據物件距離改變陰影解析度

Seamless Time of Day Transition 無縫的日夜變化轉換

Weather Effects 氣候效果

Improved Foliage Rendering改善的植物渲染功能

Material Layer Blending材質圖層混合效果 (由乾燥轉潮溼材質)

Point Light Shafts點光源的耶穌光效果

High Quality DOF For Filmmakers 針對電影製作的高品質景深效果. 看起來有做出Bokeh散景, 但實際上在十一月版的新增功能清單裡, 並沒有說明這個重要功能. 開啟11月份範例檔的確可以即時展示散景效果, 實際要開啟哪的選項或是純粹是透過舊功能的調校, 這還要再研究

以上展示功能似乎很令人期待, 但實際開啟場景的Kismet, 兩個字可以形容實際狀況--『硬幹!』

日夜變化, 天氣系統, 材質變化...等是透過Kismet串出來的. 沒有寫成美術能實際使用的功能, 嚴格說出來只能說是Epic公司自的對這些功能的prototype吧!

----以下為翻譯----
這次UDK新增了一個地圖,另外編輯功能也很有多改進

新的日夜變化地圖,你可以在以上Youtube影片看到。這張地圖也附在新版的UDK影片。

新的啟動畫面。增加一些功能。

新的絕對移動模式,方便你用滑鼠來操控移動,這是預設的移動方式。

新的功能改善了移動與旋轉的操作。
這是一個很方便的設計,方便你進行 prototype前期設計。因此。這個工具被定成預設值。

幾個旋轉功能也改善了,但是這幾個功能預設是關閉的。

現在在透視圖也可以進行框選了
\UnrealEngine3\Binaries\MemLeakCheckDiffer.exe.
新的記憶體露出檢查MemLeakCheckDiffer工具,可以在這裡找到。
\UnrealEngine3\Binaries\MemLeakCheckDiffer.exe.

在Matinee裡面,多了一個的針對眼部與頭部的,頭部追蹤的軌道
當你儲存關卡時,你可以對每個子關卡重新命名,甚至可以做前綴命名。

增加新的移動重新命名(“move/rename”)控制指令
當你進行多個soundcues複製到另外一個資產包時, “Name Suffix”這個參數會設設定為關閉。


在畫面中,添加了當游標滑過物件會高亮顯示的功能。

AnimSet編輯器現在允許你搜尋AnimSequence名稱。

材質觀看器現在背景為棋盤格,方便你觀看透明材質。

在屬性窗(PropertyWindows)內多了一個叫做水平網格的開關。

雙擊序列,會讓你開啟該序列的母序列。

當你輸出FBX檔案時再也不會得到三角化的網格了。

對rebuild與檢查關卡多了新的指令。

自動build與提交工具已經不需要了,請看這裡的說明
http://udn.epicgames.com/Three/AutomatedMapBuild.html

雜項
在socket管理員裡面的Sockets現在按字母排列了。

以下的Kismet快捷鍵更新了
C +滑鼠左鍵,添加『console event』

移除了添加註解,快捷鍵C

開啟水平分割線這個功能在不同session都會被記憶下來。

在static meshes與fractured static meshes縮圖上都會再次顯示沒有碰撞『NO COLLISION』的警告。

nFringe script debugging現在可以在64-bit UE3上執行
FBX SDK更新至FBX SDK 2011.3.1
有了這項功能,你不需要先進行三角化就可把模型導入至UE3。

----翻譯完畢----

2010/11/14

建築物爆破:真實與CG之間的鴻溝



3DCG裡面要製作爆破牽涉到幾個幾個基本流程:首先,要把完整的模型弄破碎 (碎裂),再來就是控制這些碎裂的動態移動,還有就是隨之產生的煙塵。碎裂有很多方法,免費的有FractureVoronoi、付費的有Rayfire以及Cebas VolumeBreaker。動態的話則是可以用Particle Flow或是Thinking Particles,強調物理模擬的話可使用內建的Reactor或是付費的Rayfire。煙霧的話可使用FumeFX或是最新的Phoenix FD

這樣看起來似乎一切工具都具備,要做出寫實的建築物爆破沒有太大問題。然而, 實際上真的是這樣嗎?這篇文章裡面,我們講舉幾個實際建築物爆破的例子,分析它的爆破特徵,接著,跟CG做出來的爆破效果比較,看看問題的癥結點在哪邊!

真實的建築物, 是如何爆破的?
我們收集了幾個真實的建築物爆破影片 (截圖取自http://implosionworld.com/網站),分析的重點是碎裂的分佈方式、大小、還有它移動的方式: 我們可在這幾個建築物爆破裡面看到,其實,碎裂是很局部的。一棟建築物甚至可能是一整塊像自由落體般落下,建築體本身只有扭曲的效果卻沒有真正的碎片。有些是因為埋炸藥的方式,建築物變成三大塊落下。小碎片的產生也不是沒有,它會在大塊的建築體之間有很細小的碎片,這之間伴隨著煙塵。除了一開始的炸藥小爆炸外,幾乎都會在很短的時間內,由上往下產生地面煙塵,這些煙塵也會把那些小碎片的細節遮蔽著。

從格子狀的窗戶可看出來 除了建築物本身自屋頂有扭曲之外, 沒有明顯的大塊碎裂. 真正的小碎片反而被煙塵遮蔽

碎裂成三大塊的建築物, 斷點切面間產生了小碎片 夾帶著煙塵. 三大塊幾乎原封不動地沈入地面.

這個例子有比較多的碎片 但也是很局部, 帶有一點扭曲.

建築物只有一點扭曲, 自由落體, 然後就消失在厚重的煙霧當中

我們可以說,真實的建築物爆破,它的大塊碎片幾乎是很完好地落下!如果建築物斷裂成三段,它在落下的過程並不會被切成很平均的碎片,而是頂多帶點扭曲的方式掉在底下的大塊煙塵裡面。之前的知本金帥大飯店也是很好的例子,建築物沒有分裂成小碎片,表現的重點反而是一塊大的建築體往河的方向傾斜,掉落在河流裡激起似煙塵的大水花,把倒下所隨之產生的小碎片都遮蔽著了!

若是以此為參考, 倒塌的建築物可以沒有明顯碎裂, 也能有很好的擬真效果.

電腦動畫的爆破
接下來,我們看看電腦動畫處理的大樓倒塌,效果是如何。我們先看Rayfire的幾個範例,首先,這個例子建築物被預先切割成很細的碎片。當大樓倒塌時,這些碎片很平均的擴散開來,往地面塌陷。雖然Rayfire具有根據撞擊點來產生更係小的碎片的功能,但是跟真實的大樓爆破影片想比,你就會馬上發現到問題點: 碎片根本就沒有想像的多,而就算弄了超多的碎片,也不保證模擬效果能夠很擬真。原因就是碎片本來就沒有那麼多,大樓也不會像切碎機那樣被切的那樣平均!Rayfire影片的另外一個例子是天外飛來一個隕石,把大樓打成碎片,這跟實際的大樓爆破影片也有很大差距。可以跟911的世貿大樓相比,就知道在撞擊瞬間,根本就不會把大樓切成那樣多的小碎片。因此我們知道,就算是你設定Rayfire把你的建築3D模型切碎成三萬個碎片,也不能保證做出寫實的爆破感! 況且,切的越細會讓電腦效能急速下降。

Rayfire的問題是, 碎的太平均了!

天外飛來的隕石, 讓大樓整個脆掉! 好假!

真正的狀況應該是, 撞擊點很局部的碎裂 夾帶煙塵; 其餘部分幾乎是完整的.

另外一個例子是利用VolumeBreaker與ThinkingParticle製作的電影2012特效片段。在這個例子裡很顯然製作人員比較有概念,他們知道完全用物理模擬的爆破特效反而不能做出真實的效果。所以用的是混合的表現方式:一方面用物理來計算大面積的建築物塊;一方面當右邊的建築物倒塌到左邊時,用程序性的方式產生撞擊點的細小碎片。這樣,整體而言,建築物本身並沒有太過平均的被切割成片段,而撞擊點本身就能夠提供夠細緻的碎裂片段,這的確是比較高明的作法!

電影2012的特效算圖效果

電影2012特效, 可看出Thinking Particles在撞擊點局部產生碎裂與許多微小粒子. 這粒子可以不是物理的幾何體.

話說回來,Rayfire的策略也並非完全無用武之地。對於那種本身是凸面體(convex) 而不是像建築物那樣有複雜的凹面(concave)幾何構造,例如一座雕像、或是高速公路這類的物體,用Rayfire就能產生相當不錯的效果。尤其Rayfire可以讓碎片碎了再碎,因此對於局部的爆破表現,效果仍然可圈可點。

Rayfire用在雕像的爆破相當適合.

高速公路的模型通常是凸面體, 因此效果通常可以很逼真.

筆者曾經嘗試了幾種方法想要做出寫實的建築物爆破效果,但效果總是不滿意。 後來才發現原來問題根本就不是碎片的數量問題,而是它實際的爆破方式不是像現有的破碎軟體那樣是可以『按個紐』就能模擬出來的,中間是需要一些微調、一些程序性控制、一些粒子特效(而非幾何碎片的物理碰撞模擬)、甚至一些人為的keyframing的動作,才有可能做出令人信服的特效。而這中間煙霧對細節遮蔽,也會有大大加分的效果。提供給讀者分享。


筆者利用Rayfire製作的大樓倒塌效果. 效果不是很理想.

----本文完----

[相關文章]



2010/11/07

次世代場景設計---模組化(Modular Level)的觀念


古早時代的瑪莉兄弟, 模組化的設計隨處可見!
世代的遊戲角色設計, 這個名詞常常聽到. 次世代場景設計卻少被提及. 如果讀者有開過UDK的場景地圖 就會發現即便是像Unreal這樣的第一人稱射擊遊戲的場景 並不是多人玩家的MMO遊戲, 場景卻都還是大量使用模組化的設計概念 把場景模型對記憶體的損耗減小到最低!

Unreal Engine 3關卡的模組化設計與遊戲資產

模組化場景設計並不是創新的觀念, 早在任天堂時代, 硬體昂貴記憶體匱乏的狀況下, 模組化設計其實是關卡設計師不得不做的必要策略. 在這動不動就要求相片寫實的次世代遊戲時代裡 場景設計師面對的困難並沒有改變! 即便是記憶體有了4Gb, 上限還是存在. 對於MMO類型的遊戲, 難道就不該奉行"模組化"設計的教條嗎?

2010/10/13

Normal Map 法線貼圖 (三)

這篇是Normal Map系列文章的最後一篇. Normal Map產生的重點不外乎做bevel, smooth group的設定. 如果是對稱的模型, Normal map只做一半會遇到更麻煩的問題. 最後到了遊戲裡面除了normal map以外, light map的UV又是另外一個問題點.


----以下為翻譯
原文連結請點這裡

標題:針對light-maps來拆UV
翻譯: Hammer Chen

沿著材質的X軸做鏡像

這會影響light-map材質與vertex light-maps

Light-maps會用三種不同方像儲存光線,然後根據實際的每個像素法線來做混合。 這三個方向是固定在切線空間。因此,在世界空間會跟材質座標一樣被鏡射,而這個方向只在材質的X軸會對稱。為了確保鏡射邊縫的兩邊都採用相同方向的世界空間,UV貼圖與模型的對稱邊縫會盡可能地垂直。

在鏡像邊縫的兩旁使用相同的世界座標方向是很重要的,因為這樣light-map才能精確地計算出來。如果兩側用了不同的方向,光照貼圖在兩側的邊縫計算就會不正確,最後會導至明顯的縫隙。

切線空間會建立在第一組UV set,因此,這是材質的座標,所以要沿著X軸對稱。

把light-map UVs切開來做對稱。

模型的light-map UVs必須在鏡射的縫隙之間要留幾個texel,這樣做是必要的,因為這兩半沒辦法混合在一起。如果這兩半沒有間距開來,那麼套用到light-maps上面的smoothing filter,或是材質的bilinear texture filtering會讓縫隙產生!

請看這個牆的模型,藉由把法線貼圖沿著x軸對稱可以節省材質空間。

Normal Map 法線貼圖 (二)

這篇是補充Normal Map 法線貼圖 (一)的文章. 挑選裡幾篇比較實戰的文章翻譯整理出來.


----以下為翻譯----
原文請點以下連結

標題: Maya > NormalMap > UDK 工作流程
翻譯: Hammer Chen

crapageddon: 有沒有人可以解釋我哪邊做錯了?

我想要把我在maya高模,用低模貼法線貼圖,放在udk裡面。幾乎要完成了,但是在udk裡面模型看起來一團糟。我自認為我步驟都做對了,有沒有人可以指出我哪邊做錯了,這邊我很快速地做出骷顱頭,當作練習的範例。

以下是我的步驟
1. 建立高模

Normal Map 法線貼圖 (一)

這裡翻譯/整理了幾篇關於Normal Map的文章. 因為字數太多所以分成三篇刊登. 希望對大家有幫助.


----以下為翻譯文----
原文請點以下連結

標題: 法線貼圖
翻譯: Hammer Chen

什麼是法線貼圖(Normal Map)
法線貼圖常常用在低解析度模型,偽裝出高解析度的模型細節表現。法線貼圖的每個像素儲存了法線,法線就是一種向量,紀錄了高解析度模型的表面斜度。紅色、綠色、藍色通道分別控制了每個像素的方向。

當你把法線貼圖到用到低解析度模型,法線貼圖上面的像素會控制了低階析度模型的向量,造成了模型表面更多細節的假象。然而,從側面來看,模型本身並沒有改變。

貼了normal map的低模
沒有貼normal map的低模
高模

2010/09/25

UDK九月版新增功能

每個月一度的UDK更新又來了, 請看以下翻譯:

---以下為翻譯文---

Epic論壇上面開了新的UDK建築應用版塊。你是否想利用UDK來創作3D視覺化表現或是模擬,進來論壇一起討論吧!另外Scaleform UI也有自己的論壇囉!

九月份的UDK具有很多重大新增功能,包括了:
  • UDK用戶現在可以控制gameplay profiler工具了!
  • Matinee的movement tracks現在把移動和旋轉兩個軌道分開來了!
  • 在Content Browser裡面,用戶現在可以對多個材質屬性進行編輯。
注意事項:
由於PhysX的更動,你必須要對所有場景的物件重新存檔一次。

UDKGame
  • 修正了跳躍動作會出現傾斜的問題。
  • 修正UDKVehicle當機問題。
  • ‘AllowNVidiaStereo3D’這個屬性預設變成關閉。
  • 切換UDK地圖,作為預先計算可視性(precomputed visibility)之用。
  • 重新存檔,因為更新了PhysX的元件。
Profiling
  • 現在UDK提供了遊戲玩法的屬性(Gameplay profiler)工具 。
  • ‘GamePlayProfiler’是全新的工具,讓您能挖掘更深的gameplay code。
這裡有詳細解說

Matinee
  • 現在movement tracks切割成為移動與旋轉的兩個元件,讓您可以個別調整。
請看這裡有詳細說明
  • 你可以在Matinee Kismet blocks裡面關閉聲音的濾鏡。

改善的粒子系統
  • 現在每個emitter支援多個ribbons
  • 新的隨機(RandomSeed)模組,讓你在播放粒子的時候效果更一致。
  • 隨機尺寸(Random size)與壽命(lifetime)現在能針對每個ribbon來設定。
  • 現在可以對粒子生成率(Particle spawn rates)做clamp的動作,避免產生負的生成率。

算圖
  • 加入'ImageGrain'到'UberPostProcess。
  • 在UberPostProcess裡面添加了雜訊濾鏡效果(ImageGrain)
  • 改善了後製處理。
  • 使用更少的記憶體。
  • 具有更好的CPU/GPU效能表現。
  • 改善了品質與穩定度。
  • 新增功能有HDR scale 與film grain。
  • 最佳化扭曲的pass。
  • 修正了雙螢幕會出現怪異彩色小點的問題。
  • F5鍵可以用來切換shader複雜度的顯示。
動畫
  • 對SkelControlLimb添加了Joint Bone的旋轉功能。
  • 改善了動畫壓縮率。
  • 有了自動或是壓縮動畫的指令。
  • 跟之前相比可以壓到大約省下30%的大小。
  • 可以有參數調整壓縮。

Scaleform GFx
  • 修正了到Scaleform裡面 字型處理sRGB的問題。
  • GFx現在支援了Distance Field 與RGBA UFonts. 。
  • 添加GFxUI.int的範例 放在Engine/Localization/INT/。

DCC 工具(Max/Maya)
ActorX for Maya 與Max 2011現在支援PhysX了

PhysX
  • PhysXDestructible被移除了
  • 取而代之的是APEX destructibles
其他的改善
  • 流程的改良,例如可以用貼圖來搜尋所有材質,支援local collections到Content Browser。
  • 修正了在玩遊戲時因為長時間處理零長度的linechecks所引發的卡住問題。
  • OBJ mesh的輸出現在能產生diffuse、specular 與normal的材質(譯者註:好消息!)
  • 新的mesh bone weight導入工具大大地改善了low->high 與 high->low 骨頭數目轉換的問題。
  • 現在可以透過STAT TEXTUREPOOL指令來進行Streaming texture。
  • 改善的地形編輯器(Landscape)。
  • 現在在mesh paint tool也有新的color picker了。
  • mesh paint tool現在支援油漆桶功能(flood fill)。
  • 即使在tonemapper啟動的狀態下還是可以用Gamma。
  • 現在可以在Content Browser裡面對多個貼圖做修改。
----翻譯完畢----

[相關資訊]

本站所有跟UDK相關文章請點這裡

2010/09/18

Phoenix FD流體外掛更新!

之前介紹的Phoenix FD流體外掛, 現在官方推出第一次版本更新了. 很好奇FumeFX會如何應戰? 本站將持續地追蹤!

----以下為翻譯---
為了要提昇您Phoenix FD的體驗與品質,Chaos Group公司宣布這套流體模擬外掛的更新下載!

這是Chaos Group第一次的流體動態系統的官方升級,還提供了以下幾個新增功能。

新增功能:
  • 能夠選取來源的通道。
  • 能量保留的平流計算(Conservative advection),可以用在緩慢的流體與大尺度的模擬。
  • 支援Thinking Particles作為模擬計算的來源。

修改的功能:
  • 改善了多線程模擬計算
  • GPU預覽會顯示FPS。
  • 在模擬的時候能夠改變通道。

臭蟲修正
  • 當你使用adaptive grid UVW、或是燃料通道,會發生記憶體洩漏。
  • 如果在筆刷模式沒有採用實體物件會當機。
  • 在某種light cache的狀態會產生錯誤。
  • 材質調節的功能不能用explicit的座標系統。
---翻譯完畢---

[相關資訊]

2010/09/12

UDK到底能不能開發MMO遊戲 (一)

去年,筆者有幸參加了一場秘密會議。一家大型軟體公司的研究機構,做了近年遊戲趨勢的研究。得到以下幾年結論:
  1. 互動性遊戲越來越重要。靠手勢的或是靠觸控式的硬體,提供新的遊戲玩法。
  2. 市場上遊戲年齡分布更廣了!各種類型的遊戲都有,動作、家庭、運動、射擊、競賽類遊戲等等。
  3. 遊戲公司商業模式:a. 微獲利,每套遊戲的價格很低,或是靠遊戲來賺錢的毛利很低 b. 廣告,在遊戲裡面放置廣告,也是一種遊戲的獲利方式 c. 獨立的開發工作室越來越多 d. 遊戲會以數位的方式發行,越來越不靠實體通路來販售。
而說到未來的遊戲會如何發展,該公司做出以下預測:
  1. Social Games 社群遊戲越來越重要
  2. Crowd Sourcing 群體運算,比方說利用大家電腦來計算科學研究,蛋白質結構。未來遊戲所需運算會不會靠玩家的多台電腦串連計算呢?
  3. Augment Reality 擴增實境,把遊戲跟真實世界做結合的遊戲。例如Geocaching 這類結合智慧手機與GPS的遊戲。
  4. Collaboration 合作類型的遊戲。
遊戲開發商在面對市場,所要了解的就是客戶心理。新世代的小孩,他們出生在每個人都有一個手機的時代,甚至是每個人都有一個智慧手機的時代。這樣的世代,『互動性』對他們來說是最重要的,應該是說,因為科技的進步,他們不了解『等待』是什麼東西,因此現在有些遊戲。並不需要下載遊戲才能玩,你只要線上點擊遊戲,可以立即玩,而在背景慢慢把完整的遊戲下載完畢。

互動性又代表了所有遊戲元件都有互動,會有立即的反應,例如:real time shadow即時陰影,即時的物理計算、即時影像、即時的滑鼠手勢。遊戲最好不要lag!.

遊戲的演進是有歷史潮流的,很快地各家公司都面對經營上面的瓶頸。大家都在面對一樣的問題,研發者能夠了解消費者與了解市場趨勢的確是很重要的課題。

以下翻譯了Epic論壇上面的一個有趣的討論帖,作者CrystalCore發起了這篇討論串來問UDK的MMO的遊戲開發。其他的網友名稱我就省略,留下精簡的討論串。

---以下為翻譯---


如何利用UDK製作MMO遊戲?

本欄的目的是要解答所有在這論壇問過的問題---『如何利用UDK製作MMO遊戲?』我想要把這個大哉問! 一次解決吧,我們不需要版上有人一問再問,引發版上的仇恨,這裡應該是幫大家解決問題的地方。
我可以利用UDK開發MMO遊戲嗎?

簡答
不行,因為UDK官方每個伺服器只支援最多64位玩家。

詳答
可以。如果你願意進行以下步驟,基本上,要以UDK建立MMO的方法如下:

1. 你要建立新的server/client結構,支援超過64位玩家,而且如果每個伺服器同時上線的玩家如果沒有達到2,000人,就不可以算是MMO!

2. 利用UnrealEditor開發一整個地圖,但是UDK的編輯器其實不是針對MMO開發所設計,例如地形系統並不適合MMO所需要的尺度。

3.建立大量的遊戲內容。讓我想像一下,要達到『魔獸世界』那樣的角色密度,每個地方你大概會需要50-100個NPC,而這些基本上只是quest givers,這些人還需要對話、尋路、而每個還帶有自己的材質、或是一組材質與動畫等等。這些只是NPC,現在,想想你會有多少個玩家需要客製化他的裝備?!

4. 銀彈。你需要很多經費,不只是要養團隊而已,你還需要大量的人願意花好幾個小時來玩你的遊戲。遊戲上市的第一天就要有台伺服器,不便宜,實際營運你可能需要十台以上的伺服器,這樣你的遊戲才能正常營運。

5. 時間。MMO遊戲要花幾年的時間,超過百人計薪的團隊。如果你的團隊只有20人而且不給薪水的話,那你要花多久時間開發遊戲呢?大概十五年吧。你還要確保開發人員待的夠久能等到遊戲真正上市,呵,祝你好運!


6.計費 這大概是最簡單的部份了吧 你需要開立銀行帳號 建立某種線上交易機制 持續更新法律相關資料 要不然就準備上法院吧

7. 客服 如果你有做到這個階段 我要向你致敬 但是還還需要大量的客服來幫你做臭蟲修正 遊戲糾紛 抱怨等等其他要用電話申訴的瑣碎小事 這些也要花錢的 而且這些人是要在遊戲上市之前就要先雇用了

這裡只提出幾個要素,但是清單應該還可以列出更多,我想我就先到這。

請不要會錯意,這個趨勢可套用在所有的遊戲開發,我只是想要說你可以只有2-3人花幾個越的時間做個小遊戲會有更多趣味,然後再來去思考MMO。如果像Funcom這樣的公司都要與Age of Conan競爭,你也不會有太大機會。

如果你還是堅持要用UDK做MMO,祝你好運!我希望你靠MMO賺大錢,同時也會讓Epic更有錢。

我們大約有五人在做MMO,雖然大部分都很有經驗『知道』要怎樣達到這個目標。

你可能還是會認為這很不實際,事實上不是,沒有人說你必須要重建整個遊戲世界。

當然還要看你是要做怎樣的MMO, 隨然要做魔獸世界那樣的遊戲很大,你也可以做規模小一點的遊戲。

你不一定要做10000000x10000000平方里的大地圖,你也不需要有50個種族上百個物件在場景中,也不需要200的任務。MMO有趣的地方還是跟玩法設計有關,別無他,不要把心思只擺在好的畫面、與上百萬里的大地圖。如果你的遊戲不好玩,你也不可能留住玩家!

沒錯,有很多是在營運相關的工作、網頁、支援、計費、GM等等。雖然現在伺服器算便宜的,我家裡有60mbit光纖,每個月花我美金75元而且沒有使用上限。

我們的花費會是當需要伺服器的時候,當然也跟遊戲的軟體有關,不一定要便宜。但是還是需要不斷電系統、資料庫備份、硬碟、防火牆等等東西。

如果你還有預先販售的活動,你就會大致知道實際營運的時候需要買多少硬體。

雖然不是很容易,如果之前完全沒有營運經驗的話,就沒辦法做MMO遊戲,光是壓力就會把你給殺了 !

但是如果你能把這些雜七雜八的東西處理好,別因為別人跟你說不可能你就不做!

我真的很希望你能做出MMO的遊戲,會很棒。但是我看過很多不同論壇,包含:gamedev、moddb、udk的MMO討論帖,Epic都沒有做很好的支援。認真的,我很難相信你能成功,除非你有很多錢外加夢幻團隊。我現在能想到開發MMO的獨立工作室大概就只有Planeshift 和Minions of Mirth這兩家而已。

如果你真的要開發MMO,那就不要用UDK。這只會讓你的開發時程遇到更多問題罷了!勸你還是使用原本就有好的MMO架構的引擎,例如Planeshift引擎或是Torque Game Engine。UDK根本就沒有針對MMO做調校!

我們有幾套Torque3D,我們也知道UDK對MMO遊戲並不友善,但是Torque3D其實也不友善,但是我們相信如果用UDK遇到了很重大的問題,Epic的人會幫我們處理,要不然我們就要自己想解決之道。最大的問題就是『網路傳輸的大量使用』。

根據伺服器寫的程式碼,或是客戶端的程式碼都已經寫好了,可以用在每個伺服器2-3000位玩家,我們也對Esenthel做了初步測試。

目前還沒遇到任何問題,或是其他通常會遇到的問題

是真的,如果有人問 UDK遊戲引擎能拿來做MMO遊戲嗎?答案是可行的,但是對問的人來說可能達不到,過去沒有經驗,我很難相信他們能完成使命。

因為做MMO遊戲需要處理很多東西,我們當然不會把任何遊戲相關的東西貼上來,直到達成以下目標:
1. 100%的可玩性
2. 能夠處理工作量、網站管理、媒體、社群等等。

任何東西都有可能耗費掉你的研發時間。
例如有個MMO伺服器有100.000個玩家在線上,我很想要在有生之年看到這個目標。

即便是魔獸世界,每個伺服器也大約只有3500-5000個玩家而已!

我個人認為,每個伺服器有超過五百個玩家就可以算是MMO了!
操!就算是一千個人活在同一個地方我們還是只認定它是一個小鎮而已。

真棒的討論帖,獨立遊戲工作室能夠開發MMO遊戲是一個夢想,前面提到的兩家MMO工作室,其實過去都有推出遊戲片的經驗,也對遊戲開發很老練,平均來說也有經驗。我知道就Minions of Mirth案子是這樣,我看到很多人提到Minions of Mirth當做MMO的成功案例。但是你要知道Minions of Mirth是特例 !幾乎百分之99.999999%的獨立遊戲開發工作室開發MMO都失敗了!

前面提到的工作,大概代表了你要開發MMO遊戲的5%工作內容。獨立工作室想要開發MMO 就跟工地工人說去蓋一棟帝國大廈一樣好笑!問題就在於大家看到魔獸世界這樣的遊戲並不了解魔獸世界本身有多巨大。

當你在玩魔獸世界的時候,請記得有22,000台遊戲伺服器、超過5,000位技術團隊在背後支撐。所以問題在於,遊戲引擎能否開發MMO遊戲,這根本就是問錯了問題!應該要這樣問,你有沒有資金、人力、技術來做這件事。如果你有這三項,那麼開發MMO遊戲這件事,跟引擎本身沒有太大關係。

說到這裡,我不想把各位的夢想幻滅。沒有什麼事情是不可能的,但是你必須要先了解狀況再跳進去!

好帖!

如果研發團隊真的有能力來開發MMO,它就有能力開發,不管是不是使用UDK。 開發MMO會遇到的問題很多種,很多都跟對非MMO遊戲開發者的經驗無關。

換句話說,UDK可不可以拿來開發MMO遊戲?這個問題是無意義的!你會問這個問題主要是因為你過去沒有開發過MMO遊戲的經驗才會這樣問。

不管,如果有人有經費、有時間用UDK來開發MMO遊戲,我認為他們該研究一下Atlas。 Atlas的功能就是要用來處理伺服器與聊天、戰鬥系統的問題,它也可以用來創建RPG元素,例如Quests & Vendors那樣,我是還沒用過這套啦 ,所以你要自己研究。

我還是建議各位一開始的時候不要開發MMO遊戲。即使用Atlas也會遇到很多問題,目前我們有18人的研發團隊,但是還沒開發到我們預期的狀態,聽到論壇上面有人說他們工作室有2-5人,就想要用UDK來開發MMO,我真的替他們感到悲哀!

相信我!MMO遊戲是你最不想開發的遊戲類型,它會扼殺創意,除非你有百人團隊來開發。

MMO遊戲?我呸!這種遊戲不過就是一群不認識的玩家,玩遊戲,五人在工會裡。

UDK已經提供你很好的多玩家體驗,如果我記得沒錯,『戰爭機器Gears of War』裡面就有合作模式,玩起來有很有趣。為什麼不開發任務型的、合作模式的遊戲,來取代MMO的開發呢?

我意思是,操!當你玩像是魔獸世界的遊戲,你真的是在跟上千個玩家玩遊戲嗎? 不,當然沒有。你只是在跟一群玩家,在遊戲的世界裡面以起解決、找尋問題。這個其實用UDK就能達成,不一定要是刻板印象中的MMO類型的遊戲。

怎樣才能讓MMO遊戲好玩,其實是根據你的角色。玩家都喜歡客製化角色,為什麼不添加這種功能呢?開發一套單一玩家的遊戲, 讓他有自己的的裝甲與武器,提供合作模式的玩法。

現在,我知道寫程式會有多難,但是上述作法會比較容易達成、花費更少,你甚至可以用虛擬網路來進行LAN連線。

我同意用免費版的UDK很難達到,但是如果付費版的UE3具有source code,要開發MMO應該不是問題!

天堂II完全就是用unreal引擎做出來的,因此是可行的!

你可以用一台不錯的PC當做1000 到 2000玩家的伺服器,而天堂II很多的私服都是這樣做的。

一位GM應該就夠了,因為你是開發MMO的人,你自己應該會知道遊戲會出現哪些問題。

這跟你問的問題有關嗎?如果你是這樣問,我能用免費版的UDK來處理Blizzard 與 NCsoft那樣的遊戲嗎?

我認為你只是想要告誡那些想要靠『魔獸世界』之類的遊戲成為百萬富翁的人,因為他們笨到以為可以達到這樣目標,事實上大部分的人要用免費的UDK開發MMO的話,並不需要成千上萬的玩家來玩遊戲,他們只要開發出遊戲讓大家能夠了解遊戲的概念玩法就夠了!

我會建議想要開發MMO遊戲的人,看看『天堂II』的私服,你會學到很多開發MMO遊戲需要的背後秘密!

我玩過魔獸世界,我不認為這是讓玩家喜歡MMO的原因,遊戲裡面其實很多只是個符號而起。其實大部分的時間,並沒有這麼多玩家,在一台伺服器上面有超過三千位玩家似乎是浪費資源,當你只有約5-10人的團體在你周圍時。

只需要一點點小創意,你就能開發像魔獸世界那樣的MMO的感覺,而不需要上述那些困難的需求。

待續…

---翻譯完畢---

[相關文章]

2010/08/23

Chaos Group Phoenix FD煙霧火焰模擬外掛

全新的格點計算模擬軟體!可以模擬火焰、煙霧等特效。

Choas Group的Phoenix其實也好幾年了, 曾經風迷一時的火焰外掛. 原本已經停止開發 被FumeFX打到趴的軟體 現在又如浴火鳳凰般地重生, 要來個絕地大反攻, 一下子煙霧 流體 火焰 液體通通都支援 還狹支援自家軟體的VRay的全局照明功能. 向Chaos Group這家公司的研發團隊致敬!

---以下為翻譯---
Phoenix Fluid Dynamics (FD)正式推出了!
Phoenix Fluid Dynamics是Chaos Software公司最新推出的產品,這套軟體完美地結合了以格點為基礎的流體模擬,還提供了傑出的算圖能力。除了常見的流體行為,Phoenix FD還能模擬許多特效,例如壓力的衰減、熱能冷卻、與質量溫度平衡等物理參數。流體物質會持續地變形,例如流體、氣體、岩漿等。Phoenix FD讓你在3ds Max裡面模擬這些現象,這些資料會除存在細分的3D格點裡面,每個細分都具有流體的屬性。這些屬性包含溫度、質量、與速度。再用Phoenix模擬的期間,它會轉移格子之間的資訊,根據速度與時間的函數,這些都是根據物理定律來模擬的,最後的結果可以用來算圖出來。

2010/08/14

UDK八月版新增功能

八月版的UDK(Unreal Engine)新增以下功能:

以下是新功能的完整說明:
Scaleform GFx
  • Scaleform GFx 3.3.85現在合併到UDK八月版(Aug)裡面了,所以現在UDK所有的使用者介面都是用GFx寫的了!
  • 改善了許多Scaleform的錯誤與工作流程
點光源計算陰影(Point Light Shadows)
現在點光源支援整個場景的陰影計算, 更詳細的說明文請點這裡

預先計算場景的可視度(Visibility)
預先計算可視度讓你的遊戲在不支援硬體occlusion的遊戲機也能控制可視度。

動態模糊
大大地改善了動態模糊的品質 但是不影響效能

新的細節光照顯示模式(Detail Lighting View Mode), 更詳細的說明文請點這裡
  • 取代diffuse與specular的資訊,但是維持材質其他的參數,例如normal map、opacity mask、雙面等等屬性。
  • 這對於查看場景的照明,而不被diffuse的效果所分心很有用。
  • 而舊有的只顯示照明(Lighting-only)的模式還是很有用,你可以用來查看lightmap的品質。
角色間接照明
添加了新的角色間接照明的控制,讓你可以即時地微調間接光設定,你可以控制照明與陰影。詳細的參數介面請點這裡

頭髮的照明
  • 現在新增了一個新的參數,就是用來計算透明度(translucency lighting)的單一pass的技術。
  • 之前的技術是透過多次pass來計算,這會造成多層的物件,例如頭髮,產生過亮的問題。
  • 單一pass的技術跟多次pass照明相比只會用到一半的shader指令(instructions) 因此效能會更好。詳細的說明文請點這裡
舊版的UDK計算出來的頭髮有過亮的問題

Single-pass的頭髮計算效果

Normal Maps、間接照明與Lightmaps
Normal maps現在也會影響間接光照,這是利用簡單的lightmaps來計算。
舊版UDK的效果

新的功能的效果

其他新增功能:
  • 現在你可以在Content Browser按下右鍵選單就可以直接重新編譯材質
  • 新的材質串流系統可以節省記憶體,也更有效率地優先化材質
  • 部分支援非2的倍數材質的支援(譯者註: 之前輸入貼圖必須是要2的倍數,例如1024X1024,因此253X243這樣的解析度就不合法),但是MIP maps不能用非2的倍數,而DXT壓縮必須能被4整除。
  • 現在你輸出OBJ檔案,Vertex normals能被正確的儲存。
  • Terrain輸出現在支援有洞的Terrain。
  • 新的資產內容比較功能(ContentComparison)指令,幫助裡最佳化遊戲資產
  • 現在預設定Lightmass靜態陰影支援texture space filtering,這樣可以把反鋸齒柔化
  • 材質編輯器的Undo 與Redo變個更快了!
  • 添加了多個攝影機對粒子的偏移支援,與攝影機對mesh emitters偏移的支援
  • 在bone/socket 產生的粒子,現在支援了旋轉的mesh particles 跟bone/socket的朝向能夠正確對應了

新的說明文件:

MoveTexture的教學文, 請點這裡

FaceFX口形同步模組的使用說明文, 請點這裡


使用橫向捲軸攝影機的說明文, 請點這裡

[相關資訊]


2010/08/08

Unreal Engine功能介紹: 動態計算陰影透明度

Unreal Engine 3現在新增動態計算陰影透明度(dynamically shadowed translucency),可以用在以下兩種狀況

1)透明度的照明,是在場景中具有dominant lights 投射在可以接收動態光影的環境上。簡單的說,角色的頭髮現在可以在環境裡面計算陰影。


上圖中,並沒有開啟這個功能。因此,頭髮的透明度計算不正確;而下圖是有開啟透明度的功能。


在材質裡面如果要開啟這個功能是
bTranslucencyReceiveDominantShadowsFromStatic. 而在燈光環境裡面也有這個設定,你可以把頭髮開啟陰影的選項,或是就採用動態陰影 bAllowDynamicShadowsOnTranslucency,這個屬性預設是關閉的,因此如果你想要看到效果請務必把這個選項開啟。

效能的問題
開啟這個效果,在Xbox 360裡面每個角色會損耗大約.2ms的計算時間,這個功能還會增加四個材質lookups,且會增加某些ALU instructions到頭髮的shader上面,大概也會花費少量的GPU計算時間,大約.02ms。因為其實角色佔畫面的面積其實很小的。

限制
這種陰影只會投射在靜態的環境上,頭髮無法接受其他角色的陰影,也不能處理自身陰影(self-shadowing)。

2)透明度可以繼承dominant shadows,投射在不透面的表面上,這表示透明度可以使用動態陰影,投射在半透明後面的不透明的pixel上面。這個功能的目的是要讓地面mesh的動態陰影,當採用半透明混合模式時(translucent blend mode)與深度偏差alpha(depth biased alpha),能夠隱藏幾何體的縫隙。

如果沒有上述功能,半透明的mesh放在地上就會看起來像這樣:

如果有把功能啟動,看起來會像這樣:


要把材質啟動陰影計算的參數是bTranslucencyInheritDominantShadowsFromOpaque。請注意啟動這個功能會降低效能,因此你只針對地面的mesh做設定,而不是把所有的半透明材質都把這個選項打開。

效能的考量
如果是在Xbox 360 ,會有持續的.27ms計算開銷,如果還有添加材質的話還會增加.1ms,如果半透明地面mesh暫了畫面很大一部分的話。

限制
這個功能只對場景中打的是dominant lights光源有效,所以採用modulated shadows會沒有效果。

這個功能目前在PC平台上只對dominant directional lights有效;但是在遊戲機平台上面對所有類型的dominant light都有效!

透明度會使用在其後面的不透明物件的動態陰影,你可以在以下的遊戲截圖看到階梯陰影效果,但是如果半透明mesh背後的不透明mesh之間沒有對位很好就會出現計算錯誤。


[相關文章]
40 個你不能錯過的UDK (Unreal Engine)網站

2010/08/05

UDK新增功能:針對頭髮只計算一次pass


之前UE3在計算透明度的時候,只能計算多個pass。很不幸地,燈光的透明度,在多個passes的時候會在同一個mesh,多個圖層的位置產生照明過亮的錯誤!(如上圖)

八月份的UE3及將具有只計算一次pass的照明方式,讓頭髮的混合(blending)結果是正常的(如下圖)。

在SkeletalMeshCinematicActor裡,新的一次pass照明預設是開啟的,因此把SkeletalMeshCinematicActor放在場景你就可以預覽出效果。
你必須要把bUseOnePassLightingOnTranslucency這個參數在gameplay pawns裡面的script設定為true,才能得到這個效果,為了要讓照明計算一次pass,除了dominant light(或是在cinematics裡面的non-rim light)以外的燈光都會由單一個unshadowed SH light來計算逼近,但是在大部分的狀況差異並不明顯。感謝這樣的逼近計算,單一pass的照明大概只花了多pass照明的指令的一半而已,因此能更快速地計算頭髮!

[更多文章]

UDK新增功能:單一點光源就能產生整個場景的陰影

八月版的UE3及將會有單一點光源產生整個場景的陰影的功能。詳情如下:
  • 以上燈光是一盞PointLightMovable,能夠產生正確的陰影。
  • 任何點光源,帶有預先計算的陰影(可開關的或是一般點光源),而這樣的照明並不需要計算light map
整個場景會用6 90的投影算圖,因此對場景渲染來說是非常耗資源的,因此這種燈可被用來當做編輯器裡面預覽用,因為這種光源可以用來顯示燈光在被rebuild後陰影的位置。

[更多UDK功能介紹]