Wednesday, September 28, 2005

帥氣的微軟....

終於開始想寫東西..啟動了好久不見的DirectX
赫然發現....ㄟ?!怎麼SDK不一樣....
我的notebook上面的是DX9 SDK 2004 Summer版
PC上裝的是DX9 SDK 2005 June版
一看才知道2005版的DX9 SDK沒有directshow的sample
好吧..從notebook上抓過去..
居然..不能執行....

猛然想起凱文老師的話..2005年的DX9改為dynamic linking....
好吧..那也就表示我得找到新版的dll檔..不然就不能跑了

一找就發現....靠....微軟你太帥氣了....
DX9 Feburary版 -> d3dx9_
24.dll
DX9 April版 -> d3dx9_
25.dll
DX9 June版 -> d3dx9_
26.dll
DX9 Aug版 -> d3dx9_
27.dll

意思也就是..我用了Feb版compile出來的程式..要有24號
用Apr版compile出來的程式..得有25號
沒有就不給跑..不然就是要拿原始檔重新compile....

有沒這麼神啊..搞成dynamic linking還每一版就換一次dll檔的名字..T-T
我真是猜不透你啊....微軟

本來是很不想用..可是看在Unicode以及直接支援IME的份上..還是得回到微軟的懷抱..
誰叫我的目標是多國語系呢....

饒了我吧..微軟..我只是想寫個聊天程式啊....


先從聊天機能做起吧

越來越覺得很多事情其實就是要硬著頭皮踏第一步..才有第二步..才會有後來的發展
事前即便想很多..如果第一步始終踏不下去..那又怎麼可能有未來可言
當然為了避免投資錯誤導致全盤皆輸或是浪費了寶貴的時間..把事情切割成小模組是必要的方式
那麼..就先從聊天機能做起吧

如同之前對於巴哈姆特投票結果那篇的分析..聊天以及所謂公會(其實就是群組功能)的機制是否周全是相當重要的
遊戲可能不吸引人..但是這些社交功能卻是更可以主導人氣的最主要項目
而這樣的聊天功能..是共通的..所以先撰寫這樣的模組並不會是無謂的投資

然而..chat其實很好寫..第一學期的Lua課程我就已經在教如何用socket實作出類MSN的chat程式
以及可以跟人線上聊天的機器人(雖然它只會對某些話有反應)
socket是很好玩的東西..可惜最後沒有人想做網路相關的應用..果然大家還是視覺系的..喜歡玩圖學(ㄟ...離題了)
也因為chat太好寫..要做變化或者說要顯得突出就不容易
現在多半都會加入表情/情緒等能夠顯示個人心理狀態的功能
所以? 現在的社交功能就是 chat + group + emotion?
頂多加上PvP..也就是開扁..不管是為利搶奪/為情義/為奇檬子..大概就是上述功能的綜合..手段不管是明殺或是暗害都一樣
人與人之間的互動..除了開扁/對談/身分認同/情緒傳達..還能有別的嗎?
這可能得要參考小路未來的研究成果吧?
虛擬世界是這樣..但反觀真實世界呢?好像也差不多..差異應該是在於手段的種類多寡
那麼友情愛情親情這些情感又如何在虛擬世界中傳達?在真實世界中這些情感的傳達已經是個大問題了..何況是虛擬世界?
再者..情感究竟算不算情緒的一種也是個爭論

真該死..原本說要從最簡單的開始做起..這麼一搞....

又變得很複雜了......Orz

Wednesday, September 21, 2005

Online遊戲為何都是RPG居多?

線上遊戲的發展也超過五年了..
怎麼到現在還是RPG為主?
難道沒有廠商要出其他類型的遊戲?

現在青一色都是按了怪..然後我方角色就打個不停..
不能像action或是shooting那樣想打誰就打誰

說起來應該不能怪廠商啦..誰不想出點不一樣的遊戲啊
關鍵還是在網路傳遞的delay time上....
delay time的問題居然影響了遊戲類型的發展
不過短時間內似乎還是沒有在技術層面解決的可能性
(從其他層面倒是有可能....)

delay time造成的asynchronous問題雖然可以用預測或是加上delta time的方式解決..
但是delay所耗掉的時間並不會回來..
所以必須是某個程度上可預測的行為狀態才有辦法補救
這也難怪人物行動狀態的FSM在線上遊戲大行其道..
因為RPG系統裡人物的行為狀態是有限的..
戰鬥狀態->魔法狀態 -> ...
更重要的是..這些行為狀態的切換並不快..
玩家下決策..改變指令等行為的轉換極少發生在毫秒單位的時間差裡..這對預測系統而言是比較容易handle的
然而action或是shooting類互動對象轉換迅速..考驗手眼腦反應的遊戲..幾毫秒的delay就會出錯..
即便是預測..這種infinite state 也不可能靠著跳frame或是加delta time算的出來..補內插都沒用

雖然把client frame挪到local端來算可以解決這個問題..但是這樣會讓作弊的可能性大增
(但以現在外掛的氾濫..好像並沒什麼差啊XD)

有些遊戲標榜跳脫RPG格局的遊戲方式
例如:mabinogi, freestyle或是之前有一款看似FPS的遊戲
不過在看過系統後..應該仍不脫離這個限制
mabinogi用類似剪刀石頭布....雖然防禦的時候也要輸入指令
但是狀態的轉換還是在可預測的範圍內....
那款看似FPS的其實也不過是視角轉成first person而已-_-|||
頂多算是MMOFPG(沒有S)..哈哈
freestyle應該是比較類似making match的玩法....
配對後team玩team的(比賽嘛....)..跟主server間的互動應該很少
(跟麻將開桌的原理應該是相同的..基本上應該不太能算是MMOG)

不過matching本來就是我的遊戲的主架構..至少我覺得在兼顧遊戲性跟安全性的架構下..用配對的玩法是遊戲類型的可能性較大也比較有樂趣的
但是為什麼沒有廣為流行我也覺得很奇怪..觀察還不夠吧
類似石器跟crossgate(魔力寶貝?)那樣的配對那裡有問題呢?
是因為交易系統?組隊後的自由度問題?擬真度的問題?還是有其他問題?
需要再多一點點時間觀察....

至於上面提到的非技術層面能夠解決的方式..
就是利用遊戲行為學的研究來修改預測系統..
讓預測系統能夠預測各類型遊戲中使用者的可能判斷以提高預測準確度
例如在射擊遊戲中..如果能預測使用者閃躲子彈或是決定攻擊/閃躲的pattern
不用很長..只要能預測到200ms的話..應該就足以彌補現行網路硬體架構的lag
有點像跟棋王對奕一樣..預測是可以做到的..
但是對奕是選擇最佳化的手段..某個程度上並不算是預測..而只是為了贏
真正的預測還是得遵循行為模式的pattern以及個人化的特徵差異

可是..遊戲行為學....誰研究啊....f-_-a

3D Game Programming?

雖然跟自己想寫的東西有點差距....
但終究算是踏出了一步
希望用一學期的課程逼自己把延宕已久的遊戲寫出來

ARPG勉強算是第二志願的類型....
弄個接近TOP的模式也還算是可以接受..
不過還是得想個法子把企劃搞成自己要的類型

美術都給你做了..企劃也讓你那我還玩個屁?
倒是有點想把引擎換成torque....趁機摸熟也不錯
不過有點擔心大學的鳥事重演..哈哈哈哈

Let's WAIT & SEE!

最近想做的事的進度....

嗯....好多事..卻沒有組織也沒有計畫....唉
維持這樣走一步算一步的方式能走多久呢?

要督促自己一下了

Paper #1 (10%)
Paper #2 (20%)
Memex proposal (60%)
MEL for Automation (0%)
Quest3D fused with Lua (40%)
Making customized channel for Quest3D (60%)
Portrait for Game (0%)
Game concept (0%)
Torque (20%)
Design in Game (10%)
MSN AR (10%)

....不敢再列下去了....Orz.....

嗯!走一步算一步吧!

Tuesday, September 20, 2005

Design Optimization within Representation

剛剛跟基義老師討論了一下我所想的design optimization之於representation的概念
可能是自己講的很混亂吧..或是書唸得還不夠多
總覺得沒有表達清楚....

但是基義老師的意思倒是很清楚..
至少第一步的segment simplification就被乾淨地否定掉了....Orz

他認為設計的再現重視在如何以"最好"的方式呈現設計..而不在最簡單的方式
(這裡是我認為我沒講清楚導致誤會的地方..最好就是optimization啊)
基義老師倒是有提到在某些設計概念下..只要一隻筆..不需其他媒材就可以達到重現設計的目的
(這跟我想的就是一樣的啊T-T..我想知道的就是在"什麼"情況下..不論是題材或是設計的思考等)

這樣我就可以在最正確的狀況下用最精確的媒材重現設計....
這也就是我所想說的design optimization within representation

至於抽象思考的部份....我連想都沒想到呢..
....看來路還遠著呢..
多看點書後再去找他研究吧....


Wednesday, September 14, 2005

可憐的程式設計者 (或 可憐的我)

看了近來軟硬體的發展..自己深深地覺得..
學習程式語言的最大動力其實是來自於 - 「徹底的無奈」

從機車的微軟開始用力推銷「擦磨」(XML)開始..就有預感那應該是個大型陷阱的餌..
果不期然...「打虐」(.NET)就接著出現了..
本來想說自己窩在這邊玩digital media..怎麼樣也不會被這個風暴搞到..
無奈的是..現在還是得玩起「偉柏色米斯」(webservice)..為的是能夠與別人的媒材資料相互流用..除了"靠!"我嘴裡實在發不出第二個音
偉柏色米斯..不走打虐..就只剩下「湯姆貓」(Tomcat)..啊..還不是一樣難搞..就開發難度以及學習曲線..打虐還是可愛一點..
但是..無奈終究還是無奈....

再看看今年硬體的發展..除了冷汗..還有一種充滿悲情的無奈..
CPU的發展在希望保持Moore's Law的威信(他老預測到2010年)下..受限於過小的晶圓跟難以解決的高熱..只好從一顆A成兩顆..保住了他老的面子..
如果加上HT..我買一顆CPU黏黏散熱膏貼上主機板..開機進XP就看到四顆了..真是熱鬧ㄟ..
然後看看電腦裡另一個跟效能絕對相關的玩意..顯示卡..
ATI端出Crossfire..nVidia推SLI....
喔喔喔..當年的Voodoo2再現..又拿兩張顯示卡合體打人家一張
(不過這次比較公平一點..兩邊都可以拿多張來對幹啦..)

照這個發展..過不了多久CPU跟顯示卡GPU大概都是複數的吧..
打開我的電腦一看..16顆CPU+4張顯示卡..一個螢幕給一個人用這樣
喝..以後PC通通變成深藏不露的cluster了....
多顆是沒什麼鳥不起啦..看起來還滿爽的..
但是以往習慣寫單執行緒的偏安程式設計者們..不學著寫多執行緒的話會被使用者幹到翻..沒辦法像以前一樣期望硬體更新後自己的程式效能就會跟著進化
(想到以前寫視覺程式..效能不彰也只要補一句未來硬體進化後會有更快的更新率就沒錯..用300Hz的Pentium跑只有五張的更新率..換成了2GHz的P4後就破十張了..程式都不用改)
但是以後寫單執行緒程式都只有CPU的N分之一效能..換新硬體也沒用唷..因為分母N只會越大而已
(以現在3GHz做為瓶頸的話..進化也只是增加CPU數量來換取效能..單一CPU的效能永遠只有3GHz....
從四顆進化到八顆的話..只會更彰顯這個程式寫的真鳥)
這很慘啊..不把執行緒寫好的話..程式爛就一路爛到底了
悲哀啊..要能寫好執行緒..除了著名的死結(dead lock)要小心之外..更嚴肅的issue是job scheduling & merging
排程看來簡單..啊就工作分一分叫每個CPU都去做事啊
其實學問很深啊..從最簡單的RR(round robin)法到複雜的人工智慧預測..不同狀況有各種不同適用的排程法
最後把所有工作的成果組合起來更是令人腿軟....
(好在排程功能多半會被OS做掉..但是切割執行緒並不見得工作量就比較少..
不但要切的漂亮..切的精采..還要知道怎麼搭配自己的切割選用適用的排程法)
以後寫個程式的流程大概會像老師帶一個project一樣吧..要管可用資源..要會分工..要會整合..
然後未來資訊科系的先修課程就是PMP....
沒學過專案管理..你根本管不動手下的一票CPU+顯示卡呀!

奇怪..科技越發達不是會帶來越多便利嗎?
我怎麼有種越來越累的感覺....Orz

Tuesday, September 13, 2005

耶耶..開學了

燃燒中....

超high的....

這學期要加油呀!

目標就是「目標達成率 80%以上」
所以..目標的目標達成率64%以上
所以..目標的目標的目標達成率51%以上?

所以..目標的目標的目標的目標的....達成率....是

往零逼近?