Activision and Blizzard 兩家公司要合併了!!! 合併後的公司可以跟EA抗衡嗎？ 看來應該可以玩到更好玩的遊戲 
ref:
http://www.hollywoodreporter.com/hr/content_display/news/e3ic663debf321a4f2a52fc4e853c644f04
http://interactive.usc.edu/members/tfullerton/archives/008487.html
source:http://www.businessweek.com/innovate/content/oct2007/id20071012_041625.htm
遊戲中101條重要的使用性法則：
source:http://www.gamasutra.com/view/feature/1419/designing_for_motivation.php
我們都知道:當我們對一款遊戲的熱情消失後，這款遊戲的生命就消逝了。於是對於遊戲設計者來說，如何讓玩家可以在玩完遊戲之前都保持著強烈的熱情，甚至是熱情到玩個兩次三次，就是個重要的課題。
此篇文章的作者提出了一個 PNRC 系統來描述玩家熱情的變化。
P:Player State，玩家狀態。泛指玩家的技術等級或是角色裝備，意思就是玩家的強壯度。
N:Need，需求。當挑戰出現的時候，此時玩家的需要(像是打敗敵人)，也可以說遊戲的目的是什麼。
R:Reward ，獎賞。玩家通過挑戰後得到的獎賞。
C:Challenge，挑戰。遊戲給予玩家的挑戰。
所以，某個玩家p的熱情就可以表示為：
M(p) = N(p)*C(p)*R(p)
翻成中文就是：
熱情=需求*挑戰*獎賞
通常來說，玩家如果遇到很大的挑戰，那他的需求(Need)就也會很大，這時如果獎賞很小，那麼玩家的熱情就會變小。但是不可以一開始就把所有的值變得很 大，因為玩家的狀態是一個時間函數，它會隨著時間變化。這也就是為什麼所有遊戲都不會讓你在一開始拿到神兵利器的道理是一樣的。
接下來作者舉了幾個例子來說明這個系統。不過他的歸類我不是很同意XD
以星海爭霸為例，一開始的時候玩家什麼都沒有，所以很弱，而其他參數可以表示如下：
P:玩家狀態，弱。
N:需求-發展基地，強。
C:挑戰-保護自己的基地
一段時間之後，玩家的資源消耗殆盡，挑戰就成為追尋新的礦產。之後又轉變成交戰..的情況。 而作者認為一旦礦產耗盡，玩家就會立刻離開。唔，應該是大勢已去才會離開吧，有時沒礦產還可以靠著盟友支撐阿XD
不過我覺得阿，其實這邊一開始的需求就是打敗敵人，也就是說，礦產之類的都是其次。要不然怎麼會有scv快攻，或是異形蟲一出來沒多久整場戰役就結束的情形。
所以私以為應該是這樣：
P:玩家狀態
N:需求-擊敗對手，強
C:隨著需求(對手強度)改變
那麼會導致熱情很高的情況就是：高手對戰。 唔 這樣才比較合理阿！想想與跟自己程度差不多的對手交戰，那戰役真是刺激萬分!!!
source:http://aigamedev.com/modular-behaviors/motivation
從設計的觀點來看，近代的遊戲行為越來越複雜。因此實做出來的程式和資料就變得越來越難以管理。
模組化行為針對下列基本的問題提供了可行的解答：
人工智慧引擎通常都擁有這些功能，使用模組化設計也是一個達到這個目的的好方法。
圖(作者說之後會放大一點的圖)
Halo2 中所有行為的一個子集
實際上，當你在做一款遊戲的時候如果有下列現象，你就會注意到這是行為的模組化。
所以，讓我們接觸更多技術上得細節，這些模組化的行為到底長什麼樣子?
source:http://aigamedev.com/modular-behaviors
每個人都了解模組化在程式設計中的好處。實際上，今日所有的遊戲引擎都至少有著某種程度的模組化。但是在人工智慧的行為這領域中模組化意味著什麼？一般來說在實際的情況下它是如何完成這些工作？和 還有哪部份它可以增進的地方?
這系列的文章包含了人工智慧的模組化方面你所需要知道的事情
作者歡迎提問，只需留言在原網址下
(唔，標題的中文似乎有點怪….)
source:http://aigamedev.com/learn
遊戲人工智慧基本上與行為有關。你需要設計並且實做程式控制你的演員讓遊戲變得有趣。要達到這個目標，你需要這樣做:
有許多方式可以做到這些，但是在這個網站你將會學到一些在實做上最棒的技術。你將會很快地發現世界上所有專業的遊戲人工智慧開發者都使用類似的技術 – 但是會產生非常不一樣的結果。在這個網站上你將會從經驗中學到一些很重要的課程，而這會幫助你把事情做對。
一個好的遊戲人工智慧引擎基本上必須遵守下列的原則：
source : http://www.gamasutra.com/view/feature/1408/designing_usable_and_accessible_.php
這篇談到遊戲設計方面的Usablity 和 Accessibility 的問題。有些地方我覺得不太實際啦，像是做遊戲還要考慮到視障同胞們…
不過其他地方講的很好，作者也針對幾個問題提出設計樣式(Design pattern) ，不過文章中只有三種，其餘的請到http://www.helpyouplay.com 去看(目前作者已經收集了23種)。
不過應該要有人告訴這個網站的作者：網站設計也需要Usablity 和 Accessibility的。沒有rss ，都用圖代替文字…，雖然說文字也都寫在alt裡，這樣視障同胞的閱讀機就可以念出來，不過這種作法真的匪夷所思…
這個設計重點說穿了就是讓你的遊戲可以被更多的玩家可以接受。畢竟很多玩家可能反應能力比較差，眼睛可能不是那麼好，可能有點聽力障礙。此外環境也是一個問題，如果只靠聲音提示，那當玩家處於吵雜的環境或是不能開啟聲音(半夜偷偷玩?) 的時候，那就等於沒用。
此外，還有難度等級的設定，可以讓一些可能不是那麼有天份的玩家不會一而再再而三的卡在同一個地方，當然也是有例外啦，有些遊戲就以虐待玩家出名。例如無窮無盡的迷宮(仙劍XD)，或是超難的關卡(炎龍系列:P)。
從以前到現在可以看到很多設計都開始遵循所謂的設計樣式，像是教學關卡的設計(玩家不想等，玩家想要現在就開始玩!!!!)。或是以往載入式的世界，現在大多走向無縫式的世界(當初wow宣佈他們採用無縫式的設計時，很多人還很擔憂呢:P) 不過這點後來證明的確是個很棒的設計。但是遊戲的設計還是有很多細微之處，就算是採用漸進式的教學關卡設計，有些遊戲也還是做的很差。wow跟星海的教學關卡都做的很棒，不會讓人家有種：我正在教學關卡，滑鼠趕快點一點，知道些什麼，然後，就開始玩阿!!!
再回到主題， 諸如此類的議題還有很多值得參考，有興趣的人可以去他們的網站仔細看看，他們會針對每個問題提出解決方法，並且拿實際遊戲的作法當作範例喔!!
source:http://www.gamasutra.com/features/20070419/garcia_01.shtml
這篇值得紀錄一下。這篇主要在比較如何快速地從硬碟或是DVD光碟機中把檔案載入。作者一共比較了四種。
程式碼我就不貼了，請連回原本的網站看。
1)正統可攜的方式(傳統c fopen的方式)
2)使用win32 api
3)File Memory Mapping
4)非同步IO
測試環境：
而作者為了怕作業系統cache這個檔案，還自行撰寫一個程式於讀取後清掉cache。這每個測試都測試過十次。
底下是測試數據，作者使用了一個100 MB的檔案。
硬碟讀取部份：
| 硬碟 | Min(MB/s) | Max(MB/s) | Average(MB/s) |
| ANSIC | 47.847 | 48.828 | 48.527 |
| W32 | 47.483 | 48.852 | 48.497 |
| MMapped | 45.830 | 48.828 | 48.190 |
| Async I/O | 48.239 | 48.852 | 48.700 |
DVD部份：
| DVD | Min(MB/s) | Max(MB/s) | Average(MB/s) |
| ANSIC | 2.381 | 2.386 | 2.383 |
| W32 | 2.383 | 2.390 | 2.386 |
| MMapped | 2.524 | 2.528 | 2.526 |
| Async I/O | 2.384 | 2.408 | 2.399 |
從上面的結果你可以看到，硬碟部份差異不大。作者建議使用非同步IO的方法，一方面是非同步IO的方式是最穩定的方式，另一方面是可以同時啟動多個I/O的request。
結果…其實作者建議搭配另一種方式XD。其實很容易聯想啦，就是壓縮資料，畢竟在I/O的時候 CPU是處於idle狀態的。作者在此處利用了ZLIB而不是使用LZO。因為LZO並不支援串流格式。100MB 的資料被壓縮成64 MB。
底下是結果：
硬碟部份：
| 硬碟 | Min(MB/s) | Max(MB/s) | Average(MB/s) | Improvement % |
| ANSIC | 59.067 | 69.384 | 67.558 | +39% |
| W32 | 67.797 | 69.396 | 68.446 | +41% |
| MMapped | 52.247 | 53.562 | 52.980 | +10% |
| Async I/O | 68.634 | 69.832 | 69.242 | +42% |
DVD部份：
| DVD | Min(MB/s) | Max(MB/s) | Average(MB/s) | Improvement % |
| ANSIC | 2.469 | 2.476 | 2.472 | +3% |
| W32 | 3.437 | 3.467 | 3.455 | +44% |
| MMapped | 3.713 | 3.724 | 3.720 | +47% |
| Async I/O | 3.464 | 3.475 | 3.470 | +44% |
結論)
作者推薦使用非同步分式，雖然他在每個特定的情況下都不是頂尖，但是他是最平均的方法。並且在使用壓縮格式的檔案方面也是最快的。
source: http://www.gamasutra.com/features/20070301/schofield_01.shtml
翻好的：http://gamedev.tw/gamedev/modules/news/article.php?storyid=311
這篇放到都爛了阿~~~ 也正式宣告沒有存檔了 T_T
今日被使用vc 2005編譯boost 1.34 出現的一大堆c4819 錯誤搞得昏頭昏腦，到現在還不知道該怎麼解決最好….
所以晚點再來把感想寫下來.
最新留言